Services DevOps & cloud
Containers & scaling
Applications packaged as containers and run with capacity sized to the traffic your service actually receives.
At a glance
- Includes
- Container images, orchestration, autoscaling rules, resource limits and health checks
- Works with
- Docker, Kubernetes and the managed container services of AWS, Azure and Google Cloud
- Delivered as
- Container and cluster configuration in your own repositories and accounts
- Starts with
- A look at how your application runs and how its load changes
Fit
Is this right for you?
Usually the right call when one of these sounds familiar.
It works on one machine only
The application behaves differently in each environment.
Traffic arrives in waves
Servers are too small at the peak and idle the rest of the time.
Releases take servers down
Updating one service means restarting the others.
Servers you maintain by hand
Each one has been patched and tuned differently.
Not the right service? Environments to run them in: Cloud infrastructure. Speeding up a slow application: Performance.
Scope
Scope and what you get
Containers and scaling rules are written as code and tuned against measured load. Each piece of work has a matching thing you receive.
- What we do
Container images
Applications packaged with everything they need, built and scanned in the pipeline.
What you receiveThe same behaviour everywhere
An image that runs the same on a laptop, in testing and in production.
- What we do
Orchestration
Containers scheduled, restarted and updated by a platform such as Kubernetes or a managed service.
What you receiveA platform that looks after itself
Failed containers replaced and updates rolled out without taking the service down.
- What we do
Autoscaling rules
Capacity added and removed from measured load such as requests, queue length or memory.
What you receiveCapacity that follows demand
Rules your team can read, with limits agreed so cost stays predictable.
- What we do
Limits and health checks
Resource limits and health checks defined for every service.
What you receiveServices that report their state
Health and load visible in dashboards your team uses.
Use cases
Relevant use cases
Practical situations where this service is put to work. Open a card to see how it applies.
Packaging an application to run the same everywhere
An existing application placed in a container, so testing and production behave alike.
- Image built from a documented recipe
- Scanned for known weaknesses in the pipeline
- Run locally by developers with one command
Handling traffic that rises and falls
Capacity that grows when demand does and shrinks when it passes, within limits you set.
- Rules based on load you have measured
- Upper and lower limits agreed in advance
- Tested with a planned rise in traffic
Running several services on one platform
A set of services with their own limits, health checks and update steps on a shared cluster.
- Each service restarted and updated on its own
- Resource limits so one service cannot starve another
- Shared logs and dashboards for the whole platform
Sample use cases, drafted as placeholders. The Plethora team confirms the final list.
Process
How it works
Four stops, agreed with you as we go. Each shows what we do and what we need from you.
Understand
We doWe study how the application runs, what it depends on and how its load changes through the day and the year.
You doYou give us access to the application, its logs and any load figures you have.
Design
We doWe propose the container layout, platform and scaling rules, with the trade-offs written out.
You doYou choose the platform and the limits you are comfortable with.
Build
We doWe containerise the services, set up the platform and test the scaling rules under load.
You doYou review the changes and test the services on the new platform.
Run
We doWe hand over with runbooks and dashboards, or stay on to tune the rules as real traffic arrives.
You doYou take over the platform, or tell us what support you want.
Quality
Quality and handover
How the work is checked, accepted and passed to you.
Scaling tested under load
Rules are exercised with a planned rise in traffic before handover.
Images scanned
Container images are checked for known weaknesses in the pipeline.
Limits written down
Resource limits and scaling bounds are recorded, so cost stays within what you expect.
A runbook for your team
How to deploy, scale, roll back and read the dashboards.
Tools
Tools and technology
Tools we use in delivery. We choose them to suit your team, and the list does not imply any partnership. Logos belong to their owners.
- Docker
- Kubernetes
- Terraform
- Prometheus
- Grafana
- AWS
- Microsoft Azure
- Google Cloud
Engagement
Engagement and cost factors
Ways to work with us
A scoped project
A defined platform, built, tested and handed over.
A team alongside yours
Our engineers work with yours on the platform and the services running on it.
Ongoing support
We keep tuning the platform as your traffic and services change.
What shapes scope, timing and cost
- How many services run, and how they depend on each other
- How variable your traffic is
- Whether you prefer a managed service or running Kubernetes yourself
- Stateful parts such as databases and queues
- How much support you want after handover
Scope and cost are confirmed with you in writing before work starts.
FAQ
Frequently asked questions
Not always. For a few services a managed container service is often simpler and cheaper to run. We recommend what fits and say why.
Usually. We start by reviewing how it is built and what it relies on, then confirm what is practical.
Capacity grows with demand, so cost can too. We set upper limits and budget alerts with you in advance.
You do. It is delivered to your repositories and runs in your own cloud accounts.
Run what you have, sized to the traffic you get. Start with a conversation.
Tell us what you run today and we will come back with next steps.
Talk to usRelated