Skip to content

Instantly share code, notes, and snippets.

@christian-posta

christian-posta/ServiceMeshReview.md

Created January 17, 2020 15:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save christian-posta/5d38e232793059ff653b59e2f4752611 to your computer and use it in GitHub Desktop.
Save christian-posta/5d38e232793059ff653b59e2f4752611 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
ServiceMeshReview.md

Review of service mesh 2019:

In 2019 the common themes for service mesh were:

  • more service-mesh distributions! everyone in the API/software networking space is coming up with their own distributions of service mesh. I think this is natrually a good thing for the market as it shows there is some value to be provided here and that different approaches should be explored. this will also lead us to a point of convergence soon in the future.

  • more organizations are POCing service mesh (up from just having architectural discussions from previous year)

  • usability is key! mesh technology like linkerd has shown how a mesh can be simpler to use and operate, with other mesh technologies taking note and improving their usability

  • istio has consistent quarterly releases which speaks to its stability and predictability

  • consul service mesh debuted their L7 routing features which ties nicely in to the consul model

  • not to be overlooked: although more folks are getting hands on and/or POCing a service mesh technology, it doesn't come without struggles like

    • who's going to support it?
    • it doesn't seem to support multi-tenancy very well
    • not always transparent to existing applications
    • no good VM+containers support
    • what APIs to expose to users

Looking forward 2020:

Service mesh was heating up in 2019 and I expect that to contine more forcefully. 2020 is the year of service mesh in production across more organizations, continued adoption of existing mesh technology like Istio, and some other observations:

  • multi-mesh is here to stay! although there are quite a few mesh implementations out today, eventually convergence will happen. the interesting thing, though, is that i don't think convergence will happen quite like it did with kubernetes (where we all landed on one thing). i suspect there will always be multiple service-mesh implementations that make it mainstream. each cloud provider will have its own provider-native mesh and that will likely be different from the on-premises ones. for this reason, multi-cluster and multi-distribution of mesh will be a dominant deployment reality.

  • web assembly is heating up: web assembly provides a way to securly and safely run user code within a proxy like envoy and we will see service meshes and api gateways like istio and gloo, respectivley, support this very soon. web assembly will allow users/vendors/organizations to provide curated pieces of functionality which alter the default behavior of the proxy for tailored use cases. web assembly tooling will begin to pop up and ways to manage it as well. this will be exciting for those folks struggling to integrate service mesh into existing environments and maintain organizational compatibility

  • optimization of service mesh data plane: i gave a talk at the first ServiceMeshCon last year discussing this (see slides: https://www.slideshare.net/ceposta/the-truth-about-the-service-mesh-data-plane) wherein the data plane of the service mesh begin to see optimizations like running directly in your code, as side proxies, and as shared proxies. For example, gRPC recently added support for xDS APis (grpc/proposal#170) and the CNCF has a working group to help standardize this "universal data plane api" for other uses: https://github.com/cncf/udpa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment