Overview

Environment Manager enables a self-service model for Development and DevOps teams to create environments while providing enough control to the central Ops, SRE, and Platform teams to enforce security, cost, governance guardrails, and standardization.

Did you know ?

Environment Manager Lifecycle can be managed through various methods:

• UI
• Terraform
• GitOps
• Swagger API

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.

Info

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 resource templates and associated configurations/policies across the full cloud stack such as a shared EKS Cluster, Redis Cache, S3 Bucket etc.

• Platform teams can then stitch those resource templates together into full-stack templates that contain all the dependencies, policies, and configurations needed to define and deploy applications

• Developers or DevOps teams can use any interface they want such as Rafay UI, GitHub Actions or Backstage to select from these templates and rapidly deploy environments to test applications

Environment Manager Features

Rafay Environment Manager will include the following capabilities upon it’s release:

Feature	Description
Native Terraform Support	Platform teams can define any resource such as an AWS S3 Bucket, Elastic Cache, Elastic Load Balancer, etc in Terraform 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	Environment Manager enables a model for implementing multi-tenancy. 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 Template User role so that developers can deploy/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

Current Workflow

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

New Workflow

In the new world, the following can happen in a few steps:

1. Platform Engineering define IaC and Environment Blueprints/Templates:

   • Platform teams 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.

2. 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?

Resource	Description
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 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

---