What is Environment-as-a-Service (EaaS)?
An Environment-as-a-Service solution is a third-party offering that automates, builds, and manages pre-production environments for your internal org. EaaS solutions are generally adopted by medium and large scale engineering teams to outsource some of the biggest environment pain points that happen when they’re building at scale. This includes cluster maintenance, multi-tenacity, networking, and data migrations.
EaaS solutions are revered as a good investment — they enable orgs with enterprise-grade environment management, something usually reserved for those with sizable Platform or DevOps teams dedicated to exactly this. They’re a shortcut to getting frequent, reliable deployments without the overhead of building dedicated infrastructure.
Features of an Environment-as-a-Service solution
In order for Environment-as-a-Service solutions to add value to your release cycle, they should offer more than just environment provisioning. This minimizes the number of features your team needs to build out, as well as limits developer cognitive load (reduce manual steps whenever/wherever possible!). Here are a few non-negotiables:
- GitOps: short-lived (ephemeral) environments will build and update based on code changes you make to your SSOT repository.
- Role-based access control (RBAC): login and environment access is dictated by an external SSO provider. You’ll grant access to different individuals and teams on a granular level.
- Life cycle management: unlike traditional static environments, EaaS environments should automatically build when needed and spin down after a period of inactivity to best conserve cloud costs.
When do teams adopt an EaaS solution?
Most engineering teams start looking into Environment-as-a-Service offerings when they want to improve their delivery metrics (see DORA). These orgs have a limited number of static staging environments, which quickly bottleneck with merged PRs and only offer a narrow automated testing window before each deployment.
Smaller teams can get away with this: less frequent deployments means PRs flow through the dev → staging → production pipeline pretty efficiently. But for orgs that exceed 20 engineers, this becomes one of the greatest blockers to continuous delivery. Increasing the number of long-lived environments isn’t a feasible solution — they’re incredibly cloud cost hungry, and are on standby for the majority of the time anyway.
Before looking into EaaS, most teams assess their budget and resources to determine whether they can build an in-house environment solution. This is a serious undertaking and gets postponed on the roadmap, practically being on-hold until the org can muster up enough budget and engineers to dedicate to this effort.
This is where EaaS solutions make sense: for a small fraction of the infrastructure/salary costs of developing an in-house environment solution, teams can get a quick turnaround on their deployment metrics.
TLDR: teams can adopt an EaaS at any maturity stage; many tend to prioritize this when they start losing velocity from infrastructure blocks/limitations.
What are some EaaS use cases?
Environment-as-a-Service platforms can replace or supplement your existing static environments. Beyond that, they can improve your internal processes with environments for previously untapped use cases. Let’s say you could have unlimited environments. What would change? Many teams have a few goals on the roadmap:
- Environments attached to every pull request: test code changes before staging, both through automated testing and UAT. Sync latest code changes through GitOps.
- Product preview environments: Design and Product can review and interact with live environments, offering feedback beyond a screenshare/mockup.
- Representative test environments: mirror of production for testing features against real data, integrations, and infrastructure (no more waiting until prod to test).
- Sandbox environments for Sales demos: need to build a feature to close a deal? Send a link to the live sandbox environment to prove it!
Environment-as-a-Service and Internal Developer Platforms
Internal Developer Platforms (IDPs) have a few core components, often sourced from some combination of built in-house and bought. While IDP architecture varies between orgs, environment management tends to be a constant, MVP(latform) feature.
When building a feature-complete IDP, an Environment-as-a-Service tool is a reliable and cost-effective solution for IDP environment management. Most available offerings are easy to integrate with your Internal Developer Portal (e.g. Backstage), and thanks to intrinsic GitOps support, many EaaS offerings can be plug-and-play.
Shipyard: the all-in-one EaaS platform
Whether you’re looking for an IDP environment management plugin or a centralized dashboard for all your available environments, Shipyard has you covered. Shipyard handles every aspect of environment management, including provisioning, life cycle management, access control, GitOps, observability, and database operations.
Shipyard makes it affordable to get enterprise-quality DevOps automation. Shipyard enables teams to:
- Replace product mockup screenshots with live environment links
- Test against every PR before merge
- Run their full test suites 20-40x more per week
- Demo new features to customers with readily-available sandbox environments
- Shift QA and UAT left to before staging/prod
- Improve DORA metrics by shortening dev/test feedback loops
…all while saving 40-70% on cloud costs. Try it free for 30 days, or book a demo to learn more.
