Azure Kubernetes Service - Unleash The Power! by Allen O’Neill || Azure Virtual Conference

Share the power

Okay, okay. So, what I'm going to do here today, folks, is I'm going to talk to you about Kubernetes

Azure Kubernetes service in particular. And what I'm going to basically talk about is the background to it, where it came from

why it is, and why you guys should be using it. So before we get stuck into that, I'm going to give you some brief background on myself

So I'm the very handsome Santa Claus chap beaming out of your screen there

I'm an engineer, which means that I'm obsessed with understanding how things work and with making things

and you know when we're talking about Kubernetes and Docker and serverless and all this type of

stuff it's very much a case of if you understand how it works you can use the power of it much

better. You don't need to go in there and to develop it but you need to understand where it

came from, why it's there, why it exists and what the Azure Kubernetes service adds to

Kubernetes and Docker itself. So I'm a CTO of a company called the DataWorks, and we mostly play

with big data and machine learning. And this is one of the reasons that I became deeply involved

in Kubernetes, because it offers such immense opportunity and goodness for folk who work with

big data, who work with applications that have to scale quickly and easily

and people who want to put managed services into their pipeline. My most prized award is the one that I got from C Sharp Corner for being a most valued

professional member of the community. And C Sharp Corner, as you know, it's not simply online

it's also offline, apart from our COVID days right now. And in a serious way, these folk

organize local meetups. They promote technology. They promote diversity and inclusion. And, you

know, there's millions of members across the world. So my message from this slide here is that I'm

speaking to you. I'm giving you some of my time. I'm giving you some of my expertise. I'd like you

who are watching today, if you don't already, to strongly consider giving back to your tech

community. It's not difficult. Just start by answering some questions online. Write an article

considering sharing some of your knowledge with fellow techies either virtually or

when we get back into whatever the new normal becomes with physical meetups and physical people

And the biggest message that I want to give everyone at the start of this slide here

is that knowledge must be shared for the good of everyone. So do your best to share your knowledge and to help others

So let's talk about Azure Kubernetes Service. or AKS as it's also called

The agenda that we're going to look at today is we are going to talk about the history and the background of Kubernetes

We are going to talk about the Kubernetes and containers themselves, what they are, what they do

We're going to cover some basic Kubernetes fundamentals. We'll then talk about AKS and what it brings to the party

and then we'll go through any Q&A that you might have at the end. The very first website that I was involved with was back in the late 1990s

And at the time, the project undertaking was absolutely huge. And I mean, really, really big

You wouldn't think it, but if you look at some of the websites that were around from the big boys

like Apple and Microsoft at the time that I have there on the screen, You'd look at those and you'd go, goodness, well, isn't that the type of thing that a kid puts together in code camp, like in an afternoon or a weekend, you know

They look so basic. But the thing is, even to get to that stage there took a huge amount of effort and a huge amount of money

And what we're going to do now is we're going to talk about the evolution of this stuff over time

So when I did my first website, having decided what the service we were providing was going to do, what was going to be, we put together a project plan and a budget

And at the time, our project costing estimates were, well, it was going to cost us $250,000, a quarter million dollars to purchase the servers

It was going to cost us to host those servers and bring the internet pipe into them, into our office, because there was no data centers, really

It was going to cost us $75,000 for a fast ISDN line, which was, I think, $32,000

and the engineers and other people related costs it was going to take us about 30 to 40 people to

bring this all together and that was going to cost us about 350 000 and to ensure the that we gave our

project success and we moved the new office then near to a digital exchange at the time so we could

get a guaranteed 128k speed internet connection so as you can see it was a very big project well

it really was back in the 1990s right um now don't get me wrong i mean this wasn't something that was

completely out of the dark ages we didn't have punch cards and um the like but it was a very big

project for the time and if you converted it back to today's projects well it was just a basic

website but back then it was such a big deal it was like something you would make your career on

And you would say, I did this big project and it was, you know, three quarters of a million dollars and et cetera, et cetera, et cetera

