The Enterprise Path to Service Mesh Architectures, 2nd Edition

Chapter 5. Conclusion

In many respects, the advent of cloud native is marked by the introduction of Docker. The popularization of containers brought the need for orchestrators. In turn, containers and orchestrators, coupled with the popularity of microservice architecture for their speed of development, smaller surface area to reason over, and decoupling of development teams, lead to service sprawl. The ability to run a number of distributed services brought the need for empowering developers, operators, and service owners with a service mesh.

Service meshes are one layer of your infrastructure and don’t bring all that you need. They do give you the ability to bridge the divide between your infrastructure and your application in ways most people have not previously seen, however. Service meshes and where they layer into the infrastructure makes them ripe with possibility beyond what they are being used for today. We will see growth in the following areas of service mesh usage and see how they change how developers write applications and how product owners manage their services:

• Refine developer experiences by:

  • Offering distributed debugging.

  • Allowing developers to skip past building in many user/tenancy segregation considerations and instead rely on the service mesh to provide enforcement based on configuration, not application code.

• Provide compelling topology and dependency graphs that allow you to not only visualize the service mesh and its workloads but design them ...