With microservices, you can distribute work evenly across teams while a smaller, nimble team maintains the core platform and communications. For many engineers, these benefits are enough reason to leave monolithic architectures behind. But microservices isn’t just an architectural design—it’s operational as well.
It’s important not to take a narrow view of microservices. There’s a bigger picture to look at, here.
Your data and the source of truth.
Going Beyond the Business Logic
The benefits that drive engineers to start projects with a microservices approach are drawn from the business logic layer and the promise of being able to plug-and-play new services/offerings easily down the road. But when you actually start building out the microservices, you see that the data layer is just as important (if not moreso).
Starting with microservices in mind means you need a detailed understanding of the source of truth. How are you going to combine all the different pieces of data from individual microservices into one model?
As an example, think about how you’ll create a complete view of your customers. In one microservice, you have data about the orders that have been placed. In another microservice, you can see data about their interactions with the different products and how they got to the purchase decision. In microservices, those could be two different customer records with distinct pieces of their journey through the system. But in reality, that is one customer and one journey.
This same data challenge is multiplied across all of your services. If you don’t understand the bigger picture around microservices, data challenges will grow exponentially until the system is as cumbersome as the monolith you wanted to avoid.
From an architectural perspective, microservices is all about mapping the logical splits between system functions. But just as important is designing the orchestration system that makes those microservices communicate effectively and gather data proficiently.
The problem is that this bigger microservices picture leads to a roadblock for engineers - when is it time to actually start implementing microservices?
Starting with Microservices Isn’t Always a Given
When you start down the path of microservices, you quickly see just how difficult it is to design the orchestration layer. This effort will surely take the most of your engineering leadership’s attention and focus. Your engineering team will need to focus on the platform’s technology core and most likely won’t have time to look into the business value added to your customers.
This is when I think of a few wise words from a colleague: “If you haven’t had to deal with re-architecting your system over and over again, you over-engineered it the first time.”
Going through cycles of re-architecting is normal and should be accepted as part of the evolution of any system. You’ve seen giant online systems like Amazon and eBay go through it. Sometimes they even had to go through complete rewrites on the path to microservices. And yet, they’ve arrived at microservices architectures.
That’s why I think it’s important to change the either/or narrative around monoliths and microservices. You don’t always have to start with microservices to be agile, flexible, and scalable. Rather, I think there are situations where it’s perfectly okay to start with a monolith and re-architect your way to microservices.
Doing so might actually help you understand exactly when and how to move toward microservices.
Let me give an example.
For one platform the Dialexa team architected, we originally planned to split the platform into microservices from the start, creating separations based on different logical pieces throughout the application. Instead of moving forward with that plan, we decided to start with a monolithic platform (services and database).
The goal was to split services internally, within the monolith, and monitor continuously from a load perspective (keeping in mind that eventually we would split it into multiple microservices).
And that’s exactly what happened later down the road. As we saw certain services see more and more of the load, we knew those were the logical choices to turn into separate, isolated microservices.
In this scenario, we were able to scale efficiently because we knew which services could be grouped together and which needed isolated management. I’ve seen platforms first hand that suffered from the idea of microservices - you start there and struggle to keep up with maintenance on each individual service.
All of this is meant to show that you shouldn’t let the idea of microservices slow you down. Think and plan ahead, but don’t delay implementation as you try to perfect the split between your microservices. Put something in place, run with it, learn from it, and update from there.
When in Doubt, Ask the Experts
There’s nothing wrong with wanting to start with microservices. You just have to be ready to shift your focus from business logic to architecting a communication protocol and orchestration layer.
However, that shift often leads to an imbalance between the technology and business needs. It’s never good to focus just on the technology - you need to drive toward business value and what you’re bringing to customers.
And that’s why it helps to bring in experts. At Dialexa, we have the tools and experience to help you design and build a platform that delivers the business/customer value you need - whether that means starting with monoliths or microservices.
Get in touch with us today to learn how we can help you with your latest project.