But in retrospect, for what was a very, very pretty basic website, it was at the time extraordinarily complex to do

And it was big. I mean, really big. And it used very big resources

And in the background picture that you can see there on the slide, when you see those big physical racks and the power units and everything else, that's exactly what we had

Now you could fit all that into an iPhone, but back then that's what we had, and this was not cheap stuff. It was extremely expensive

So last week, I had an idea for a new SaaS website

And after spending, you know, the bones of 45, 60 minutes slapping together a React.js, an entity framework into place and spinning up my CRUD

And what I did was I did like, you know, in Visual Studio, file a new website

And my website was up. Like within four or five minutes, I had a website that was up, deployed and done

And it cost me almost nothing. I mean, you know, you get your free $25 a month from Microsoft under the different programs

And I just did that So I put up the equivalent of what cost us over a half a million dollars and took months and months and months to push through incompletion back when I started in IT

And I published one in a few minutes. And it just overall cost me less than a dollar a month to run

And that's absolutely incredible. So the days that we had to publish into, and a lot of you remember this, publish into a particular folder and then FTP the code or the DLLs and all of the supporting files up to your service hosts and beg them to please allow you to include some kind of non-standard plugin or DLL that you really, really needed for this particular website so that I could get paid

and then hoped that everything connected together and worked and that the website would deploy

Only the gods themselves could help me if something went wrong or something went right

because there was very little support for logging and debugging on the machines that you uploaded to things at that stage

And even now, some hosts are still in the dark ages when stuff like that went wrong

So how did we get to this stage? How did we get to the stage where we can do this amazing web stuff at the speed of light

And what exactly is containers and Kubernetes and serverless and cloud functions

What's all that kind of stuff and how is it related? So what we're going to do now is we're going to just step through the progression of these things over the few years and see how things emerged

so 15 years ago or so it was even 10 or earlier it was very commonplace to have an actual physical

server in your office or in your home and this was directly connected full-time to the web

and by this I mean that you had a physical server with the fixed IP address that physically sat in

your office and was exposed to the web. And some places, you know, they still have this kind of

setup, but it's becoming increasingly rare for obvious reasons. And when we wanted to publish a

website or expose a service or some kind of thing on the net, it was really easy because we had

control. We had direct access to the physical machine and we could do what we wanted on that

machine. We could install this DLL. We could bring up that library. We could have an exotic

ActiveX plugin. Does people remember ActiveX plugins, right? The things that your website

had to have or they just simply would not work without. But the problem with this setup is that

it's very wasteful. It's expensive. And it left you and the folk in your office, your team

to be the managers of the entire infrastructure, not just the website that you built

And this is a huge deal because not only did you have to be someone

who developed the code and the backend and the HTML and the CSS

because, of course, we didn't have great frameworks like Angular and React

and Vue and all these things back then. You also had to be the guy who actually went and took care of the box

and you had to be the DBA guy and all these different things. So it was very, very difficult

So somebody then came up with the idea of renting out rack space

in their data centers to people who had their own physical machines

and wanted to offload some of the management work of, well, if a disk goes wrong, going over and plugging it in

and plugging it out and that kind of stuff. You know, offloading your management work in a shared server, in a co-hosted server, meant that you still owned the physical machine, but you could send it to this dedicated space where people knew how to, as it were, keep the lights on for internet-facing servers

and take care of some of the things like backup, fast database connectivity

making sure that the servers were patched, that the security was up to date

stuff that, to be honest, website developers really shouldn't have to worry about, right

This should be like just part of the plumbing at this stage. And the thing about co-hosting your own server, though, is that it's still your own server, right

It's still your own hardware. you still have to buy that thing it's still going to cost you a lot of money

and while somebody else is managing the machine and all its related overhead issues it's still

not really efficient like the machine is not being used to its optimal and perhaps 80 percent of its

80 plus indeed of its actual compute life cycle is just spent there lying idle it's money being

wasted that would be put to better use. It could employ a new developer. It could get somebody

else to take the pressure off your team, etc. So the next step up in this evolution of computers

