Cloud & DevOps
Infrastructure and delivery you can rely on
Cloud architecture, pipelines, observability and cost, done alongside your team, so releases stop being events.
Triggers
The situations that lead here
Nobody asks for DevOps. They arrive with one of these.
- Releases take a day and need three people watching
- The cloud bill grew faster than the business
- One person knows how production is set up
- Incidents are found by customers before by the team
- Environments differ, so what passed in staging fails in production
- Security and access are handled case by case
- A migration or re-platform is on the table and nobody can size it
The work
What the engagement covers
-
Cloud architecture
Accounts, networks, services and data laid out for the product you have, with the trade-offs written down.
-
Delivery pipelines
Build, test and deploy paths that are boring on purpose: repeatable, fast, and safe to run on a Friday.
-
Observability and incidents
Logs, metrics and alerts that find problems before customers do, and an incident practice the team keeps.
-
Security and access
Identity, secrets and permissions as a system rather than a series of exceptions.
-
Cost
Spend mapped to what it buys, with the waste removed and the growth priced in advance.
-
Infrastructure as code
Environments defined in code, so they match, review like software and can be rebuilt.
What this is, and what it is not
What it is
- Senior cloud and DevOps engineering inside your team
- Decisions on architecture, pipelines and operations, with the reasoning kept
- Capability left in the team when the engagement ends
What it is not
- An outsourced operations desk
- A migration sold before the current system is understood
- Tooling for its own sake
Questions people ask first
Which clouds do you work with?
The one you are on. The work starts from your current accounts, pipelines and incidents, not from a migration proposal.
Is this a managed service?
No. It is senior engineering and leadership on your infrastructure, alongside your team, with the aim that the team runs it afterwards.
How does it connect to the rest of Kendoo's work?
Cloud and delivery decisions sit under the same technical direction as architecture and team performance.
Bring the release that hurt most
Thirty minutes with Amir, starting from your current infrastructure.