Cloud architecture
Most cloud bills are not the price of running software. They are the price of decisions nobody revisited.
The default failure here is building for a scale you do not have. Kubernetes, a service mesh and a queue between every component is a reasonable architecture for a large engineering organisation and an enormous tax on a team of four. The complexity is not free: every layer is something to configure, monitor, upgrade and be paged about. Most products are well served by boring infrastructure — a managed database, a few stateless services, a CDN — for far longer than the conference talks suggest.
Infrastructure defined as code is the part worth insisting on regardless of size. Not for elegance, but because a console-configured environment cannot be reproduced, reviewed or rolled back — and the person who knows why a particular setting is the way it is will eventually leave. When the environment is a file in the repository, a change is a diff someone approves rather than a click nobody witnessed.
Cost is an architectural property, not a procurement one. The usual culprits are dull and consistent: data transferred between regions or out to the internet, logs retained at full fidelity forever, environments left running overnight and at weekends, and instances sized for a peak that occurs twice a year. Reducing a bill is rarely about finding a cheaper provider; it is about noticing which of those you are paying for and deciding whether you meant to.
How we work
- Architecture sized to current load with a known path to the next order of magnitude — not built for it on day one.
- Everything in code and under review. If an environment cannot be recreated from the repository, it does not really exist.
- The bill is read as a design document. Egress, retention and idle environments are examined before anyone shops for discounts.
What this includes
Pick what you need and send it over.
Questions
- Which cloud provider?
- For most products it matters far less than the architecture on top of it. Where it does matter is the managed services you intend to lean on, and how hard they would be to leave — a decision worth making with eyes open rather than by defaulting to whichever one your last team used.
- Do we need Kubernetes?
- Probably not yet. It solves problems that appear with many services and many teams. Before that it mostly adds a system to operate, and the honest test is whether anyone on your team would be comfortable debugging it at three in the morning.