and servers on the internet was shared servers. And this is where a Rackspace company installed

some you know cool fancy pants server but on their own operating and hardware systems that allowed

them to isolate certain folders and processes and to share resources over a number of different

website customers this had the immediate benefit of using the server for a lot more of the time

and at the cost of flexibility to the customer. The customer has got access to, and you've seen these things before, a control panel

And we use this to interface with the services that we could install and upload

and it was quite restrictive. And one of the major problems with shared servers is that, as the name says, things were shared

The operating system was shared. The machine resource was shared. The CPUs were shared

The RAM was shared, the operating system and everything on it, all of the different components were shared

And the problem with this is that if one process goes rogue, if something goes wrong, well, then it can maybe hog 100% of the CPUs on the machine for quite some time

And then any other websites or processes that were sharing the space on that machine will suffer as a consequence

And that's not a great situation. So, along came another clever person, and they came up with this cool idea of virtual machines

And this is where we have a system that can very specifically isolate part of a server's hardware and present it to the operating system, which sees these isolated parts of the server as another entire server

and when I learned about this, first of all, it just blew my mind, right

Like think about it. We take a snapshot of an entire machine an entire server We break it into chunks We hand this to a full operating system and we say this is all you get And that kind of cool because we could now take a very very powerful machine

let's say with one motherboard, a gigabyte of hard drive space, 32 gigs of RAM

and virtually split that into, for example, maybe eight virtual machines with two gigs of RAM

and 100 megs of hard drive space each or whatever it happens to be

one of which would be absolutely tons for you to run maybe a reasonable instance of SQL server

and still have loads of space carved out to run the underlying virtual machine operating system itself

So virtual machines and servers worked really well, and they still do

But they have a limitation. And the limitation is that they're a full-blown operating system environment

And what you need to do is, if you need to create another virtual machine, is you need to spin up another full operating system environment for each and every service that's needed

So despite the fact that we have all of these virtual machines sitting on top of one physical box, it's still a wasteful process, and it's still not optimal on resources

But it's still come a very long way since we had the physical machines in the office, right

So the next step up and the next major step in the evolution was the move towards containerization

And what container technology allows us to do is to create an isolated block of resources within a machine, virtual or otherwise, and to share the underlying machine resources without bleeding into the other services that are using the same resources

And that's really important to note, that you can isolate things on the same machine, on the same operating system, without one application or one container affecting the other

So in effect, this is like a shared server, but without the side effect of one installed system having unintended control over another one due to bad resource management

The other major benefit of a container is that you can specify particular versions of system level dependencies

So, you know this thing where you'd go off and you'd write a piece of software on your machine and then you transfer it to your colleague's machine and they'd say, no, it doesn't work

And you say, well, it works on my machine. No, it doesn't work on my machine. It complains about X, Y, or Z

Library is not installed or it's out of date or it's not up to date or it's the wrong version

It's incompatible. All those problems go away when you start dealing in containers, right

As I said, you can specify particular versions of system-level dependencies. So let's say, for example, that you need to have a particular version of a DLL, a library

another installable. But the problem is that maybe it's custom or even that it's older or it's out of date

to another system or another application that needs to also share that system

on the virtual machine. So that causes a problem. Somebody has to give away

But with containers, what you can do is you can isolate dependencies like this

and you can keep them effectively firewalled from each other. And the added benefit of this

is that if something works on your machine, well, then you can take a snapshot of this configuration

and you can transport it to an online host or another developer's machine

and it will still simply work. No questions asked. If it works within a container on your machine

it will work within a container on any other machine that you put it on. And this is an incredibly powerful feature of containers

and it's worth checking out for this particular feature, if nothing else whatsoever

So now we're going to take another little jump upwards before we come back down again. The container paradigm moved us into an area

where we can have, let's call them, surgically sliced up parts of the operating system just for our simple system

We can use containers to host simple single services like, for example, an SQL server

or even more complex arrangements of different services in combination. But sometimes we need something leaner again

