Services / Cloud infrastructure

Cloud

We design and operate AWS, Azure, and GCP infrastructure for your application

We design, deploy, and operate environments on AWS, Azure, and Google Cloud. We start from the application: database, secrets, traffic, and what stays in the server room. Then we stand up accounts, the network, and the cluster. We deploy the application from Git, staging first, then production, with on-call, copies, and a budget.

Application Stack, database, secrets, and traffic first
Staging The same shape as production, only smaller
Production A deploy from Git, with a record of who shipped
Operations On-call, copies, budget, and a bridge to the server room
How it fits together

From the application to the cluster, the deploy, and on-call

First we understand the application and its dependencies. On that basis we put together accounts, network, Kubernetes, deploys, and monitoring. Terraform, Argo CD, and Grafana are what we use for that work every day.

  • Permissions and logs are in from the first environment. Audit and on-call later use the same base.
  • We pick AWS, Azure, or GCP for the application, the data, and the cost. We add a second vendor when the business needs it.
Terraform Registry, infrastructure providers and modules
01, Terraform

We prepare accounts, network, and permissions for the application

We start with the place the application will run. In Terraform we record accounts, folders, networks, IAM, logs, and rules. Each environment has its own module. A change goes through a plan in a merge request, and the pipeline applies it.

Organization

A separate account for production and a separate one for logs. An incident on one does not open the whole environment.

Network

VPC, peering, PrivateLink, and a link to the server room. Access to the application stays private unless it is meant to be public.

Rules

Policy and mandatory tags. A public bucket only with an exception, a date, and an owner.

Review

The Terraform plan is visible in the merge request. The pipeline applies the change.

Kubernetes Dashboard, pods, CPU and memory
02, Kubernetes

We stand up a cluster for the application traffic and data

On EKS, AKS, or GKE we set network policy, limits, copies, and an upgrade plan. We pick the vendor for the team and for how the application is loaded. We add serverless where traffic is short and uneven.

Add-ons

Ingress, DNS, storage, and autoscaler. We keep versions in code.

Data

A managed database or on the cluster, always with a copy. Application secrets live in vault.

Upgrade

A version plan, a test on staging, a change window with a way back.

Cost

We size the node group from the start. Tags and an alert on a bill spike come in with the cluster.

Argo CD, applications, health and GitOps sync
03, Argo CD

We deploy the application from Git, staging first

The pipeline builds the application image. Argo CD deploys what passed review. Staging first, then production. Cloud permissions stay in the pipeline, with a record of who deployed. The vendor console is for diagnosis.

Environments

The same Helm chart, different values per environment. Production is reached by merge.

Boundaries

A project per team. Production has narrower access.

Secrets

External Secrets or Sealed Secrets, with rotation. We do not keep passwords in the repo as open text.

Failure

Rollback to a known commit. A playbook for the region and for the cluster itself.

Grafana, dashboard catalog and data sources
04, Grafana

On-call sees the application, the cluster, and cost

Metrics from the application, the cluster, and the cloud go to Grafana or stay with the vendor, with a bridge. On-call has one picture. Budget sits next to SLO, so cost and reliability have the same owner.

Telemetry

API, database, queue, cluster, and tag cost. An alert on an application error and on a bill spike.

Logs

Retention, encryption, who may read. The cloud change trail travels with the application logs.

Hybrid

The same dashboard for the cloud and the server room, when the bridge is already in place.

People

The team and finance see the cost of a given service.

How we work

From the client application to production

We start from the application: database, secrets, traffic, and what stays in the server room. Then we stand up accounts, the network, and the cluster. We build the application in the pipeline and deploy it from Git, staging first, then production. We stay for on-call, copies, and cost.

  1. Application We check the stack, database, queues, and traffic model. We agree environments, secrets, and what stays on-prem. That gives the scope: account, region, cluster.
  2. Accounts and network In Terraform we prepare accounts, IAM, network, and logs. Separate production, separate logs. Access to the application stays private unless it is meant to be public.
  3. Cluster and staging We stand up the cluster, add-ons, secrets, and copies. Staging has the same shape as production, only smaller. The pipeline builds the application image.
  4. Production and on-call Argo CD deploys what passed review. After go-live: alerts, copies, budget, and an upgrade window. We add a bridge to the server room when some systems stay with you.
Talk

We will discuss the application, the environments, and cost

On that basis we will prepare a scope: accounts, cluster, deploys, and operations.

Contact us