Unfortunately, it is not disaster recovery, high availability, or cloud technologies that are inherently difficult to understand, but rather the action of implementing them for software applications that is difficult. The unique method of implementation for a microservices architecture is explored. Regulatory compliance doesn’t stop just because an effective disaster recovery requirement is tough to satisfy for infrastructure unique to sleek microservices. The high-availability location transparency bliss offered by a cloud solution is appealing to a security engineering department. However, the headache starts when the technology presents a handful of undesirable surprises that leak RESTful microservices to the outside world. These are the challenges that post-SOA cloud-resident robustly scalable applications will need to address and overcome. The goal is to explore several popular methods of accomplishing these tough objectives so that engineers can further research the most practical solution. An innovative implementation that leverages Service Bus relays as an elegant disaster recovery solution while enforcing a strict subnet where RESTful microservices solely live will be discussed. The curiosity lies in the atypical experimentation beyond basic gateways and the facility of using such simplicity while still answering day-to-day software development infrastructure challenges for applications we build. Resilient full-service web proxy service crashes and delivery latency switches by harnessing the microservices pod health will also be discussed [1].

A failure in any crucial business application can wield significant ramifications, which can result in customer dissatisfaction, loss of revenue, brand damage, and compliance sanctions. Industries expend considerable resources and capital to ensure that contingency plans and systems are in place to circumvent lost operations. Traditional application architectures deploy a myriad of defensive infrastructures connected to the perimeter of an application and its network. Typically deployed in the form of a DMZ, this critical perimeter is essential for the demarcation of security and trust levels as defined and enforced by compliance and governance. Here we present the traditional and modern security models and frameworks available for applications, examining their viability in cloud-managed platforms and assessing their deployment in chronically changing microservice architectures. The overall aim is to examine current cloud platform tooling for disaster recovery and application-level security to identify the broader set of effective capabilities in numerous scenarios.

Microservices are an architectural style increasing in popularity, as is the adoption of containers and container management systems. However, the effective maintenance of security and disaster recovery continues to pose a significant challenge. It is the shared responsibility between the cloud platform, its components, the customer, and the applications that run in the cloud that makes the landscape complex. There is no single panacea that delivers security or resilience of applications in distributed systems, especially in rapidly evolving ones like microservice deployments. At present, tools, techniques, and patterns are still being discussed and developed. Nor is there a one-size-fits-all solution applicable to all running applications; each possesses unique attributes around their participation in specific business processes and their requirements for data security, service levels, recovery point, recovery time, and so forth. As organizations increasingly consider cloud deployment for an ever wider range of business applications with varying vital importance to their economic health, the need for the discussion and development of cloud infrastructures and applications that integrate security best practices persists [2].

1.1. Background and Context of Microservices

All internet businesses start small and, depending on the success of the offering, grow. This growth occurs in scaling the business elements that are the engine of the offering. In small businesses, scaling happens on the "edges" - more customers, more processing, etc. Systems are built to manage the size of the business. This scale and growth perspective is the kernel for the microservice application platform. As the business becomes successful, the demands it places on systems grow and increase. The systems can be called on to do more and run at a larger level of capacity. More machines are added, more network ports are filled, and increased system demands arise. Taking a macroscopic view of an application design is healthy when contemplating the various challenges it will face in the fullness of its life. When viewing the application as a system, some ingredients are prerequisites for being able to deliver the desired results [3]. The continuation from the initial system design to production and distribution plays equally significant roles in the life cycle development phase.

Consideration also needs to be given to how this system can be easily rolled out in different environments and not just on the target data center. Componentization of the application is a necessary attribute to make the other system aspects function as intended. As individual parts can be segregated, improved, and upgraded, they can follow different life cycles. These life-cycle stages can also include security patching of the components. The migration to the modern application structure of microservices in a container-based architecture is viewed as a beneficial solution. Specifically, cloud-hosting environments that are ubiquitous in availability and address a larger number of the system constraints and goals we have are the target system deployment destination.