Sometimes we need something tighter. we need a little simple thing where you think actually this one particular part of my system

or my architecture would actually be better just being in a shared instance, doing its thing when

I need it, but without the overhead of a virtual machine or even the overhead of having to manage

a container. And now you can have your cake and eat it. This is what they call function as a service

are serverless computing. On Amazon, they call it Lambda. On Azure, we call it functions

And you now can go in and write a simple function with no supporting website, no container

and just simply say, run this code when some event happens. So functions as a service allow us to write

simple functions or methods that does something on the web, let's say, and to deploy it to run

without having to worry about the underlying infrastructure, without having to worry about setting up a container or a virtual machine

and without having to worry about all of the usual things that we need to do

even to get to a starting point. It's defined as server-less computing because that's actually what it is

It's the ability to write a function or a set of functions in reality

and deploy to what seems to us like an environment that has no servers

no containers, nothing. The cloud provider, in this case Azure, worries about the deployment, the isolation, and critically, the auto-scaling horizontally and vertically when it's necessary

Now, unlike virtual machines and Azure platform-as-a-service type offerings, functions aren't charged by the hour, but rather they're charged by the execution of the function on the microsecond

Like, that's just incredible, by the microsecond. And that raises a really interesting question

In the past, and now really still, we look at our applications and we say, where's the bottleneck

Where are things actually slowing down? Where can we improve our speed, our process for the customer

What's costing us time and what's costing us money? But now, now with the introduction of serverless computing and the fact that we're being charged by the function running

we can now look at things from the point of view of saying what function is costing the business

the most money what function and that's really really really interesting and i suspect that

will bring up um a lot of focus on design decisions in the future and when we talk about architecture of these types of uh big applications but that aside that for a different day session So let say our customer came to us and said

hey, can we implement a simple thing that when an image is uploaded

we check to see if it's in our specified dimensions, and maybe if not, we edit and resize it dynamically

to make it fit our requirements. Now, before functions, we would have had to either add this new functionality to our existing web offering in code someplace, integrate it, upload the changes

But with functions, we can simply go into an online editor, define an endpoint, in this case, something to monitor incoming image files, and write some code that will be processed when the image lands

And that's it. There's no hosting setup. there's not even a file new project, for goodness sakes. I mean, you can do that, but it's not really

needed. So that's incredibly powerful. So we've gone the full loop from physical servers

in our own office through to how they evolved up to functions and serverless

And now we're going to step back a little bit and we're going to look at things from an orchestration and a

management point of view, because actually under the hood, these functions as a service

they actually run as specialized containers, if you like, and they have to be managed

So let's go and focus on containers and Kubernetes again. So the job of containers, as we've seen, is to isolate an application and to package up all of

the dependencies that the application needs into an isolated bundle. and then to run this in a self-contained isolated part of the system

So if Docker manages the applications themselves and the communication between the applications inside the containers

what Kubernetes does is it manages the orchestration of those containers. Kubernetes is the thing, it's that glue in the middle

that manages the containers on the virtual machines on which they run

It ensures that they have enough CPU and RAM. It ensures that the hard drive space is adequate or will alert if it's not

It will ensure that the containers that need to be close together for quick communications are placed onto the same machine

They're deployed or scheduled onto that same machine or to close networks

And if a container dies, it'll start up a new replica of that container

So it monitors the health of the system and a heck of a lot more

And that's the magic of Kubernetes. It manages the containers so that you don't have to

So if we look back and we compare this to the start of the story

when we talked about having a machine in your office, where you had to physically go and physically do all the checks

and put in the floppy disk and the CD and everything else, right? You have to do all those physical things around the machine

it's almost like the same thing in that kubernetes is that person who did all those things

right all you as a developer have to worry about is you deploy your code in the container

shoot the container up to um let's say azure container services and then let kubernetes pull

it down and manage within that so this is um kelsey high towers um github repo um and it has a

a whole set of instructions, step-by-step book, almost if you like, online. And it's called

Kubernetes the Hard Way. And what it does is it talks you through setting up Kubernetes

