How to resolve with DevOps principles and engineering (part 2)
by Daemonite Des Walker
A good deal of project time is lost in environment churn. Or worse, a ‘good enough’ approach emerges, where you end up using an environment that doesn’t fully represent your desired state.
At Daemon Solutions, we don’t see the challenges of managing environments as insurmountable. Let’s examine some ways to resolve these difficulties using DevOps principles and engineering:
- Have a coherent environment strategy
Have a coherent path for any software you build and test.
Create a clear picture of how many environments you need. Ideally, this should be at least one per test phase. Ask yourself:
- What test phases are we carrying out?
- What does our progression of systems and code look like?
- Where do we need real connectivity and integration?
- Where could we use service virtualisation or stubs instead?
The more testing you do in a controlled manner, the better your software will perform.
Limit full integration until the end of the test cycle, keeping real integrations to one or two environments. The rest you can test using a service virtualisation or stubs, putting you in control.
A high street retail client of ours decided to fully migrate to the Cloud, but made the assumption they’d only need three environments (and these would live forever).
We advised they’d need more as they would be running multiple development workstreams; different data sets put too many demands on only three. Within four months a bottleneck had occurred, which frustrated the entire process. What’s the lesson?
Account for different team access and project work streams as well as test phases. You’ll need enough environments that different workstreams and types of testing are available to everyone.
2. Automate the environment build
Rather than relying on human input, automation holds the key to improving environments consistency. At Daemon Solutions, we advocate building systems as code. This provides two key benefits:
- Instead of risking human error, environments are built from scripts
- You can provision a system whenever you need it
In the traditional IT world, an environment build is split across teams with many steps and dependencies. This sequence can take a long time and is very prone to error.
DevOps principles hold that you should automate as many of the steps as possible. Building the environment this way results in a consistent, faster and repeatable system.
At Daemon our preferred Infrastructure as code tool is Terraform. We use Ansible or Puppet as configuration management tools, but there are lots of options available out there and tools arent the most important decision.
3. Integration virtualisation
Integration of environments will always be an issue, whatever approach you take. However we can reduce the size of the problem by replacing real integrations with virtual services.
Service virtualisation is the creation a virtual service instead of a real integration to a real system. With Service Virtualization, DevOps teams use virtual services instead of production services, so they can test the system even when key components are not ready or available.
Service Virutualisation puts teams in control of their environments. For example when developing a new eCommerce platform, common integrations are payment providers, order management and warehouse management systems. Creating replicas of payment provider systems and order management systems may not be possible and is certainly very costly. By virtualising these systems we create predictability, we increase our speed of delivery and we save cost.
Our mantra: Instead of building 10 integrated environments, build 10 virtual services that mimic the system.