1.2. Significance of Disaster Recovery and Application Security

Disaster recovery and application security are significant challenges for both traditional and modern cloud-native enterprise application development services. With microservices and the Kubernetes application platform, the restoration and resilience of services and data require meticulous planning. Using official and production-ready application gateways, the reduction of vulnerabilities through ready-made devices and services that require minimal IT proficiency is becoming increasingly important in the cloud.

Figure 1

Disaster recovery scenarios for applications

To maintain disaster recovery capability and application security, investigations and professional IT expertise in Kubernetes and application gateways are integral parts of the cloud. Disaster recovery capability is the ability of an organization to systematically recover data, operations, and services in case of a failure or a disaster. Disaster recovery is one important part of business continuity, while business continuity is the ability to maintain or quickly resume mission-critical operations after a failure or a disaster has occurred. Business continuity usually has three major issues: disaster recovery, high availability, and failure prevention. High availability and failure prevention have different meanings. High availability can ensure that machine services and hardware failover remain operational, providing quantitative uptime and service level assurance, dedicated server hot standbys, and the physical separation of cybersecurity. However, these cannot prevent disasters and the cascading failure effects of dependent system failures.

Abstract Disaster recovery (DR) and security are critical elements during the design and deployment of physical or cloud data center solutions. In this paper, we explore solutions to make microservices more reliable and secure. We begin by providing an overview of microservices architecture (MSA). The advantages of a microservices-based infrastructure will be discussed. Furthermore, this paper reviews the utilization of Kubernetes, Helm, Service Mesh, and application gateways in a cloud-based microservices system. A secure microservices infrastructure is mandatory for data security policies. Finally, best practices of cloud-based solutions will be examined in this paper [4].

In this chapter, we start our discussion on Kubernetes, Helm, Service Mesh, application gateways, and cloud security by introducing the basic concepts of MSA. We present the advantages of MSA and discuss the key characteristics of MSA. We also briefly discuss the major features and advantages of different service models, including Functions as a Service, Platform as a Service, Software as a Service, and Infrastructure as a Service.

2.1. Key Concepts and Principles

This section introduces the reader to the key concepts and principles underpinning the specialized use of Kubernetes persistent volumes for secure storage. First, the microservices architectural style is defined. Next, in the context of microservices, we explore more specific requirements centered on application security. Each of these requirements can grow to be specific to different application teams, no matter whether iterative development methods are used within a monolithic application or continuous development methodology is used for different microservices. Subsequently, we highlight the importance of data in the context of applications. It is more specific than the operational management of persistent volume claims by Kubernetes, such as snapshots, backup, storage, retention, recovery, and remote replication protection [5].

When managing persistent storage for microservices, it is also important to consider various methods of encryption to protect the resulting data, whether it is at rest or in transit. By deploying Kubernetes to run on Linux, Kubernetes uses various security-relevant Linux attributes to provide various protection technologies for containers and their internal volumes. The current version of Kubernetes has been enhanced for container-aware storage technologies, which allows Kubernetes to transparently utilize storage protection functions, for example, volume encryption and data protection functions. Although security was not the top priority at the time of creating the draft volume encryption function, it is a thing of progress, not only driven by the financial sector, to confirm that, if available, volume encryption could be applied to the volume with no modifications to existing containers and their deployed applications [6].

Equation 1: Disaster Recovery Equation

High Availability (HA) can be expressed as:

Where:

Uptime is the time the service is operational.

Downtime is the time the service is unavailable due to failures or maintenance.

Disaster Recovery Time Objective (RTO) can be formulated as:

Where:

Total Recovery Time is the sum of all recovery efforts for incidents within a defined period.

Number of Incidents is the count of incidents impacting service availability [7].

2.2. Benefits and Challenges

Microservice architecture offers several significant benefits when compared to traditional monolithic architectures. For example, developing an application as multiple services is faster than developing it as a single monolith, as the smaller codebases, clean API designs, and frequent releases in microservices reduce the development cycle time. Microservices also allow different teams to work at different paces through their independent release cycle. This makes teams responsible for their individual application parts, aligns development processes, and facilitates better communication among teams and team members. Increasing the scalability, performance, and security of applications—such as reducing load on a particular service and securing sensitive data processing—against disaster recovery and application security threats can be addressed more effectively through microservices. They make it easier to identify a potential performance bottleneck for a specific service and design it to handle a high volume of requests.

Microservices are also more tolerant of failure because if one service fails, then another can handle the request, identify and report the failure, and recover from the failure without affecting the overall application operation. Thus, microservices ensure the high availability and fault tolerance of applications; not only during the maintenance period but also when sudden requests come that cannot be handled by the services. At the same time, microservices pose several challenges, such as infrastructure management, data management, service discovery and load balancing, fluid failures, distributed monitoring and logging, and continuous integration, testing, and deployment.

Disaster, that is, a failure in IT systems, can occur at any time and may have serious consequences that interrupt the provision of services to users. Building resilience in preparing for a disaster and recovering from it is therefore essential for such a failure. In particular, disaster recovery is essential for system availability. To increase the reliability of an IT system, various solutions can be implemented, such as a high availability design, failover, or automatic failback design. However, deployments of microservices on Kubernetes and failover among clusters still require time and effort and are not easy to do. Additionally, cloud resources are required to cope with microservice service requests during upgrades.

The process of migrating from a traditional virtual machine system holding a conventional application to a cloud-based microservices system includes both the migration of existing data and operations to carry out recovery from problems in the future. In other words, migration cannot simply be regarded as a move, and in case of failure, the ability to maintain the level of service to users required in the past under the conventional system will not be maintained. To construct an application security function when migrating a traditional application to microservices, it is necessary to provide high availability by preparing for a failure by storing data at an appropriate recovery point in time and its appropriate recovery procedures [8].

3.1. Understanding Disaster Recovery Planning

Strategic feasibility studies represent a macro perspective for the creation of a computing ecosystem. During the past few decades, designers and developers have given an edge to technology enhancement using advanced digital algorithms and innovative methodologies. With the advent of artificial intelligence, machine learning, hybrid programming, nodes, computer models, and big data analytics, we have seen a significant change in the field of computer science and system engineering. Big data and computationally intensive problems depend on the performance of the computing infrastructure. Around 10 years ago, the concept of cloud computing was introduced to address such performance challenges. Disaster recovery planning is an essential management system consideration that must exist within an organization as it provides the knowledge and capacity to administer and control disaster recovery testing and strategies [9].

The plans for disaster recovery are more important for large business organizations compared to small organizations, as large organizations are more dependent on computer systems. Without disaster recovery plans, a simple error or natural event can lead to destructive consequences and significant economic loss. The key considerations for proper disaster recovery should start with an examination of the company’s mission-critical components. It should identify not only the computer-related structures but also the human and structural components that could affect the response and recovery of quarantined business processes combined with the critical data as resources. Without the identification process, the recovery engine of the system will end up focusing on the technical problems associated with the computer resources and could ignore the valuable and indispensable interests of the users of the computer-supported process and other vital company resources.

Figure 2

5 Disaster Recovery Strategies

3.2. Disaster Recovery Strategies for Microservices

Microservices are meant to run as immutable entities, removing the need to frequently change running instances. Developing robust services following principles fits very well with container services. Stateless microservices can be easily replicated or scaled. Stateless services are also akin to cattle in a cattle vs. pets approach, quickly and easily replaceable versus pet services, which are unique and irreplaceable. Yet microservices are very unique cattle [10]. Applications, specifically the state inside the microservices, enable them to produce unique results. Application state can be implemented via multiple persistent means such as an in-memory store, sidecar containers, or shared volumes, which can range to microservices with server-centric state models. Simple microservices can be easily replaced. Backup policies can complement this style of microservices [11].

