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.
In the 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.
Now, in this second part, we discuss the nature of software trends and this leads into questions about the decision-making process when it comes to figuring out the tools for the job and issues of scaling.
SARAH: I was just thinking, just one random kind of unrelated question or thought. When you and I were working together, because we were working in a kind of co-located company that was in Europe and also in the US, I thought it was interesting to see how the trends were very different.
There was always a little bit of tension between technology choices, especially with languages with our European cohort really wanting to go hard with ASP and then internally, that was not what we wanted to do in Boston. So is that something that you see with architecture, is that a little bit more of a kind of worldwide shift and not quite as regional?
FREEDOM: There is, well, I think programming languages and framework trends tend to be somewhat global, but they don't happen all at once globally.
I remember that and at that time we were, there was a huge upheaval against Java and .NET and other enterprise sort of technologies, especially in the US, but generally across a lot of the Western world of software engineering. And the problem that presented at the time was: how do you build a team of people when we've suddenly seen that this technology is a very unflattering technology to have on your resume, right? Like, we could not attract the best talent if we were using it. I think .NET was on the table, Java was also on the table at the time.
I think ultimately we decided to build that on Node, and not because Node was a particularly good choice, but because Node was popular and software engineers who really loved the craft of building software, they were really interested in using Node. And so we were able to hire some great people.
By the way, I remember we had a brilliant group also in Budapest at the time, and of course they were very attached to their roots in C# and .NET, but a lot of them came around and became excellent Node developers as well. I think even one of them was somewhat prolific in creating new NPM packages to support other people who were making that bold journey.
So yeah, those kinds of trends, they're always going to come, right? And I've followed them throughout my career for sure, like I was building software in C and C++, and then Perl when that became viable, and then PHP, and then Ruby on Rails and Python. I've been through a lot.
I think now I've got the wisdom of two decades of doing this. If I keep chasing the next new framework or language that comes out, I'm going to spend a lot more of my time learning the latest thing instead of delivering the feature that my customer really wants from me.
My advice to anybody who is experiencing this themselves, let's just say for example, like you're looking at like Rust right now as a great solution for your company's next set of deliverables – take a hard look and say like, Rust is a fine language and you can build anything in it, and I'm a big fan of Rust as a language nerd. Is Rust going to give you a big advantage in delivering a feature to your customer before your competitor does?
If the answer isn’t yes, then you probably look for a solution where that answer is yes, right? Find the tool that allows you to get the product delivered in a timeline that lets you capture more of the market than your competitor who's out there trying to do the same thing.
One of the things at Flexcar was moving all of those microservices, re-monolithifying almost all of them into a Ruby on Rails application, which was a very internally controversial choice to make, but one that we made very thoughtfully and actually took a couple of months of research to settle on that as the choice. I wasn't certain that it would be the right choice, to be quite honest.
But when you're looking for that tool that lets you ship the feature to your customer more quickly, there aren't a lot of better options than that. Quite frankly, it's a batteries-included framework, it has everything in there. The developers have kept it fresh and they're constantly introducing new stuff, and it just seems to be that all of the original promises of the framework are still in place. A single engineer can end to end implement something without having to get three teams involved to get a feature done. That's really appealing for a company that's trying to grow.
SARAH: Lance, what's your approach when thinking about having to choose a new technology to solve a problem? There are costs associated with learning something new that you're unfamiliar with. How do you balance that?
LANCE: I think there were a couple of points that Freedom brought up that I tend to think about. One is speed – how fast can you get it up and running? Then there is scale – does it need to scale? I think it is critical and perhaps under-asked for the same reasons that we want to use technology that Google is using. How big do we need to get? How many concurrent users is this actually going to serve in a reasonable amount of time before I have to throw it out and start again and think of another solution or migrate to something else?
I haven't done as much hiring in my career, so it's not the first thing that I think about, but I think attracting talent based on the technologies that you've chosen is a big factor or should be a big factor. I don't know what year this was, but I can imagine that Node wasn't maybe the most technically mature choice, if we're talking about some years ago.But it might have been the right choice based on the other factors that have to come together to actually deliver something.
I know personally, at least initially, if I see microservices architecture, I can get excited because I'm like, okay, I will be able to work on things with a well-defined scope that are pretty small, that have a well-understood release path that's probably all automated, and it's just going to be nicely oiled, and things will fit together well. And that can be attractive from a talent position.
But of course, as soon as the design meets the real world, everything binds in different places and things get very, very friction-y very quickly, in my experience. So anyway, that's a thing where microservices, I think, still have some cache.
Everyone is looking for the “right” tool these days, but I think that there are some general purpose tools that are good for a very wide range of jobs. I mean, we've seen this in foundational technologies like databases. Like Postgres, at this point, it is a very mature piece of technology that can act as your primary data store. It can run your job processing, like a task queue pretty handily. It can be special-purposed for time series work with not that much effort or some extra extensions.
That’s what I look for instead of chasing the hyper-specialized tool that may only have one application in my entire stack and may not be translatable to other products that I want to build. Plus, it may be new and have hidden gotchas that I'm just going to trip over later that are going to be painful for me until version x.x comes out and they're resolved.
…but will it scale?
FREEDOM: Yeah, all the right points. Scale is one that I find engineers, as engineers, we often overestimate how much scale is needed. When we started talking about dropping the microservices stack in favor of something else here and condensing, I think we had a couple dozen Postgres instances and started saying, hey, why don't we put some of these together?
The first question that every engineer asks is, well, will that scale? And the truth is you can answer that question because it's simply a matter of math. I think if we take the moment when we ask ourselves about scale and say like, what's our actual transaction volume now? What's our aspirational transaction volume? What if we went 100x of what we have now? How far are we getting?
This really helped to crystallize the types of decisions we should be making going forward.
But as we did that, it made me think back. I've worked on systems at Amazon where we were dealing literally with petabytes of data on a regular basis, and I remember what those solutions looked like. I've also worked at small startups where we only had a couple dozen customers and I remember what those solutions looked like.
It’s interesting how throughout my career, the systems that I have seen tend to evolve or even start out closer to trying to be that bigger scaled system than what they really need to be. And I wonder if that isn't just because as engineers, we're always looking for a way to prevent failure, right? Like we don't want to end up in that situation where we get the call on Saturday night where it's like, hey, something's wrong. Can you log in? And you log in, you're like, oh crap, like for some reason we chose the wrong identifier scheme and we're about out of IDs and we're going to need to charge this thing.
You don't want one of those things, and so you really build in a lot to like to make it so that you can sleep at night. And I wonder how much of this overestimating scale comes from that desire to be able to sleep well and spend our weekends offline?
SARAH: I think that's a really good point. One of my favorite past colleagues always wanted to refactor everything to be sure that it was future-proof and bulletproof. We were just constantly like, if we do this, we will never get to market in time for this to be viable and we will have no customers and it will not matter.
But it's that tension between product, who's just like driving, driving, driving, trying to be the first everywhere, and engineering, trying to counter that and say, you know, if you launch a brilliant idea that falls over immediately, you know, that's worthless.
So it's that middle ground of we have to be quick, but it has to be at least mostly stable. A lot of these really early companies, kind of one-founder, they're over engineering and over complicating something that has 10 users because they aspire to have a million. But I think you have to have to think about that as just sort of debt that you're building in. I would love for scale to be the problem at any company I work at.
FREEDOM: You know, the nice thing about software is literally that it's not intended to be forever. It's soft. I can rebuild, refactor, and I can change without the expense of having to go to manufacturing. But it's hard to see that because the work is still hard for the individuals who are writing the code and running the implementation and managing the infrastructure.
It’s hard to see that, hey, you know, a slightly smaller investment in the scale and stability could actually be all the difference in getting the thing to market in time to get the customer who's going to make it so you keep the lights on even longer – and you earn the right to invest in scale by adding those customers to your portfolio. Though, it is very human to want to avoid the pain of certain failures.