absolutely from scratch. Because the bottom line, my friends, is that Kubernetes setup

and management is not for the faint-hearted. It can be quite complex

And one of the things that Microsoft does well is they do very good at automation

They do very good at removing pain. They do very good at removing the things that get in our way

that stop us being productive as developers. Because as an engineer, when I look at something

I want to code it, okay? I don't want to get in there and start messing around with all sorts of settings and pipelines and everything else

I want it to just work. I want to do my creative work and keep driving that forward, right

But Kubernetes is an absolutely fantastic and awesome system, and it runs some of the biggest services on the planet today

and will continue to do. It's only growing bigger. But it is not an easy system to work with

Okay. It is not an easy system to work with. And Kubernetes setup and management is hard

And this is one of the reasons that Kelsey's website there says Kubernetes the hard way

because it's difficult. It's a bit like hardware. You know, we have hardware and we've got software

Like there's a little hint there in the name, hard, hardware, because hardware is hard, right

Kubernetes setting up is also hard. So if you look here at this diagram

what we're looking at is we're looking at three machines. We call them nodes

One is running CentOS, the other is running CentOS, the other is running CentOS

So three machines running CentOS. That's the Cent operating system version 7

And each of those has a particular role, and each one of them runs containers

If we didn't have Kubernetes, we would have to dial in and manage those machines ourselves

as we deploy the containers onto them. Kubernetes does that management for us

Before I continue, I'm just going to check on the website here

and to make sure that we're actually doing okay on time. So can you just give me a ping there, Stephen

in the chat window to make sure that I'm okay, because I don't want to run too much over or

under time. Yes, I think we're doing good. That's fine. So we're doing good. Okay, so let's go back

here now. And in this here, we can see that we have three virtual machines, and we have Kubernetes

managing. And it seems reasonably clean there, okay? It seems like there's not a lot to do

Now I'm going to show you another screen. And this screen here shows a little bit more of what's

actually going on inside in the Kubernetes network when we have it running and what is it actually

doing. So this looks a little bit more complex, right? So in Kubernetes, we have two main types

of machines or nodes, as they're called. We have a master machine, a master virtual machine, and then

we have node machines. Now, these guys used to be called, and they weren't called nodes

They were actually previously called Minions from the Minion cartoon program

I thought it was really cool. I prefer them to call Minions, but they've changed the name. And that's the way it is

In any case, what you can see here is that in every node, we have a stack, which is, first of all, the operating system

On top of that, we have the container runtime. And this is the thing that runs the actual Docker containers that have our applications

On top of that, we have a thing called a kubelet. And a kubelet is a small application that runs like a daemon

It runs as a service on the nodes, and it continuously communicates back and forth to the master Kubernetes node, reporting on the health of the system, reporting on the containers that are running, what type of CPU they're taking, how much space they're taking, all these different things

Above that, again, we have the networking layer, and we look at networking a little bit later in a live system I'm going to demonstrate to you

And if you look at the different color of the arrows, right, of the information going up and forward, you'll see that it uses a number of different types of network message communication protocol

It uses JSON message exchange on REST APIs. It uses gRPC. It uses core protobufs

So an awful lot going on there. By the way, if you are doing all of high-speed messaging

I would recommend that you look at GRPC and Protobufs. They're absolutely awesome from a speed point of view

That aside, let's go back to the picture here. So on the top, then, the master machine

it has a number of different services that it runs and it manages

First of all, it has an API server. And this is to allow the different nodes via the kubelets to communicate back to it

so that it knows what's going on all the time. Then it has a scheduler and a control manager

which decides exactly what containers should be running where, how many there should be, et cetera, et cetera

And it keeps those all ticking along. But the bottom line here to note is that the container part

the container runtime, is an extremely small part of this entire process

And what you can see there in this high-level diagram is actually quite a complex environment

There's a huge amount that's actually going on there. Kubernetes is hard

So what Azure Kubernetes service does is it comes along and it manages the hard stuff for us

