The Monolith vs Microservices Debate is Back in a Big Way!
Michael Scott Winslow
Transformational Engineering Leader | Author | International Keynote Speaker
I received a text message from one of my favorite human beings Jacob Rozran a few days ago. Since I was busy watching my son's soccer match, I only had time to read the first sentence which read: "I immediately thought of you!"
When I finally had time to read it, Jake was forwarding a post called "Even Amazon can't make sense of serverless or microservices" by David Heinemeier Hansson . Oh wow! I knew exactly where this was going the moment I read it. The industry was finally starting to rise up against the ultimate example of Resume Driven Development(RDD)!
Why did Jake immediately think of you?
In 2016, Jake had to hear me complain about microservices daily since we sat close to each other during the launch of the first mobile phone company born from a cable company, Xfinity Mobile. We were important role players along with many others. Jake was helping create the data-driven models that could protect us from fraudsters and I was leading the creation of the backoffice APIs that would run the sales and activations of phones. We worked closely because his models needed to be imbedded into our sales processes.
I was very proud of the beautiful monolith our engineers had put together. Sure, it was a little off-putting how much was packed into our single fat (.war) file, but our architecture was solid. Namespaces were intelligently thought through and logic was clearly separated. Our CI/CD was simple and reliable largely because our team believed deeply in not creating Self-Imposed Complexity. We were 8 month away from our launch date and we were in a nice groove of being able to extend functionality daily.
That's when the new idea came in. Microservices! More specifically a Microservice Oriented Architecture behind an API gateway with software-based discovery services and graceful failure logic controlled by cloud configuration. Umm... did I mention we were 8 months from our launch date?
In no way did I think that this idea would have any legs. Surely, leadership would not take a risk like this. But the microservices pitch deck was immaculate and the presenter of the idea was a well-respected, very accomplished engineering leader in the company. My much less impressive pitch deck to keep the Monolith and forget about microservices looked something like this:
I was very much against this risky change. In fact, I went on a mission to educate every leader about exactly what microservices were, in what circumstances they are useful, and why we did not need them at this time. So I expanded my rudimentary slides to be much more comprehensive. In the end, I was unsuccessful in my attempt to stop the onset of microservices. I led my team to break down the monolith and we still launched on time. But I have never waivered from my belief that it was a risky and unnecessary decision.
领英推荐
What did you and your team learn?
A lot! I compiled this list of Do's and Dont's when deciding to move to microservices:
DO's
DON'Ts
Was there a bright side?
It turns out that my fierce reluctance of Microservices, followed by my team actually having to implement them anyway, made me a expert on the subject! In the years following our launch, I spoke internally and externally about all the painful lessons our teams learned during that journey. You can check out my talks at DevOps Enterprise Summit or read my LeadDev article on the subject.
Is anyone else fired up that this topic is coming back up?
Experienced SW Engineer/Architect/Manager
1 年Keeping it short. This is just another variant of two design patterns which are basically polar opposites. Each has a number of? advantages, but also have disadvantages, so the best solution should really be neither. Because the elements of a pattern usually entangle? with others the?trade offs are more complex.? Essentially it is a multi-variable optimization problem.? Typically, models of a design do not include all? the key linkages to other elements. That impairs the quality of the analysis.? I have usually needed to get people on the same page of the requirements, especially the non-functional ones. Some of these dimensions have metrics that are? organization or group specific owing to their needs,? such as time to market with 'something'. Thus one design pattern may not be the best for everyone.?? Metrics, like cost, change over time. Thus a good? choice today may not be in a year or two which results in a approach being revisited. The swings back and forth tend to go on over time. The question is what is the design model that that blends the best features of design that you? need and minimizes those that cause the most? pain over the span of time you will be using it.?
I'd be wary of boiling that article to an answer to the debate of "monolith" vs. "microservice", though. I don't think the description of the solution either before or after fit those definitions. The former is definitely a "serverless nanoservice", and the latter still doesn't mix multiple business responsibilities in a way that would make me consider it to be a "monolith". At the end of the day I guess the important takeaways from that article is that when you size your solution you should consider the operational and performance costs that result from adding in more layers of abstraction. And that AWS Step Functions are too expensive at scale even for AWS. ??
Beautifully written article! Some of us thought the same way as you Winslow and never let anyone put their agenda through. Result - happy clients, some for over a decade.
Technology Org Leader Comcast, NRG & goPuff
1 年Great writeup. You story reminds me about how I got into Kubernetes! I think the future is a monolith with pluggable wasm business logic. Takes everything we want from K8s and shrinks it to something manageable and testable.
Sr. Software Development Manager at Amazon Music
1 年I thought of you when I read this article a week or two back too! We did have a hallway discussion about this when you were in Bangalore :) Really interesting how life has come a full cycle!