Environment Manager enables a self-service model for Development and DevOps teams to create environments while giving enough control to the central Ops, SRE, and Platform teams to enforce security, cost, governance guardrails, and standardization.
Environment Manager reduces the complexity in provisioning public and private cloud environments. Environment Manager takes care of the heavy lifting of deploying and managing the interdependencies between services and resources. Whether this is an S3 bucket for a containerized application or 20 different services deployed in a particular order, Environment Manager does this for you.
It is possible to expose environment templates created through Environment Manager to application teams and enable developer self-service through Rafay's Backstage Plugin. More details available here
How Environment Manager Works¶
Using Infrastructure as Code such as Terraform. platform teams can define resources and the associated configurations and policies across the full cloud stack such as an AWS S3 Bucket, a Redis Cache, a shared EKS Cluster, etc
Platform teams can then stitch those resources together into full-stack templates that contain all the dependencies, policies, and configurations needed to define and deploy complex Kubernetes applications
Finally, developers can then use any interface they want such as GitHub Actions or Backstage to select from these templates and rapidly build and deploy applications to these environments with confidence that they are operating within a golden path and with the latest tools and updates, allowing them to focus on their core responsibilities and be more efficient
Environment Manager Features¶
Rafay Environment Manager will include the following capabilities upon it’s release:
|Native Terraform Support||Platform teams can define any resource such as an AWS S3 Bucket, Elastic Cache, Elastic Load Balancer, etc in Terraform (Terraform Enterprise, Terraform Cloud) and combine those with existing Rafay constructs such as shared Kubernetes clusters needed for full-stack app deployments with the appropriate governance policies and dependencies. All automation is done in Terraform including support for Terraform history of runs, and the ability to define high availability for Terraform agents.|
|Developer Self-Service||Developer teams can provision full-stack environments with a single click (or pull request) via environment templates that live in Git. Environment templates are defined, vetted and maintained by platform teams. Developers get to choose between Backstage, Rafay UI or Git to deploy environments without the need to configure separate pipelines.|
|Secure Multi-Tenancy and Access Controls||Want to use shared clusters? Or do you want to dedicate a cluster per team? Everything in Environment Manager is multi-tenant by default meaning you have flexibility between different operations. Enable developers to deploy complex apps on top of shared compute while having the necessary governance, security, and cost management capabilities needed to make this a reality. Appropriately assign Environment Admin roles to deploy or manage environments based on your organizational requirements.|
|Easy dependency and variable configuration for flexibility and template reusability||Using any syntax you want, such as Terraform HCL or JSON, platform teams can configure the appropriate input variables or global environment variables needed to support different environment deployments while maintaining the same codebase for reusability.|
|Multi-Interface Support including GitOps and UI||Whether you want to leverage GitOps to maintain environment templates or use the UI to make small changes, take advantage of Rafay’s two-way system sync so that changes are synchronized between Git and the Rafay console natively.|
Example Use Case¶
For some organizations, it can take months to test and deploy new apps to production because of the overhead involved in the platform teams actioning on requests for environments from the development teams.
- Developers are ready to test new code/application changes but don’t have access to an environment to test them
- Developer has to go through the organization's ticketing process to request for a resource, for example a namespace on an EKS Cluster or a full-stack environment
- DevOps has to go back to the developer and find out their needs, why they need the stack, whether it will work with their code or some changes need to be made, etc
- DevOps has to make changes to Terraform scripts and validate that with platform and security ops teams, for example to open a port or make some changes to support the developer app
- Eventually, the developer gets the app but has no idea how to use it and refer to certain constructs. For example, if they need to authenticate to a database, what mechanism should be used? There is no golden path and the developer has to spend time getting familiar with infrastructure constructs rather than building and testing code
In the new world, the following can happen in a few steps:
Platform Engineering define IaC and Environment Blueprints/Templates:
- Platform teams, either infra admins or org admins define infrastructure and environment blueprints declaratively and make updates via Git. The blueprints are typically located in a central infrastructure project where all the templates are managed, continuously updated, vetted, etc.
- These templates contain different IaC and Kubernetes manifests in whatever syntax the platform team wants to use - Terraform, RCTL Spec, etc.
- They include things such as governance policies, input variables needed, etc. The goal is to build templates that define a golden path and meet standards but can also be flexible/reusable to meet different developer needs.
Share Templates With Different Developer Teams once the templates are created.
- Platform teams can then offer up these templates to different development teams i.e. different developer projects in Rafay.
- Developers can deploy environments and point their code to these environments while platform teams can.
What does a typical environment stack look like?¶
|Compute||An environment could have the following forms of compute:|
|Shared Cluster / Namespace per Environment: Developers will deploy environments to a shared cluster that is managed by the Platform Engineering team in the Console with the appropriate isolation and security policies defined. In this context, typically every developer environment is deployed to its own namespace.|
|Dedicated Cluster: Some Platform Engineering teams may want each developer to have their own dedicated cluster. This can be enabled using Environment Manager.|
|Cache||Example: Redis cache|
|Queue||Example: Kafka queue|
|Object storage||Example: S3 bucket|
|State storage||Use a system state store or remote backend configuration to store data state files. If a state is lost, the environment will not know of provisioned resources and the destroy/re-apply command will not work|
|Load balancer||Example: Elastic load balancer|