By Christian Posta
Translator: Luo Guangming
Original text: blog.christianposta.com/challenges-…
Editor’s note
The author describes the challenges facing enterprise organizations in adopting the service grid, suggests that enterprises should start with the data plane, learn about it, become familiar with it, and then scale up to use it, and introduces the steps of architecture evolution using his presentation slides as a starting point.
The body of the
Recently, I wrote an article on the challenges of adopting a service grid in an enterprise organization for a report on DZone and its migration to microservices. In this article, one of the first questions we addressed was “Should you go down the path of service grid adoption?” and HERE’s what I said:
Answer “No” first. If you are just starting out with microservices architecture and a small number of services, make sure you have the basics ready first. Microservices and their associated infrastructure are an optimized way to make changes to your applications faster. Without a service grid, you can move in a faster direction. You might even want some of the benefits of a service grid, rather than focus on all of its complexity. So, take a look at something like Gloo, an API gateway built on Envoy proxy.
I think this is a very important consideration at this point for two main reasons:
- Overall, the service grid implementation is not ready for production.
- The complexity of all-in investment into a service network remains high.
This does not mean that no team has successfully used the service grid, or that you should stay away from it. However, I do think you should build the capability to eventually successfully introduce the service grid when you are really ready and can benefit from it. For example, in the report, I list the reasons why you might want to use a service grid:
- Deploy a large number of microservices across multiple clusters
- Mixed deployment of container/K8S and virtual machines
- Heterogeneous deployment of languages used to build services
- Incomplete and inconsistent views of network observability
Even with all these reasons, you still face these challenges:
- Which service Grid product to choose?
- Who will do the technical support?
- Multi-tenant problems in a single cluster
- Lack of multi-cluster management methods
- How existing services fit (sidecar life cycle, race conditions, and so on)
- Where do developers and operations draw the line
- Non-container environment/hybrid environment
- Centralization vs. decentralization
Through my combined work at Red Hat and now Solo.io for over two years, I’ve been helping people solve tough problems (by the way, if you want to talk/need help with these things, you can contact me at @Christianposta). But one thing I have been observing from our customers/users and have been recommending for some time is that your first step in adopting a service grid should always start with some degree of (self-isolating) data plane technology, understanding how it works, how it is implemented, how it is debug-ed, etc.
For example, in a recent talk I gave, I said to start with Envoy, the underlying data plane technology for many service grid implementations. PPT is as follows:
From an architectural point of view, it might look like this:
Of course, if you’re going to use Envoy, I recommend starting with Gloo, which is basically an enterprise version of Envoy with EDGE and API gateway capabilities, nicely integrated into the service grid. Once you have it and become comfortable with it, then you’ll be ready to increase its use and perhaps even introduce some isolation through layering of agents:
The next approach is to push the gateway into the application architecture. We saw our users take a gateway approach at each application boundary, beginning to have a “feel” of a grid, but introducing some structure into the application (for example, the API gateway pattern). I started calling it the “waypoints” architecture. Just as pilots use waypoints to guide their flight plans, these gateways add structure to your application architecture, while addressing north-south communication issues such as security and API decoupling, while laying the foundation for successful adoption of a service grid.
Finally, you can begin to introduce boundary-independent service grid agents into your applications to solve the thorny but very service-to-service communication challenges that service grid technologies are best at solving:
The important part here is the gateway, and still has very useful uses! They add structure and waypoints to the application architecture, while separating and hiding some implementation details from other services where needed. In many ways, this follows the DDD bounded context model, where gateways provide an “anti-corruption” layer. Otherwise, if you just treat all services as “buddies,” you’ll be firmly on your way to the Death Star:
Hopefully, this article has helped you lay out a successful approach by using the service grid on a small scale, then gradually scaling it out where it makes sense, and your applications can benefit from the service grid architecture. Otherwise, you run the risk of introducing too much complexity at once, which defeats your intent to modernize your applications and infrastructure.
About ServiceMesher community
The ServiceMesher community was launched in April 2018 by a group of volunteers who share the same values and ideals.
Community focus areas: container, microservice, Service Mesh, Serverless, embrace open source and cloud native, dedicated to promoting the vigorous development of Service Mesh in China.
Community official website: www.servicemesher.com
