DevOps & Cloud practice
DevOps and cloud: making deployment boring
A good deployment system is recognisable by the fact that nobody finds it interesting any more. It runs in the middle of the day, it is reversible, and it does not tie up three people on a Friday evening.
Many organisations moved to the cloud without changing how they deploy. The result is infrastructure rented by the hour but managed by hand: costs rise, reproducibility does not exist, and the knowledge stays in one or two people's heads.
Our end-of-assignment criterion is simple and verifiable: a complete environment must be destroyable and rebuildable identically from your repository. Until that is true, industrialisation is not finished, however many tools are installed.
The symptoms we see most often
- Releases happen in the evening or at weekends, and tie up several people
- Nobody can rebuild an environment from scratch
- The cloud bill grows with nobody able to explain which line
- Monitoring amounts to checking the machine responds
- Backups exist but restore has never been tested
- One single person holds the critical access
How we approach it
The path before the target diagram
A target architecture diagram is easy to produce and commits nobody. What matters is the sequence: which block moves first, where the point of no return sits, and how to roll back at each step.
The restore test, actually executed
An unrestored backup is not a backup. We run a full restore and time it, which gives your real recovery time rather than the one written in the procedure.
Alerts wired to runbooks
An alert that does not say what to do ends up ignored within weeks. Every alert we set up points to a written procedure, and those that do not deserve one are removed.
Recommending simplicity, including against our own interest
Kubernetes earns its keep above a certain number of services and with a team able to operate it. Below that, a managed application service costs less and breaks less often. We regularly advise against it, even though it would be a longer assignment to sell.
Services in this practice
Frequently asked questions
How much can be saved on a cloud bill?
Entirely dependent on your starting point, and be wary of any percentage quoted before the bill has been read. The most commonly affected items are instance sizing, orphaned resources, non-production environments left running and log retention. The audit prices each item separately.
Should everything migrate at once?
No, unless a data centre deadline forces it. A wave-based migration with parallel run and a rollback point at each step costs slightly more and fails far less often. Single-weekend migrations mostly succeed in sales decks.
Do you provide on-call cover?
During business hours under a maintenance contract, yes. Extended on-call is contracted separately, with a written scope and commitments. We do not offer standalone first-line managed services: it is not our trade and doing it badly would be worse than not doing it.
Twenty minutes is enough to know whether we are useful
No sales deck. You describe the need, we say whether it is in scope, at what price and on what timeline. If it is not for us, we say so during the call.