Opsilla LLC home

DevOps and cloud infrastructure consulting

Menu

Cloud infrastructure your team can ship on.

Opsilla builds and fixes everything between a merged pull request and production: CI/CD pipelines, Terraform, Kubernetes, and monitoring on AWS, Azure, and Google Cloud. We do the work in your repositories and hand it back to your team in working order.

Email us about your project See what we do

What we work with

  • AWS
  • Microsoft Azure
  • Google Cloud
  • Kubernetes
  • Terraform
  • OpenTofu
  • GitHub Actions
  • GitLab CI
  • Argo CD
  • Helm
  • Prometheus
  • Grafana
  • OpenTelemetry

What we do

Take one area or several. We start where it hurts most.

  • CI/CD and release engineering

    Pipelines that build, test, and deploy on every merge, with rollback as a single step. GitHub Actions, GitLab CI, Argo CD, and Argo Rollouts.

    Typical work

    • Move a slow or brittle pipeline to GitHub Actions or GitLab CI, with caching and parallel test jobs
    • Set up GitOps deployment with Argo CD, so what’s in Git is what’s running
    • Add canary or blue-green releases that roll back on their own when health checks fail

  • Infrastructure as code

    Every cloud resource defined in Terraform or OpenTofu, reviewed in a pull request, and applied by a pipeline instead of by hand.

    Typical work

    • Bring hand-built resources under Terraform without downtime
    • Break one large state file into modules with clear owners per team and environment
    • Add plan-on-pull-request, policy checks, and drift detection

  • Kubernetes and platform engineering

    Clusters on Amazon EKS, Azure AKS, or Google GKE that your developers can deploy to without filing a ticket.

    Typical work

    • Build or upgrade production clusters, node pools, and ingress
    • Package services with Helm or Kustomize, with a standard template for every new service
    • Give developers self-service preview environments with sensible defaults and guardrails

  • Cloud architecture and migration

    An account and network layout that holds up as you add teams, environments, and regions. Moves off older hosting go service by service, with a way back at each step.

    Typical work

    • Set up AWS Organizations, Azure management groups, or Google Cloud folders, with production kept apart from everything else
    • Design VPCs and VNets, private networking, and DNS
    • Migrate from VMs, Heroku, or one shared account, one service at a time

  • Observability and incident response

    Metrics, logs, and traces that tell you what broke and why before a customer does. Prometheus, Grafana, Loki, and OpenTelemetry.

    Typical work

    • Instrument services with OpenTelemetry and send metrics, logs, and traces to one place
    • Replace noisy alerts with SLO-based alerts that page someone only when users are affected
    • Write runbooks and set up on-call rotation and post-incident reviews

  • Security hardening

    Least-privilege access, secrets out of the codebase, and a build pipeline you can audit.

    Typical work

    • Tighten IAM, and replace long-lived access keys with SSO and short-lived OIDC credentials in CI
    • Move secrets into HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager
    • Scan images and dependencies with Trivy, enforce cluster policy with OPA Gatekeeper or Kyverno, and keep the audit logs a SOC 2 or ISO 27001 review asks for

  • Cloud cost optimization

    A bill broken down by team, service, and environment, and a clear list of what to cut first.

    Typical work

    • Set up tagging and cost allocation in AWS Cost Explorer, Azure Cost Management, or Google Cloud billing exports, and break down Kubernetes spend with OpenCost
    • Rightsize instances and node pools, and shut down non-production environments outside working hours
    • Size Savings Plans, reserved instances, or committed use discounts against real usage

How we work

Every step ends with something written down, so you always know where the work stands.

  1. Assess

    We get read-only access to your cloud accounts, repositories, and pipelines, and talk with the engineers who run them.

    You get a written report: what works, what’s at risk, and what to fix first.

  2. Plan

    We turn the findings into a scoped plan with deliverables, order, and timeline.

    You sign off on it before any work starts.

  3. Build

    We work in your repositories through pull requests, so your team reviews every change.

    A short written update goes out every week.

  4. Hand over

    Your team gets the code, the documentation, and the runbooks, plus walkthroughs with the people who will own it.

    Nothing we build needs us to keep running.

What we measure

We track the five DORA software delivery metrics. We take a baseline from your Git history, CI/CD runs, and incident log at the start, and report the same numbers as the work goes on. They come from your systems, not from a survey.

Change lead time
How long a commit takes to reach production.
Deployment frequency
How often code reaches production.
Failed deployment recovery time
How long it takes to recover when a deployment fails.
Change fail rate
The share of deployments that cause a failure in production and need a fix or rollback.
Deployment rework rate
The share of deployments that are unplanned and made because of an incident in production.

For cost work, we add cloud spend per service and per environment, from your own billing data.

Ways to work with us

Every engagement starts with a written scope. We quote after the first conversation, once we know what the work is.

  • Assessment

    A fixed-scope review of one area, or of your whole setup.

    Best for
    teams that know something is off but not where to start
    You get
    a written report and a ranked plan you can carry out with us or on your own

  • Project

    A defined piece of work with clear deliverables and an end date: a migration, a new pipeline, a Kubernetes platform.

    Best for
    work your team needs done but doesn’t have the time or the experience for
    You get
    working infrastructure in your repositories, documentation, and a handover

  • Ongoing advisory

    A set number of hours each month for architecture and pull request reviews, upgrade planning, and help when something gets hard.

    Best for
    teams that run their own infrastructure and want an experienced second opinion
    You get
    a standing channel to us and a monthly written summary

About Opsilla

Opsilla LLC is a DevOps and cloud infrastructure consulting company. We work with companies that have their own software engineering teams and run on AWS, Microsoft Azure, or Google Cloud.

We help them design, automate, secure, and operate that infrastructure: CI/CD pipelines, infrastructure as code, Kubernetes, observability, and cloud cost. Clients pay consulting and project fees under a written agreement for each engagement.

Tell us what’s slowing your team down.

Write a few lines about your setup and what you want to change. An engineer reads it and replies, usually with a few questions and a time to talk.

info@opsilla.com

Useful to include

  • Your company and what it builds
  • Your cloud provider and main tools (for example AWS, Terraform, GitHub Actions)
  • What you want to change, and why now
  • When you’d like to start