Real Life Based – My personal story on “Cattle vs Pets” and how it relates to DevOps / Automation

Introduction

Today’s post is about a story many people have probably heard me telling “in real life”… Where with this I took the opportunity to finally publish it on this blog. 😉 In our DevOps literature we have often used the concept of “Pets versus Cattle” to indicate why go for DevOps. Though in my humble opinion, the focus has always been around tactical and sometimes even framed a bit too harsh. So with this, I hope you enjoy to read my personal version on it!

 

Real Life Based

Something that not all people might now, but I actually live in… what I sometimes unrespect fully coin … “The Middle of Nowhere”. This being that I life in a more rural municipality in Belgian terms. Where I actually recently moved in the same municipality, my previous residence was actually next to “a farmer”. And to be more precise, a dairy farmer with several hundred cows. His family was hard working 7 days out of the week. Lovely folks too, every time being greeted with awesome hospitality.

Our family itself has also never been a stranger to animals. As we have two mini pigs, two rabbits, three cats … and probably provide food for the entire region worth of birds. The thing that always struck me, was that both of our families loved our animals very much so! Though we both catered to their needs in a different manner. Our were pets… and we had the luxury to spend more time (budget even…) per animal itself. Though that did not mean that our farmer neighbors did not care about their animals. Though let us be honest, with several hundred of cows, you needed to spend your time wisely. Though the animals did not fell short of anything. At the end of they, they were also providing the living hood for this family.

 

The Difference

As you can already notice, the difference in volume of animals requires a different approach. At the end of the day, they require LOTs of automation to keep everything operational. This goes from preparing food, to feeding, to cleaning, to milking, … to ventilation, to rotating shifts on the fields, etc, etc. Almost everything, except from how little cows come into the world 😉 … was being automated.

Currently I am in the IT industry for more than 20 years already. When I started out we had a mainframe with direct cables to the terminals. The world evolved, and we got physical wintel alike servers… Desktops / workstations surfaced at the desks of everyone in the company. After a while those physical servers got virtualized, and server applications went from a monolith to three tier architecture. After which containers popped up, and also brought microservices to life.

At the end of the day… we went from a technology landscape with a modest amount of machinery… to an overly complex one with A LOT of cogwheels that need to keep on turning!

 

Automation

Now let us translate this one for the typical enterprises. Each and every one out there has gone through the same evolutions. Some at a different pace then others… Though we can all say that our IT landscapes have become very complex, and have a lot of cogwheels turning. At that point, one cannot do things with the same manual care! This is the point where automation has become a necessity.

In my role I have encountered organizations, who are maintaining multiple thousands of servers… and who still do their upgrade process pretty much manually. They typically counter that they have automated installs in place, though they must admit that the lifecycle to go through this is still pretty much manual. One of those organizations, has at least two FTEs continuously upgrading their machinery, and where they always lag about two majors versions behind on their OS. Simply cause they cannot keep up… And if you discuss deep down with them, they realize that their issue is not increasing on automation. Which in turn, does not help them with creating the value that would be needed for their organization!

 

Devops?

So what about DevOps? DevOps for me has always been around the automation. How can you increase the throughput of things? How can we drive that lap faster? How can we detect (and fix) errors faster?

And in doing so, I do not even want to discuss the technologies that can enable you here, or what implementations can help. At the end of the day, whatever technology choices you make, it is evolving around increasing the efficiency. About 10 years ago, I presented a session at Experts Live on End-to-End automation. It included the following visualization ;

See it more as an inspirational roadmap… and now think this is about 10 years old… How far is your organization along on this? As I personally cannot fathom that people still want to reside on manual actions. They are slow and error prone, and we have the tools now to do these things quite “easily”. I know… things are never easy in IT. Though trust me when I say, that in 2005, when we did the above with shell scripts and without any off the shelve tooling, it was really hard. Though at that time, the organization I worked in (a manufacturing organization) already heavily relied on automation to increase our efficiency when refactoring away from mainframe and onto our custom built ERP.

 

Closing

As always, I hope these posts help you in your daily life… That it provides insights & value. My personal opinion is that in IT we should look towards near full automation. The technology stacks are enabling us in that direction, and we should not accept the drawbacks of manual actions anymore.

