Microservices Within a Monolith: When to Consider a Hybrid Architectural Approach
One of the primary questions in application development today is whether to build applications using a monolithic or a microservices architectural approach. This is not a brand-new issue, and there are arguments on both sides that make sense.
In a recent interview with The New Builders podcast, CTO Dave Riess shared how Wunder Capital worked through the process adopting an architectural approach that uses elements of both monoliths and microservices.
Listen to Ep. 8:
“The microservice approach looks pretty appealing when you’re coming out of a monolithic environment,” he said. “There are some things that [a microservice approach] does really, really well, and it’s easy to become pretty quickly enamored with some of the benefits it presents.”
In Riess’s opinion, microservices do solve a lot of fundamental flaws in a monolithic application – like how monoliths grow unwieldy as they age, for example. In the age of cloud, dev ops and agile development, it seems like the move to microservices would be a no-brainer, and for some it is, as long as they’re able to fit together a collection of moving parts, and do so in a way that makes changes, management, security and maintenance easy.
But that doesn’t mean the process of building using microservices is always straightforward.
“When you start to dig into it,” Riess said, “running multiple services for specific functional areas of the application becomes quite challenging. You have to embrace things like [remote procedure calls]. While that might not seem like a particularly heavy lift effort at first glance, it does require that developers start considering things like network latency and network stability. It’s not just method calls within a single process.”
If your team is talented, good at setting boundaries between processes and modules, and able to work with various communication protocols, then a microservices approach might be the way to go, says “Building Microservices” author Sam Newman.
Sometimes that means starting with a monolith and then peeling off services as they become clear. Sometimes that means starting with a distributed microservices architecture.
No RPC, No Asynchrony, No Work Across 10 Code Bases
According to developer and blogger Martin Fowler, a hybrid approach, between a monolith and microservices, may be best, but it comes down to a number of factors.
First off, don’t consider using microservices unless the project is large and complex, says Fowler. If the project is fairly straightforward and can be developed easily using one programming language, then a monolithic approach is just fine.
This is because microservices, while extremely flexible and modular, come with a management penalty. This means that applications developed using microservices are highly dependent on the skill of your development team, and the extent to which they can troubleshoot, update and modify the app.
Development teams should also consider speed when evaluating a microservices approach. When developing a new application, it will inevitably go through many rounds of trial and error to get right. Taking a monolithic-first approach allows you to stand up a prototype and iterate much faster. This is where a hybrid approach can pay dividends. The idea is to start the project as a monolith and “by paying attention to modularity within the software, both at the API boundaries and how the data is stored,” you can easily shift to a microservices architecture later on, Fowler says.
Riess and Wunder Capital opted for a hybrid approach by building services within their monolith, but not having them run on different servers. According to Riess: “That allows us to make service calls that are effectively method calls. We don’t have to worry about RPC. We don’t have to worry about the asynchrony you do in a service-oriented world. We also don’t have to worry about working across 10 different code bases.”
The hybrid approach allowed Wunder Capital to compartmentalize the complexity in their namespace servers and set them up for future success.
“Down the road when we achieve a level of scale that justifies breaking out an individual service in a standalone faction, that will be relatively easy to do,” Riess said.
To learn more about what factors Wunder Capital considered when weighing microservices vs. monolith approaches, you can listen to “The Third Way in the Monolith vs. Microservices Debate” a podcast with CTO Dave Riess.
And for more stories from The New Builders podcast, find us on SoundCloud, IBM developerWorks TV at The New Builders, and on iTunes (coming soon). Please send thoughts, feedback, and guest ideas to me at firstname.lastname@example.org or Doug Flora at email@example.com, or reply in the comments.