OpenShift Service Mesh 2.0 has just been released. For many of users, the upgrade brings a bunch of performance improvements and new functionality. Take a look at Jamie Longmuir's post to learn more about the services we build based on the Istio project.
In this article, I would like to convince you that 2.0 is the time to take the plunge into using a Service Mesh. As with most enterprise software, people can be leery of adopting version 1.0 of anything. If you think way back, you might recall that Red Hat Enterprise Linux didn't even have a version 1.
However, the appeal of a framework for aspect-oriented tools in your cloud native architecture are pretty hard to pass up. "What's that Computer Science mumbo-jumbo you got going on there?" you ask? Well, if you think way back to college Computer Science classes or late night discussions of "cross-cutting concerns;" aspect-oriented programming is a way to provide functionality across all (or many) methods and classes in a uniform way. Ever used Attributes in C#, Annotations in Java, or mixins in Ruby? Well, those are actually "aspects" (usually) and allow you to implement a cross-cutting concern like error-handling, parameter validation, auditing, etc. Sometimes people use them for even more sophisticated mechanisms like a Factory Method Pattern.
One criticism, a very legitimate one, is that using these techniques can make your code hard to follow. However, whether you agree with the criticism or not, when you are talking about an architecture, particularly a cloud native one, there are many “threads” through your application consuming many different services. Services providing cross-cutting functionality may actually simplify the understanding of the architecture by reducing the repeated functionality.
With OpenShift Service Mesh 2.0 you can implement functionality that is uniform and simpler than what you do manually, if you did it at all, across your architecture.
At the simplest level, you can, with 2.0, implement secure communication (mTLS) across your services with the infrastructure managing the certificates used and updating them as needed. Leveraging this mechanism of getting secure communication means that your services don’t have to worry about it or even know about it. Going back to the cross-cutting concerns idea, you also don’t have every development team trying to implement secure communications.
You can also implement routing and scaling in your application to tolerate changes in load or outages thereby giving users and “always on” experience even through maintenance. Even better, you can route partial traffic through new versions of your services using the canary and blue/green (aka red/black) patterns to do “no downtime” releases. You even can rollback the service changes for when things go sideways.
Once you have the basics in place, the sky really is the limit in that you can now write anything you want to have happen on every inbound service request in any language that supports compilation to WebAssembly. Previously, you were limited to C++, which is great, sure, but all the cool kids are writing things in Rust these days and now they can play too. Mind you, this feature is still “Tech Preview” but it is coming from upstream and seems like the right, long term answer.
What might you do with custom, cross-cutting code? A common need is custom, complicated auditing functionality to support regulations or certifications. Something you definitely don’t want every dev team to have to figure out for themselves. Logging tools/requirements are also a common need that is unique to your business and software although you can often find good OTS software that you can still run in your service mesh if your needs are simple.
One of the obvious things you might want to build in a cross-cutting way is telemetry of your services and your architecture. However, you don’t need to do that with Service Mesh 2.0. As it is such a common requirement for applications, it is built directly into the platform.
Best of all, OpenShift Service Mesh provides visualization of the complexity of your architecture including where your traffic is actually going, in real time. As a result, you can make heads *and* tails of what is happening in the infrastructure. Also, leveraging the new features of Service Mesh 2.0, the flexibility of metrics collection is improving. Not to mention, in 2.0 the collection of those metrics has been rearchitected to be more performant.
All in all, if you haven’t been ready to take the plunge and implement a Service Mesh thus far, you should really consider it. Even if your applications are more “macro-services” than microservices having a platform that just “gives” you all of this functionality across your architecture, with *no* code changes, seems like a win.
