Most infrastructure waste starts with fear, not growth

If you point at any piece of a production architecture and ask someone why it is there, most of the time the answer will be "for scale".

Typically, when a team says that something is "for scale", what they really mean is that it may struggle under a lot of requests. They haven't measured it under the traffic that they expect, but from the way that it works, they expect issues if it gets hit too much. It isn't built for a number they imagined, but for an instinct or a feeling based on their experience.

Instead, they should be measuring its usage, its memory and CPU profile. How much does this feature or endpoint affect the overall system?

Take a look at your own setup and count the pieces that it has. The read replicas, the second region, the extra queue workers, the service that ended up getting split out of the main app because one day it might need to scale independently. Ask yourself what each one is actually doing today, under the traffic that you actually have, and the honest answer is usually "waiting".

I've lost count of how many times I have seen teams reach for autoscaling or microservices, simply because they were afraid of a traffic spike, or a DDoS attack, or some other scaling problem they don't even have.

Scale is usually fear with a better name#

A lot of the time when someone adds a replica, or a second region, or yet another service in order to "scale" something, it is usually out of fear. Fear that their system will crash, that it might go down, or that it will disrupt the day to day of the business.

That's something you need to bear in mind when you build or design a system. It shouldn't be the guiding light when it comes to infrastructure.

When a team decides to build for scale out of fear, it ends up costing them in time and attention as well as architecture decisions. Sometimes that might be a microservice where it's not needed, other times it might be an architectural approach that doesn't fit the needs beyond the "scale" itself. This becomes something that your team has to maintain both in code, and as knowledge.

Most of that protection is imagined as well. A second region doesn't help when the problem is a bad deploy, because that bad deploy goes out to both regions. A read replica doesn't help when the slow query is actually a write operation. What you've actually bought is the feeling of being covered.

"What if" keeps it all in place#

People always seem to be hesitant to remove any redundancy, because in IT we think about disaster recovery first and foremost. That always leads to a more complicated set up than what is needed, and it is the classic "what if" scenario.

Disaster recovery is a reasonable thing to plan for, but the trouble is that every "what if" gets its own answer in the infrastructure, and nobody goes back to ask whether that answer is needed anymore. The pieces end up piling up, and each one has a story attached to it that makes it feel dangerous to touch or remove.

Cleaning it up yourselves never sticks#

If your team says that they will clean it up themselves, there are always going to be parts that they hesitate over, or the next team lead will arrive with a completely different opinion. You start to feel like you are pulling out one Jenga block too many.

Eventually the tidy-up will stall halfway. A few of the obvious pieces go, the scarier ones end up staying, and a few months later someone ends up adding something new for scale. You end up owning the same thing just in a slightly different shape.

The bill is the smaller cost#

The biggest cost is the mental overhead. The extra machinery is there, and the team knows it is there, and someone has to try and balance and maintain it as it grows, all for an unmeasured "scale". It ends up going from an engineer understanding the infrastructure, to needing a dedicated infrastructure engineer all for a label.

Every piece you add is one more thing you have to keep in your head. How it fails, what it depends on, who gets the alert when it does something strange. New developers end up having to learn it before they can ship with any confidence, and none of that work moves the product forward.

But, where does this scale end? What metric are we using to measure whether scaling the application has actually worked? Is there a formula that we can apply to make sure that there are enough nodes or replicas for when we hit the elusive "scale" we always talk about?

There is no formula, so stop looking for one#

The easiest way to decide how much infrastructure is enough is to not think about infrastructure at all. Use a managed service that scales up for you when you need it and back down when you don't.

Trying to measure how many CPUs, vCPUs, RAM or vRAM an application needs is something you will waste hours on, if not days. Instead, go with a sensible default with scalability built in, and monitor it. There may be periods where it goes above an expected threshold. Learn from them, and lean on a system that manages the process for you.

Unless you have the budget for a dedicated infrastructure team, rent one using a platform as a service. Save the headaches, save the questions, and most importantly, save the fear.

Deploying without the fear#

With AWS, GCP, and Azure, the team ends up owning every layer of the process. From the network, to the operating system or container runtime, to how secrets are loaded, to the application and its runtime itself. Every part of the pipeline is yours to own, maintain, and manage. The biggest difference with Sevalla is that you don't have to worry or even think about anything beyond your direct application itself.

When running a production app on Sevalla, all you need to decide now is how many instances you want to scale up to, and how many CRON and queue workers you might need to have running. You no longer need to think about VPCs, servers, networking, IAM roles, or any of the things that usually come with scaling a production application.

No picking a server runtime, and no agonising over exact vCPU and vRAM figures, wondering whether it is enough. Just pick a sensible pod size, set how far it's allowed to grow, and let the platform scale to meet your demand and back down again, the way it was designed to.

The scaling works off what your app is actually doing. When CPU or memory on the instance reaches its target, Sevalla will add another instance, up to the maximum number that you have set in settings. You're only billed for the instances you actually end up using. Turn on deployment notifications and failed deploys land in your inbox. Set up usage alerts and you will hear about spending before it ends up surprising you. You're not sitting on a dashboard waiting for something to break or deploy.

Handing that over doesn't mean flying blind. Each app has Analytics with charts for CPU, memory and instance count per process, alongside requests per minute, response times and the slowest requests, so you can see what it actually used and when it scaled. The runtime logs are there too, in the same place for every app.

If what you are moving away from is the kind of pile that you and your team are nervous to unpick, then Sevalla's support team can help simplify your architecture safely, so that you're not pulling the Jenga blocks out all on your own.

Your team deploys from Git. Sevalla handles the runtime orchestration, networking, scaling, failover, observability, and deployment workflows all behind the platform boundary.

Your code, data, and integrations are all still yours, and you can still see everything else in the logs and metrics.

Some teams really do need it#

So the teams that genuinely need to build their own reliability tend to be financial institutions, where backups of backups and redundancies of redundancies are what you would class as normal.

If you are in that world, or somewhere with similar regulations around uptime, build it deliberately and test it properly. Most product teams aren't though. For them, that level of redundancy is usually protection against a scale problem that they don't yet have, being paid for in time they'd rather spend on their actual product.

Take stock of what the fear is costing you#

If this looks like you, or even if it doesn't, take stock of what maintaining your own infrastructure is actually costing you. The monthly bill is an obvious part of it, but the bigger part is the weight that it puts on your team and on their productivity.

Beyond the bill, your team should be looking at how many processes they have to maintain, how many instances, and how many moving parts there are that they need to take into account when building and managing a production application. Each part means another potential breaking point, and another thing they have to balance when making product decisions. On the other hand, with Sevalla, all you need to think about is how many cron processes and job workers you might need alongside your application. This frees up a lot of mental load, meaning that making decisions is much easier, as there are fewer potential issues to trip over.

If you weren't worried about scaling, would you have released that extra feature you've been meaning to get out? Has the fear of scale stopped you going pedal to the metal on your roadmap?

Sevalla will let you scale to meet the actual demand, and scale it back to meet your budget. The only thing you're giving up for this is the fear itself. You keep all of the control.

Why not pick one service, put it on Sevalla, and just see how much of the fear ends up going with it?