you don't need microservices

I was once asked by Bryan Cantrill what I thought about the pattern of "nanoservices." At that conference, one of the speakers before me had decried the "anti-pattern" of nanoservices. I disagreed. I disagreed in a very Uber kind of way. For Uber, which at the time had a little over two thousand services, nanoservices (some of the services I was working on back then were less than 500 lines of code) were important because they allowed us to isolate failure modes, increase the fidelity of instrumentation and have better observability.

But I don't work at Uber today. I still think microservices and what you might call nanoservices are the right way to do things. The reason I bring this up is I see a lot of posts on LinkedIn (I know, I know) from people who are ex-this and ex-that and they're thought leaders and whatever, and they proclaim smugly, you don't need microservices. The reason given is that it is a bulky, hard-to-understand design pattern. They say that if you're a startup, running on six figure funding and you maybe have less than ten employees, that microservices will literally put you out of business. And the reason for this is that microservices are expensive. And complicated. And you're going to spend more money building a microservices architecture than you have, and it's going to put you out of business.

the problem, kevin, is you.

Maybe it's a little more complicated to build things decomposed (I'm going to use this term mostly interchangeably with "microservices"; basically "decomposed" architecture breaks a monolith into smaller pieces which are self-contained), especially if you've never done that before or if things like docker and kubernetes are already hard for you.

But it's important to point out that this does not mean that microservices, docker, kubernetes or any of these other technology is the problem. It certainly doesn't mean that those technologies are not appropriate for startups. It means that you are not good at using them, and you are almost certainly doing things the wrong way. You can't blame the computer for doing the stupid expensive stuff you told it to do. That's on you, Kevin.

but i just need to get my app out the door and it's so smol!

Many people tell me this. I don't have an enormous kubernetes or mesos cluster because I'm just one person, and I am, like you, building an mvp. I kind of hate the term "founder" because literally everyone calls themselves a founder, and it seems like in 2025, "founder" just means unemployed. But sure, I'll take that label, too: I'm a founder. I go to meetings, I have told my family, and so on. It's okay. It's fine.

When I set out to build something, I start decomposed. I don't even bother trying to build a monolith. I know that a monolith is debt from the moment I commit it to the repository. I know that one day soon, I'm gonna have to come along and rip it into little pieces and make those pieces talk to each other.

The reason I know this is every single piece of software I build starts with classes and an API. I don't think "I need a generative ai application." When I start building something like that, I think, "I need something that handles requests. I need something that serves as the layer between clients and the listener. I need something that passes requests from the listener to my inference provider." And so on. And I sit down and I spec those things out, and I build classes and I define functions for all of those things (lately I've been using Pydantic, but most of the time I'm a Golang programmer and this is just what we do in Go). I make sure that any interface between two pieces of code (read: smallest irreducible unit of complexity in the application) is robust enough that I can change either side of that interface and the other won't suffer.

A simple example of this is the thing that I am building today. I'm building a stateful conversational agent for this company, Whole, I seem to be building. Because python seems to be the language of LLMs and inference broadly speaking, the heavy lifting is done in python. And I started writing the part that talks to hugging face in python. But all the hugging face example code is written in javascript. It was easier for me to use node for stuff that talked to hugging face, and to continue to build the things I was doing with encoding and decoding in python.

If I had built some big monolith – I have only been working on this for a little over a week – I would have been faced with a decision: do I change languages from python to node? But because each of these pieces are very small and have a very well-defined interface, it doesn't matter what language they're built in. Changing or replacing a component entirely is trivial. So I presently have Go services and Python services, and I use the language that makes the most sense for the job. I am absolutely certain that I will have Go code in this repository in the very near future. If I were doing this in a monolith, and we had just one big app that we use jenkins to build for us, we just wouldn't have the agility to change languages or add additional languages to the equation.

And sure, I'm not Netflix, and I don't imagine I ever will be Netflix. But to say that somehow this architecture is more expensive or more complicated is just an absolute trash take on architecture. It comes from a place of ignorance. It comes from a place of cursing your spanner when you pick up a 6mm and expect it to work like a 3/16". You are using the tools wrong, and blaming the tools.

When this application needs to scale up or scale out, I can scale the parts that are most important to me, or have specific requirements. For example, inference is expensive. But doing http stuff is not. Where do you think the first scaling issue I'm going to run into is? Well, I can tell you today, I'm going to have to scale up for inference, and I'm going to need beastly hardware for inference with big clanking GPU guts (exa.ai published a really neat blog post on how they're doing this). In a monolith, I'd have to put the same process that lives there in the same deployment as the thing that's listening to http requests. That, my friend, is a waste of money.

yeah, linkedin though

I know, right? I really wish there were a way to understand the expertise of a person you are talking to on LinkedIn, because it would save me a lot of hassle and wasted effort talking to people who just have no business opining on these things to begin with.

It's kind of weird to me that, for a community that is so overtly about reputation and your professional network and where-ya-been-what-ya-done, there are these puffed up charlatans telling everyone how to do things, and people are listening to them. It's incredibly frustrating.

So that's the screed for today. I have 37 lines of javascript in a container, and I guess that means I have no idea what I'm doing and my company is going to die, and it has nothing to do with bad hires.