Ladies and Gentlemen. We have to talk about something serious. Yes, this is important. I don’t mean to ruffle any feathers. But we’ve got to get this message out to the wild.
You (most likely) do not need microservices.
Stop. Take a breath. Have a seat. Chill out. Get over it.
Now let’s talk about why you don’t need them.
The dream of services
I hate to generalize, but the dream of SOA is typically forged during day-to-day work within some “monolithic” app that you’ve been struggling to extend. It feels like you have to carry a kiddy pool atop your head, half-filled with boiling mud across a priceless Persian rug to work on this thing. It’s slow, confusing and inelegant. Let’s not hold punches. It sucks and you hate it.
I feel your pain. I hate it for you.
Then Groupon blogs about dismantling the monoliths. You go on to read more from Martin Fowler and find Steve Yegge’s post about Amazon’s success with services. It’s only natural to assume slicing the responsibilities of your app into different components would reduce the complexity of your system. That’s unquestionably true, but are you considering the total cost of ownership?
Yeah, I just went all TCO on you. Because it’s real. And it’s not to be trifled with.
Services suck too
I want to keep this short and sweet. Services suck too. Why? In a word, it’s overhead. You’re essentially introducing bureaucracy into your architecture and you better have a mighty good reason to do so.
Independent services will absolutely be simpler. But are they independent? Do they provide business value in isolation? Do they even provide their functionality to two or more internal components? Think really hard about this because every service is a mouth to feed. A plant to water. A pot to stir. A plate to spin. There’s a lot of maintenance to keep a single process running. Aside of operational overhead, the code may get dusty. Simple feeding and watering isn’t enough to keep it healthy. You’ve distributed the problem, not eliminated it.
There’s actually a fantastic write up about the versioning/deployment/coordination overhead required to maintain microservices by Benjamin Wootton over at highscalability.com which does a great job listing some of the costs involved. Be certain you’re getting the right ROI.
Yes I just went all ROI on you.
Monoliths get a bad rap
I feel the “monolithic” app gets an undeserved bad reputation. A well architected large applicaiton can have the same separation of concerns internally without working about the coordination of disparate systems. Take the time to understand why the app became a big unwieldy steaming pile. Were you disciplined with your design? Do you have a healthy test suite? Are you leveraging the proper data stores? Splitting the app into vertical slices won’t actually help any of these problems. A solid separation of concerns within the same code base can yield the same type of flexibility as having several smaller repos. Plus you eliminate all of the aforementioned complexity and can use that energy to keep your garden tended.
A monolith doesn’t have to be an out of shape, immobile mouth breather. It can be Taylor Lewan, a 6’8″ 309lb offensive tackle from University of Michigan who clocks a 4.89 in the 40, hits hard and is very good at his job.
Services won’t help a lot of the problems people think they will. Discipline is necessary. With services, that discipline requirement is multiplied.
Maybe you really do need them
Of course there’s a time and a place for going the service route. Let’s dig further into Groupon. They survived (thrived even) on a monolith for years before converting to microservices. They took the proper course of action by waiting for the tipping point where distributed services made sense. Another perk is they could look at the monolith and understand exactly how to dissect it. Their migration to services shouldn’t serve as a lesson that services are the way to go, but rather that you can always switch down the road. You won’t get locked in to the monolith. Trust me.
As always, wait until you have the problem before you solve it. Assuming the service landscape is right from the onset is a surefire way to get you where assumptions usually get you. Consider the big picture, don’t let history cloud your judgement, and walk before you run.
Feel free to yell at me in the comments. I’d love discussion around specific scenarios.
Stay Classy.
DevMynd is innovation firm in Chicago and San Francisco with practice areas in custom software development, mobile and web application development.
