VirtOps #0: Intro on DevOps

Hi everyone! Welcome to this new series of blog posts related to DevOps on the Xen Orchestra stack (combined with both XCP-ng or Citrix Hypervisor). We call it "VirtOps", which is because we'll do DevOps on top of XO. And today, we'll start by explaining clearly what DevOps is, and how XO will help you there.

What's DevOps? Definition

I think this is the hardest part of this series: giving a clear definition of what DevOps is. You've probably heard the term a LOT, and it was badly "translated" to non-technical people (👋 HR or head hunters, searching for "DevOps" people! 😉).

The very first important thing to get is:

DevOps is a set of practices.

This set of practices combines software development (the Dev part) and IT operations (Ops).

It's like Karate: you aren't a Karate (except Chuck Norris maybe 🥋). You are doing Karate. Same for DevOps: you aren't a DevOps, you are doing DevOps.

Why? Goal of DevOps

DevOps to do what? Well, that's in fact a very good question. I suppose you are aware of it or similar "trendy" words. Here, I'm focusing on what matters: the real impact of DevOps for your IT environment. No bullshit!

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

Len Bass, Ingo Weber, and Liming Zhu—three computer science researchers from the CSIRO and the Software Engineering Institute

This is the definition from an academic perspective. However, that's the best one to me. "Reducing the gap between the dev world and the sysadmin world" is another way to say it, and this should bring (credits to the great Wikipedia page on DevOps):

• Improved deployment frequency;
• Faster time to market;
• Lower failure rate of new releases;
• Shortened lead time between fixes;
• Faster mean time to recovery (in the event of a new release crashing or otherwise disabling the current system).

Sounds great, doesn't it? But is it really working?

Cultural shift

This is a real transformation, made to get Ops and Devs teams working more closely. And believe me, that's not trivial! In fact, that might be the biggest challenge in adoption. So you need to go step by step. My personal experience: go with bringing solutions to each other. Eg:

• Devs have good experience on working together regarding text files (sources, eg with source code management tools). This process can be used in the Ops side, so use your devs to train your ops on it!
• Ops have good experience delivering apps in a matter "that works". This experience is really valuable, and training devs on best practices can help to build code that's easier to deploy for ops.

Better collaboration between Devs and Ops teams is a big part of DevOps success. You can also get people that are already trained in DevOps practices. But remember: you won't replace pure Devs magically with Ops and vice-versa. The experience of everyone matters!

How? Various examples

Here are some examples on how software development best practices help a lot in the context of IT operations. It's entirely possible you will realize you were already doing DevOps without knowing it!

The first simple and however game changer example, is to use Git to manage your app/system configuration. Git was made by Linus Torvalds to work together on the Linux Kernel, but it's far more than that now: this is a fantastic tool to both collaborate but also track the history of who did what and when.

What's next is also a big leap ahead for Ops: using automation.

Automation

Automation is a great way to integrate DevOps principles. For example, when you deploy a new version of your application, the ideal world will tell you that there's nothing to do. No manual tests, deploy or checks.

But this requires a lot of tooling or experience. That's why this series of blog posts will help you to go in the right direction to achieve that.

What about Dev side?

I gave various example on the Ops side, in order to expose the DevOps side of things. But what about Devs? This is not the focus of this blog post (targeting more Ops to DevOps than the opposite), however, if you are interested: take a look at deployability, modifiability, testability and monitorability. And Microservices!

Also, you can imagine modifying your dev process to include connections to your XCP-ng/Xen Orchestra infrastructure. More on that later!

Xen Orchestra: the central piece

So what about DevOps in a XCP-ng/Xen Orchestra environment? (or even with Citrix Hypervisor). Since its inception, Xen Orchestra was built with an idea in mind: being a central component, managing your whole infrastructure in one place.

Without this central architecture, each client has to connect to various pools or hosts at once:

But with a central point, it's far easier. You can rely on a fully available "middleware" to do everything you need:

And that's not all. Xen Orchestra was also built with different components, including an API you can query:

In a DevOps context, it's a formidable opportunity to use Dev practices in your Ops, with only one thing to query!

Coming next: API, CLI and more!

In our coming blog posts, we'll give you some examples on how to access Xen Orchestra programmatically, using its CLI (xo-cli) or its API. This way, you can do any kind of action in a completely automated fashion. Use cases are infinite: CI/CD, updates, rollback, deployments, migration etc. Or just connect to your IT infrastructure and report whatever you need!

Finally, we'll also have some articles regarding great DevOps tools working with Xen Orchestra, like Terraform! Stay tuned by registering on https://xen-orchestra.com or by following us on Twitter.