Rebuilding application states with a microservice can be performed with a policy of reintegrating them into the microservices’ communication systems. This assumes the application state could be found, read, and modified from past microservices. It is important to remember that, because of the highly scalable ability of microservices to be spun up, cached data will also be found on more than one instance of microservices. This also points towards managed authentication and authorization for microservices, so that potentially attested data is only available to read and write by the correct services at any given point in time. In the case of stateful microservices, attached disk volumes become a requirement. The production of the application state in the DR instance will want to regularly synchronize with other DR instances. With active-active, eventually, all persistent state instances will want to interact to achieve eventual consistency.

The dynamic and transient communication map among microservice instances in every application creates many security and privacy hazards. This includes, but is not limited to: the network is the perimeter problem; security token management and issuance among services; insecure service intercommunication; intercommunication encryption and data protection; vulnerability exploitation of the hosting platform; weak access and session controls; incomplete system logging and monitoring; and weakly protected data of sensitive or identifying nature. Specifics of these threats can be overwhelming because every microservice in an application is an HTTP server, and in most cases, it also becomes the HTTP client as well.

Understandably, these security concepts embodied by containers managed at scale can be quite worrisome [12]. Authentication and authorization of service as a client in a secure two-service HTTP request environment is only part of the security and privacy control story. The same service can be called by an unsecured non-trusted service or even an external client. The lack of gateway security components that protect every microservice from out-of-communication or that forward the call to services regardless of the sender and the requesting client can be a gradient of vulnerability vectors both vertically and horizontally. In a broad sense, service-layer protection from all communication parties is essential in an API security model, especially when running an application inside a supported development and deployment platform provided by best practice equipment and their best practice configuration profile [13].

4.1. Importance of Application Security

Application security is important for microservice architecture implementations. First, it serves to prevent unauthorized application access and service interruption. It protects the level of reliability exposed by microservices and maintains normal business operations. Specifically, microservices are implemented through different service protocols, such as HTTP, which have become the main method of service interface exchange. As a result, application security is based on the application security gateway, which controls transactions between the internal and external networks using a variety of rule sets. In some application security gateways, developers or security personnel can customize logic, carry out DNS inspection, evaluate whether to enable the HTTP/2 protocol, provide the application with availability-based pressure testing, and other functions to control access to the application.

Second, application security can increase the reliability of microservice collation. When implementing microservices, reliability is a factor that companies consider the most crucial. The final services that a company displays to the outside world are mainly composed of a series of front-end microservices that provide users with different application experiences based on logic aggregation. When the number of microservice calls increases, a wrong request to the backend logic service can seriously affect the normal operation of a front-end application that depends on a wide variety of services [14].

Equation 2: Application Security Equation

Risk Assessment can be modeled as:

Where:

Threat is the potential for an attack or incident.

Vulnerability is the weakness that can be exploited.

Impact is the potential damage from a successful attack.

4.2. Common Security Threats and Vulnerabilities in Microservices

In a microservices-based system, services are running individually but are talking to each other. Communication can be synchronous or asynchronous messaging. A security breach in one of these service interactions can affect the whole system. All the service interfaces need to have proper security configurations [15]. Furthermore, it is not always possible to secure internal communication for microservices. Service interaction is always controlled through the edge layer or API. An edge service with proper security configurations can help the system provide security with less complexity. The scope of this section is to discuss the threats and vulnerabilities of internal APIs and external APIs in the context of microservices. Relevant security solutions are then presented. Steps in enabling external API security through an API gateway are then explored. The section concludes with a comparison between security patterns.

Figure 3

Best Practices for Microservices Security

