- | 5 mins read
Don't even consider micro services unless you have a system that's too complex to manage as a monolith.
It may surprise many to find out that the title of this blog post is an actual direct quote from Martin Fowler.
If you don't know who Martin Fowler is:
a. You should definitely not consider using microservices
b. He's a world well-known software developer, architect, and author. He literally wrote the book on many enterprise design patterns used by developers around the world today.
I miss corporate governance meetings and enterprise service buses about as much as I miss my last root canal. I spent a large portion of my professional career migrating monolithic architectures to SOA (Services Oriented Architectures) or the latest iteration called Micro Services architectures. I did this at companies such as eBay, Ticketmaster, and Upwork. Half of my days were filled with corporate governance and steering committee meetings. We talked about service buses and creating corporate templates and standards that we would enforce on teams to create services. The other half was filled with DevOps planning and work and haggling with the infrastructure teams to provision the hardware we needed. All of these companies were large, established companies with 100's of millions of dollars of revenue per quarter or per year. They had engineering teams that numbered in the 1000's. \
You're NOT Facebook!
Face it; You're not Facebook, Google, Instagram, or Netflix. I get it. It's cool. It's what's in now. Docker, Kubernetes, auto-scale galore! Be honest. Chances are that the app you are creating won't even scale to the level of Basecamp. Unfortunately, the chances of that are almost nil. To create such an architecture would be like engineering your own private F1 car just to drive during your pizza delivery routes. And it would require an F1 sized engineering team to maintain it.
Another factor is that technology is changing so quickly. By the time you finish your microservices architecture and scale it to some meaningful scale, the systems you wrote will be outdated. They will be rewritten and rearchitected anyways. Either that, or you will be stuck with it because the code you wrote is constantly generating revenue and you can't turn it off. This actually happened at Ticketmaster, they had systems so old that they were running on VAX simulators on Linux and pumping out 100's of millions of dollars in revenue per quarter. No one knew how it worked. No one wanted to turn it off. That's a good place to be in. Because you're generating revenue. You can afford to rewrite it completely. Which is what they did.
Premature optimization is the root of all evil. - Donald Knuth
Don't focus on the engineering; Focus on creating value for the business or the end-user. Many engineers miss this and end up building the "perfect system". Technical optimization is hard. Don't waste brain cycles on it. You should be focusing on user happiness and generating ROI.
As I said in my previous article:
Imagine that you have been offered all the shares of a company of a startup company that has a web application product generating 10 million USD net revenue per year. Also, imagine that this web application was written in assembly or Perl CGI. Would you turn down this offer?
Only a hard-headed engineer would say no. And that's why businesses generally don't let engineers make business decisions.
There's no free lunch.
There's a lot of overhead with creating and maintaining services-oriented architectures. Your team must be good at DevOps and maintain all the extra systems that are required. It's harder to debug production problems on Docker and Kubernetes. SysAdmins are cheaper than DevOps engineers. It will be harder to hire engineers who have programming skills AND DevOps skills. It's harder for engineers to run the entire environment on their local machines. You'll have to think about how to optimize communications between the services. Service discovery and registry will have to be thought out and maintained. You'll end up governing how people create services and how they interact. How do you think corporate governance and steering committees got created?!
If you don't believe me, then see what the man himself has to say about this topic. The title of this blog post is a direct quote from Martin Fowler himself.
In enterprise environments, this ends up slowing things down with over-regulation. Just like in capitalistic markets, over-regulation slows down and stifles competition. Engineers spend their days governing and steering other engineers instead of creating value as quickly as possible. In my opinion, this is the number one factor that makes large enterprise organizations slow to innovate. In the book, Lean Startup, it's mentioned that some enterprise corporations realized this and organized teams more like startups so they could innovate faster.
Link copied to clipboard!