devopsy.kinsta.cloud

Tag: resilience

  • Empowering Developers Fuels IT Resilience and Business Transformation

    Empowering Developers Fuels IT Resilience and Business Transformation

    Developers are feeling the brunt of global economic pressures on their organizations to move digital transformation projects forward while having to do more with less. Adding to this pressure is the explosion of technologies like generative artificial intelligence (generative AI) and edge computing, which have made infrastructures more interesting and possibly more complex. The overall result is an increased mental load for developers tasked with bringing innovation to life while minimizing all the added complexity. And it’s DevOps teams who are carrying the weight of ensuring seamless integration, deployment and automation of new technologies. It’s incumbent upon IT leaders to give developers and DevOps teams a simplified, trustworthy data architecture to ease this burden if they want their modernization efforts to thrive.

    It’s a difficult juggling act IT leaders know all too well — controlling costs and improving efficiency while increasing agility and resiliency. Management, budget and technology challenges have been causing digital transformation projects to be put on pause to avoid potential drawbacks or failures. In fact, 68% of organizations facing modernization challenges were forced to push digital transformation goals back by more than three months, with delays costing organizations $4.4 million on average.

    Despite the hurdles — many of which were brought on by the COVID-19 pandemic — enterprises continue to focus on modernization: Nearly 60% said their key digitization goal is to improve business resilience and add AI-powered efficiency in the face of the evolving global economy. Recent research revealed that 53% of executives have already deployed some form of generative AI, with 45% forecasting that integration of automation and AI tech will catalyze a major transformation in their industry within the next five years.

    The call to empower developers and DevOps teams is loud, and IT leaders should heed it.

    Putting Developer Empowerment at the Top of the IT Agenda

    Developers and DevOps teams must constantly adapt, from keeping up with changing market demands and customer expectations to navigating technology stack intricacies across a myriad of platforms, tools and frameworks. They also need to stay updated on the latest security practices throughout the development life cycle. Through it all, the pressure to innovate rapidly looms large.

    Given their central role in today’s business, empowering the people who build and run modern applications must be a top IT investment priority. These investments have a synergistic payoff. They not only strengthen developers and DevOps teams, but the entire business reaps the benefits:

    • When given the support and tools they need to successfully embrace new technologies and create new services, developers are empowered to take on new projects, implement new technologies and take advantage of growth opportunities. For example, cloud-based solutions, such as database-as-a-service (DBaaS) and containers-as-a-service (CaaS), offer developers vast opportunities to enhance their agility and efficiency to drive competitive advantage for their organization.
    • Additionally, low- and no-code platforms, AI coding assistance and serverless computing allow IT to create opportunities for other business units to build their own services. This reduces reliance on developers for simpler tasks that line-of-business teams can accomplish themselves, freeing developers to focus on expediting innovation and helping to increase productivity across the organization.

    Freeing Developers to Innovate With AI Increases Their Productivity

    IT spending on AI is sure to evolve over the next few years. IDC predicts generative AI spend will reach $143 billion in 2027. Gartner recently stated that “while GenAI has not yet had a material impact on IT spending, investment in AI more broadly is supporting overall IT spending growth.” IT teams are working on their AI strategy and still need to better understand the role of generative AI or large language models (LLMs) before fully adopting them across the business. However, if one thing is clear to IT leaders today, it’s that AI can make developers more productive and speed up the pace of software development.

    Furthermore, with AI, software development can be more efficient, accurate and adaptive, leading to faster development cycles, higher-quality applications and better user experiences. AI tools can assist developers in writing complex code, detecting and fixing issues faster and automating the testing process. AI can also offer many ways to enhance the overall DevOps process by automating repetitive tasks and analyzing workflow data to optimize processes.

    As organizations aim to modernize and take advantage of generative AI, IT leaders should empower developers and DevOps teams to use it to simplify how they develop, deploy and run applications. By prioritizing the adoption of new technologies, such as cloud-native IaaS, AI, edge, mobile, serverless and low- and no-code computing, IT teams can help make DevOps teams more agile, cut down on costs and speed innovation.

  • Google Taps Nobl9 to Improve Services Reliability

    Google Taps Nobl9 to Improve Services Reliability

    Google announced this week it has added a capability for tracking reliability based on how service level objectives (SLOs) are being met that is based on a platform developed by Nobl9.

    Nobl9 launched a Nobl9 Reliability Center earlier this year that provides a single source of truth about the state of reliability in an application environment. Included in that platform is SLOgpt.ai, a generative artificial intelligence (AI) tool for programmatically creating SLOs and launching natural language queries to determine how well they are being adhered to across a distributed computing environment. The generative AI tool developed by Nobl9 is based on Vertex, a foundational large language model (LLM) provided by Google.

    Kit Merker, chief growth officer for Nobl9, said the generative AI tool also makes managing SLOs more accessible to a wider range of stakeholders.

    The expansion of the alliance with Google is the latest in a series that will make it simpler to manage SLOs across multiple ecosystems, including, most recently, partnerships that have been established with Microsoft and Cisco, noted Merker.

    The Nobl9 Reliability Center is already integrated with more than 50 DevOps, observability and incident management tools. It collects metrics, events, logs, traces and alerts to track incidents, releases, rollbacks, runbooks and other documentation. Those integrations will make it simpler for IT teams to create SLOs using historical data that would otherwise be challenging to define from scratch.

    In time, there is no doubt tools for managing SLOs will become more widely available, but given the dependencies that exist between applications and systems, DevOps teams will need an approach that can be employed across hybrid IT environments, said Merker.

    In general, as more microservices-based distributed applications are built and deployed, it’s becoming more challenging to maintain SLOs across them since they have many more dependencies than legacy monolithic applications. Each feature and application programming interface (API) added over time can adversely impact performance and reliability. The challenge is that it’s not so much that any given service will outright fail as much as it is determining where degradations are occurring that result in SLOs not being met.

    Each IT team needs to provide some sort of objective benchmark that assesses their overall effectiveness at delivering application services by making it simpler to track whether SLOs are achieved and maintained. Not every service needs to necessarily meet a stringent requirement, but IT teams do need to have confidence in the fact that, on average, certain levels of service are being consistently maintained.

    When it comes to SLOs, the challenge is first determining which dependencies might impact the level of reliability that can be maintained in the event of an outage and then, second, making sure whenever necessary workarounds—such as rerouting application programming interface (API) calls to other services—can be easily invoked.

    SLOs, of course, as a concept, have been around for decades, but with the rise of digital services that span multiple organizations, the level of reliability DevOps teams are expected to provide is now being written into business contracts. As a result, the overall level of stress related to managing SLOs is only going to increase in an era where businesses have never been more dependent on software.

  • Leaders in Resilience See ROI From Observability

    Leaders in Resilience See ROI From Observability

    Observability is maturing throughout the software industry. Observability is often defined as merging metrics, logs and traces to get a fuller picture of an application’s state. This can help pinpoint disruptions or security incidents and offer a clearer path to remediation. Observability is touted to advance the application monitoring practices of yesteryear, but are investments paying off?

    According to recent findings, many organizations are using observability tools and seeing a positive outcome. A full 73% of organizations reported using observability tools for over a year. And impressively, 86% of observability leaders said the ROI on their observability tools has exceeded their expectations. The practice appears to be paying dividends for organizations that have gone “all-in” with mature observability processes.

    The State of Observability 2023 report released by Splunk demonstrated how observability leaders are reaping a positive return from observability tools. According to the report, observability is helping to meet performance expectations, avoid downtime and enhance resilience in general. However, not all organizations are on the observability maturity bandwagon. Below, we’ll examine some of the key trends from the report and consider the benefits of refining your observability efforts.

    Now that observability is more commonplace, dedicated roles are emerging to support these initiatives. In fact, 87% of respondents now employ specialists who work exclusively on observability projects. Site reliability engineers likely make up a portion of these experts, as observability data can be used to advance efforts around meeting service-level objectives (SLOs).

    But although observability might be more common than a few years ago, not every observability practice is mature or standardized. Just 40% have a formal approach to resilience that has been institutionalized organization-wide. Because of this, only 43% are confident in their team’s ability to meet its application reliability and performance objectives. It should be noted that this number increases significantly for those with more mature observability adoption, which we’ll expand on below.

    Furthermore, not all applications are cloud-native. Organizations reported operating and maintaining, on average, 165 internally developed business applications, half of which are hosted in the public cloud and half of which are on-premises. Due to the persistence of legacy modalities, observability tools must continue to support a hybrid architecture if they are to be comprehensive and useful.

    And although we’ve previously covered how many organizations are drowning in a sea of observability data, observability leaders now say their ROI on observability tools far exceeded their expectations. Perhaps this indicates that, with more open standards, analysis centralization and fewer false positives, teams are finding ways to avoid observabiliy tooling sprawl.

    Lastly, the report unveiled desires to loop AI and ML into the observability pipeline. In fact, 66% of observability teams already use AI/ML, while 26% are in the process of deploying the technology. And 91% said AIOps is an important enabler of their observability goals. Certainly, AI is becoming a pervasive instrument to accelerate many areas, including observability.

    Benefits of Observability

    An impressive 64% reported that their investment into observability has exceeded their expectations. So, what are some of the top benefits of observability? Well, the report found the topmost benefits to be areas like decreasing problem detection and resolution times, identifying “true positive” incidents, and enhancing application security.

    Observability is being deployed as a tool to evolve traditional security efforts, as it uncovers a deeper understanding of application behaviors. This can help security teams correlate errors to specific diagnoses and spot potential threats in a quick manner. As such, 59% said observability helps them uncover security issues thanks to the intelligence capabilities of observability solutions. And 55% say they can uncover more security vulnerabilities thanks to the visibility afforded by observability.

    Observability can also be used to improve visibility into hybrid architectures. A full 86% said it’s important to have flexible observability solutions that cover hybrid architectures, though half identify this as an area for improvement. Although we like to think that cloud-native development is the status quo, many enterprises still oversee a mixture of on-premises, private cloud and multi-cloud environments. A unified, agnostic observability layer is thus essential to peek into all these disparate environments to grapple with disparate data outputs.

    The Leaders of the Observability Pack Win

    Service interruptions can have negative consequences for organizations, including lower customer satisfaction, loss of revenue and loss of customers. In fact, 76% of respondents reported downtime can cost up to $500,000 per hour.

    Thankfully, observability has emerged to help improve overall resilience and avoid these negative repercussions. But, to truly reap the benefits, you must have a mature practice in place. As defined by the report, “observability leaders” have a more formal approach to resilience and have standardized this across their organization. And 89% of those leaders are completely confident in their ability to meet their application availability and performance requirements. The catch-22 with observability is that you must invest more energy into formalization and knowing when the effort is worthwhile is a moving target.

    A solid observability practice is supported by standardized metrics, logs and traces across the organization. Furthermore, to make observability behave correctly, you will need flexible tooling that can leverage data from multiple sources, such as the network, infrastructure, servers and databases.

    The State of Observability 2023 report surveyed 1,750 observability practitioners from around the globe, making it the most extensive study on observability to date. For more insights, you can pick up a copy of the report behind an email gate here.

  • Why You Need a Multi-Cloud and Multi-Region Deployment Strategy

    Why You Need a Multi-Cloud and Multi-Region Deployment Strategy

    As I began writing this article, I encountered some technical challenges in my attempt to provision three cloud providers in three separate regions to simulate multi-cloud and multi-region deployments.

    I couldn’t get one of the regions to behave as I expected when provisioning the environment. As it turned out, the region (and by association, cloud) was down due to a cut undersea cable, and it would take several weeks until the outage was mitigated.

    Fortunately, there are plenty of clouds in the sky to choose from, but this experience emphasized the importance of multi-cloud redundancy, especially in a production environment.

    This article examines the benefits of adopting a multi-region and multi-cloud deployment strategy for better resiliency, regulatory compliance and optimal user experience.

    Resilient Reasons to Choose Multi-Cloud and Multi-Region Architectures

    The first reason to choose a multi-cloud or multi-region environment is for data resilience. When our data is in a single region or on a single cluster, there is a good chance that you will experience data failure. You need a mitigation strategy if you want to keep the data lights on 24/7. These strategies fall into two buckets: Multi-region and multi-cloud.

    We first need to define the differences between multi-cloud and multi-region. The architectures are simply the implementation details of how we plan for one versus the other. However, depending on your database provider, those details can represent a significant time investment, which we’ll look at later.

    Multi-Region

    With multi-region, we typically deploy our applications to globally distributed regions. However, regional deploys are subjected to physical faults. Inclement weather, political unrest, acts of foreign or domestic terrorism and other physical variables have all led to regional outages in the past.

    Regardless of the cloud, the regions are exposed to similar physical faults. Instead of losing your data, we can switch to another region to handle the workload. Even though much as our industry hates latency, it is always preferred over loss.

    Deploying to multiple regions allows for failover handling. If the Sydney region goes down, Singapore may still be online. It would be a globally bad day if the same physical faults simultaneously impacted Frankfurt, Sydney and Seattle, for example.

    Multi-Cloud

    Physical faults are only one of the problems that public and private clouds encounter. User error, poorly configured networks and even banal errors can have substantial consequences that impact entire clouds, either from the provider or the user.

    In these circumstances, regional failover won’t help you. An expired certificate, accidental deletion or disabling the wrong port will take you offline, regardless of whether you’re in Seattle or Sydney. If that happens, someone somewhere is most definitely awake and is likely very unhappy.

    Choosing a multi-cloud configuration protects you from these types of faults so that if Google, for example, has interruptions, AWS is still online—or IBM, Deutsche Telekom, OVH or Hetzner.

    The Correct Answer: Deploy Both!

    Multi-region is a go-to method to mitigate against mostly physical faults. Multi-node clusters in each of those regions handle general data corruption or failures on a more granular level.

    Multi-cloud is a go-to method to mitigate configuration or software-level faults, which are not that uncommon.

    The correct answer is to blend the two, working within operational cost constraints and general survivable requirements from regulatory and business objective use cases. For example, I do want access to my heart-rate data from two years ago, but the order of browsing across Amazon shopping is less important.

    Regulatory Reasons for Multi-Region Architecture

    Apart from data resiliency, most companies serving a global market are subject to a number of geopolitical influences, as well. Most users will be familiar with the GDPR regulations ensuring European data stays on European soil. Further regulations require the ability for government oversight to request data at will from service providers, which requires its own set of reasonable isolation from those not in those jurisdictions.

    Using a multi-region database provider allows companies to ship single binaries of software without creating isolated applications for different countries—a practice that was the norm not too many years ago.

    Performant Reasons for Multi-Region Architecture

    Co-locating data and access provides the optimal pathway for getting a user’s data to the end destination. It goes without saying, but the less copper your data has to traverse, the faster the experience will be for your users. Retention and regulation aside, in many cases, you need to mitigate latency caused by region separation.

    It’s not just the individual user’s data. Imagine a sales enablement platform where an account executive needs to manage all of APAC or EMEA. If these accounts are optimally stored for reads on geo boundaries, you can remove seconds of delay between page navigations for your account manager. We all know how much account executives like to click!

    Choosing a DB Provider With Multi-Region and Multi-Cloud

    At this point, you should be convinced of the benefits of multi-region and multi-cloud deployments. But at what cost? Creating replication, failover, logging and synchronization mechanisms is a big, expensive ask. Even with deployment tooling, coordinating all the pieces for multi-region deploys is still a significant operational lift, let alone multi-cloud, where variables in APIs come into play.

    Choosing a single provider that deploys across regions and clouds means you get to benefit from their collective experience while reducing a significant burden.

    Having a database provider offer one-click multi-region deploys is the way to go, but you still need to handle the data access layer. The role-based access, federation and other settings that enable your developers still need to be distributed along with the underlying data sources.

    You need a provider that makes it simple to deploy the same configuration for horizontally scaled instances, leaving you to pick your geo router of choice to distribute the request to the nearest point of presence.

    Closing

    Multi-cloud and multi-region deployments provide significant redundancy, scalability and flexibility. Not only does this enable faster access times and improved reliability, but also provides the flexibility required to adapt to disruptions or unpredictable increases in traffic.

    Deploying multi-cloud and multi-region is no small feat–but the peace of mind and security it provides make it worth the effort.

  • Predicting, Preventing and Resolving Incidents With AIOps

    Predicting, Preventing and Resolving Incidents With AIOps

    IT operations teams, site reliability engineers (SREs) and service providers are on a mission to scale across geographies, expand their digital services and create new experiences for customers. Amid this drive, their backend IT systems are getting more complex. This hinders visibility into applications and makes monitoring and troubleshooting cumbersome. With heightened competition in the market, businesses cannot afford to take hits on revenue or customer experience scores due to issues stemming from their IT stack, such as unknown outages, increased incident management times and data replication.

    Infusing artificial intelligence capabilities into IT operations (AIOps) can raise efficiency through automation, improve security and make a significant impact in warding off downtime. AIOps uses machine learning (ML) to enhance IT operations such as performance monitoring, event correlation and analysis. With AIOps, IT teams, SREs and service providers can predict and prevent outages before they occur and resolve them automatically. Moreover, AIOps uses ML to analyze current and past data to make precise predictions, reducing costs and speeding up return on investment (ROI).

    AIOps Implementation

    Launching AIOps requires a unique approach depending on your organization, its capabilities and needs. This article provides a three-step implementation strategy to help your organization detect incidents before they impact users, automate responses and prevent recurring issues.

    AIOps 201

    Fig: AIOps implementation approach

    With the advanced ability to collect and analyze IT operational data, AIOps is an asset for a range of actions and solutions. When implemented effectively, AIOps can enable IT teams, SRES and service providers to significantly reduce application outage costs by over 60% within a span of 24 months.

    Getting Started With AIOps: Predicting Outages in Applications and Infrastructure

    The AIOps platform can be leveraged by IT teams, SREs and service providers for data gathering, analysis and generation of useful insights. It is designed to enhance operational efficiency, offer predictive alerts, reduce mean-time-to-identify (MTTI) and mean-time-to-repair (MTTR) as well as prevent service outages.

    Recommendations

    • Prioritize onboarding mission-critical applications, such as network monitoring, fault management and service assurance onto the AIOps platform.
    • Determine the best method to ingest data from the different monitoring tools. For example, build APIs, use pre-built connectors, use MuleSoft to automatically collect data from different systems, etc.
    • Choose the right ML model based on the types of raw data, e.g., use an anomaly detection model to identify issues from a dataset or use a time-series model to understand patterns based on historic data.
    • Use closed-loop automation to resolve low-risk issues; for example, automate disk clean-up issues or Java Virtual Machine (JVM) bounce for JVM-related issues.

    AIOps platform

    Fig: AIOps platform

    Assess Your Organization’s Adoption of AIOps to Gain Value

    Organizations contemplating AIOps as a strategy should first evaluate their current maturity and then chart out a path to make the best use of AIOps, which is automated resolution. There are three levels of maturity in AIOps adoption.

    Maturity

    Recommendations

    Level 1: Dashboard

    • Remove operational siloes by integrating the application data sources into unified architecture and ITOM tool.
    • Collect logs from applications and set up alerts that are commissioned to command centers to escalate as per the defined SOPs.

    Level 2: Alarm & Recommend

    • Implement supervised or unsupervised ML algorithms on the unified data to derive insights.
    • De-duplicate and correlate alerts and events through noise reduction to alleviate alert fatigue

    Level 3: Automation

    • Correlate incidents and events with business impacts by leveraging ML algorithms.
    • Trigger autonomous remediation bots spontaneously based on the predictive insights to fix incidents that are likely to happen in operations.

    Identify Applications for the AIOps Platform

    Conduct an AIOps workshop with key stakeholders to narrow down the list of apps and prioritize them for evaluation. Apply specific criteria to prioritize applications that meet the required onboarding standards.

    Recommendations

    • Prioritize onboarding critical apps and outage-causing apps on the AIOps platform.
    • Tag the data e.g., metrics, logs, inventory, topology, to ease the browsing, searching and visualization of data across the distributed analytics repository.
    • Setup an AIOps service and support team, as there is a constant need to maintain and update the platform features
    • Collect all relevant logs, metrics and traces along with data collected from ITOM platforms. A poorly constructed AIOps platform will show incorrect insights and inaccurately reflect the activities in the IT environment.

    Onboard Applications and Leverage AI to Predict and Resolve Issues

    To initiate application onboarding, monitoring tools must be set up to collect data for ML models. Predictions from the models can be integrated into visual dashboards for analysis.

    Automate AIOps

    Fig: Application onboarding

    Recommendations

    • Route both the on-premises and cloud-centric data to the AIOps platform. This will facilitate the prediction of issues in both the environments.
    • Use ML models such as Prophet, Nelson, Arisma, Random Forest, etc., to forecast the time series data, correlate the events and predict thresholds.
    • Choose secure connectors to transfer data in/out of the AIOps platform. For instance, any log flowing into the platform must be sent over transport layer security (e.g., syslog) or HTTPS (API endpoints).

    By implementing AIOps, service providers can successfully reduce the MTTI and MTTR, attaining a 63% reduction in outage costs for applications within 24 months, a 90% reduction in false-positive alerts and a 400+ hours reduction in downtime per annum.

    Ramesh Ram (Assistant Vice President), Sreedhar S K (Associate Director), Sakthivel D (Director), and Rohit Karthikeyan (Manager) also contributed to this article.

  • How To Build Anti-Fragile Software Ecosystems

    How To Build Anti-Fragile Software Ecosystems

    Just as organisms are susceptible to diseases and viruses, software systems are susceptible to hacks and errors. And within many complex interconnected systems, a minor bug could have a cascading effect across an entire organism, causing it to break. As such, increasing the resiliency of a software ecosystem is something engineers continually strive for. But how do we get there?

    One concept to consider is anti-fragile. Being anti-fragile refers to the ability of a system to thrive in adversity and adapt to change. Specifically, with regard to software, anti-fragile can equate to responsive coding practices, such as auto-scaling or default backups, to mitigate unforeseen events. Chaos engineering, for example, is one method to expose edge cases and build with adaptability in mind. And with the introduction of intelligent automation, often fueled by machine learning (ML) and artificial intelligence (AI), it’s becoming more and more feasible to build anti-fragile software systems.

    I recently met with Asim Razzaq, co-founder and CEO of Yotascale and former head of platform engineering at PayPal, to discover what it takes to build anti-fragile software. According to Razzaq, anti-fragile represents the next evolution of reactive, resilient software systems. And introducing anti-fragile concepts into your application networks can be done with just a few (relatively) simple steps. Below, we’ll define what anti-fragile is and see how this concept can be applied to software development and DevOps.

    Understanding Anti-Fragile

    As the adage goes, “What doesn’t kill you makes you stronger.” And it’s true—many natural systems tend to thrive under inhospitable conditions. As described by Nassim Nicholas Taleb in the book ‘Antifragile: Things That Gain from Disorder,’ anti-fragile systems thrive in adversity. For example, consider how human muscle grows under stress and load. Immune systems similarly adapt and respond to new viruses and improve the body’s resilience over time. So, how does this relate to software development?

    Well, organizations need to develop highly-tolerant software systems to meet rising digital consumer expectations. Especially when under extreme loads, systems must be elastic to adapt and survive. To meet high user demands, as well as specific service-level objectives (SLOs) and agreements (SLAs), most software companies are already investing in cloud-native tools that improve reliability. For example, a hallmark of site reliability engineering (SRE) is introducing automation to enhance the stability of applications.

    One example of gauging anti-fragile in software environments is chaos engineering, says Razzaq. Chaos engineering is the act of throwing a wrench into the machine. You randomly introduce bugs and malformed requests and attempt to create as much havoc as possible to see what happens. This could mean pulling out cables and restarting servers to gauge how software systems respond.

    “Software that can respond the best adapts the best,” said Razzaq. For example, if you manually remove a few nodes from the cluster but the system knows it needs seven to function, it could automatically spin up additional nodes. Or if the whole cluster goes down, ideally, the system would automatically restart and scale to the necessary requirements. In essence, anti-fragile software systems can understand and adapt to new environments without much, or any, human input.

    Tips to Construct Anti-Fragile Software Systems

    So, how can we construct anti-fragile software systems — especially when real-world challenges are often unpredictable? Razzaq shared helpful advice to consider when crafting anti-fragile software architecture.

    1. Start With Your Most Critical Systems First

    First, introduce chaos engineering to your most absolute critical systems. Define these vital components at the heart of your product which must remain functional. For a payments processor SaaS, for example, this would be the infrastructure supporting its transactional engine, such as the login and payment microservices.

    2. Determine How to Test Fragility

    Once you’ve identified this critical infrastructure, figure out how to test for fragility in your environment. Introduce chaos engineering to the component to see how it behaves. For example, returning to our payment platform example, this may include switching off a payment transaction type to see how the system functions in an extreme scenario.

    3. Decouple Components

    If systems are too closely coupled, errors and outages can ripple across multiple software services. To avoid that, it’s a good practice to prevent tight coupling between components—especially between critical systems and non-critical ones.

    4. Introduce Alternate Paths

    One method to decouple is by introducing alternate paths. For example, if a credit card verification component goes offline, the system should naturally accept other forms of payment and automatically suggest another form, such as a bank transfer. If all systems are down, the system could still accept unverified payments in a queue and let this continue until the threshold reaches a certain risk level.

    5. Learn From Past Events

    The next frontier of designing anti-fragile architecture is developing self-learning, autonomous systems. Of course, there is a limit to how automation can respond to unforeseen issues. But by feeding a machine learning model with more and more experiences, it could deal with untested new scenarios more gracefully. Of course, AI has the potential to make harmful decisions and even introduce unintentional bias, so organizations should have accountability for the algorithms they oversee, cautioned Razzaq.

    Benefits of Building With Anti-Fragile in Mind

    The goal is to able to thrive and function even under duress. By identifying the elements of core infrastructure to keep alive and putting it through the wringer, you can discover frailties before they cause significant consequences. And by decoupling components and introducing alternate paths, software systems can be better equipped for whatever may come. Uplevelling system operations with increased automation and AI is likely the future of constructing more fault-tolerant applications.

    “Software is everything in this day and age,” said Razzaq. “It increasingly plays a critical role in life-enhancing capabilities.” As such, the end benefits of developing an anti-fragile style could have hugely positive effects. In health care situations, it could make a difference in saving lives. For other less dire scenarios, increased fault tolerance leads to less lost revenue during peak traffic times and more consistent end-user experiences.