Services DevOps & cloud
Cloud infrastructure
Cloud environments on the major platforms, defined as code from the outset, so they can be recreated, reviewed and scaled.
At a glance
- Includes
- Landing zones, networking, identity and access, cost tagging and budgets
- Works with
- AWS, Microsoft Azure and Google Cloud
- Delivered as
- Infrastructure as code, in your own repositories and cloud accounts
- Starts with
- An assessment of your workloads, costs and constraints
Fit
Is this right for you?
Usually the right call when one of these sounds familiar.
Nothing set up for launch
No production environment yet, only an experiment.
An environment built by hand
Nobody is sure how it was set up.
Testing and live share a space
A mistake in one place shows up in another.
A bill nobody can explain
You cannot tell which team is behind the spend.
Not the right service? Faster, safer releases: CI/CD pipelines. Moving off existing hosting: Cloud migration.
Scope
Scope and what you get
Every environment is written as code and delivered into your own accounts. Each piece of work has a matching thing you receive.
- What we do
Landing zones
A separate account or subscription for development, testing and production, with shared guardrails set once.
What you receiveAn environment you can recreate
The same code builds a new environment the same way, for testing or after a failure.
- What we do
Networking
Networks, subnets and private connections written in code and reviewed like any other change.
What you receiveDocumentation that matches what runs
A written description of how the environment is built and how to change it.
- What we do
Identity and access
Roles granted by group and by need; service accounts and secrets handled apart from people.
What you receiveAccess you can review
A clear record of who can reach what, kept in your repositories.
- What we do
Cost tagging and budgets
Resources tagged by team or project, with budget alerts set from the first day.
What you receiveSpend you can read
Cost views your own team can follow without a cloud specialist.
Use cases
Relevant use cases
Practical situations where this service is put to work. Open a card to see how it applies.
A production environment for a new product
A first set of environments, built as code and ready for the first release and the changes after it.
- Production and a test environment set up together
- Access and budgets in place before the first release
- Documented, so the next engineer starts from the same place
Separating development, testing and production
Three separate environments, so work in one cannot disturb another.
- A separate account or subscription for each
- Access set by environment and by role
- The same code creates all three, so they match
Cost visibility for a growing platform
Tags and budget alerts that show which team or project is behind each part of the bill.
- Resources tagged by team, project or environment
- Budget alerts that reach the right people
- Cost views readable without a cloud specialist
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.
Assess
We doWe review your workloads, traffic, costs and constraints, and agree what the environment has to do.
You doYou share access to what exists and tell us what the environment must support.
Design
We doWe propose the account structure, network and access model, with options and trade-offs written out.
You doYou choose between the options and sign off the design.
Build
We doWe build the environment as code in your repositories and check that it can be recreated from scratch.
You doYou review changes as they arrive and answer questions about your systems.
Run
We doWe hand it over with documentation, or keep monitoring and tuning it where agreed.
You doYou take over the accounts and repositories, or tell us what support you want.
Quality
Quality and handover
How the work is checked, accepted and passed to you.
Review before release
Every change goes through review in your repositories before it is applied.
Built to be recreated
We check that the environment can be built again from code before handover.
Written documentation
How the environment is built, how to change it and what to do when something breaks.
A defined handover
Accounts, repositories and access pass to you, with a walk-through for your team.
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.
- AWS
- Microsoft Azure
- Google Cloud
- Terraform
- Kubernetes
- Docker
Engagement
Engagement and cost factors
Ways to work with us
A scoped project
A defined environment, built, documented and handed over.
A team alongside yours
Our engineers work with yours, in your repositories and reviews.
Ongoing support
We keep monitoring, tuning and improving it after handover.
What shapes scope, timing and cost
- How many environments and workloads are involved
- Which cloud platforms you use or want to use
- What already exists, and how much of it can be brought under code
- Security, access and data-location requirements
- How much support you want after handover
Scope and cost are confirmed with you in writing before work starts.
FAQ
Frequently asked questions
We recommend one from your workload, team skills and cost, and write down the reasons. We work with AWS, Azure and Google Cloud.
You do. It is delivered to your repositories and runs in your own cloud accounts.
Often, yes. We start by reviewing what exists and confirm in the assessment what can be brought under code and in what order.
Yes, if you want that. Ongoing support is agreed separately, and the documentation means your own team can take over whenever you prefer.
Build your environment as code. Start with a conversation.
Tell us what you run today and we will come back with next steps.
Talk to usRelated