Why a Microservices Hybrid Model Is What You Probably Need Instead
If you listen to most folks talk about microservices, you’ll notice that they tend to discuss them as an either-or proposition: either you refactor your app to run on microservices or you stick with your monolith. It’s easy to understand why people think this — microservices are a complex topic and complexity is easier to master when you boil it down into binary categories.
However, the reality of microservices is they don’t have to be an either-or concept. It’s possible to have your microservices and eat them, too — or, to put it in more prosaic terms, to use microservices for some parts of your application, but not for everything. This applies, of course, even if other components remain based on a monolithic architecture.
Doing so means taking a hybrid approach to microservices. In this article, I’d like to explain what hybrid microservices mean, why you’d use them and how to go about building a hybridized microservices architecture.
The What and Why of Hybrid Microservices
Put simply, a hybrid microservices architecture means one in which some parts of an application are developed and deployed as microservices, while the rest of the application remains monolithic.
If you like analogies, think of hybrid microservices as akin to a hybrid cloud, which mixes public, private and/or on-premises infrastructure together. Hybrid cloud is a pretty popular practice; in fact, I think you’d be hard-pressed to find an organization whose cloud infrastructure is not hybridized to some extent.
If we can hybridize the cloud, we can hybridize microservices architectures, too. Doing so makes it much easier to start reaping the flexibility, scalability and security benefits of microservices without having to refactor a legacy app to run entirely as microservices.
Given that marshaling the developer resources required to refactor a monolith fully into microservices is a big challenge for most organizations, adopting a hybrid microservices strategy is a good way to place microservices within the reach of software delivery teams. These teams might otherwise think that microservices are not feasible for them to implement due to a lack of time and/or expertise in refactoring monoliths.
Best Practices for Creating Hybridized Microservices Architectures
The basic concept of hybrid microservices is easy enough to understand. Things get trickier when it comes to implementing a hybrid microservices architecture. That requires you to identify which parts of your app to “microservice-ize” (I know, that’s not really a word, but I feel like it should be), and which to keep within the monolithic code base. Here are some tips for making those decisions.
Refactor Where the Microservices Payoff Is Greatest
The most obvious and most important thing to do within a hybrid microservices strategy is to identify which parts of your app will deliver the greatest benefit when they run as microservices.
Which parts of the app meet those criteria? The answer will vary according to your unique circumstances, of course, but in general, use these pointers as a guide for determining what to convert into microservices:
- Scalability. Some parts of your app probably have to scale more than others. For example, demand for authentication might peak at certain times of the day, when people log in for the first time, whereas demand for other parts of the app may not fluctuate as widely. In that case, breaking authentication out into a separate microservice would put you in a better position to meet fluctuations in demand for that feature in a resource-efficient way;
- Security. Which parts of your app have the greatest exposure to security threats, and which ones could attackers most easily use to escalate a breach from one part of the app into the rest of it? These components are priority candidates for turning into microservices, which will help to isolate them and mitigate the security risks they pose;
- Updates. One important benefit of microservices is that they enable you to update parts of an application without disturbing other parts. Chances are that some components of your application receive updates more frequently than others. Perhaps you regularly push out interface updates where your backend doesn’t change very often, for example. In that case, you could refactor your application’s frontend as a microservice (or a set of microservices) to facilitate easier updates to that part of the application, while continuing to run the backend as part of a monolithic codebase.
Managing Microservices Complexity
Microservices have lots of advantages, but they also have a big downside: They add considerably more complexity to your application architecture. Dealing with that complexity makes the jobs of developers and admins harder.
For that reason, it’s smart to build a hybrid microservices strategy that minimizes (to the extent possible) the additional complexity introduced by microservices. In practice, this may mean doing things such as determining which microservices will require the fewest API calls in order to do their jobs, or which can be neatly packaged into individual containers. If you prioritize those parts of your app for conversion into microservices, you can avoid having to manage more API overhead or containers than necessary.
Think About the Future
Like a hybrid cloud infrastructure, a hybrid microservices strategy is not a set-it-and-forget-it affair. Instead, it’s something that you should expect to evolve continually. You might begin your hybrid microservices strategy by refactoring only a small part of your app into microservices, but you don’t have to stop there. You can refactor more as time goes on.
For that reason, you should have a microservices roadmap in mind from the outset of your hybrid microservices transition. Even if you don’t commit to specific dates, at least have a general sense of how you expect your hybrid microservices architecture to evolve over time.
Conclusion
We all want to move our monoliths, but the reality is that most of us don’t have the developer resources necessary to convert all of our monolithic code to microservices overnight. Instead of letting this fact get you down and deciding to forswear microservices entirely, consider adopting a hybrid microservices architecture. You can use the pointers above to determine which parts of your application to “microservice-ize” (there I go again, making up words), and which parts can remain monolithic.
