Microservices and service mesh are the latest buzzwords in business application architecture. In the past couple of years, a lot of blogs have been written, a lot of videos have been recorded, a lot of demos have been given on them. However, our conversations with the market show that those organizations that would benefit the most from architecting their applications with those are not clear on their benefits and therefore not implementing them. In this article, I will describe what microservices and service mesh are, and how your organization can take advantage of these technologies by integrating them into your business application strategy through APIs.
Raise your hand if your organization suffers from these:
- You have at least one gigantic application that no one person knows how the whole thing works, yet everybody working on its different parts have to play by the same rules. They need to use the same programming language, and updates impact all the downstream users the same way.
- You have a release calendar for that gigantic application and all the different teams working on different pieces of it have to wait for those dates for the smallest update to their piece.
- All the different pieces of code that will get released go through the same approval process by getting sign off for every imaginable compliance requirement.
- Each time you start an IT project, you start directly from your data sources and build the business logic from scratch.
- You waste large amounts of money and resources on creating the same applications over and over again because different teams don’t know what other teams have already created.
- The application slows down to a crawl during heavy usage periods such as quarter closes or holiday seasons. This causes delays in reviewing financial performance or serving customers, wasted time waiting, and anxiety for your employees and customers.
Microservices architecture relieves these pain points by emphasizing modularity. You implement this style by breaking down your large applications into small and reusable pieces. A different team can be responsible for each piece: meaning they can choose the programming language they are the most comfortable with and they can have their own independent releases without worrying about how the other pieces work or what their timelines look like. All they need to make sure is to define how their microservice interfaces with other microservices. Their code becomes a piece of the greater application; updated independently from the rest of the application and reused in different workflows. And during operation, microservices can be scaled up independently based on their workload for quicker response time, just like hiring seasonal workers.
Microservices sound awesome, don’t they? You create the Lego building blocks without having to mold the whole model… Except that just like life, every good thing comes with a cost. When you break down your application, you need to worry about networking and security. How do you make sure that those independent services communicate with each other? How will you protect your services and data from unauthorized use? How will different microservices find each other?
Service mesh concept was created to answer these questions. You integrate your microservices into the mesh, and the mesh takes care of authentication, authorization, and networking. It separates the data layer and creates a control layer. The data layer is where the day-to-day operation happens through transactions between microservices, and the control layer is where you define the rules of the transactions. Once the rules are defined, all the new microservices added to the mesh obey them without having to be individually configured.
Let’s summarize up to this point: You broke down your gigantic application into small and independent pieces, and you integrated them into the mesh to manage and secure those pieces. You can stop here. Or you can take this one step further by integrating your mesh into API Management because what I described so far about networking and security is what API Management solution providers are experts of. By using an API Management solution that has a top-notch service mesh support, you can secure your microservices with industry tested API security features. You can route the traffic into different flavors of the microservice based on the transaction context or content. For example, when your inventory service is called, if the call is coming from a supply chain manager, you can list raw materials. If the call is coming from a sales manager, you can list end products. And last but definitely not the least, you can publish the microservices different teams created in a single marketplace for other folks to search through and reuse.
In a nutshell, microservices, service mesh, and their integration with API Management makes your applications more extensible, more reusable, and more scalable while cutting the ties between different teams. Coming back to the pain points I started with, with a microservices strategy:
- You can divide and conquer your gigantic application. You can designate teams responsible for its different parts and these teams can work independently without being constrained by other teams’ design choices, skills or requirements.
- Each team can decide their own timeline based on their priorities. You don’t have to go through the same release cycles with every other team.
- You can relax the approval process for some of the microservices that have nothing to do with critical data. This will give you a much faster and less cumbersome turnaround.
- You don’t have to start each project from scratch. You can create a new microservice to embed with the previously created ones to enhance its features or create a different version to give a new flavor to the same task.
- You can see what services others have previously created and reuse them. You don’t have to waste precious money or time just because you didn’t know what’s out there.
- You can optimize your IT infrastructure to have more computing resources during busy times and less resources during stale times. You don’t have to pay for unused capacity while achieving fast response times throughout.
Creating a microservices strategy takes time. But it is well worth it if you consider the time and money you will save once you make your applications more modular. That’s how services that you use every day like Netflix, Spotify, Uber have nimble teams that release code and grow their applications as fast as their markets require. Why don’t you bring the same agility and flexibility to your Enterprise IT?