🔟Environment On Demand

Modular Infrastructure As code, delivery pipelines as code, configuration management, test driven delivery, zero downtime deployments.

Modern infrastructure faces various challenges especially due to manual setups which leads to untraceable changes in systems making every server a work of art on its own.

Then there are classic issues like code works in local machine or container, but fails in Production, testing takes forever etc.

Environment On Demand is a setup of having an environment that can be brought up, tested, decommissioned or recreated on demand within a few minutes. This enables performance based auto scale, continuous delivery, backward compatibility and immutable infrastructure.

Basically you treat environments line commodity items. Of course not Production :) because that will be disastrous.

For secure, scalable and sustainable software development and delivery you need multiple production like environments on demand so end to end testing can happen faster and efficiently.

So heres what we need to create Environment On Demand

Modular Infrastructure As Code

Don’t just automate, modularise and parameterise server configurations, relationships with other servers in code.

Server configuration, packages installed, relationships with other servers etc should be modelled with code to be automated, removing error prone manual steps.

For example, If you are using terraform don't create one module and try to execute every resource from that. Instead create independent modules for each infra component and a separate module to provision these. These can be called module and provisioners. Here is how modules and provisioners structure for can look like.

Configuration Management

Automate model server configurations, parameterise everything, relationships with other servers, packages in code. This is called Configuration Management.

Configuration is especially useful for software upgrades, patching, files/folder creation, user management and more. This code should always be version controlled.

For instance we can (and should!)

• Tag, branch and release the code that define our servers.

• Have a lifecycle that covers different stages through the infrastructure code, ie. dev, QA, production.

• Continuously test your infrastructure as you make changes.

Test Driven Delivery

Test before delivery. Host a production like environment right at your dev laptop and the same in QA. So all engineers(Devs, QAs, BAs etc) have a prod like environment to test the same code that will eventually go in production.This way more bugs are caught before it goes to production.

Write tests to validate functionality of each module. This must run each up the module gets configuration update to ensure the base functionality works

Integration test are needed to test service to service, app to service, service to db or integration with third part services.

Infrastructure must be performance tested to meet the benchmarks before going live in production.

User acceptance tests to ensure business scenarios must be ensured.

Pipeline As Code

• When is comes to infrastructure provisioning its better not to just run execute commands manually from local host or any remote machine. Instead create parameterised jobs/tasks that can be executed in stages in a pipeline.

• Create version controlled CI/CD pipelines as code for provisioning infrastructure. There must be separate stages for specific tasks. For example, you can have one pipeline for creating a Kubernetes cluster with separate stages for different environments like dev, test, prod etc.

• Pipeline as code can be used beyond provisioning, for upgrades, patching, data migration, in short any automated task that happens in infrastructure.

• And not to mention the logs and historical tracing report that can be generated from pipeline as code are a must during infrastructure audits. It's not possible to the same from any cli or terminal of a standalone machine.

• Other benefits include parallel execution of variety of tasks from a CI/CD platform, which otherwise is not possible from a standalone machine.

Zero Downtime Deployment

• A deployment model where zero downtime occurs for the end user services, in short no downtime experience by the users using that service/platform/system.

• This includes strategies for blue-green, rolling and canary deployment for platform upgrades, infrastructure scaling, new deployment or any other change event.

• To achieve this high availability for persistent storage using network file storage with geo-replication across data centers is a must.

Centralised Command Center

• One stop centralised command centre for infrastructure administration

• Prevents vendor lock-in.

• Centralised logging, monitoring and identity management for better observability

Summary

• EOD ensures test driven delivery for consistent and reliable releases.

• Production like environment on your machine in minutes will be a reality now ensuring consistency across all environments.

• Automated and scalable environment on demand can enable faster time to market by making production releases from weeks to days.