Last week, I posted a blog that addressed the question of whether platform engineering was "the new DevOps." I mentioned that although Gartner had included platform engineering in its hype cycle for emerging technology in 2022, it actually pre-dated DevOps by several years. Time warp!

Of course, this phenomenon is not unique. Case in point: 1970s-era platform boots are back in style, too. Maybe the "everything that's old is new again" fashion merry-go-round holds true for technology, as well.

Then again, maybe not.

A recent blog by Marcin Kolny, a Senior Software Development Engineer for Amazon Prime Video, left a lot of people wondering whether monolithic applications were destined to make a comeback. Kolny talked about how the Prime Video team had shifted away from the serverless Amazon Web Services (AWS) Lambda, moving its monitoring service to a (gasp!) monolithic model. The disclosure sent shockwaves rippling throughout the cloud-native community.

"While onboarding more streams to the service, we noticed that running the infrastructure at a high scale was very expensive. We also noticed scaling bottlenecks that prevented us from monitoring thousands of streams. So, we took a step back and revisited the architecture of the existing service, focusing on the cost and scaling bottlenecks," he wrote. "Moving our service to a monolith reduced our infrastructure cost by over 90%. It also increased our scaling capabilities. Today, we're able to handle thousands of streams and we still have capacity to scale the service even further."

Let the wild rumpus begin

Unsurprisingly, people had #feelings—lots of them. To many in the cloud-native community, Kolny's admission seemed to insinuate that it's both too difficult and too expensive to scale with distributed/serverless architecture. That did not sit well with a former Docker executive, who even called it "an embarrassment."

Others, such as former AWS engineer Daniel Vassallo, had the opposite reaction. "Everyone is surprised Amazon Prime Video is ditching Lambda for a monolith. I saw Lambda being born, and understood it inside out. I was never convinced it would become a suitable application host," he wrote on Twitter. He attributed Prime Video's adoption to AWS leadership forcing serverless technology down the throats of the rest of the company.

This assertion was disputed by Randall Hunt, another former AWS employee. "I have no idea why [Vassallo] is crafting this absurd narrative that AWS leadership was pushing Lambda. Half of them had no idea what Lambda was. The idea that AWS leadership has any input into tech decisions is kind of laughable." Touché.

Kelsey Hightower, a lauded software engineer, developer advocate, and pre-eminent speaker in the cloud-native community, had a different take. He commented that the blog wasn't meant to be a dig against Lambda, the platform that helped the Prime Video team build the service fast and get to market. "It is a testament to the overhead of microservices in the real world," he wrote. "Moving data around is typically an underestimated cost." He added that a monolithic architecture doesn't mean a spaghetti code base. "You should be writing modular code regardless of the deployment model."

Arun Gupta, author, Vice President, and General Manager of Open Ecosystem Initiatives at Intel Corporation—an open source strategist, advocate, and practitioner for over two decades—agreed with Hightower. "Between #microservices and #monolith, there is NORA (No One Right Answer)," he tweeted. "@primevideo used microservices to get started quickly but then moved to monolith to scale (hard scaling limit at 5% of expected load) and reduce costs by 90%."

Replying to Gupta, Mike Chenetz, Head of Product Marketing at Cisco's Emerging Technology & Incubation Group, and host of the CloudUnfiltered podcast, responded, "I totally agree!"

When all you've got is a hammer, everything looks like a nail

Since Chenetz happens to be my manager and gave me the idea for this blog, I probed him for further thoughts on the topic. "Too many people will pick their platform and program to that platform," he said. "It's backwards. You should first think about the needs of the application, then back into the platform that meets your needs. It might be Kubernetes, maybe monoliths, maybe both."

He explained that trends are irrelevant. "Think about memory, distribution, scalability, latency" he continued. "What are the needs of that application? What are the needs of the components of that application? This is where architects are supposed to come in."

The issue goes beyond comparing microservices to monoliths, Chenetz explained. "The same goes for Kubernetes. "The big corporations started doing it. But it doesn't make sense for startups. You need teams to manage Kubernetes. You don't just spin up one or two Kubernetes clusters and then say, 'I'm done.'"

David Heinemeier Hansson, creator of Ruby on Rails and co-owner and CTO of 37 signals (creators of Basecamp and HEY), echoed Gupta's and Chenetz' sentiments. In a blog entitled "How to recover from microservices," he wrote, "Remember that even the likes of GitHub and Shopify run their main applications as monoliths with millions of lines of code and have thousands of programmers collaborating on them. Do you have many more millions of lines of code or thousands of programmers working on the same code bases? If not, exercise extreme caution before even thinking about microservices."

The right tool for the right job

Jan Schulte, a former Senior Software Engineer for a now-defunct German consulting firm called Asquera GmbH, cautioned that it's important to avoid being seduced by "shiny object syndrome." "Sure, the hot, new shiny thing in tech is cool…but only as long as it actually helps you to get stuff shipped," he said.

Schulte explained that it made sense for the Prime Video team to kick off its service with Lambda, since it helped them get to market quickly. Likewise, it made sense to switch to a monolithic architecture once the service had matured and the team wanted more control. "If you're a software engineer, does it matter to you to run your startup code the same way a Fortune 500 company does, just so you can say 'I run my code the same way Amazon does?' Or would you rather ship new features, bug fixes consistently and provide a reliable experience?"

The latter, he said, should be what engineers focus on. "Every software project is unique. To generally say 'monoliths are bad' or 'microservices are dead now, since someone on the Amazon Prime Video team said something' is really comparing apples with oranges. It's all about choosing the right tool for the job at every stage along the way."

All that said, what do YOU think? Was Kolny's blog a bold move, a crazy one, or a humble discussion of the learning process his team had gone through? What are your thoughts about the costs and benefits of monolithic architecture? Let me know in the comments!