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 want 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, like perhaps being
noted on 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 the 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 the CTO of a company called The Data Works, 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. And 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, unfortunately, on COVID days right now
And in a serious way, these folk organise local meetups, they promote technology, they promote
diversity and inclusion, and 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 and 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, but start by answering some questions online
write an article, considering sharing some of your knowledge with fellow techies, either virtually or
in a way when we get back into whatever the new normal becomes with physical meetups and
physical people. And the biggest message I want to give everyone, you know, 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
container controls, 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 to a
Q&A that 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 look at those and you 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. And 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 it 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 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, 32K. And the engineers and other people related
costs, it was going to take us 30 to 40 people to bring this all together. And that was going
to cost us about $250,000. And to ensure that we gave our project success, 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. 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 the like, but it was a very big project for the time
And if you convert this 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. You would say
I did this big project and it was 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've seen those big
little 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 the
bones of 45, 50 minutes slapping together a React.js and Entity Framework into place and
spinning up my code, and what I did was I did like, you know, Visual Studio and file 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 half a million dollars and took months and months and months to push through
in completion 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 will remember this, publish into a particular folder
and then FTP the code or the DLLs and all of the supporting files up to the service host and
beg them, you know, 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 hope that everything connected together and worked and that the website would deploy
You know, undergods 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 this 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 a few years and see how things emerge. 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 have a physical server with the fixed IP address but 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 rarer 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. Those people remember ActiveX plugins, right? The things that your
websites had to have or they just simply would not work with them. But the problem with this setup
is that it's very wasteful, it's expensive, and it lets 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 was a huge deal because not only did you have to be someone who developed the code
and the backend and do 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. Offloading your management work in a shared
server, in a co-hosted server, meant you could still own 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
activity, making sure that the servers were attached, 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 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 when 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 for its optimal and perhaps 80% of its
80% plus, indeed, of its actual complete lifecycle is just spent online idle. It's money being wasted
that'll be put to better use. It could employ a new developer to 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 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 customers got access to, you've seen these
things before, a control panel. And we used this to interface with the services that we could
install and upload. It was quite restrictive. And one of the major problems with shared servers
is that, as its name says, things are shared. The operating system is 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's
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 8 virtual machines with 2 gigs of RAM and 100 megs of hard drive space each, or whatever
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 work 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 fairly 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'd transfer it to your colleague's
machine, and they'd say, no, it doesn't work. And you'd say, well, it works on my machine
No, it doesn't work on my machine. The container XYZ library is not installed, or it's over days
it's not up to date, or it's the wrong version, it's incompatible. All those problems go away
when you start dealing with containers, right? As I said, you can specify particular versions
of system-level dependencies. So, let's say, for example, that we 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, another application that needs to also share that
system on the virtual machine. So, that causes a problem. Somebody has to give way. But with
containers, what you can do is you can isolate dependencies like this, and you 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
It will work 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 you 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 this 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, or
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 build 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 serverless 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 hours, but rather they're charged by the execution of the function
on the microseconds. That's just incredible, the microseconds. 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
interesting. And I suspect that that will bring up a lot of focus on design decisions in the future
when we talk about architecture of these types of big applications. But that's aside, that's for
a different day's lesson. So let's 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 dimension
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
offing in code from place, integrate it, upload the changes. But with functions, we can simply
go into an online editor, define an end point, in this case, something to monitor incoming
image files, and write some code that will be processed from the image lines. And that's it
There's no whole thing set up. There's not even a file new project for goodness sake
But 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, and 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 a 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 acknowledges the orchestration of those containers
Kubernetes is this thing, it's that blue 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 spaces is adequate, or will alert if it's not. It will ensure that the containers that
need to be pulled 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 will 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
and we talked about having a machine in your office, where you have 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 containers, shoot the container up to, let's say Azure Container Services
and then let Kubernetes pull it down and manage it in that. So this is Kelsey Heitauer's GitHub repo
and it has a whole set of instructions, step-by-step book, almost, if you like, online
and it's called Kubernetes for Hardware. 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 same target. 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 a code
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
sliding that forward. But Kubernetes is an absolutely fantastic and awesome system, and
is one of the biggest services on the planet today, and will continue to do this 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 is the hard way, because it's difficult. It's a bit like hardware. We have
hardware and we've got software. The little things there in the name, hard, hardware
because hardware is hard, right? Kubernetes, that 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. It was running CentOS. It was running CentOS. The three machines running CentOS
And 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 just want to check on the website here to make sure that
we're actually doing okay on time. So can you just give me a finger, 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. 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. 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 it's 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. I thought it was really cool. I prefer them to be called
minions, but they changed the nodes, 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 dino. 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'll look at networking a little bit later in a live system I'm going to demonstrate
to you. And if you look at the addition 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
protobuf, an awful lot going on there. By the way, if you are doing a lot of high-speed messaging
I would recommend that you look at gRPC and protobuf, and 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, and 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 kubelet 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
and it keeps all this 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. It takes away the pain, and there's a lot of
pain if you're trying to do it yourself, trust me. It takes away the pain and it does all 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 of 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
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
KEDA. And KEDA is really interesting because what it is, is it's an event preprocessor, and it's a
system that can look at a queue. So it can look at a queue of work that's 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
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 it just has an advert on TV
maybe it's been on Super Bowl Monday or something, and 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 their end point, and those messages come into the queue
KEDA can look at those coming into the queue and can say, ah, we need to autoscale 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 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 grown 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 have 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. And when they do a push on Git, they put in a flag in the comments
to say that a task that this particular push they're doing for a PR request is linked to a
particular job. It's linked to a particular task that was sent to them on the board. That gets in
the other members of the team, they request a 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 in-built 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
guys, all these different folks 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
into the repos. They can come up, they can automatically do a continuous integration and
deployment. It can go and automatically pull down, deploy, or deploy into and pull down from the
Azure Container Agency services. It can kick that then into Azure Kubernetes production cluster
Everything is automatic from end-to-end. And this is one of the, for me, the huge draws of
an AKS integrated with everything else. Deploying your code into Azure Kubernetes itself
is extremely easy. 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 where I can make one request
and would deploy my code directly up to a container, running my code up in the cloud, and push it
through all those loops in my predefined pipeline. And I don't have to worry about this
So this is the beauty of the managed service. The other thing is that, if you recall, we talked
about how Azure Kubernetes service removes the pain of managing all of these
virtual machines that sit 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 also scale this with certain criteria, potentially hook you into the Lexis computer 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
a little peek inside all 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
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 an Azure
Kubernetes service, or another similar managed service. But importantly, you want to get somebody
else to manage this for you, because you don't want to spend the 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
I'm just going to double check with the guys here to confirm that they still have that
So Simon and Steven, 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 all 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's got SCAN certificate manager. It's got SuperSET, which is a database visualizer type
tool. We have Cassandra database over here. We have Redis over here. We've got Mongo over here
So there's a huge amount going on here. Okay, you can see there's a 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
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, there's updates here. It shows 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 host 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 a percent. CPU is less than four percent. 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's Weedworks, Tunnel Probe, 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. If I had to go and do that myself by hand
that would take a serious amount of work managing all this stuff. 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 want to do is I want to look
at some of the containers that I have, and I want 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 within inside Azure's 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 this managing all this for me, either A
I would have even less care than I have right now left, or B, it wouldn't be up there
because it is difficult to do that. So if you're getting into deployments, I strongly recommend
that you consider using this part. So let me just now finally wrap up and
ask if anybody has any questions