Special techniques for segmenting and developing high-availability architectures for SAD microservices must be considered not only because of the typical load distribution and internal characteristics but also due to the necessity of planning for stateless and tolerant microservices when accidents or new deployments occur in the service. Using these techniques, mainly from a system of quick restoration when a SAD microservice no longer works, addresses the reasons for many accidents when the service is requested, especially when we use protection systems like load balancers. Among these techniques, we can mention replicated projects, load processing balances and limits, and system protection using application gateways. Unscheduled disconnections of a SAD microservice requested by the application gateway need not affect the transaction, which will be redirected by the application gateway to other functions of the system. This search for recoverable systems and SAD microservices is part of the effort to enable high availability for SAD systems, avoiding, as much as possible, unavailability, discouragement, slow responses, or lost processing [16].

For a solution to be considered applicable in SAD systems, the completion time must be faster than the system's timeout. In a bank, for example, it is common to have a timeout of around 2 to 4 minutes. During a regular and scheduled stop, pod cessation usually takes a few seconds, achieving the desired completion time in SAD requests, without affecting the high availability of the service. In a halt due to an error injection, which is unexpected, the halt completion time should not exceed the bank's timeout, which is a point of attention in the accident-free operation of microservices and SAD systems. With the accident managed quickly, it is possible to redirect the transaction close to an end, through the application gateway, for example, which allows continuing the operation without affecting the end customer. For these reasons, we need to limit the execution time of the halted functions to values that are important to the system, taking into account not only the lost time associated with unavailable microservices but also the timeout for transactions of that system.

5.1. Overview of Kubernetes

Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. It is, in other words, a better way of managing and operating microservices and cloud-native applications. With Kubernetes, it is easier to build and update production applications, install and manage vendor-supplied systems running as containers, and collaborate with other teams also managing containers in a cloud environment [17].

Kubernetes works by managing a cluster of "worker" nodes and a "master" node. The worker nodes are the part of Kubernetes where the application processes run, as well as other supporting environmental software. The master node is responsible for managing the worker nodes. The Kubernetes cluster can be deployed on a cloud platform.

5.2. Role of Application Gateways

Microservices architectures, micro-segmentation, and micro-proxy security solutions leveraging application gateways at the edge, service entry, service mesh, and service protection points provide fit-for-purpose, high-performance, elastic, secure, and available services. To recover from application hacks or compromises, security should be built in from the coding, build, pipeline, and integration phases. Application encryption, tokenization, and network isolation with partitions and egress controls are key security features of application gateways. The role of an application gateway in the security of microservices-based applications is as the primary perimeter traffic processing component at entry points and within the microservices [18].

In microservices with applications that are public-facing, the Ingress service is the primary traffic entry point for getting the packets to the back-end microservices. Other points of entry include the rich API and application gateways at the service micro-segmentation and service mesh service processing points. Automated filtering, access control, authorization, and logging services restrict the traffic in a quick, coarse fashion to the right service, based on security functions. Once the packet header is inspected, then switch to software proxies at micro-segments with traffic. The software proxies will then find and pack all the necessary attributes for intelligent traffic steering to the right backend service at points of value.

Figure 4

API gateways in microservices

5.3. Leveraging Cloud Solutions

Public cloud computing services provide opportunities to organizations with limited budgets to create high availability and disaster recovery plans and implementations. This can be a cost-effective approach due to on-demand billing; companies do not have to maintain a high infrastructure cost, they can create temporary resources when needed and drop these resources when they are not needed. Cloud environments provide high availability and reliability services through their service level agreements. They have high physical and logical infrastructure and redundant components with best practice design, and they meet standards for data centers. Cloud providers have multiple data centers located in different geographical areas; they can provide redundancy and backup services between data centers as well as different regions with different networks [19].

Large-scale server platforms, even on-premises, can be an expensive solution due to high hardware and infrastructure costs. Maintaining these types of high availability and disaster recovery solutions requires continuous operational costs, operations, and governance. The second data center should be at least 100 miles away from the first one to survive geographic disasters such as earthquakes and floods, which might be a prohibitive solution for small to medium-sized enterprises. Using the data centers of a cloud provider enables companies with limited budgets to implement disaster recovery and backup plans that might not be possible in secure and physical infrastructure.

