Abel Wang – Real World DevOps with Azure Cloud and GitLab

I am thrilled to introduce Abel Wang, Principal Cloud Advocate, Devops lead at Microsoft. His talk is titled "Real World Devops". The deployment of cloud native applications can involve many moving parts more than your typical demo app has.

In this fun and energetic talk, Abel takes a look at Devops and then uses Devops best practices to demonstrate a real world micro services app being deployed to Azure using GitLab. Let's check it out. Good morning, everyone.

I am so excited to be here today talking to you all about real world Devops but before we begin, I wanted to show a real world problem I ran into this morning. Check this out. So before I do any of these types of demos and shows and stuff, I always check my demo, make sure everything's working.

So I jumped over to my demo site and this is what I saw. Not great, right? But I'm trying to figure out what went wrong.

And I figured, OK, everything that I'm doing, it's all hosted up in Azure. Let me jump into Azure to take a look. So here is my Azure subscription and there should be a whole bunch of resource groups with like Kubernetes clusters, databases, all sorts of stuff.

There's nothing in here except for like a temp resource group. So, yeah, somebody probably went in here and deleted my entire demo out of my Azure account. Not good, right?

Of course, that idiot was probably me cleaning up my subscription the other day and I might have just gone in and blew everything away. So normally I should be panicking. Right.

But because I used real world Devops principles for my talk, I should be OK. So in theory, I should be able to go back to GitLab. I should go into my CI CD pipeline.

And from here, assuming the gods are good to me, I should be able to kick off my pipeline. It will build my application, all the pieces and deploy everything. And by the time I'm done talking, hopefully everything will be ready.

Right. So let's go ahead and kick it off. We'll cross our fingers and while it's running, we'll go ahead and go on with my talk because what could possibly go wrong?

All right. So quick introduction before I begin. My name is Abel.

I'm a principal Cloud advocate and also the Devops lead here at Microsoft. I've been writing code forever, but I am super, super lucky because I do lead a team of five Devops practitioners. And our sole charter is to help everybody get into Azure using Devops best practices.

Now, notice, I didn't say you had to use Microsoft tooling to get into Azure. Right, because Azure's open system, you can literally use whatever tooling you want. You don't have to use Azure Devops services or GitHub or whatever.

In fact, I'm doing everything with GitLab. Why? Because the tooling is awesome and Azure is open so I can totally use GitLab to get into Azure.

So if you have any questions, we're a resource. Please do use us. Don't email me though, because I don't really read my email a lot, so I'm probably maybe two or three weeks behind, but I'm on Twitter all the time, so if you tweet at me, I will see it immediately.

You can even hashtag it - LoECDA. That will literally light up a team room. We will see it.

I will answer your questions and if I can't answer your questions, I will find the person at Microsoft that can. So we're a resource. Please, please do use us.

All right. So before we can talk about what Real World Devops is all about, what is Devops right? If you ask 10 different people what Devops is, you're probably going to get 20 different answers.

So let me give you Microsoft's definition. For us, devops is something very, very specific. Devops is a union of people, process, and products to enable the continuous delivery of value to our end users.

I said this really carefully because every word here has meaning. Notice I didn't say continuously deliver code. Right, because what will that give us?

Piles and piles of code sitting on some source control system somewhere. Who cares? It doesn't do anybody any good.

And notice I didn't even say continuously deliver features because I could be delivering feature after feature, sprint after Sprint. But again, if this is not what my end users need or want, why am I wasting time doing this? Right.

We have to continuously deliver value. Now, some of you might be thinking, why do we even care about that? Why should we do that?

In the end, well, let's get real for a second. Here's the thing. If you don't adopt Devops best practices, your competitors, they either have or they will.

And once they do, they will out innovate you. And when that happens, bam, you become obsolete and no one wants to be obsolete. Now, this isn't just Devops theory that I'm talking about.

We've been doing this long enough now that we have empirical proof that shows beyond a shadow of a doubt that teams that adopt Devops best practices absolutely innovate, teams that don't. So this is why it's so important to adopt Devops best practices. However, it's not easy to do this at all.

You have to trust the people, the process and the products that you're going to use. The people, this will be the most important pillar that has to be addressed. his is a cultural change that has to occur within your organization from the very, very top all the way down to the bottom, where every single person has to be hyper aligned, hyper focused on continuously delivering value.

And for the process, you need to have a process that will let you iterate fast enough, yet still deliver a code of high enough quality. And finally, you need to have products and tools that can help enable all of this. And today I'm going to show using GitLab doing this because GitLab is a fantastic tool.

Now, usually about this time. This is where I do my demo. Right.

And I do a beautiful demo that's flashy. I make some changes and immediately those changes code gets built. It gets tests are run, it gets shipped all the way out into production and bam, the change happens right to the website.

