Hazel Vane Email us

Cloud and DevOps consultancy

Infrastructure your team can read, change and trust.

We work alongside your engineers to migrate workloads, describe infrastructure in code, build delivery pipelines and set up monitoring that tells you when something is wrong. Everything we build is reviewed in your repositories and written up for the people who run it.

Describe your setup
  • Changes arrive as pull requests in your repositories
  • Every alert we add comes with a runbook
  • Documentation written for whoever is on call

Services

Five areas of work, often combined.

We start where the friction is sharpest, whether that is a slow release, a noisy pager or a bill nobody can explain, and work outward from there.

Ask about a specific service →

  1. Cloud migration

    We inventory what you run today and decide with you what moves as it is, what gets rebuilt and what is retired. Services then move in planned waves, each with a tested way back.

    You getMigration plan, landing environment, cutover runbooks

  2. Infrastructure as code

    We bring existing resources under code, split them into modules your team can follow, and add review and plan checks so every change is visible before it is applied.

    You getVersioned modules, state and access setup, change workflow

  3. CI/CD pipelines

    We build pipelines that test, package and deploy on every merge, promote releases through environments in order, and give you a rehearsed, quick way back when a release goes wrong.

    You getPipeline definitions, deployment strategy, rollback procedure

  4. Observability and on-call

    We agree with you which signals matter, wire up metrics, logs and traces, and write alerts that point to a likely cause and a runbook. Then we help shape a rota people can keep up.

    You getDashboards, alert rules, runbooks, rota and escalation guide

  5. Cloud cost reviews

    We read your bills and usage alongside the architecture, find idle and oversized resources and pricing options that fit how you run, and rank each change by effort and risk.

    You getFindings report, ordered change list, tagging and budget alerts

Engagements

How an engagement works

Four stages that run in order. Each one ends with something written down, so you can pause or stop between them without losing the work.

  1. Stage 1 · scope

    Talk it through

    A call about your systems, your team and what you want to change. Afterwards we write up what we would do, what we would need from you and how we would work together.

  2. Stage 2 · assess

    Read before we write

    We read the code, infrastructure and pipelines, and talk to the engineers who run them. You get a written assessment with the risks we found and a proposed order of work.

  3. Stage 3 · build

    Build alongside your team

    We work in your repositories and your chat, in short iterations, pairing with your engineers. Every change goes through your normal review before it is merged.

  4. Stage 4 · hand over

    Hand over and step back

    Runbooks, documentation and walkthroughs, then your team makes the next changes while we review. We step back once they are comfortable running it on their own.

Contact

Tell us what you run and what is getting in the way.

A short description is plenty: where your systems run, how you deploy today and what you would like to change.

Write to

Plain text is fine. There is no need for a formal brief.

Email Hazel Vane