Five Questions Everyone Is Asking About Microservices (Part 5)
How would an API gateway or service mesh be used to migrate an application to a more modern way of working?
Join the DZone community and get the full member experience.Join For Free
When discussing the development impact on existing applications while transitioning to microservices, there are five questions that keep popping up in one form or another. They are the same regardless of the size of the organization and seem to become part of strategy discussions later in the process as organizations move towards microservice architectures.
These articles cover questions that everyone should ask about microservices. They're based on experiences from interactions with organizations in the process of conquering microservices for existing development and for delivering modern applications.
Previously we covered four questions; the performance impact of microservices, dealing with statefulness after splitting up monolithic applications, data and microservices, and a question regarding testing stateful microservices.
In this fourth article, we'll cover the final question centering on the confusion around using API management or service mesh.
You may also like: Demystifying the Event Driven Architecture - An Introduction
API Management or Service Mesh
In this last and final part of the series, we encounter a question that centers around confusion as to what the roles are an API gateway and a service mesh. It goes something like the following.
"How would an API gateway or service mesh be used to migrate an application to a more modern way of working?"
First off let's position how API management's used, remembering that we previously talked about microservice development teams functioning independently much like a business-to-business partner. These development teams have an API that's the front to their particular microservice. Using API management tooling, the development team's publishing their microservice API into their organizations managed API layer for consumption.
Contrasting this is a service mesh technology, which is concerned with microservices being able to communicate with each other in their deployment layers. Think of things like microservice discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh solves the intra-microservice challenges that distributed services encounter and does it in a novel way.
As you can see, each one of the technologies above has a different role to play and we'd offer that each is a necessary component in a successful microservice strategy.
Microservices in Your Future?
Now that you’ve seen the five questions that many are asking out there in the wild, did you notice some of the same questions you’ve been wrestling with? Since they’re based on interactions with organizations in the process of modernizing their service layers, these questions are both actual and relevant as you're transitioning towards modern architectures for delivering applications.
Don't hesitate to head back to the first article in this series and review all the questions covered in this series. These insights should help you make good decisions, tackle the complexity of your existing monolithic applications, and move towards a fundamentally sound microservices architecture for years to come.
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.