And it's beautiful as unicorns and rainbows. However, that's not really what the real world is like, right? Because if you do real world Devops, it's a little bit more like this real world Devops oftentimes turns into a massive dumpster fire because things pop up where your pipelines, your your simple hello world pipelines start to fall apart.

So I figured what I would do today is actually dove in and show you Devops using a real world application versus a hello world application. So the real world app and I'm going to show you this is a modern micro service-based application. It has a web front end.

Right. And this Web front end has been a been here for a while. So it's written in an old language.

net. And I don't mean dot net core. net.

Right now on the back end there's a SQL Server database as well. So there is a relational database. On top of that, there is also going to be a rest API that's written in node and this needs to be done in a container hosted in a Kubernetes cluster.

And finally, there's a whole nother service layer as well. net core and it's containerized as well. Right.

And then there's also a mobile portion as well. Now, there's a lot of moving pieces here, right? So once I try to Devops all of this, bad things start to happen.

And this is what I mean. First of all, my app is not ready for a real micro service deployment. So micro services are freaking awesome because if I make a change to one micro service, in theory, I don't need to deploy everything.

All I need to do is deploy that one small service that change. And by doing it that way, it's so much easier because the deployment is so much smaller and testing it and getting the quality right. It's so much easier when it's just one small service versus this entire massive monolithic application.

Right. So I was like, great, I'm going to build out a bunch of these little tiny pipelines and they'll be great. The problem is that only worked two times and then bad things start to happen because I forgot that when I teased apart my monolith, my services still had dependencies, right?

Service A dependent on service B, so because of that, the order that I deployed my application or my services started to matter. And it got even worse because I have the scenario where service A dependent on service B, that depends on service C, that depends on service A, so that. Oh crap.

Now what do I do. Right, because I have a circular dependency and if I keep on doing this somehow some way, I don't know how to do it. I'm going to have downtime at some point in time because of that.

So that's a really big problem. Right. The other problem that I have is the infrastructure that I'm trying to spin up is really difficult to configure and and to to spin up.

It's just hard. It's a lot of stuff. Right?

There's an app service and Azure and the SQL Server. I need Kubernetes Clusters. I need storage, I need functions.

There's all sorts of moving pieces that I need to provision and configure. So that's a huge pain. The other thing that I'm having problems with is that my micro services are getting very, very difficult to join up.

I have a bunch of micro services on the back end. Right. And immediately I started running into cause issues where.

Well, I can get around it with using code, but that's kind of a pain, too. And of course, I have things like a SQL Server database, I have a relational database. So now I have to worry about like database Devops and mobile Devops and how do I maintain quality in my pipelines, in security?

And on top of that, since this is a real world application, I have to worry about things like DNS and https as well. So how do I fix all of these things? And the answer is...

My beautiful pipeline that I can use in GitLab. So enough of me talking. Let's take a look and see what actually happened with my deployment.

Oh, look at that, it actually deployed everything awesome. So it looks like we're good, but before we dive into this crazy pipeline, well, you know what? Let's just dive into this crazy pipeline to see what's going on.

The very first thing that I do in parallel, I start building up all the pieces that I need. So I build up my Web application. I build up my applications that need to be deployed in a Kubernetes cluster.

And I also build this weird thing called infra tools. What's infra tools we'll dive into that a little bit more. And once I do that, then I start deploying all of my pieces out.

Now, in GitLab, the way that you define your pipelines is by using Yaml. So let's jump in to my editor really quickly and we can see exactly what I'm doing. So the very first thing that I do is I define all the stages that I have.

And then from there I have some variables that I use throughout this entire process, some service principles. I have my secrets stored inside of the secret section and GitLab as well. And like I said, these are just variables that I use throughout my entire pipelines.

I also wrote some scripts, right, that I'm going to be using throughout my pipeline as well, including things like getting my secrets from Azure key vault, where I store all of my secrets. net application, the only thing I can build it on is a Windows server. So I needed to make sure I could use both Windows and Ubuntu runners.

So I have a couple of different scripts I can do. I can log in to bash using bash. I can log into Azure using a power shell as well.

And finally I build my web and I build my database as well. So when I first looked at GitLab, I wasn't super familiar with it. But it was pretty easy because the way you set up your e-mail is basically you just start scripting it out.

So I'm like, cool, I can do back, I can do power shell. How would I do this pipeline using the command line? Let's just dump all that into this Yaml file and bam, magically it worked.

So I built my up my web application web front end. I built up my database projects and hooray for that. Right.

And I do the same thing with my info tools. What are infra tools? These are inline tools that I need to help me deploy the rest of my application and I can dive into that in a little more detail.

Later, I build up my application for my API layer using Kubernetes. Right. So this is basically I'm just building this as a container for now and then we'll use Helm to deploy it later.

And then I start deploying my application, I deploy my database. This is actually kind of neat the way that I deploy it. I could have scripted everything just in here, but I already had partial scripts that did everything for me.

