How to keep your service mesh from turning into an integration mess

A service mesh has become a vital piece of infrastructure in a microservice architecture. As with so many trends I’ve witnessed in IT, a fresh approach can work wonders in an experimental setting. When you put together a focused team of your best people and have them fight some epic battle, chances are you will end up winning. We have been there with client-server, with service-oriented architecture, with mobile development, with event-driven architecture, with cloud-native development, and now with service meshes. In each case we learned the lesson that scaling up from the laboratory stage to the factory stage is tough and takes time.

Or have we?

Scaling up

When scaling up an impactful new practice, multiple things interacting at once. For instance, you evolve from an 80% MVP to a full-featured product. Thereby you inevitably increase the overall complexity, if only because you have to tackle the use cases that didn’t make the MVP for having a less than an optimal fit to the chosen solution. Simultaneously, you bring the new approach to more teams, requiring knowledge transfer, oversight, guidance and so on. Your pioneer team also has to transfer at least some of its responsibilities to other parts of the organization and embed them in the regular processes. More often than not, these processes don’t fit perfectly with the new way of working. It may take considerable time to adapt. And all this time, there are impatient businesspeople waiting for this new silver bullet to materialize.

Sounds familiar?

How to plan for success

If you ask me how I would apply the lessons I learned about adopting new technologies to make the novel approach to integration known as service mesh a resounding success, my honest answer would be straightforward. You need to get three things right. And here they are:

1. Create an overview you can trust
   

   A microservice architecture harmonizes beautifully with a Domain Driven Design (DDD). At the core, your microservices expose a system API, and intercommunicate over a service mesh. WSO2 Micro Gateway is a solid way to create a service mesh, as it has a powerful integration with WSO2 API Manager and it smoothly connects to your Kafka and NATS event broker.

   Domain APIs
   On top of the system APIs, you create so-called Domain APIs to expose your domain logic. In fact, this is a crucial part in making DDD work for you. For those of you who want to learn more about how to practice DDD and microservices together, Christopher Lane recently published a nice introduction entitled Domain Driven Design: Things to Remember When Building a Bounded Context. Once you want to get an overview over the flow of information across your microservices, your Domain APIs should be your first stop.

   Sequence Diagrams
   Without question, sequence diagrams are still the best way to design and document your Domain APIs. They are proven to express all the integration patterns you need in composing your Domain APIs from your system APIs. Obviously, both synchronous and asynchronous patterns are supported, allowing you to implement more traditional orchestration-style integration as well as the newer event-driven patterns such as CQRS and the Saga pattern.

   Although you can use PlantUML – as suggested in the article of Christopher Laine mentioned before – or an equivalent tool for your design, there’s a catch. As well as it works for analysis and design, a sequence diagram as a design artefact is not always kept in sync with your current implementation. In other words, as an overview of your running integrations, your documentation is not reliable per se.

   To help assure your all-important overview diagrams are a fair representation of your implementation, you might opt for a quality process – maybe a review cycle, or pair programming. And this process might even work for you. At this point in time. At least mostly. But is it truly one hundred percent reliable? All the time

   Bidirectional sequence diagrams
   So, I have a better idea for you. It’s called Ballerina. This is a modern programming language that is designed with distributed systems in mind. In fact, it completely eliminates the synchronization challenge we mentioned by automating it. You read that right. With Ballerina, you can choose to use a sequence diagram view or a text view of your code. You can switch at any time between the two representations. There really is no difference between the code and the design. The diagram is the code. The code is the diagram.

   No matter if your people are handling an emergency fix, under pressure of deadlines, still building experience, or anything else, with Ballerina you have an overview you can rely on. Under any circumstance. All the time. Trust me, that’s priceless.

2. Add Smart Governance

   Once you have a reliable overview over your microservice landscape, why not use it to optimize your governance processes? API Management is the sensible technology to hook into. More specifically, your API Lifecycle Management is the perfect trigger to add your governance to the development process. In the design phase, when the Domain API is created and prototyped, you can have an early review to assess adherence to security and architecture guidelines. At the time of the publication of the API, you must be sure the API has been well tested and properly implemented.

   If you do not want to micro govern, which you probably shouldn’t, you can simply focus on your Domain APIs only, and leave the responsibility for the system APIs with your domain teams. You can also differentiate your governance policy for different audiences. If the accessibility of the Domain API is limited, there is a lower risk, and a more lenient governance can be appropriate. High-risk APIs, with high volumes and high visibility, should be assessed more rigorously. That’s what I call smart governance.

   WSO2 API Manager allows you to develop different approval workflows for different risk classes of APIs. This is how you can make sure that only appropriately assessed APIs are offered in your API store.

3. Get serious about surveillance

   Design-time governance is an essential part of staying in control. At the same time, it’s not enough. You need to be vigilant about continuously monitoring what’s going on and, if necessary, act to retain control. There are so many affairs you might need to interfere in. Be it simple developers not timely adopting new versions of your API, be it unforeseen usage or even accidental misuse of your APIs. And then there is malicious misuse.

   WSO2 API Manager Analytics is an excellent tool to monitor the usage of your APIs, to generate reports and dashboards, to detect bots crawling for vulnerabilities, and also to raise alert when a possible intervention is needed. You just have to ensure a proper follow-up. And perhaps the best part, it comes at no additional cost.

No excuse

So, now you know how to stay in control of your microservice architecture and keep your integration mesh from turning into an integration mess. It’s a matter of cleverly applying integration technology to make it work for you. As so often, the way you decide to apply it is more important than the technology you use. That’s where we bring the experience for you to tap into.

If you like to discuss this strategy more in depth, you’re welcome as always.