Aka “Get started with Environments-as-a-Service (EaaS)”
As software developers, we are living through interesting times, witnessing an accelerated evolution in terms of software development practices related to environments — for development, testing, staging, UAT, and for other purposes as well, such as security testing or compliance testing.
The broader concept encompassing this movement is called Environments-as-a-Service — or EaaS. I personally see it as the next evolutionary step, achieved through the unification of a few concepts we are already familiar with, like Internal Developer Platform (IDP), Test Environment Management (TEM) Platform, Service Catalog and the new kids on the block: Cloud Development Environments (CDEs), and the one which supercharges everything: Ephemeral Environments.
Why is Environments-as-a-Service (EaaS) important?
For Software Development teams, having the ability to develop applications in a realistic environment is crucial, like is being able to deploy applications for integration and testing. When using EaaS, creating and deploying cloud environments is trivial:
- in terms of effort — all it takes is a few clicks or a couple of command lines to run and you have an environment running in the cloud
- in terms of time — you will have it available in minutes!
This kind of next-gen Internal Developer Platform, offering Cloud Development Environments is a game-changer for development teams and enables the adoption of a different mindset when it comes to developing and reviewing code, as well as testing it — in all forms, from manual or automated testing to security or compliance testing.
Having the ability to create short-lived, disposable environments allows us to eliminate guesswork and time spent mocking dependencies for intermediary testing. It allows us to focus on delivering value to the applications we’re building instead of wasting energy on chores like troubleshooting or replicating configurations related to environments. And it enables true real-time collaboration between team members, including stakeholders.
Environments-as-a-Service (EaaS) in Bunnyshell
Bunnyshell is an Internal Developer Platform that operates on GitOps principles and offers Standardized Development Environments, Preview Environments and Test Environments of all sorts.
In Bunnyshell, you declare how an environment looks like — write its definition — in a YAML format, and then use this definition to create as many short-lived, isolated replicas as you need, for various purposes. An environment is built out of components, configurations, and workflows to deploy, start, stop or destroy the environment.
When defining environment components in Bunnyshell, it is very easy to reuse what you already have today, and link components of different kinds into a unified environment. You can leverage existing:
- Docker Compose configurations
- Ready-built container images (eg: postgres, mysql, mongo, redis etc.)
- Kubernetes manifests
- Helm Charts
- And even non-containerized applications, based on traditional infrastructure running on VMs — these applications can have the infrastructure created with Terraform modules, while provisioning and deploying can be done with custom deploy scripts.
Environments on Bunnyshell run in your infrastructure, either on Kubernetes clusters or on infrastructure you create with Terraform, such as managed databases or managed services, serverless, VMs etc. The Bunnyshell platform can run as well in your infrastructure if you don’t want to adopt the SaaS offering.
Basically, if you look at Bunnyshell from a “black-box” perspective, it is a platform which has inputs and outputs.
Inputs: Git repositories and container registries
Outputs: Kubernetes cluster(s), cloud resources (managed databases or queues, storage buckets), VMs or even serverless runners.
Ready to Automate Ephemeral Environments?
Bunnyshell supports you with access to remote development, properly isolated QA environments, and easy replication of full-stack environments. This will boost development productivity and shorten development cycles.
Self-service at the core
Environments-as-a-Service (EaaS) is all about giving autonomy to development teams so they can do the work themselves.
Bunnyshell stays true to this value by offering developers the ability to see deployment logs (as well as start/stop logs) and also see container logs in real-time, so debugging can be performed without any need for infrastructure access.
On top of that, developers can SSH into containers or forward ports (for connecting to a database, for example) using the Bunnyshell CLI tool.
When using cloud environments for development, the developer experience is the same as on local: the same IDE can be used, debuggers work the same, allowing you to run code line-by-line and see the call stack and variable values, or evaluate arbitrary code.
Every interaction is well-thought and carefully considered from the developer’s perspective.
Starting with Environments-as-a-Service (EaaS) in Bunnyshell
The easiest way to get started with Bunnyshell is through Environment Templates. Bunnyshell offers a few examples, to get you started.
A Bunnyshell environment template contains a demo application and the YAML configuration describing how the environment looks like. You can see all available templates on the website or you can uncover them in the platform, in the Templates section. Just choose one and have your first environment created in minutes.
The great thing about Bunnyshell environment templates is that you can see how the platform works without connecting your resources: no git repository is needed, nor a container registry or a Kubernetes cluster. You can use one of the applications from Bunnyshell’s repository, and the Bunnyshell-offered container registry and Kubernetes cluster to get started and deploy your first application in a few minutes.
A simple application is provided in multiple programming languages and frameworks, for both backend and frontend, and there’s variety in terms of the database as well. For example, you can choose between node.js, Java or PHP for the backend and React, Vue or Angular for the frontend. Postgres, MySQL or Mongo can be used as storage. By using familiar technologies, you can explore the Bunnyshell platform without putting effort into understanding the application itself.
Of course, after you decide to move forward and deploy your application as well, you can define your own custom templates and store them in Git.
Templates are the easiest way to create environments even after you get well underway with EaaS because they give flexibility on one hand, and also keep people in sync with what happens around them, by flagging that there is new work available and allowing them to reconcile changes. No more lost changes due to divergent work, and no more endless time spent troubleshooting configuration drift.
So…
I’d love to hear about your thoughts on ephemeral environments, preview environments, or any other form of automation when it comes to environments. If you have experience — good or bad — it would be great to share it.