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. Their 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, a question on state and monoliths, one about data and microservices, and on testing microservices. In this fifth and final article we look at the confusion around using API management or service mesh.
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 this:
“How would an API gateway such as 3Scale or service mesh be used to migrate applications to a more modern way of working?”
First off, let’s clarify that this question references Red Hat 3Scale API Management product which is an API management technology offering based on open source community projects. It’s focus is very different that a service mesh technology such as Istio, one of the community offerings.
Now to position how API management’s used, remember 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.
Looking at service mesh technology, it’s 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.
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.
(article co-authored with Burr Sutter)
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: 5 Questions Everyone’s Asking About Microservices (Question 5) Opinions expressed by Java Code Geeks contributors are their own. |
