In 2025, many companies are reckoning with the true cost of microservices, especially as cloud bills grow and engineering teams face coordination fatigue. The move back to monoliths is gaining traction, particularly for startups and mid-sized businesses who need:
- Faster product delivery
- Lower operational costs
- Simpler infrastructure
At Scout APM, we’ve been thinking about these shifts not just from a monitoring perspective, but from a broader architectural one. So, to explore what’s driving this return to monoliths, I sat down with Freedom Dumlao, Former Chief Technology Officer at Flexcar (now with Vestmark), and Lance Erickson, our own Head of Engineering, to talk through what they’ve seen in the field. What followed was a candid conversation about architectural trends, tech decision-making, and why sometimes …the best way forward is backwards.
In this first part, we set the stage for that way “forwards” in the next parts by discussing the earlier re-emergence of MVC and the hidden costs of microservices.
Architectural deja vu
SARAH: We're here today to chat about both architecture in general, and a trend that we've been seeing, which is a move back towards the monolith as kind of a preferred method of architecture for a multitude of reasons, but one of them is that it’s the right fit for the problem that we're trying to solve.
I'm Sarah from Scout, from the product team, Lance is our head of engineering, and I’m super excited to have Freedom from FlexCar. To kick off, all of us have been in software for a while. I don't know how old both of you are, but I have been around for longer than I like to remember.
I wanted to talk about trends, because I think that one of the things that I think of when I think of architecture is that we have seen some big shifts in some sort of fanfare and buzz around some of them, which make them feel attractive …even if they're not necessarily the right solution. So, I would love to hear your thoughts on that, just kind of in general.
FREEDOM: Sure. Like yourself, Sarah, I've been doing this a really long time. I think I've gone beyond two decades at this point now. And you know, the thing that's constant in building software is that there are always going to be trends that come and go. And I think early on in my career, as I started seeing new trends emerge for the first time, you know, to me, everything looked brand new, flashy and exciting. And I thought, wow, that's going to be the future.
I had no idea at the time that all of that trendy stuff was, you know, pre-existing concepts that were re-dug up from the past and being reintroduced.
So, like, for example, you know, in the early 2000s, or mid to late 2000s, we actually saw this resurgence of patterns like model view controller, that suddenly became, you know, all the rage, and you saw tons of frameworks like Ruby on Rails, and Django (which is more model view presenter, but very similar). Even some .NET frameworks, like ASP.NET MVC, and, and Monorails, and things like were embracing, you know, this “brand new” MVC trend.
But anyone who had been, you know, building software a decade before would have been very familiar with the concept. So, what felt like it was brand new to me at the time, was actually an older tech that was sort of reintroduced.
And it's funny how often now I've seen that happen throughout my career, where a brand new idea comes and everyone embraces it and jumps on board and thinks, wow, this is the thing of the future, we've got to be doing it. Only to find out, like, we're really just reintroducing and recycling old ideas and using them all over again.
MVC’s new life in the 2000s
SARAH: Yeah, MVC. Did MVC originate in just regular UI programming, or like a desktop environment and then find a new life on the web in the early 2000s?
LANCE: Yeah, I think Smalltalk was one of the original pioneers of the MVC paradigm. And a lot of other great things came out of Smalltalk, too. But yeah, if you look back at the old Smalltalk stuff, you'll see a lot of very familiar concepts for sure.
SARAH: Yeah, I think it's always kind of funny to watch the sort of skepticism – and then adoption – because I mean, for me, it's, I've seen it more around the product world where it's like, nobody's gonna want to do that on mobile. Nobody's ever gonna trust their data with that third party. And then the next thing you know, that's like the main agenda.
Microservices: “This is insane. Just absolute insanity.”
FREEDOM: That's exactly right. Yeah, it's funny, like the topic that we're talking about today is one that I also was an early adopter of – this microservices concept. You know, I was building software, and shipping very large scale software applications, long before people were really talking in any substantial way about microservices.
Then I remember seeing this and saying, like, oh, it's so obvious. Now, really, the microservices concept was a recycling of the concept of service oriented architectures. But I think with some constraints that made it a little bit more palatable. But it just seemed like such an obvious right way to do things.
And I think a lot of that obviousness came from where we were hearing about it from, right? Lance, I don't know if you were like me, and reading Martin Fowler's stuff about microservices in the early days. But then, of course, the world's biggest technology companies were telling us all about how they did microservices. And so, you know, Google was telling us, like, this is how you build software as well as Amazon, where I spent some time working.
So, like every major large scale software company was saying, microservices, this is the way to do it. And suddenly, the next thing you know, everyone's building their software as microservices, it just became the the right way to build software was to do it this way.
Now I've got engineers on my team who've never seen, for example, an n tier architecture application – like they've never seen that – except maybe in a textbook, they don't even know what that would look like.
And it's kind of bizarre.
LANCE: Yeah, I think Netflix was the evangelist that I personally remember receiving the most kind of microservice broadcasting from, I think, that and AWS. These were the kind of places that I was picking up that idea. I don't remember reading Martin Fowler articles, I probably should go back to that.
FREEDOM: Well, if you go back now, you'll find the article where Martin Fowler talks about microservices, then you'll find this other one that everyone ignored that said, you probably shouldn't do this. That was really …it's really interesting. But he's written some great stuff on the topic, and now people are starting to unearth some of the rationale behind the second article that everyone kind of ignored.
SARAH: Yeah, that's funny. I can remember being at this company, and it was before you and I worked together Freedom, but I can remember this like very tense discussion about architecture and somebody just being like, “we are not Netflix, we do not need to scale like Netflix scales”, like we need to think about how we can actually support this internally and not just choose tools because they look fun, or solutions because they look exciting and new.
FREEDOM: So, I guess I wish I thought that way, including myself, to be quite honest. It’s such the right way to be thinking about this. What I saw happen, both in my own department a decade ago, back when we were working together, Sarah – but also all across the industry – was this aspirational idea that we as a technology company, whoever “we” are in the proverbial week, we aspire to be big like Netflix or Google. …and so we should do what Netflix and Google does, which is this, it's really …it doesn't make any sense. But it's very cargo culty, right?
It's like, if I want to be like them, then I should behave the way they do. And it puts us in this position where suddenly like microservices is an excellent architectural choice, so long as you can afford it.
And that's, it's that second piece, I think that a lot of companies overlook because the costs of microservices can be hard to predict. And because it comes in so many different ways, right? Like, every service you deploy has some infrastructure overhead that goes along with that. But then you also start getting other costs such as new network overhead, if I can't, if I have to get data from here, and here into one place, so that I can make a determination about what the right thing is to do.
Now I have multiple web requests instead of just database requests to pull data together. And then I have some extra compute to put it together that I didn't have before. And now I have to figure out how to make that all just as fast as the thing where I was hitting one server and that server was hitting a database, which I can do. Thankfully, the cloud allows me to do so as long as I am willing to spend the money on the higher performance networking interface and the higher performance compute instances. And so that that cost grows as well.
And then you get slapped with the other hidden cost, which is the complexity of the system as a trend as you get the sprawl. You know, we recently got into a position where – I'm trying to remember exactly what the feature was – but the feature was one where on its surface, you would think it’s something easy, you know, like Flexcar from the outside can look a lot like an e-commerce stack. And as we looked at getting that work done, instead of being what I would have assumed would be like one, maybe two engineers to get the work done, it was going to take the collaboration of three different teams across offices in Boston and Bangalore in order to get that work done.
And I just thought, what? This is insane. Just absolute insanity. Because I can remember a time when I was the engineer who was able to get something like that done myself on a similarly sized system in business. And so I just thought …something is wrong. If it takes this much effort and that kind of time to get something done, I just could not fathom that we were doing things the way that was ideal for our business and our size.
SARAH: I feel like the cognitive overhead of all of the different services and how they interface and the teams required, whether it's in one person's head or spread across multiple teams, seems to me to be just a huge limiting factor in microservices in a lot of ways – or for a lot of businesses that maybe would rather spend that human brainpower on something else. And that along with the hard compute costs… It's just a huge iceberg, it feels like additional work and effort that is often hidden by everything else – because it's not easily apparent when you're just trying to get a feature that should be simple.
From like, the human aspect of things – which is more where I've been involved – the sort of myopic take on just your domain, and not thinking about upstream and downstream has some really wild repercussions on the team that I was working on.
You know, we were dependent on another team's API, it didn't handle both requests, our front-end engineers wrote something that just iterated across the giant table to make those requests, took that API down, zero communication.
And suddenly, you know, our users are having a bad time, and nobody really understands why. So it's things being built without thinking about your internal stakeholders, your other engineering teams, and it just opens up so much room for… not a great understanding, especially if you don't have good documentation and good commenting and good testing and that kind of thing. And, you know, that's, that's a big ask.
FREEDOM: All of which has its own cost, right? Like all of those things, documentation, testing, like for a small company or a startup, like Flexcar, all of those things cost us money. Like I have to pay somebody to write those docs and I have to pay somebody to write those tests. And the more of that we have to write in order to maintain and manage the stack, the more expensive it becomes. And it gets quite expensive.
Before we arrested the process and said, you know, this isn't the way we're going to build anymore, we had sprawled out to 69 microservices that we'd built. Now, to be fair, a good number of those were rendering, primarily rendering application code, but it still was a huge stack of services to operate, you know, a business. Now, we are the biggest car subscription company in the US, but we are still a very modes- sized business and shouldn't be paying the penalty that a much larger company could afford to pay in the name of doing things the right way.
