Cloud native technology is based on containers, service grids, microservices, immutable infrastructure and declarative apis to build fault-tolerant, easily managed, easily observed application systems that can easily cope with frequent changes. So how do you build these cloud-native applications? This article illustrates the best design patterns for cloud native apps.

Multi-copy mode

The multi-replica pattern is the most commonly used design pattern in microservices to ensure the high availability of services. It creates multiple copies for the business container and distributes these copies to different machines in different availability areas. These copies are then provided to external consumption through load balancing. In general, multi-replica business containers are stateless, so external requests can be allocated to any idle container. In Kubernetes, you can implement this pattern using Deployment and Service. Of course, you can also leverage the HPA feature to automatically expand or contract the number of replicas depending on the load on the business container.

The following figure, for example, uses the multi-replica pattern to provide high availability for the business container to ensure that the service can achieve the expected SLAs.

Note that in order to ensure SLA, load balancing alone is not enough. Load balancers also need to be able to identify and remove failed containers in a timely manner, i.e. health probes need to dynamically monitor the health of each container.

Sidecars mode

The Sidecar pattern is the most commonly used non-intrusive design pattern for modifying application behavior. It adds another proxy container to the Pod that the application container belongs to, and the proxy container takes over the Pod network, thus further adding additional features to network requests. For example, in the Service Mesh, Sidecar containers are used to implement rich traffic management features such as flow control, fuses, TLS authentication, network monitoring, and tracing.

For example, the sidecar mode is used to add TLS authentication to the application container. Since all TLS authentication logic is controlled in the proxy container, no changes are required in the application container.

Ambassador mode

The Ambassador pattern hides the complexity of external services by providing a unified interface for business services to access external services through a container. Ambassador containers typically provide a simplified view of external services and are deployed in the same Pod as business containers in a Sidecar fashion.

For example, the ambassador pattern is shown in the figure below to provide a business container with access to a database. Service discovery, exception handling, cache acceleration for database access are all implemented in the proxy container, and different business containers can reuse the simplified interface of the proxy container without modifying the code of the business container.

The difference between the Ambassador mode and Sidecar mode is that the Ambassador container serves the business container, which simplifies the access of external dependencies. The Sidecar mode provides additional functionality for the business container. They all have the common advantage of not having to modify business code.

Adapter mode

Adapter patterns provide a standardized interface for heterogeneous applications that can be handled uniformly by external services. Adapters are also typically deployed with the business container as a Sidecar container and hide the complexity of the business container from external services.

For example, many applications may have built non-standard monitoring interfaces based on different libraries prior to containerization, and after the adoption of microservices, all monitoring needs to be consolidated to Prometheus. The following figure shows the use of the adapter pattern to unify the monitoring interface of heterogeneous systems into the Prometheus measurement interface, so that all business systems can be monitored through unified Prometheus.

In addition to monitoring systems, another common adapter pattern is logging. Many business systems record logs directly to files before containerization, abandoning the practice of storing logs at different levels in different files. After containerization, using the adapter pattern, the contents of these log files can be redirected to stdout and STderr of the adapter container without modifying these business systems, thus making it possible to process all container logs in a uniform manner (for example, Kubectl logs can also be used on these systems).

Stateful service

Stateful services require each instance to have a persistent unique identity, and typically each instance will be arranged in a different location (ordered). Therefore, each container must be assigned a unique DNS name and a serial number during deployment. Databases and distributed storage often need to run as stateful services to ensure consistency of state from instance to instance.

The following is an example of using stateful services to deploy Zookeeper. Each Zookeepr is assigned a unique name, serial number, and a different persistent store. In Kubernetes, this can be done through StatefulSet + PVC.

When managing stateful services, special care needs to be taken to use persistent storage (such as PVC in Kubernetes) for each instance, and that persistent storage should be retained when instances are deleted. This way, all data is not lost when the instance is rebuilt for routine maintenance.

Operator mode

Operator mode is a design pattern that utilizes Kubernetes Custom Resources (CRD) to manage complex applications and components. Following the design concept of Kubernetes, operators capture key indicators of application components on behalf of O&M personnel, and maintain application operation, deployment, exception handling, and fault migration based on these indicators to achieve automatic management of the entire life cycle of application software. You can find a list of operators commonly used by the Kubernetes community at OperatorHub. IO /.

The following figure shows an example of an Etcd Operator that extends the EtcdCluster resource using the Kubernetes API and creates multiple Etcd pods for each EtcdCluster resource to form a cluster. The Etcd Operator also typically runs in the same Kubernetes cluster as a normal Pod and dynamically monitors the status of the Etcd Pod. When an exception occurs to the Etcd Pod, the Etcd Operator dynamically fixes the exception based on the cause.

Service grid

Service Mesh ensures secure and reliable communication between services by lightweight network proxy Sidecar, and provides unified network observation and traffic control features for Service applications. Service grid decouples service governance from actual business services, avoids the intrusion of applications in the process of microservitization, and can be used to accelerate the transformation from traditional applications to microservices and cloud native.

FaaS mode

Function-as-a-service (FaaS) is an event-driven computing execution model running in stateless containers. It uses event-driven Funtion to build and execute business applications without maintaining its own infrastructure. FaaS does not require server processes to run in the background for a long time. Instead, new containers are dynamically deployed to perform tasks driven by events. After the tasks are successfully executed, the container is reclaimed. FaaS mode is commonly used for data processing, Web applications, batch tasks, IoT services, and so on.

In many places you may see people equate FaaS with Serverless, but in reality FaaS is just one way to implement Serverless, which usually also covers a broader set of architectural patterns and design practices.

Welcome to pay attention to chat cloud native public number, know more about cloud native knowledge.