Cloud and containers, two buzzwords of the IT world put together. What can go wrong?

This post is a refresh on a previous one (https://cloudinthealps.mandin.net/2017/03/24/containers-azure-and-service-fabric/) with a focus on containers, rather than the other micro-services architectures.

As usual, I’ll speak mainly of the solutions provided by Microsoft Azure, but they usually have an equivalent within Google Cloud Platform or Amazon Web Services, and probably other more boutique providers.

And let’s be more specific, considering what happened in the container orchestrator world in the recent weeks. I am of the general opinion that this war is already over, and Kubernetes has won. Let’s focus on how to run/use/execute a Kubernetes cluster.

First step : you want to try out Kubernetes on your own. The ideal starter pack would be called Minikube (https://github.com/kubernetes/minikube)

. I already wrote about it, the good thing about it is that you can run a Kubernetes installation on your laptop, in a few minutes. No need to worry about setting up any cluster and configurations you do not understand at all.

You might want to play out a bit with Kubernetes the hard way, in order to be able to understand the underlying components. But that is not necessary if you only want to focus on the running pods themselves.

Now you are ready to run a production workload Kubernetes Cluster. And you would like to handle everything on your own. There are many ways to get there.

First, you want to deploy your own cluster, not manually but on your own terms. There is a solution, kubeadm (https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/), that will help you along the way, without having to do everything by hand. This is a solution that is compatible with any underlying hardware, cloud, virtual or physical.

On Azure specifically,  there are two concurrent solutions to build your Kubernetes cluster : ACS (https://azure.microsoft.com/en-us/services/container-service/) & ACS-engine (https://github.com/Azure/acs-engine).

ACS (Azure Container Service) is mostly a deployment assistant, that will ask you the relevant questions on your K8s deployment, and then create and launch the corresponding ARM template. After that, you’re on your own. And you may download the template, edit it and re-use it anytime you want!

ACS-Engine is a command line customizable version of ACS, with more power to it 🙂

I feel that both are Azure dedicated versions of Kubeadm, but they do not add value to your production. They still are good ways to quickly deploy your tailored cluster!

BTW, if you go to the official webpage for ACS, it now just speaks about AKS, and you’ll have to dig a bit deeper to find out about the other orchestrators 😉

What if you could have your K8s cluster, be able to run your containers, and just have to manage the clustering and workload details? There is a brilliant solution called AKS (https://azure.microsoft.com/en-us/services/container-service/) , and no it does not stand for Azure K8S Service… It actually means Azure Container Service. Don’t ask. With that solution you just have to take care of your worker nodes, and the running workloads. Azure will manage the control plane for you. Nothing to do on the etcd & control nodes. Cherry on the top : you only pay for the IaaS cost of the worker nodes, the rest is free!

In my opinion, it’s the best solution today, it offers you a wide flexibility and control on your cluster, at a very low cost, and lets you focus on what is important : running your containers.

One last contestant to join the ring : Azure Container Instances (https://azure.microsoft.com/en-us/services/container-instances/). This solution is still in Preview, but might become a strong player soon. The idea is that you just care about running your container, and nothing else. For now it is a plugin for an actual K8S cluster, that will present itself as a dedicated worker node, where you can force a pod to run. I did not have time to fully test the solution and see where the limits and constraints are, but we’ll probably hear from this team again soon.

Yes, DevOps is the new black. I might not be the first to use the phrase, but it’s so obviously true.
I am currently working on building some kind of offer around DevOps, so you’ll probably see more posts on the topic.
But two things struck me recently and I decided I would make a post out of those. Both items are related to the people side of DevOps. The first is the importance of the people involved in your DevOps transformation or organization. The second, corollary to the first, is the recruitment of these people.

People matter

People are important, that’s obvious. However a customer experience has lately surfaced the importance for a successful DevOps transformation. I may not be able to go into many details but the broad outline is quite simple.
The organization is a software team, within a large company. It delivers its own product, to be used by other business units. It has decided to run its own operations. Perfect candidate for DevOps, right? Using a custom approach, based on industry standards, an Agile/DevOps organization is designed and implemented.
Fast forward one year. The transformation is quite successful, the stability and quality of the product have improved. The only thing that prevented the team to be outstanding seems to come from the people. Don’t misunderstand me, I am not judging this team and its members. But for an Agile/DevOps transformation to be successful you need the right people, with the right mindset. And not everyone fits the bill. Like some people are more comfortable in an open-space and some prefer a closed-off office. It has been the same with Agile practices, which could not apply to every situation and team.
We need to pay extra attention to the people we include in these transformation projects, if we want them to succeed.

Recruitment is crucial

As a follow-up of the above assessment, recruitment of people for your team is important. Yes, I know, it has always been important. However, take a second look at the title of this post. Done? Alright. Now have a look at the job offers in IT. See any pattern?
DevOps is written everywhere.
It is somehow justified, as DevOps encompasses many modern practices that we have or would like to implement. Take automation, continuous delivery, continuous deployment, testing, QA etc.
The issue is that not every job offer is for a DevOps team or project. Most of the offers are for traditional sysadmins or developers with a hint of DevOps. Which is a good trend, but not a good fit for a full devops profile.

So, people matter in DevOps environments, so take care of your profile 🙂

Note : this post was inspired by a LinkedIN post that I cannot find, in french, regarding the abusive use of DevOps in job postings in France. If anyone can find it, I’d love to thank and credit its author!