In the microservice architecture, applications replace the rigidity and stability of call stack with the flexibility and chaos of network. Unrelated to the call stack, such as delay, interrupt retries, security and traceability have become the focus of service invocation. Service grid helps developers get away from these problems and focus on developing business solutions.
There is a lot of overlap between API gateway and service grid. This paper discusses the concept, advantages and differences between service grid and API gateway, and provides suggestions for the use of service grid.
Summary of recommendations
For large component-based distributed applications running on containers, application teams should use service grid to manage, protect and monitor their services.In these applications, the traffic between services is the most suitable for service grid. API gateway is used to manage the interaction between business and partners or between two internal business departments.
There are many modes in service grid, and the ideal mode is sidecar proxy running in container.Istio is the most common service grid product, and others are consul and linkerd. Before investing in service grid, we should evaluate the prospect and maturity of service grid products, and whether there are clear benchmark products in the industry (for example, kubernetes is the de facto industry standard in the container field).
Although service grid largely overlaps with API gateway, security, resilience and monitoring, it is better to regard it as a cloud technology because it is closely integrated with containers and supports cloud native applications.
What is service grid?
Transferring from function call stack to network will bring security, instability and debugging problems. Service grid is a set of architecture patterns and supporting tools to solve these problems. For example, a function call can know that the called function is always available, but a network call cannot. Service grid can help client endpoint to deal with this kind of network instability by transparently retrying client applications. In addition, it routes requests to the server node with the best configuration policy.
Service grid is usually implemented by two layers: data plane and control plane.The data plane acts as a proxy to connect the client and server endpoints, executes the policies received from the control plane, and is a monitoring tool to feed back the runtime indicators to the control plane. Control plane is the arrangement of management service policy and data plane.
Service grid topology
The most popular data plane is envoy, which is an open source agent created by LYFT and can run as a sidecar for local Cloud Applications (including local private clouds).The most popular control plane is istioThis is an open source service grid jointly created by LYFT, Google and IBM, which can inject and manage cloud native applications with envoy instances as container sidecar.
Here are some typical service grid features, but not all service grids have them.
The service grid can route requests to service instances based on policy or configuration.It can also prioritize traffic from client applications and selectively route traffic to different versions of services
- Canary deployment.
- AB Test。
- Service version control, backward compatibility.
Proxy log calls replace developers to log in to each client and server. Through these logs, downstream monitoring tools can analyze and report performance and availability, and provide basic cross call chain tracing. With additional programming, developers can enhance call chain analysis, including business transaction tracking.
Some typical observability functions are as follows:
- The service diagram and dashboard show how services connect to each other (without changing the code).
- Signal and alert to show latency, throughput, and error rate (no code change required).
- Track how requests or business transactions pass through the grid (just change the delivery transaction ID in the code header).
The proxy enforced retrial policy enables developers to solve the problem that service calls cannot be used for a short time. The agent can try to use the alternate path of the service or fail over to the backup service. For example, if Netflix’s personalized recommendation service is offline, it will return to the unpersonalized default recommendation service. It does not return an error until all efforts have been tried. Developers believe that if the service call fails, the agent should try its best to deal with the communication error.
Examples of elastic patterns that we can configure and implement:
- Retry policy.
- Circuit breaker mode.
- Speed limit, throttling.
Splitting a single application into many independent services will greatly increase its attack surface.Every service is an entry that needs to be protected. With service grid, agents on both client and server endpoints can apply policies to protect communication between them. Service grid does not require developers to program security into each service manually. Agents are responsible for authentication, authorization and encryption, which is zero trust security in service grid.
Service grid can manage and maintain which identities can access which services, and maintain the log of visitors accessing services.Identity can be verified by JWT, which allows authorization based on end users and service calls.
As mentioned above, communication between services is encrypted.The control plane provides certificate management function, such as certificate generation and certificate rotation, which will push these certificates and related configuration data to the data plane.
The support for mutual TLS authentication is very strong. Mutual TLS means that two endpoints add certificates to the white list of the other end of the connection, which can provide authentication and encryption.
Some organizations prefer OAuth to mutual TLS authentication as their API gateway authentication protocol. This is because using mutual TLS requires manual maintenance of certificates. If manual maintenance is not completed correctly, this may lead to maintenance failure and production disruption. In contrast, service grid can issue new certificates immediately without human operation. This is because the grid manages the client and server endpoints and controls the certificates they use and expect to use.
Service grid and API gateway
Although service grid and API gateway look very similar at first glance, they will be very different when we deeply study the different requirements of microservice and API serve.
Different requirements of microservice and API service
Microservices and API services solve two different problems, the former is a technical problem, the latter is a business problem.
- Microservices should communicate in bounded context. Their design is driven by component requirements that connect to form a bounded context, just like remote procedure call (RPC).
- API (usually rest, but also includes event flow and other protocols, such as soap, grpc and graphql) should provide interfaces to expose bounded context to the outside world. Ideally, their interface design is driven by business value, not just RPC.
let me put it another way,API is to expose the business of one bounded context to another, and microservice is the component of the bounded context. In traditional architecture, these components may be classes or DLLs that communicate through the process call stack. In the microservice architecture, they may be independent services for cross network communication.
Service grid and API gateway meet different requirements
To understand the difference between service grid and API gateway, we first need to define “directional traffic”.The east-west traffic usually refers to the data in the data center, while the north-south traffic refers to the traffic in and out of the data center.
In this paper, from the perspective of bounded context, traffic staying in the bounded context is east-west traffic, while traffic crossing the bounded context is north-south traffic.
The service grid is designed to manage traffic.Although the gateway is more suitable for the grid service. This is because the service grid has proxies at both ends of the connection. Both the East and the west can do this because both endpoints are controlled by the same application development organization.
Service grid manages the client and server endpoints of east-west traffic between the same application component
Service grid can also manage north-south traffic, but API gateway is more suitableBecause part of the grid connection is out of control.
API gateway manages the service endpoint of traffic between different applications
In addition, north-south traffic usually involves business partners and needs to manage the end-user experience.The API gateway is more focused on managing the end user experience.They are usually part of a larger API management solution with an integrated API catalog and developer portal that can bring in internal developers and external business partners.
On the contrary, the service grid does not focus on managing the service client end user experience. becauseA service grid is designed to manage the services that make up an application and have a bounded contextTherefore, all its clients are usually built by the same IT department that owns the service, and the team can easily change the interface of the micro service.
to make a long story short,API gateway and service grid are complementary: API gateway handles external traffic and service grid handles internal trafficThe topological structure is shown in the figure below:
When to use grid services
If we have a distributed component architecture (i.e. microservice or microservice Architecture) with dynamic, frequently changing services and a large amount of east-west traffic, we need service grid. Here are some considerations to help you make a decision. If the answer to a question is “yes”, consider the service grid.
- Environmental Science.Does the network topology change frequently with the scaling of multiple services?
- Code change.Does the code change weekly or more frequently?
- Number of services.Are there ten or more microservices? Is there a lot of Internet traffic? Can each point be expanded to five or more instances?
- Safety.Do you need mutual TLS to protect services, but can’t maintain so many service certificates manually? Please note that automatic mutual TLS is the primary reason for the adoption of service grid.
- Observability.Do you need to observe the interaction between services and track business transactions through the system?
When not to use service grid
The service grid may not bring any other benefits if:
- Very little service.There are only a few services (less than 10 are standard), or services cannot be extended to many instances (less than 5 are standard).
- Observability.Fine grained tracing between services is not required or can be easily solved by simple tools such as appdynamics.
- There’s no traffic.All communication in the application remains within a boundary, with no or almost no internal network communication.
- Fixed network topology.The network topology of the application is fixed, and the change is very limited.
- Code changes are rare.The agility provided by microservices and service grids is not applicable when the enterprise needs to change applications very little.
Service grid assessment
Almost all service grids use envoy sidecar as the data plane. theyThe most obvious difference is in the control plane. Although most control planes use istio, there is still a lot of competition with istio. The evaluation of different service grids should focus on the function of control plane and which control plane meets our requirements. Here are some considerations:
- Does the control plane provide the most value in CL / CD pipeline?
- Is the control plane declarative?
- Is self service allowed?
Service grid packages many micro services or micro services that are used to manage distributed component applications. They overlap a lot with API gateways, but their main concerns are different. A service grid manages the traffic that makes up an application or bounded context service. API gateway manages the north-south traffic of public interface, and focuses on the relationship between user and API. The service grid manages the two endpoints of the connection and is limited to containerized applications. API gateway manages the server endpoint of the connection and can manage any API.
Link to the original text:https://mp.weixin.qq.com/s/6H…