Chapter 3, Connectivity and Composition Patterns Flashcards
What are native connectivity patterns?
Native connectivity patterns allow you to build connectivity among microservices as well as with other systems in your cloud native application. As discussed in Chapter 1, a cloud native application consists of microservices and may also connect with existing proprietary or legacy systems, external services such as software-as-a-service (SaaS) applications, databases, messaging infrastructure such as message brokers, and more.
Page: 95
What should be considered when connecting more microservices and systems in a cloud native application?
The more microservices and systems we have to connect, the greater the complexity of the entire cloud native application. Before applying connectivity patterns, ensure the appropriate service granularities are used. Too many interactions among microservices indicate a too fine-grained service design scope, necessitating a revisit of the microservice design phase to redefine the service scope directly mapped to business capabilities. The foundational communication patterns should be determined by the business use case. Interactive business capabilities like searching for items in an online store need a synchronous Request-Response pattern, while placing orders requires an asynchronous Single-Receiver pattern. We should identify or define service interaction styles and underlying protocols during the microservice design phase. Ensure infrastructure is not leaked into the application’s connectivity logic to maintain portability. Service connectivity capabilities not mandatory for application behavior should be implemented at other layers, like sidecars.
Page: 100
What is a Kubernetes service?
A Kubernetes service groups a set of pod endpoints into a single resource. You can configure how you access that service in various ways, such as load balancing or cluster IP.
Page: 105
What does a Kubernetes service provide for grouped pods?
Kubernetes service provides seamless load balancing among the grouped pods. Using the service type LoadBalancer, Kubernetes automatically creates a cloud network load balancer of the underlying cloud platform (AWS, Azure, GCP, etc.), which provides an externally accessible IP address that sends traffic to the correct port on your cluster nodes.
Page: 106
What is the Service Abstraction pattern?
With the Service Abstraction pattern, you can expose any other monolithic or proprietary systems consumed by your cloud native application as a service.
Page: 105
What are the considerations for using the Service Abstraction pattern?
Service Abstraction is essential for cloud native applications to achieve scalability, redundancy, and encapsulation of microservices and other systems. While possible to implement without an underlying platform, using a platform like Kubernetes that supports service abstractions as a first-class construct is recommended.
Page: 106
What is a service registry and what information does it contain?
A service registry is a repository containing service information and metadata, such as service URLs, service interface definitions, service-level agreements, and other useful information for service consumers. Implemented as a service offering a registry repository API and discovery API, service owners/developers register and maintain the service information, while consumers use the registry to learn how to consume the service.
Page: 107
What are the two ways to implement the Service Registry and Discovery pattern?
The Service Registry and Discovery pattern can be implemented in two ways: client-side service discovery, where the client is responsible for service discovery, and server-side discovery, where an intermediate component like a load balancer handles service discovery.
Page: 108
How does Kubernetes handle service discovery?
Kubernetes uses DNS names to discover pods, resolving and mapping service names to actual endpoints. Kubernetes uses etcd as the distributed key-value store for service registry, but it may require a dedicated service registry like Consul for complex service registry and discovery requirements.
Page: 110
What should be considered when using the Service Registry and Discovery pattern?
Service Registry and Discovery is essential for building cloud native applications. However, a full-blown solution is not necessary from day one, as platforms like Kubernetes and cloud services (AWS, Azure, GCP) offer primitive capabilities. Invest in a dedicated solution if advanced capabilities like managing service dependencies, health checks, and leader election are required.
Page: 111
What related patterns are used with the Service Registry and Discovery pattern?
Service Registry and Discovery is foundational for most connectivity patterns. In API management, dedicated API registries known as API developer portals are used to store and expose business capabilities as APIs.
Page: 111
What is the purpose of a time-out in service calls?
A time-out prevents a caller service from waiting indefinitely for a response from a target service, enhancing application responsiveness. Realistic time-out values should be set based on network latency and target service processing time.
Page: 113
What is retry logic in resilient connectivity?
Retry logic aims to get the expected response despite network disruption by invoking the same service multiple times. Specify the number of retries and duration between retries, and define logic for handling maximum retry count reached.
Page: 114
What are deadlines in resilient connectivity?
Deadlines specify a fixed point in time for completing a service invocation. They are useful for chains of services, where each service checks the deadline and invokes deadline-exceeded logic if expired.
Page: 115
What is a circuit breaker in resilient connectivity?
A circuit breaker prevents further service invocations if previous invocations failed and the circuit state reaches a threshold. It switches between closed, open, and half-open states to manage service invocation failures and recovery.
Page: 116
What is the fail-fast principle?
Fail-fast detects failures related to service connectivity as quickly as possible, often by validating requests before sending them to the target service.
Page: 117
What are the considerations for resilient connectivity?
Resilient connectivity is essential for cloud native applications and can be implemented as part of the service’s business logic, a separate runtime (sidecar), or via underlying cloud services. Resilient connectivity styles can be combined with various communication patterns.
Page: 119
What patterns are often used with the Resilient Connectivity pattern?
The Resilient Connectivity pattern is often used with the Sidecar and Service Mesh patterns.
Page: 119
How does the Sidecar pattern work for service connectivity?
The Sidecar pattern offloads interservice communication logic to a separate runtime colocated with the main microservice. This is often implemented as a colocated container with the main container in Kubernetes pods, allowing clear separation of concerns and easier management and scaling.
Page: 120
How is the Sidecar pattern used in practice?
The Sidecar pattern is often realized with platforms like Kubernetes, encapsulating a sidecar-based microservices application as a multicontainer pod. This allows clear separation of business logic and enhancement logic while managing and scaling the application as a single unit.
Page: 121
What is a sidecar proxy?
A sidecar proxy mediates inbound and outbound communication to the main microservices it is attached to, handling additional network communication features like security or service discovery.
Page: 122
What is a sidecar bridge?
A sidecar bridge allows communication between two different protocols. For example, a main container communicating with HTTP can connect with messaging systems like Kafka through a sidecar bridge.
Page: 123
What pattern is closely related to the Sidecar pattern?
The Sidecar pattern is closely related to and extended by the Service Mesh pattern.
Page: 126
What challenges does the Service Mesh pattern address?
The Service Mesh pattern addresses challenges in building connectivity between microservices and systems, offloading interservice communication logic to a different layer to keep service code independent. This pattern is used instead of the centralized ESB architecture, reducing the complexity of business logic and development time.
Page: 126
How does the Service Mesh pattern work?
Service Mesh implementations define a configuration language or API to control capabilities and manage the data plane via the control plane. Reliability, security, observability, service discovery, and policy enforcement are applied at the data-plane level and controlled through the control plane.
Page: 129
What is the relationship between the Service Mesh pattern and other patterns?
The Service Mesh pattern is closely related to the Service Connectivity and Sidecar patterns.
Page: 132
What is the Sidecarless Service Mesh pattern?
The Sidecarless Service Mesh pattern eliminates the need for a sidecar by embedding sidecar proxy logic into the microservice runtime, directly managing and controlling network communication via the control plane.
Page: 132
How does the Sidecarless Service Mesh pattern work?
The Sidecarless Service Mesh pattern uses a control plane to manage and configure communication between microservices, embedding mesh traffic logic into the microservice runtime. This requires each implementation technology to support the control plane API and network communication logic at each layer.
Page: 133
What are the considerations for using the Sidecarless Service Mesh pattern?
Sidecarless Service Mesh is an emerging pattern that overcomes the limitations of sidecar-based service mesh architecture. It requires client libraries to support service mesh control plane APIs and network communication logic.
Page: 136
What related patterns are associated with the Sidecarless Service Mesh pattern?
Sidecarless Service Mesh is an alternative to the Service Mesh pattern with a sidecar proxy. Resilient communication patterns are often implemented at the control plane–compliant client libraries used to build microservices.
Page: 136
What is the relationship between Service Orchestration and Service Choreography?
Service Orchestration is used alongside Service Choreography in a hybrid way, often requiring both synchronous and asynchronous service interactions.
Page: 145
What patterns are used in conjunction with Service Orchestration?
Service Choreography is often used with Service Orchestration in a hybrid manner, using asynchronous communication patterns like Single-Receiver and Multiple-Receiver.
Page: 150
What is the main protocol used in implementing distributed transactions?
Distributed transactions use the two-phase commit (2PC) protocol to orchestrate transaction steps through a transaction manager.
Page: 151
Describe The Service Connectivity pattern
The Service Connectivity pattern is a high-level, composite pattern that can be used in building cloud native applications. This pattern explains how a cloud native application is formed by connecting microservices and existing systems, and how these services interface with the consumers of the application.
96
How does The Service Connectivity pattern work?
The Service Connectivity pattern provides a generic way to connect different components such as microservices, external systems, and APIs exposed to consumers. This pattern uses one or more foundational communication patterns such as synchronous or asynchronous communication to establish the connectivity in your cloud native applications. It is applied to the backend implementation of any of the business capabilities of your cloud native application.
So, the key idea of the Service Connectivity pattern is that it should be used as a high-level pattern that connects services and systems to realize the end-to-end business capabilities of a cloud native application.
96
How does The Service Abstraction Pattern work?
A given microservice or any other external system in a cloud native application can be represented as a service, so that it hides all the implementation details. For example, a given service may have multiple runtime instances running in different locations, with different Domain Name System (DNS) names and Internet Protocol (IP) addresses, and so on. If we don’t use an abstraction to represent that microservice, all the clients or other services that consume it need to know the implementation details of the target service or system. Therefore, we can introduce a service abstraction in front of the microservices or systems in a cloud native application (Figure 3-3).
101
how does the Resilient Connectivity Pattern work?
The Resilient Connectivity pattern allows you to design a resilient interaction between the microservice and the other services or systems it invokes, so that if a failure occurs, the system will be able to handle it or recover from it. For example, suppose you have two microservices in your cloud native application: Microservices A and B. Microservice A invokes Microservice B via network communication, and we need to make sure that communication happens resiliently.
The logic that invokes Microservice B should be able to handle the failures that could occur, recover from them if possible, or gracefully take actions to avoid the failure in the future. The key idea here is that Microservice A contains resilient communication logic that is executed as part of the service runtime.
Depending on the nature of the failure that could occur during interservice communication, we may implement the resilient communication logic in different ways, but the high-level architecture implementing resilient communication can be generalized as shown in Figure 3-8.
112
How does Service Mesh Pattern work?
The Service Mesh pattern allows you to have an interservice communication infrastructure between your microservices and other systems. With a service mesh, a given microservice won’t directly communicate with the other microservices. Rather, all service-to-service communications take place through a sidecar proxy. As illustrated in Figure 3-18, the Service Mesh pattern introduces the following components to provide a simple, scalable, and configurable communication infrastructure:
-Service Mesh sidecar proxy
This is known as the data plane, in which all the interservice communication logic is applied to the messages exchanged between services and systems.
- Control plane
Sidecar proxies are controlled through the control plane. This centralized component provides a rich and simple API to control sidecar proxies of the data plane. - Service Mesh configuration language
This is the configuration API that allows you to configure the data plane to control the interservice communication logic. - Built-in support
This support provides reliability, security, observability, service discovery, policy enforcement, and more.
127
How does the Service Orchestration Pattern work?
Service Orchestration implements the business logic of a microservice by invoking and integrating one or more microservices and systems. Suppose you are building a new business capability implemented as Microservice Z (Figure 3-22). It requires the integration of several existing microservices such as Microservices A, B, and C. You can build the business logic of Microservice Z so that it invokes Microservices A, B, and C with the required messages and finally sends the response back to the consumer of Microservice Z. The downstream services may use disparate message formats and communication protocols. Therefore, Microservice Z needs to handle all that complexity. The entire composition logic is self-contained within Microservice Z’s scope.
The downstream services can use either synchronous or asynchronous communication. These downstream services may call several other downstream services too. This style of communication is known as service chaining. From the perspective of composite services such as Microservice Z, the existence of multiple chained downstream services is irrelevant.
141
How does the Service Choreography Pattern work?
At the heart of the Service Choreography pattern, we build a business use case that requires interaction among multiple microservices and other systems by creating asynchronous event-driven communication links with the use of a message broker (or event hub). The interaction logic is dispersed across multiple microservices, and no direct coupling occurs between microservices. Unlike in the Service Orchestration pattern, microservices do not actively invoke other microservices, but operate more or less in a reactive mode based on the events and messages coming into the service. Hence the microservices that we use in Service Choreography are also known as reactive microservices.
The composition logic is formed by publishing messages to queues or topics and the consumer microservices subscribing to them. By using asynchronous messaging patterns such as Single-Receiver (queue-based) or Multiple-Receiver (pub-sub with topics), we can create distributed asynchronous composition logic across multiple microservices.
It’s important to note that in the Service Choreography pattern, we use the message broker as a primitive messaging infrastructure. We don’t put any business logic (such as routing based on a certain criteria) inside the broker. All the logic should reside inside either producer or consumer microservices.
146