Okay. It takes away the pain. And there's a lot of pain if you try and do it yourself, trust me

It takes away the pain and it does all of these things for you. It ensures that the virtual machines stay up

If one goes down, it will deploy another one. It will ensure that it gets filled out with the right containers

It will auto-scale them. It'll keep your machine healthy. It'll keep your security up to date

Every single thing that you would normally have to do as a person tweaking Kubernetes manually

Azure Kubernetes Service takes care of for you. And that's incredibly important

So some of the key benefits of using Azure Kubernetes Service, at least to me, like most of Azure, is that we have incredibly tight integration with all of the other Azure services that we know and love

So we have, first of all, elastic provisioning, and we can use a tool that Microsoft have generated and given out as open source called KIDA

and KIDA is really interesting because what it is is it's an event preprocessor

and it a system that can look at a queue so it can look at a queue of work that coming down into your system into your app And it can make a decision based on the amount of work in that queue

So the amount of work coming down into your app that's spread across many containers

It can say, hmm, I think that this particular system is about to explode

I think this particular system is going to need to grow really, really fast, really quickly

because maybe you've just put an advert on TV. Maybe it's been on Super Bowl Monday or something

Maybe it goes out as an advert on the most popular reality TV show

and suddenly everybody says, oh, we want to go and we want to use this service. So as all these people hit your end point and those messages come into your queue

Kida can look at those coming into the queue and can say, ah, we need to auto-scale the system up

So it can grow your system. You don't have to do this

You don't have to go in and manually trigger up Kubernetes. AKS will take care of this for you

You just need to configure it, give it the boundaries, because we don't want our budget to be blown either, right

And it'll take care of that for us. The other thing that it does is it takes care of very tight integration

with our Azure DevOps. And this is one thing that I use very heavily myself

So all of the code that my company uses, we push into Azure DevOps

And we have our ticketing system in there in Azure Boards. We use Azure Container Services

We've everything tightly integrated. And this means that when I go in and I write a ticket for one of the engineers on my team to say

go and do this particular thing here, they go off and do it. When they do a push on Git, they put in a flag in the comment to say that it's attacked that this particular push they're doing for a PR request is linked to a particular job

So it's linked to a particular task that I issued to them on the board. That gets in

The other members of the team, they'll check the PR, and that's accepted

and then it gets pushed up and it goes through and it's integrated into the overall system

and gets pushed up into Azure Container Services and then gets automatically deployed down into Azure Kubernetes Service itself

So for me, one of the huge wins here is the end-to-end tight integration that we have

The other thing it does is it integrates very tightly with Azure Active Directory

which means that we can have our inbuilt security layer very, very tightly

And the other benefit that it has is it is in more regions

than any other cloud provider that we have at the moment. So earlier on, I talked about having to have numerous people involved

in the process to get our application up and running. We talked about having IT pros and the DBA and the security guy

all of these different folk involved. But the beauty of using an integrated service is that we can now automate all of this and put it into a pipeline

And this is what my company does. All of our work is in one smooth pipeline

Everything gets taken care of from end to end. So now we can easily define, deploy, debug, and upgrade incredibly complex systems and automatically containerize everything

We can ensure that all of our routine tasks are automated and that we have a very, very deep level of traceability

across everything in our deployments. And this is incredibly important. You can see there from the diagram on screen

where we can start out and we can send everything in through the repos They can come up They can automatically do a continuous integration and deployment

It can go and it can automatically pull down, deploy, or deploy into and pull down from the Azure Container Registry Services

It can kick that then into the Azure Kubernetes production cluster. Everything is automatic from end to end

And this is one of the, for me, the huge draws of AKS integrated with everything else

Deploying your code into Azure Kubernetes Service is extremely easy. Like, it just could not be easier, both in the large Visual Studio and in the lightweight Visual VS Code itself

So this screen, for example, shows how I can make one request and will deploy my code directly up to a container

running my code up on the cloud and push it through all those loops

in my predefined pipeline. And I don't have to worry about this, right

So this is the beauty of the managed service. The other thing is that if you recall