So let me go ahead and show you what I mean. So here's my powershell script. It's not and you can do this and bash as well, right?

I've written everything in Bash as well, but I did it in power shell because I do come from Microsoft. First thing that I do is I pass on a whole bunch of parameters that I need. And then the next thing I do, basically, since everything is an Azure, I do everything using the Azure CLI.

So the first thing that I do is I log into Azure using the Azure Cli and then I go ahead and start doing stuff. So what do I do. I first create my resource group in Azure, I create my SQL Server in Azure.

I start configuring my firewalls and things like that as well. And as I was doing this, I thought of something to which is, hey, if I'm running this and there is no data in my database, clearly something really bad has happened. Right?

So if that's happened, why don't I do disaster recovery from within my pipeline? Because if you store your data in Azure cycle, it automatically takes backups for you and sticks it into a long term storage. So all of this nonsense that I'm writing here basically is just saying, hey, grab the long term storage backup and restore your backups as well.

So my pipelines, not only does it provisioned everything, it also does disaster recovery. Let's jump back to the pipeline so you can actually see what's going on. Right.

So I build up my application in parallel, then I stand back in and deploy the infrastructure tools that I need to help me deploy the rest of my application. I deploy my database and restore from backup if I need to. I go ahead and deploy my Kubernetes cluster or a provision by Kubernetes cluster and then deploy my application using Helme and then I go ahead and deploy my Web app as well.

Right. So I'm starting to deploy all these different pieces. And because this is a real world application, I can even set my DNS.

So what is DNS? My DNS is held in CloudFlare, right. CloudFlare has a full set of rest APIs that lets you manipulate it and do whatever you need to with it.

So in my Yaml, I just call the rest API to set my DNS settings. So in theory it should set up my DNS within my pipeline as well. The next thing that I do, let's skip the chat DNS for a second and look at why am I deploying deploying this Front Door thing.

Front Door is an uber load balancer that sits in front of everything. So I needed that Front Door has a really quirky problem as well, which is I cannot provision and configure Front Door until the DNS settings that I need has propagated all the way down locally. Why?

I don't know. This sounds absolutely ridiculous. But that's why I add it in a whole nother stage here where I check my DNS settings and I wait here until my DNS has actually propagated from CloudFlare all the way down to my runner.

And when that happens, I go ahead and. Provision in Configure my uber load Balancer, and then from there I set up https as well because again, real world application, we have to have a https. And when that's done, I go ahead and run a whole series of selenium web tests to make sure my application is up and running and good.

And if I look at this, it seems like it's running OK. It seems like everything's good. So maybe we should test it out and see what's going on.

Right. If we go back to my Azure Resource Group and we go ahead and refresh this. Look at that, it's already created a whole bunch of stuff for us, if we go into my Mercury Health Resource Group, we can see all the resources that it created, which is a lot, right?

I've got an app service that's running my front end. I've got application insights to collect telemetry while people are using my application. I have a front door, which is my Uber load balancer.

I have my container registry which holds the built images for my containers that I build throughout my application. I have my database. I have functions that I use, I have storage and I even have my Kubernetes cluster.

So remember, we started with nothing at all. But because I use Devops best practices using infrastructure as code, I can start from nothing, kick my pipeline and it will provision and configure everything that I need. So assuming I did everything correctly, let's go ahead and take a look.

We'll refresh this and bam, there's my application, it's up and it's running. And remember when I said I did disaster recovery for my data as well? Let's go ahead and look at what I've been eating.

If I did disaster recovery correctly, there should be stuff here. And if I didn't, it's going to be an empty table. So we'll go to the nutrition section.

And yes, look at that. It did disaster recovery. One last thing that I wanted to show.

Notice this little lock sign right here. That's because I set up a https within my pipeline as well. So that means I had to download my certificate, upload it to Azure.

All of those things can be done within your pipeline. And the last thing, if you look at this URL. com is just a normal dotcom, you are all because I set up DNS as well.

This isn't some weird Azure-y, raw URL, right. No, I set up DNS as well. So this is a real pipeline that did absolutely everything for you.

So the takeaway that I wanted everyone to have is not even necessarily oh Azure's awesome or GitLa's awesome, which they both absolutely are. But the take away that I wanted everyone to walk away with is that Devops can do everything for you. If you use Devops best practices, you can have incredibly resilient pipelines and you can do what you can do in your pipelines is way more than you can imagine.

Really, your imagination is the limit. So everyone out there go check out GitLab. This is a very flexible and powerful tool.

Of course, I work for Microsoft, so I want you to check out I want you to check out Azure as well. In the meantime, if you want more detail on exactly what I did here, a bunch of resources that you can use. I'm also on Twitter.

I am on Twitter all the time. Reach out, ask me questions. I'm here to help.

All right. Thank you all very, very much.