- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Palo Alto Networks dives into managing microservices complexity, what hybrid microservices means, why you’d use them, and how to go about building a hybridized microservices architecture. Find answers on LIVEcommunity.
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 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.
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 right away.
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.
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 migrate, and which to keep within the monolithic code base. Here are some tips for making those decisions.
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:
Microservices have lots of advantages, but they also add complexity to your application architecture. Dealing with that complexity makes the jobs of DevOps and security 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.
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.
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 learn more about microservices and containers in the on-demand digital summit, Cloud Native Security Live - 2020 Summit.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subject | Likes |
---|---|
3 Likes | |
1 Like | |
1 Like | |
1 Like | |
1 Like |