Skip to content

Multi-cloud and hybrid infrastructure

Use more than one provider, or your own hardware, where it actually helps: resilience, data residency, cost or bargaining power. Portable tooling keeps the extra work small.

An engineer replies, not a salesperson — within one business day.

  • Start from the reason, not the diagram
  • Portable Kubernetes and Terraform
  • Cross-cloud backup and failover
  • Co-founders do the work

Official cloud partners

  • Yandex Cloud
  • Selectel
  • Timeweb Cloud
among our clients
  • Novotek
  • RZD
  • SberCorus
  • Otus
  • Besttrip
  • JedAI
  • IMSystems
  • Builddocs
  • Headframe
  • RTDS
Case studies →
symptoms.log

When teams come to us

One provider, one account, one region

Your whole business depends on a single provider's availability and pricing.

Data has to stay in a country

Customers or regulators require residency that one provider can't cover.

Accidental multi-cloud

Workloads drifted across providers without a plan, and each is run differently.

GPU capacity or cost

You need compute that your current provider can't supply at a sane price.

scope.md

What we do

Strategy

Which workloads go where, and why — with a cost comparison.

Portable platform

Kubernetes, Terraform or Pulumi modules and GitOps that run the same way on every provider.

Networking and identity

Connectivity, DNS and access management across providers.

Cross-cloud resilience

Backups and failover to a second provider for the systems that need it.

Hybrid and bare metal

On-premises and bare-metal capacity connected to the cloud — including air-gapped sites.

Exit plans

Staged migrations with rollback points, so leaving a provider is a project, not a crisis.

What you keep

  • Strategy memo with a cost comparison
  • Target architecture
  • Reusable IaC modules
  • Unified observability and failover runbooks

Stack

  • Kubernetes
  • Terraform
  • Pulumi
  • ArgoCD
  • DNS failover
  • Prometheus
git log --cases

Similar problems we have solved

All case studies
EdTech

Otus

Traffic comes in spikes around course launches, and paying for permanent spare capacity made no sense.

  • Migrated the infrastructure to the cloud in stages, without service downtime
  • Set up autoscaling for peak load
  • Added monitoring and regular cost reviews
System integration

IMSystems

Deployments for different customers in air-gapped environments had to be repeated by hand.

  • Described the infrastructure as code so every environment deploys the same way
  • Accounted for air-gapped networks with limited internet access
  • Cut the time needed to stand up a new environment
Construction document management

Builddocs

The system ran on its own hardware; maintenance was getting more expensive and capacity was running out.

  • Planned and executed a cloud migration with a rollback plan at every step
  • Set up backups with regular restore testing
  • Built deployment pipelines on the new platform

TEAM.md

Who will work on your project

There are three of us, by design: the engineers you talk to are the engineers who do the work. No account managers, no hand-offs.

  • Alexander Kaloshin — Co-founder

    Alexander Kaloshin

    Co-founder

    20+ years in IT. In 2014 he founded Last.Backend, a container orchestrator built at almost the same time as Kubernetes. Leads our AI practice.

    • Last.Backend: container management and DevOps as a service
    • Fault-tolerant infrastructure: Kubernetes, CI/CD, bare metal
    • Go engineering
    • Speaker at ProIT Fest and GolangConf
  • Alexander Tikhomirov — Co-founder

    Alexander Tikhomirov

    Co-founder

    7 years in DevOps and dozens of delivered projects, from a first pipeline to production under heavy load.

    • Infrastructure design and operations
    • Cloud migrations and greenfield builds
    • CI/CD, Kubernetes, infrastructure as code
  • Denis Gerasimov — Co-founder

    Denis Gerasimov

    Co-founder

    5 years in DevOps. Takes on the hardest problems and sees them through.

    • Complex infrastructure projects
    • Monitoring, on-call and incident response
    • Operations automation
FAQ.md

FAQ

Is multi-cloud worth the complexity?
Often not for an entire stack. It pays off for specific reasons: disaster recovery, data residency, GPU capacity or negotiating leverage. We start from the reason, not from the architecture.
Can the same tooling run everywhere?
Mostly. Kubernetes, Terraform and GitOps cover the bulk. Provider-specific services need adapters, and we're explicit about that cost.
Which providers do you work with?
Our tooling is provider-agnostic, and we run production on public clouds, private clouds and bare metal, including air-gapped sites. Tell us what you use and we'll be specific about our experience with it.
How do you keep costs visible across providers?
Unified tagging, shared dashboards and a monthly cost review.
Do we own everything you build?
Yes. Code, Terraform, Helm charts and runbooks live in your repositories from day one, and cloud accounts stay in your name. If you ever take the work in-house, the handover is documentation and a call, not a rescue project.

Let's talk about your infrastructure

Tell us what is going on today. We reply within one business day with a free initial review.