I will not start this post turning it into an origin story about when we realized the problem and touched with a brilliant solution. The requirement for environments has always existed. Lets revisit the requirement for environments.
What is an environment?
Lets start with a simple case; you have an application that serves your clients. That needs to be up and running for 7/24. The virtual machines and configuration for this app are operated in a mission-critical manner. Such an environment is called a production environment. Because we want to minimise the risk, we keep it secure and the access to a minimum. It is scaled based on our most busy day even with some extra margin. These set of machines and configurations build up to a Production Environment.
Like all the software products, you need to add new features and fix its existing bugs. These actions require another environment that the developers can work on. It does not need to be critically operated but must resemble to the production environments, should be capable of running your app's tech stack. This minimal, non critical environment is called a Development Environment. All your developers need to access it.
Lets assume you have more than one team working on developing new features. That means your app has a lot of moving parts and they must be kept in harmony. Then you need an Integration Environment to see that your app is intact and independent pieces operate consistently with each other.
Why does everybody need them?
The requirement for environments is even more if you start talking about system integration tests, business units testing, performance tests, security tests or maybe a replica of the Production environment to reproduce the very same conditions to find a bug. Seems like there is no end to desire for an environment. Now we understand that there is no point in challenging the requirement, it is sound and real. Lets see the solution part of the problem.
How can I create one?
Creating an environment is a costly job. You need many resources like networks, operating systems, middleware and all the configurations of all these to talk to each other. Some of the resources can only be single but some are grouped redundantly. All of them has its own lifecycle for upgrades and security patches. Even though the pricing model for a public cloud is pay-as-you-go, at least for the primitive types, it is still a high cost at least in terms of human effort. Lets see what we can do to optimize the price and the effort.
Thanks to public cloud providers and CNCF, almost all the resources including infrastructure, platform or even SaaS, and their configurations in an environment can be defined programmatically using the APIs. Modern practices of infrastructure engineering dictate that all the environments should be created with a code-first style. And then it should be treated as code and stored in a versioned store that enables roll backs and roll forwards. Now your app and its infrastructure are both some pieces of code. And the same way you treat your app like a digital product, you should start treating your infra as a product. This is another topic for another post, here.
Now that we have the code that creates it all, we have the full control on the lifecycle of an environment. We can create and kill whenever we want and can modify based on the conditions. And assume our budget is infinite, we don't need to limit the number of the environments we create. In a real world example whatever your business is, an infinite budget is not realistic, so change the assumption to the cost of an environment is minimal. In this imaginary world, we can be the all-father of these environments and decide the faith of each and the population.
Below is a visualization of this idea.
There are some trendy terms that call such solutions as ZeroOps, environment-as-a-service. I would rather call that a problem of creation and deletion of environments, and coding them in a standard and controllable way. Such solution development can better be called platform engineering.
As all the cloud providers resources and services as APIs, it is only a matter of time to integrate any of them to our infrastructure code.
What is developer access to an environment?
The whole purpose for this engineering is to allow developers or anybody to play with the digital product in their own sandbox. The sandbox needs to be secure, private, ideally confidential yet functional.
The developer needs development time access to this environment. Some basic requirements for such access from a classical control systems perspective (because everything started with the same theory, check it here)
- Input control - to test with different inputs,
- Output visibility - to see the reaction of the app,
- Control the code - to apply the code changes.