During this research, we developed three microservices: IdM for identity management, UbiBroker for publishing events from IoT devices, and ActDSR for interoperability with e-class and ebV, using Eclipse MicroProfile [20]. A common feature of the microservices is that they use JSON Web Token for authentication and RBAC for authorization. The present study is motivated by the complex authentication and authorization requirements of a modern enterprise architecture that are faced in an Open Data Space pilot project for ISO 8000 data standards. The privacy and security challenges faced when deploying microservices are introduced and discussed. In the context of a major research and development project on digital IDs and trusted data standards with industry, we describe real issues we have faced deploying microservices in the cloud [21].

Since the microservices we developed differ significantly from one another, we stress the similarities and differences through the architectural layers of the microservices. The characteristics of the services are discussed in turn, layer by layer, along with their resilience features. Then the challenges faced in developing the use cases and use scenarios are introduced. Finally, we describe Kubernetes pods as factories and the use of Kubernetes application gateways to connect microservices. We illustrate the constrained effect of the latest API gateway software and propose a real-time distributed digital ID to solve the issues that arise. We discuss the application gateways and cloud solutions for the high availability of the project. This discussion of case studies and best practices makes a private digital ID solution, while securely federating among correct users anywhere with organizational card-based IDs. The system scales elastically across multiple industrial nodes on trusted data. It controls and enables seamless connections in the most ubiquitous legacy system for IIoT, everywhere [22].

6.1. Real-world Examples of Disaster Recovery in Microservices

The concepts and techniques discussed in this chapter give a good starting point for the research and design of real disaster recovery solutions for microservices in case of an unforeseen event. We have shown that it is possible to deal with preparing for recovery, as well as recover from actual events, within a confined period, allowing for possible service outages without leaving clients dissatisfied. In a microservice landscape, disaster recovery comes with some unique characteristics compared with traditional disaster recovery. In microservices, the composition of the service has become unpredictable—device failures and misconfigurations are not the only issues a service suffers, as applications generally operate in more complex environments. The benefits of microservices then need to be reaped concerning disaster recovery capabilities.

More testing of disaster recovery in microservices is desired, including methods to stress-test actual production environments and disaster recovery plans. Resilience to such events is only tested after the recovery has taken place [23]. Production events break disaster recovery norms, but when they occur, they must be framed within a context where many impacted end users are reaping the benefits of new software faster than before. At the same time, cloud solutions are put in place that allow for impressive infrastructure build-ups within minutes or hours and not weeks. It will be interesting to research in the future how such capabilities can be combined with microservices in the event of a disaster recovery plan being put into action.

Figure 5

Architecting Disaster Recovery for Cloud Infrastructure Outages

6.2. Effective Application Security Measures

This chapter encompasses the essence of application security concerns prominent in applications developed using a microservices architecture. Dissected into two distinctive phases, a detailed overview of the scope of development of an effective access governance policy, along with the recommended application security measures, paves the path for safe deployment and efficient management of the application. Effective development and incorporation of the structure modeled herein are found to assure secure application governance [24]. This is supported by facts backing the reduction of the involvement of DevOps teams to maintain efficient application governance over the traditional approach practiced so far, thus embedding secure measures in microservices applications with minimal effort and concern through the recommendation.

In this development phase, the application yields are calibrated, comprising empowered decentralization of essential control rights to DevOps teams, accompanied by a fine-grained API usage tracking mechanism integrated into the platform, thus establishing substantial positive correlations in microservice applications with effective application governance in place, surpassing traditional application development. Post the effective establishment, the implementation requirements common to securing applications developed on all platforms are dealt with in detail, touching on the assurance of reliable authentication setup, and efficient, scalable authorization policy implementation via access control strategy comprising static and dynamic parts. The extensive reusable code with components in web services utilizing various technologies, single-page applications developed, made in the grid leveraging various tools, no expiry token feature, overhaul proxy, elastic search, and finally dockerizing proxy service mobility flow are addressed, thus enhancing efficiency in the microservices application created securely in-house, thus enriching it with high availability, disaster recovery, and effective application security [25].

