Managing environments in IT delivery

How to resolve using DevOps principles (part 1)

by Daemonite Des Walker

For any company to successfully release new applications, a good approach to Environments is crucial. Well managed Environments offer three important benefits:

Less time to deploy new software — a faster time to market

Reduced IT costs and fewer human errors

High quality code deployed — reducing the chance of customers faults

Yet environments also present a series of unique challenges, making them complicated to manage.

Getting consistency across different environments is problematic. It’s difficult to govern complex IT infrastructure dependencies, especially as infrastructure is constantly evolving.

It’s my belief that anyone developing or delivering software must have an environment strategy.

This allows you to deploy and test changes in a controlled way. Whether your business is enterprise sized, or smaller, most companies will require at least 4 stages in the development lifecycle of testing.

Stages of testing that require separate environments:

• Development & unit testing
• System testing
• Integration testing
• User Acceptance / pre-production testing

The multiple stages of testing means that companies should not rely on a single environment. If you have four test cycles, that can easily lead to bottlenecks.

Environments should be built in the same way as the production system, giving you confidence that the final production service is working exactly as expected. For example, I had a recent customer who’s Production environment was built to a different specification and even with different products to that of his system testing environment (containers vs EC2). This meant that results obtained during testing gave no confidence, and in fact we saw a deployment failure to production because the deployment process used in test did not work in production.

The quality of your environments matter. How you deploy IT releases, manage necessary changes and quickly deliver the end product to the customer is all affected by how long the cycle takes. This is at the heart of why environments are so important in IT delivery.

The challenges of managing environments in traditional IT delivery

In companies still using traditional IT practises, there are clear challenges that we regularly come across:

Drift

Companies often build environments and expect to never rebuild them. Over the lifetime of an environment, changes to the environment have to be controlled, otherwise you end up with something we call ‘drift’.

Drift in environments results in configuration that ends up far from the original design, creating confusion in development and testing.

Customers often spend more time verifying the state of their existing environment than testing new code. One solution to excessive ‘drift’ is to rebuild the environment itself, but this isn’t without problems either.

Rebuild

Some companies choose to rebuild their environment every release cycle, expecting the process to take a week or so.

With manual methods, environment rebuilds take longer, lasting on average 3–5 weeks. This causes further issues — an environment shakedown can uncover all sorts of problems hitherto unseen.

Many feel slowed down by environments that are tricky to successfully recreate. It’s frustrating to spend weeks getting an environment ready for testing if the test itself only takes a few days.

In the traditional IT space, systems like this might be built from a set of instructions rather than code. This leads to mistakes, a lack of steps being updated and an increasingly complex, slow and frustrating system.

Integration

Early stage environments often involve tricky integrations. Baseline data between different environments needs to be coherent, as the architecture relies on systems talking to each other.

On average, we see 10+ integrations per environment. Most companies manage a mix of Cloud, in-house and SaaS third party data. This results in a constantly growing complexity of integrations.

Historically, we’ve dealt with very tightly coupled systems. Setting up systems that can easily talk to each other, using the correct data, to successfully make calls, is becoming harder than ever. Modern design and development principles such as Microservices addresses this issue, but its not always an option for our customers.

Next up in Part 2 we’ll look at how you can resolve some of these challenges.