Microservices: The Good, the Bad and the Hype
Microservices may bring many benefits to the enterprise but they also can bring some headaches, especially if you are not anticipating them, argued engineer Michal Franc, during his talk at the Agile Roundabout meetup held in London last month.
Franc presented microservices as a costly tool to solve problems — but those problems have to generate a lot of profit to make it valuable.
Remember, he said, “The first rule of distributed systems is: don’t distribute your system until you have an observable reason to.”
For his talk, Franc explained the lessons he learned from helping his former employer, charity funds platform JustGiving, moving from a monolith to microservices and the cloud.
The Beauty of Microservices
Franc started glass half full, listing the following benefits of a microservice:
- It is easily replaceable.
- It is easily deployable.
- It addresses one business objective or technical capability at a time.
- It can be any size length of code (even 10,000 lines of code, reminding us that “micro” means one service).
- It can be enabled by DevOps or self-service agile infrastructure (everyone is involved).
- It is messaging based.
One of the chief benefits is scalability, he argued. “The system you can easily modify and able to support more load, if it will be able to operate with a million,” Franc said.
You can scale and duplicate microservices horizontally, while a monolith can only scale vertically. Microservices also allow you to scale functionality from a different system. Finally, it can allow data partitioning into smaller databases handling different kinds of data.
“The benefit of microservices is that you give yourself and your system a flexible approach to scalability. Instead of making your whole monolith, you check out where you need scale and you multiply just that deployable part to flexibly scale,” Franc said.
He then said that monoliths are also scalable, but with limits, which “can suit many companies. Microservices are a lot more scalable but they bring in a lot of costs.”
Microservices also offer flexibility. This is where you get to explore the rich diversity of language, technology, and frameworks. But he pointed out that the greater this diversity, the higher the cost. Certainly, a monolith has significantly less flexibility, but with a distributed system like microservices, you have to learn how to deal with transactions and other actions in an asynchronous way.
The Beast Lurking Behind Microservices
“If you go into microservices, you distribute your system and then you have to learn what it is and what it means to work inside a network,” Franc said, offering the following challenges that come along with microservices:
- latency problems
- complexity
- debugging
- security
- connectivity
Franc put up an image of what he calls “micro-monolithic architecture,” that can happen if your microservices transition isn’t planned well, which tends to result in a lot of spaghetti code linking up microservices.
“Most of the monoliths that we build are kind of ‘accidental architecture’,” he said. “When you build your product you don’t know what you want to build, and you decide features and code.”
But then he said you can move the accidental over to microservices, you have to start thinking about the domain.
“When you have a monolith, you already explored your problem space and already have customers,” he said.
Microservices opens up a new opportunity to think via domain-drive design (DDD), placing each project’s focus on a specific domain or purpose and solving problems in that area.
Programmers worrying about whether their architecture will Web Scale is like buying a lottery coupon and fretting about which yacht to buy.
— DHH (@dhh) July 13, 2017
What if You Build Both a Monolith and Microservices?
“I believe that both monolith and microservices are useful tools. it’s up to you to decide which tool is better.” But Franc warned that “This decision might not stay with you for long.”
He offered a third option — building a monolith in a way that is easy to later break up into microservices. But, alas, they are mostly still the result of accidents.
He called JustGiving a continual transition to break away from the monolith. They first tried out microservices with new features.
And it wasn’t easy to break the rest apart. They found particular difficulties in breaking away from Salesforce and Sharepoint, which were so tightly tied to the monolith.
In the end, Franc advised that your transition to microservices should be agile and iterative. And you have to be careful not to lose a lot of money while making the change.
To accomplish this, he says you have to create a strategy, first separating out the pieces of the monolith that require scaling or those that keep breaking causing you a lot of technical debt.
He also warned that “People think about microservices as only about technology. You have to change your organization, team, structure.”
Franc continued that your team has to learn to work separately from each other.
“At JustGiving, it happened naturally but that wasted a lot of time,” he said.