In this paper, we demonstrated that with a couple of simple configurations and cloud solutions, a microservices solution can not only provide high availability with zero recovery time but can also enhance application security and provide extra ways to guarantee business continuity. When compared to other traditional microservices solutions, despite the cost of resources used, our approach provides much simpler recovery procedures with automation at the service level. Our security control for a single entry point and application-level firewall can help to reduce the number of security solutions required. Every time a security issue was resolved at the application gateway level, it removed the necessity for code modifications or upgrades. An application gateway can also reduce the effects of zero-day attacks by using transparent or non-transparent HTTP header insertions whenever necessary. Lastly, the recovery procedures on the cloud can ensure that the data stored across all services is still consistent.

7.1. Summary of Key Findings

A SaaS company used its development workflow to utilize test suites that help ensure container security for microservice-based applications on Kubernetes. The development sandbox is used for this purpose [26]. The development tooling we describe performs non-traditional workflow activities such as dependency management. It uses layers of directories that simulate network layers. Builds don't need to occur within the container, so building and executing tests can easily happen in containers on the developers' machine. The security issues were mitigated by running build and test commands on the host machine, rather than inside the build Pod. This ensures that while passing code and tests to the hosted container, talented but inexperienced developers cannot execute harmful operations in the cluster. On the other hand, the build Pod should have some level of isolation from the host that it may be able to compromise.

Software microservices provide significant benefits to developers. While it is essential to introduce security early in the application life-cycle, developers new to working within a microservices context may struggle to remember some of the important security characteristics of these environments. A development tool that includes features like sandboxes that can simulate network traffic and are designated for validating proper security, secure build operations and cryptographic operations, and automated integrity checks and container vulnerability management suites will make microservice environments both easier to use and safer to use. It can also encourage best practice behavior in developers who may lack the experience to anticipate security issues. Providing easy-to-use tools can reduce common sources of risk in microservice development and allow developers to make better use of the tools available [27].

Equation 3: Cloud Solution Availability Equation

For cloud solutions, the overall availability can be expressed as:

Where:

Total Cloud Uptime is the total time the cloud services are operational.

Total Time is the total time in the observation period.

7.2. Future Trends and Directions in Disaster Recovery and Application Security

We now discuss a variety of future trends and directions in disaster recovery and application security in the context of microservices. It is key to realize that many of the hot topics discussed in this section are fields of active and ongoing research, and while these topics are likely to drive meaningful innovations in the industry shortly, many of the technologies are currently associated with substantial challenges regarding practicability, manageability, stability, performance, usability, and real-world efficacy. Some of the discussed trends consist of evolutions or minor variations of domains that already carry extensive corresponding best practices for traditional architectures, such as databases or service decomposition patterns. Bottom line, when driving an agenda of evaluating the practical impact or effectiveness of many of the discussed future trends in fields like security, operational disaster recovery, or traffic management concerns, organizations have to be pragmatic in balancing the benefits of being a very early adopter of new technologies against the costs of coping with a potentially large amount of rough edges, incomplete tooling ecosystems, volatile third-party solution offerings, or even maintenance or operation costs. Today’s best practice for service ownership in the Kubernetes ecosystem often consists of creating well-documented, supported, manageable, and sustained API contracts for other engineers to leverage to reduce human error, avoid daunting operational ramp-up costs for developers, and foster division of labor. Crucial service resources start from obvious entities like deployment, pod, and service definitions, and can contain many other objects like ingress and network policies, or even custom resources like service monitors or a set of checks.