we talked about how Azure container, or sorry, Azure Kubernetes service removes the pain of managing all of these virtual machines

that sits under Kubernetes. Well, this is how easy it is. We can define the type of machine that we want

And then we can either choose to manually update these ourselves, or we can let Azure auto-scale this with certain criteria, potentially hooked into the likes of Kida to push that along for us, which is pretty awesome

So what I'm going to do now is I'm going to show you, give you a little peek inside one of my own systems of things that's going on inside a Kubernetes cluster

In this case, this is a Kubernetes cluster that's managed by AKS

So I'm going to investigate it through a thing called WeaveScope, which is a tool for examining the network, and show you some of the different things that's going on

And I think by looking at this here, you will see the complexity of Kubernetes

You will see the huge amount of things that it has to manage

And you'll understand why you do not want to do this yourself, right? You'll understand why you want to use Azure Kubernetes Service or another similar managed service

But importantly, you'll want to get somebody else to manage this for you because you don't want to spend your time here unless that's what you want to do

And if that's what your thing is, that's awesome. Go for it. So what I'm going to do now is I'm going to skip over hopefully to my live screen here and see if I can pick it up

let me see if I go here and I click out of this, I think I'm now in WeaveScope. So I'm just going

to double check with the guys here to confirm that they still have that. So Simon, Stephen

you have the correct desktop there at the moment. I did this last week and I turned out I was showing

the wrong desktop. So you should be seeing a thing called WeaveScope and you should see my mouse

moving around now. WeaveScope. Awesome. Okay. So what we're doing now is we're looking inside

a live Kubernetes instance. And this particular thing here has a number of

services inside. It has a thing called Grafana, which is a dashboard system

It's got JupyterLab, which is a system for machine learning and working with AI

It got then Certificate Manager it got Superset which is a database visualizer type tool We have Cassandra database over here We have Redis over here We

got Mongo over here. So there's a huge amount going on here. Okay, we can see an awful lot going on

here in this particular system. And what I'm looking at here now is I'm looking at the containers

live as they're working across my system, which is why you're seeing things move in and move out

What I'm now going to do is I'm going to show you the underlying machinery underneath this, and I'm going to do that by clicking on the hosts button up here at the top

So if I click on hosts, as it goes and it updates here, it sees that I have one, two, three, four hosts

Okay, so there's four hosts that I have, and each one of these is running Kubernetes, and they're all managed by AKS

Now, if I go to one particular host, this first one here, I'm going to click into it, and it would bring up the properties on the right-hand side here

And inside this, I can get information on what's happening on this particular host

So you can see here that it's using a small amount of memory

The overall load is less than half of a percent. CPU is less than 4%

If I look down here and see what containers are on the machine, it tells me exactly what containers are deployed onto this machine at the moment

And I can see also what processes are running on the machine

Now what I'm going to do is I'm going to click on a different machine. So we can see here that there is Weaveworks, TunnelProbe

and four pods on this machine here. So now I click to this machine over here

And we can see here that it's running different containers. So these are the different containers

that this machine is running for us. If I had to go and do that myself by hand

that would take a serious amount of work managing all this stuff, right? But again, by using this here, it does it for us automatically

So what I want to show you now is if I go into containers

Stephen tells me I have to wrap up soon, so I'll do that

Now what I'm going to do is I'm going to look at some of the containers that I have, and I'm

going to look at the work that they're doing. So this one here is one of our main things, which is a worker

And if I go into this worker here, I can see all of the information about that particular system

I can also go in and I can execute a shell onto that system there

And it will allow me to interact with it directly. So all of this here I can do from inside Azure Kubernetes Service

And the reason I can do it from inside it is because all of the hard work is taken care of for me by Azure, by the Azure Kubernetes service

If I didn't have it managing all this for me, either A, I would have even less hair than I have right now left, or B, it just wouldn't be up there because it is difficult to do, guys

So if you're getting into deployments, I strongly recommend that you consider using this for it

So let me just now finally wrap up and ask if anybody has any questions