Infrastructure-as-Code mistakes and how to avoid them

by Tim McNamara on 10 January 2020

Two industry trends point to a gap in DevOps tooling chosen by many. Operations teams need more than an Infrastructure-as-Code approach, but a complete model-driven operations mentality. Learn how Canonical has addressed these concerns by developing Juju, an open source DevOps tool, to allow it create multiple world-leading products.

Two DevOps trends in 2020

Let’s consider the two trends and their impacts on DevOps:

Microservices push complexity from applications into operations

Switching to microservices involves breaking up large, complex applications into many smaller service units. In a ‘divide and conquer’ style, each unit becomes easier to deploy, scale-out, update and remove in isolation from the rest. Yet, microservices architectures risk pushing complexity onto operations, rather than removing it.

Adopting Infrastructure-as-Code tools removes some of this burden, but not all of it. Suddenly you need to consider network latency, message formats and connectivity. Each new service needs to connect to every other service. Without adequate tooling, upgrades and migrations can become time-consuming and brittle.

Container-based deployment can incur a performance penalty

A container-based deployment platform, such as Kubernetes, is a joy for many applications. But containers do not suit all use cases. Databases and other middleware are often bound by I/O constraints. These applications receive a performance penalty when they run as containers.

Most Infrastructure-as-Code tools tend to work well for hosting applications on a single platform.  But reality is more complex. They rarely allow you to deploy applications across platforms. And life is even more complicated when containers and virtual machines are combined.

Systems engineers and operations teams want to provide maximum performance, but they also want to provide agility to product engineering teams writing applications. Eventually, complexity will catch up to the business. A management decision to consolidate on tooling is likely to mean that databases are moved into Kubernetes clusters.  

Self-driving software is here

Canonical develops Juju to address these concerns. Its approach differs from other DevOps tools in the ways:

• Reduced complexity by allowing devops teams to work at a higher level of abstraction
• Increased stability by enabling applications to dynamically respond to their deployment
• Increased flexibility by decoupling configuration management from an application’s specific hosting environment

Juju is simple, secure devops tooling built to manage today’s complex applications wherever you run your software. Compute, storage, networking, service discovery and health monitoring come for free and work with Kubernetes, the cloud and the laptop. 

Juju allows your software infrastructure to maintain always-optimal configuration. As your deployment changes, every applications’ configuration operations are dynamically adjusted by charms. Charms are software packages that are run alongside your applications. They encode business rules for adapting to environmental changes.

Using a model-driven mentality means raising the level of abstraction. Users of Juju quickly get used to a flexible, declarative syntax that is substrate-agnostic. Juju interacts with the infrastructure provider, but operations code remains the same across. Focusing on creating a software model of your product’s infrastructure increases productivity and reduces complexity.

Automating infrastructure at a low level of abstraction, DevOps has bought the industry from breathing space. But that breathing space is running out.

Examples of Infrastructure-as-Code excellence

Using a single tool that speaks multiple backends at the same time has several benefits: productivity increases and complexity remains constant. Here are two examples of Canonical’s products and services that rely on Juju to provide their competitive advantage: 

• Open Source MANO (OSM) is an open-source implementation of the ETSI NFV MANO stack supported by global telecommunications service providers like Telefonica, BT and Telenor. By providing a native framework for implementing service orchestration capabilities, Juju charms have been selected by the OSM community as an engine behind Open Source MANO project.
• Canonical’s managed services for OpenStack and Kubernetes provide the fastest and cost-effective path to a private cloud and container orchestration platform. The cost reductions are enabled through enhanced tooling, namely Juju.

Learn more

The best place to learn about Juju is by following its getting started guide.