When you are thinking that you are able to do so. Also start thinking why you have not already? Why are you being limited here? Focus on removing those barriers. As in a lot of cases, it is cargo cult that is blocking you here.

Azure DevOps – Automatic user provisioning via Azure Active Directory

Introduction

When managing any IT infrastructure, you want to rely on as much automation as possible. As you probably know, you can integrate Azure DevOps with Azure Active Directory. The next step would be to ensure that you do not need to do any manual tasks in terms of adding/removing users from Azure DevOps. Which is something you can do with Group Rules. So for today, let us go through a brief setup of how we can achieve that all users from a given Azure Active Directory (AAD) group get automatically added upon login to a given access level in Azure DevOps.

What are we going to do?

The thing we want to achieve it the following outcome ;

A user got added by a group rule and not “Direct”-ly (manual). We want to choose which access level this user gets by default too.

Azure DevOps Governance 101 – How does Identity, Billing and Service Endpoints intertwine?

Introduction

A common discussion I have had in my role is around the “billing structure” of Azure DevOps. Though the discussion typically spreads out to other topics like identity and service connections for deployment. In today’s post, we’ll go over the general governance structure behind Azure DevOps.

 

High Level Structure

For this, let us start with a complex drawing! 😉

 

As a bit of an introduction ;

• Azure Active Directory is a component used for identity on both the Azure DevOps side (organization level), Azure Subscription and on the contract level for Role Based Access Control (RBAC).
• Azure DevOps has the concept of an organization, which can hold multiple projects. The billing & identity part reside on organizational level (marked in red). Where the service connections for deployment (pipelines) resides on project level (marked in green).
  
• There can only be one AAD linked to an Azure DevOps subscription. Though you can invite users from another AAD tenant via a typical B2B invite. Thus granting access to users outside of the AAD tenant linked to that organization.
• There can only be one Azure subscription linked for billing. Though you can have multiple Azure subscriptions linked as service connections for deployment.
• Multiple Azure DevOps organizations can use the same Azure subscription for billing. This will even allow the scenario of multi org billing.

So far for the basics… Let us now delve deeper into various topics.

Azure Serverless Compute Options

Introduction
A bit less than a year ago I blogged my opinion on “Cloud Native”, where the objective of today is to provide a bit more nuance to this previous post. Let us categorize it as “progressive insights”, due to having these type of discussions on a virtually daily basis. Therefore I wanted to share this with a broader audience, as I expect this is valuable to all. Where I will also try to make it a bit more tangible to link it to “Serverless” options in Azure.

Opinion – Cloud Native, Cloud Native and Cloud Native? What I like about, and my two cents on, running Containers, Kubernetes and/or Serverless

Introduction

In the beginning of the month I posted about my experience of moving VMchooser from “Serverless” to “Containers”. As in, moving from one way of implementing a CloudNative architecture to another… Since then, I have actually moved back to “Serverless”.  Though the cogwheels in my head have been turning 24/7 on how to put everything around this into perspective. Yesterday Yves made a tweet (reply) that really made something click inside of my head…

Azure is itself an orchestrator, it provisions stamps, vm's, containers and finer grained constructs such as ASB namespaces. Embrace that fact and you won't need systems such as kubernetes, or containers for that matter. I'd rather see @MicrosoftAzure invest in better serverless

— Yves Goeleven (@YvesGoeleven) February 22, 2020

In today’s post I’m going to try to do a “brain dump” of several thoughts that have been floating around in my mind. Where I hope this will help you in your journey of “finding your perfect rock”. Here I will indicate what I like about the various options and what my typical advice would be to organizations looking to do a given option.

Improving your code quality by linking Azure DevOps with SonarCloud

Introduction

In a customer workshop earlier this week, Hans mentioned a very nice tool (SonarCloud). He used it “in his previous life and was very enthusiastic about it. So this immediately triggered my curiosity… 😉 As it is free for public projects, I investigated how easy it was to integrate into my existing pipelines. Which turned out to be quite easy! After browsing around a bit on how to integrate it into a YAML pipeline, I can proudly say that VMchooser is now fully hooked up with SonarCloud.

However, it did confirm my suspicion, that I am a lousy developer! 😉 Though better lousy code fulfilling a purpose than having no alternative at all?!?

Anyhow, today’s post is about the experience of moving existing pipelines to SonarCloud and investigate the results you get out of it.

