Your submission was sent successfully! Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

Adopting a low-ops approach with software operators

Tags: Charms , Juju , juju.is

This article is more than 1 year old.


How enterprise DevOps teams can automate repetitive tasks while staying in control 

Low-ops means minimising the effort for operating applications by automating as many tasks as possible. However, given the maximum automation, how can an SRE or DevOps engineer stay in control? Doesn’t automating tasks and being in control sound like a paradox?

A software operator can help resolve this paradox. In software operators, the automation is covered by source code, and the DevOps engineer or SRE can exercise control by defining and reviewing this code. Using software operators results in implementations that are testable and more reliable at runtime. Proven engineering methodologies ensure high-quality development leading to stable releases of operators – that is one way of implementing SRE. However, operating applications is not just about writing automation code: operating applications poses challenges when building solutions:

  1. How can I successfully provide a solution within budget and time?
  2. How can I reuse all the popular open source software (OSS) available?
  3. Who protects included OSS against security vulnerabilities?
  4. Do I need to execute operational policies for every application individually?

It is obvious: enterprise-grade solutions benefit from automation code, but to operate these, we need to cover the questions above as well. Today, the pace of delivering solutions has accelerated. Software-reuse has played an important role in helping organisations save time and resources.

Reusing popular open source

Only few applications exist today as stand-alone. In most cases, applications are composed of building blocks. An endless amount of building blocks is available from the vast global bazaar of open source: database servers, content management systems, machine learning software, and much more – freely available for adoption and, in many cases, even available in multiple variants, implementing different flavours or a slightly different focus.

Contrary to the many choices available, several elements are repeatedly part of enterprise-grade solutions, for example user management, observability or database servers. In the ideal case, they are part of a collection of building blocks available for reuse. The availability of standardised building blocks accelerates the creation and delivery of solutions. The next level of reuse covers an entire solution setup of building blocks arranged in a reference architecture. 

Reusing building blocks helps delivering within time and budget.

Consistent reference builds for predictable projects

The execution of IT projects has matured over the past decade. It’s now more common for  IT projects to meet their deadlines and stay within the planned budget. The best practice applied here is the creation of reference builds or reference architectures which serve as a reusable template for building solutions. When building solutions, software operators supporting the configuration and integration of applications are crucial. They turn the setup and integration into a predictable effort and eliminate uncertainties. Having the composition of building blocks arranged in a reusable reference architecture begs the question: how do you ensure maintenance? All the included open source software requires patches for bugs and security vulnerabilities.  

Container ships are usually built within budget and time because they reuse building blocks and use reference builds, a class type ship.

Security and bug fixes

One of the top priorities today in the IT industry is managing security vulnerabilities – this affects open source and proprietary software. However, a guaranteed source for bug fixes and patches is not always obvious for those using open source.

Because open source is present on all levels of the technology stack, supporting the entire stack is very difficult: from the kernel of the operating system, the drivers, and the technical platform, to individual applications. Without a source for security patches, operating applications is a risky and volatile effort for most companies without dedicated expertise in this area.

The unique advantage of building on a proven and mature Linux distribution for bug fixes and patches is that not only the pure operating system is covered, all the popular open source packages for technology platforms and building blocks are also included. Currently, the service provided with Ubuntu Pro covers more than 23, 000 packages. This broad coverage is the ideal foundation for any platform, framework or software development kit you build on top.

Providing uniformity for operational policies

Besides ensuring security patching, it’s important to ensure operational policies can be applied at scale. Our experience has shown that there are always recurring common actions and events in any application. Examples for events include changes to configuration values or a sudden loss in network connectivity. Examples of actions include scheduling a backup or scaling up the application to cover more load.

A mature framework for software operators defines such common actions and events, ensuring uniformity and stability. As a result of this uniformity, policies for operating applications can be applied uniformly as well. This avoids exposing all the custom software operating methods and reduces confusion.

A framework for low-ops enterprise-ready solutions

Canonical’s experience building private clouds and running managed applications over the past years has led to a comprehensive toolbox for building solutions. This toolbox reuses popular open source building blocks and features reusable reference architectures. The building blocks run on Ubuntu Pro for support, bug fixes and patches for vulnerabilities.

For covering applications with operators, Canonical provides an SDK for building them, the Charm SDK. The Charm SDK consists of the ops library and Charmcraft. The ops library is a Python framework for developing and testing operators, called charms. Charmcraft is a tool for building, packaging and publishing charms. Juju is the open source orchestration engine that runs these operators. Juju  enables the deployment, integration and lifecycle management of solutions at any scale on any infrastructure.

Low-ops refers to automating the configuration and operation wherever applicable to reduce manual tasks to the minimum. Using the Charm SDK to write operators for all the solution elements and operating them with Juju exactly implements the low-ops approach. 

Learn more about Juju and Charms

Interested? – read our introduction to Juju and Charmed Operators

In case you would like to contact us – we would be happy to answer your questions:

Contact Canonical

Talk to us today

Interested in running Ubuntu in your organisation?

Newsletter signup

Get the latest Ubuntu news and updates in your inbox.

By submitting this form, I confirm that I have read and agree to Canonical's Privacy Policy.

Related posts

Kubernetes backups just got easier with the CloudCasa charm from Catalogic

For a native integration for Canonical’s Kubernetes platform, Juju was the perfect fit, and the charm makes consuming CloudCasa seamless for users.

What is a Kubernetes operator?

Kubernetes is the open source, industry-standard platform for deploying, managing and scaling containerized applications – and applications on Kubernetes are...

Operate popular open source on Kubernetes – Attend Operator Day at KubeCon EU 2024

Operate popular open source on Kubernetes – Attend Operator Day at KubeCon EU 2024