CV/Work/Kubernetes scenario

Scenario: health-tech from one server to Kubernetes

A young health-tech company runs its product on a single server and deploys releases by hand. This is how I would move it to a platform with CI/CD, releases without downtime and monitoring across everything. The approach follows the patterns I used to build the Nun Pirat platform.

Starting point

The product is a web application that lets practices share appointments and findings with their patients. It consists of an API, a web frontend and a service for background jobs. Everything runs on one virtual machine, and deploys happen over SSH with a script, usually in the evening. During each release the application is unreachable for a few minutes. There is no test environment, and the logs only live on the server. The team has six developers and no operations staff of its own. Several larger practice groups want to use the product and ask about availability and audit trails.

What is at stake

With every new customer an outage gets more expensive, and a single server is a single point of failure. Evening releases tie up exactly the people who should be building during the day. Without a test environment, bugs go straight to the practices. And because health data is processed, larger customers want to see who changed what and when.

Approach

1. Containers

Each of the three services gets a container image built by the pipeline. Configuration and credentials come from the environment and no longer live in the code. Locally, the team starts everything with one command.

2. Infrastructure as code

I describe networks, clusters, the database, DNS and access rights in Terraform. The provider-specific part stays in a small layer of its own. Hosting is in a data centre in Germany.

3. Staging and production

The same code produces two environments that only differ in size. Kubernetes pays off here because three services need to scale and roll out independently, and more are on the way. For a single application I would stay with containers on one server.

4. CI/CD with tests and migrations

Every change takes the same path. Database migrations run before the rollout. If one fails, the running version stays in place.

5. Releases without downtime

New versions start next to the old ones. Only once they report ready do they receive requests, and the old ones are stopped one by one. Releases can then happen during the day, and a rollback is one step in the pipeline.

6. Monitoring across everything

All services send metrics, logs and traces through OpenTelemetry to a Grafana stack. Every signal carries the version it came from. When the application slows down, the path to the cause takes a few steps.

7. Cost and capacity

After a few weeks in operation I look at what the platform actually needs. Resources are matched to the real load, and the test environment only runs during working hours. That keeps costs traceable as new customers arrive.

The result I would aim for

• Releases happen during the day without downtime, several times a week if the team wants.
• Bugs show up on staging before they reach a practice.
• Every change to the application and the infrastructure can be traced.
• When something breaks, the monitoring shows the cause and the version, without anyone digging through logs on a server.
• After the handover, the team can run the platform on its own.

What it takes

The team needs one person who builds the platform with me and owns it afterwards, and time to bring the existing tests into the pipeline. Decisions are needed on the hosting provider and how strict approvals should be. Costs come from running two environments, the monitoring stack and the time for setup and handover. We work out the exact scope in the first call.

Related