Azure DevOps : Operational validation with Approval Gates & Azure Monitor Alerts

Introduction

After having migrated VMchooser from a fully Serverless infrastructure to Containers, I am currently doing the opposite move. As I can start off the same code base to basically run different deployment options in Azure. Where I found that the serverless deployment added more value for me compared to a lower cost profile. That being said, one of the big learnings I had this week is that while having an automated landscape with Terraform, some changes are rather intrusive… Where I should have checked the output of the terraform plan stage, I failed to do so. Which resulted in downtime for VMchooser. So I  was looking for way to do operational validation in the least intrusive and re-usable way. This led me to a solution where the Azure DevOps pipelines would leverage the health-check used in the Traffic manager deployment. This was already part of the deployment of course and in this a key aspect of understanding if the deployment was healthy or not.

 

Gates

In order to add validation steps in our deployment process, we can leverage the concept of Gates in Azure DevOps ;

Gates allow automatic collection of health signals from external services, and then promote the release when all the signals are successful at the same time or stop the deployment on timeout. Typically, gates are used in connection with incident management, problem management, change management, monitoring, and external approval systems.

As most of the health parameters vary over time, regularly changing their status from healthy to unhealthy and back to healthy. To account for such variations, all the gates are periodically re-evaluated until all of them are successful at the same time. The release execution and deployment does not proceed if all gates do not succeed in the same interval and before the configured timeout. The following diagram illustrates the flow of gate evaluation where, after the initial stabilization delay period and three sampling intervals, the deployment is approved.

Leveraging Azure Tags and Azure Graph for deploying to your Blue/Green environments

Introduction

For this post I am assuming you are pretty familiar with the concept of deployment strategies (if not check out this post by Etienne). Now these are typically seen from an application deployment level, where platforms (like for instance Kubernetes) typically have out-of-the box mechanisms in place to do this. Now what if you would want to do this on an “infrastructure level”, like for instance the Kubernetes version of Azure Kubernetes Service. We could do an in-place upgrade, which will carefully cordon and drain the nodes. Though what if things go bad? We could do a Canary, Blue/Green, A/B, Shadow, … on cluster level too? Though how would we tackle the infrastructure point of view of this? That is the base for today’s post!

 

Architecture at hand

For today’s post we’ll leverage the following high level architecture ;

This project leverages Terraform under the hood. Things like DNS, Traffic Manager, Key Vault, CosmosDB, etc are “statefull’ where its lifecycle is fully managed by Terraform. On the other hand, our kubernetes clusters are “stateless” from an Infrastructure-as-Code point-of-view. We deploy them via Terraform, though do not keep track of them… All the lifecycle management is done on operating on the associated tags afterwards.

 

Community-Tool-of-the-day

The drawing above was not created in Visio for once. The above was made leveraging CloudSkew, which was created by Mithun Shanbhag. Always awesome to see community contributions, which we can only applaud!

Improving the security & compatibility aspects of package management with native GitHub features

Introduction

Did you know almost every piece of software depends on OpenSource? Not sure… What libraries is your software using? Bingo! 😉

Now we all know that package management can be a true hell. Tracking everything and ensure you are up-to-date to achieve the needed security level is hard. Next to that, there is always the risk that your build will break to moving to a library version.

What if we could enhance that flow a bit? You guessed it… Today’s post will be around how we can leverage native GitHub features to help us in this area!

 

Let’s hit the slopes!

For this walk-through, we’ll use the following ;

• an existing code repository, where we’ve forked CoreUI’s VueJS repo
• GitHub’s actions to run a workflow on every pull request
• GitHub’s automated security feature that will send pull requests to us when it detects security issues

Want to test this one out or follow along? Browse to the following sample repository ; https://github.com/beluxappdev/CoreUI-VueJS-GitHubSecurityDemo

So let’s fork this sample repository!

Taking a look at Github Enterprise Server & Github Connect

Introduction

For today’s post we’re going to take a look at GitHub Connect … It’s the link between the On-Premises installation of GitHub Enterprise Server and the popular SaaS offering (as we all have come to love it) called GitHub. 😉

 

Installing GitHub Enterprise Server (on Azure)

So my journey for today started with registering for the GitHub Enterprise Trial, where I decided to install it on Azure… as my “On Premises” location.