WEBVTT
00:00:09.291 --> 00:00:16.126
Hello, welcome to Microsoft Community Insight podcast, where we share insight from community experts to stay up to date with Azure.
00:00:16.126 --> 00:00:18.707
My name is Nick and I will be host today.
00:00:18.707 --> 00:00:31.088
In this episode we will dive into Azure Kubernetes service, but before we get started, I want to remind you to follow us on social media and never miss this episode, so it helps us reach more amazing people like yourself.
00:00:31.088 --> 00:00:33.645
So today we have a special guest.
00:00:33.645 --> 00:00:38.244
Today, richard Hooper, can you please start introducing yourself, please?
00:00:39.209 --> 00:00:58.810
Yeah, hi, I'm Richard Hooper, also known as Pixel Robots Online, so you can follow me on all socials and on the blog and at Pixel Robots Azure MVP for five years now, microsoft Certified Trainer Hooper of a book called Azure Containers Explained and so much more.
00:00:58.810 --> 00:01:02.268
Probably haven't got enough time, so, yeah, we'll leave it at that.
00:01:03.280 --> 00:01:03.500
Okay.
00:01:03.500 --> 00:01:12.525
So, speaking about your offer about Azure Explained, do you want to give a little brief summary of your book before we get started?
00:01:12.525 --> 00:01:13.046
Yeah, of course.
00:01:13.507 --> 00:01:23.308
Yeah, so the book which is available on Amazon and Appact is basically all about the different technologies you can run containers on inside Microsoft Azure.
00:01:23.308 --> 00:01:45.075
We go into the use case of why you would do it, the pitfalls, the pros, the cons, and then it would build up your application from a simple app all the way up to a multi-tenant sort of multi I don't know how to describe this multiple containers into your app.
00:01:45.075 --> 00:01:54.876
So you've got your front-end, your back-end APIs and stuff like that, and, yeah, so you go all the way from running it on VMs all the way up to AQS and further.
00:01:54.876 --> 00:01:54.977
Okay.
00:01:56.742 --> 00:01:59.108
And I take it this book is available from Amazon, right?
00:01:59.870 --> 00:02:03.268
Yes, yeah, go on Amazon and online Appact as well.
00:02:04.350 --> 00:02:07.480
Okay, so today's theme is Azure Kubernetes Service.
00:02:07.480 --> 00:02:09.807
We just get to the access and question regarding it.
00:02:09.807 --> 00:02:14.250
So what are the most common use case for using AQS?
00:02:15.680 --> 00:02:44.800
So, yeah, the good question, the most common use case we see is where software companies have got an application that's running in web servers and then other apps and they've already, like, slightly decoupled them, and then they want to basically be able to scale this quicker but without having to add a new virtual machine, setting up IIS or Apache, setting up all that web server config and then adding this on, adding that on, and they want to be able to scale their app based on demand.
00:02:44.879 --> 00:02:49.912
So, like when you've got Black Friday or Christmas sales, they want their app to expand.
00:02:49.912 --> 00:02:56.448
But when you've got it on virtual machines you need to add more compute or you need to add a new one into the cluster.
00:02:56.448 --> 00:02:58.826
So it gets a bit complicated and a bit more manual.
00:02:58.826 --> 00:03:26.586
Whereas with AQS you've got your containers running and you can just say, oh yeah, I, just once I've hit this certain threshold be it CPU memory, even maybe HTTP requests or other metrics on service bus or RabbitMQ, it will just scale it up and automatically scale it and then use the virtual machines in the background to automatically scale and you've just got that sort of I wouldn't say unlimited scale, but near unlimited, based on your quotas in Azure.
00:03:27.640 --> 00:03:36.752
Okay, so, speaking of scaling up, how does this Azure Kubernetes service differ from other AQS, like Kubernetes service, because they have different providers?
00:03:37.836 --> 00:03:45.468
Yeah, so it's a good one, because AKS used to just have the cluster auto scaler, which is a Kubernetes thing.
00:03:45.468 --> 00:03:47.979
All of the cloud providers use cluster or scale.
00:03:47.979 --> 00:03:54.741
All of the on-prem Kubernetes distributions will use cluster or scale.
00:03:54.741 --> 00:04:01.187
And then there's a company called AWS Amazon massive big company they got their own one.
00:04:01.187 --> 00:04:09.837
They created this cool tool called Carpenter, which basically is a new and improved in a way auto scale up.
00:04:09.837 --> 00:04:19.805
But it's now being open sourced, donated to the CNCF part of the auto scaler SIG, and it basically can work in Azure now and other cloud providers.
00:04:19.935 --> 00:04:23.749
But what this does differently to the auto scale is you can tell it right.
00:04:23.749 --> 00:04:45.324
I would like to use any VM size in this family and then it will go off find the best resources available to you, the best VM size, automatically for you, based on your workload you're giving it, whereas with the cluster or scale up you need to have your node pools already created and it can scale up and down, but it can't change the SKU randomly.
00:04:45.324 --> 00:04:54.425
So Carpenter is new they call it node auto provision inside AKS and definitely worth a look if anyone's wanting to look it out.
00:04:54.425 --> 00:04:58.384
It's in preview so it can be a bit buggy, but it's good.
00:05:00.134 --> 00:05:08.303
So, speaking of auto like Kubernetes services from different cloud provider, what are the major benefits of using AKS than other Kubernetes service?
00:05:09.975 --> 00:05:29.201
For me, I would say the ease of use, the ease of onboarding the developer experience, the integration to things like Azure, ad, entra ID, where most of you find most of the enterprises will have a mugs of active directory in their own intendants or they'll use Entra ID, so AKS can easily integrate into that.
00:05:29.201 --> 00:05:35.964
But, yeah, the AKS development team and the product management team have put a lot of effort in to make the updates a lot easier.
00:05:35.964 --> 00:05:40.141
So it does pre-validation checks to make sure your APIs aren't depreciated.
00:05:40.141 --> 00:05:53.420
They've invested a lot of time given back to the open source community so they work on the actual Kubernetes source code and all these third party add-ons, give it back to the CNCF and then other people can use it.
00:05:53.420 --> 00:06:03.920
Other cloud providers can use it, whereas other companies like Amazon and that they're not always nice at giving back to the open source community, whereas Azure really is.
00:06:03.920 --> 00:06:04.882
So I love that about them.
00:06:07.254 --> 00:06:16.000
So, speaking of when, again scaling with Azure Kubernetes service, how does AKS handle scaling and balancing?
00:06:17.216 --> 00:06:18.862
Yeah, so good question again.
00:06:18.862 --> 00:06:21.139
So obviously you've got the node scaling.
00:06:21.139 --> 00:06:32.824
So that depends on if I have too much workload for the existing nodes, it will add a new node for me, either using the cluster autoscaler or by using the node access node order provision.
00:06:32.824 --> 00:06:41.384
But when your workloads need to scale, by default it uses the Kubernetes methods, which is CPU and memory and the horizontal pod autoscaler.
00:06:41.384 --> 00:06:46.497
But you have a nice add-on feature which is called KEDA or KEDA, depending on where you're from.
00:06:46.778 --> 00:07:10.108
I always call it KEDA, but this is an open source tool which was actually created with Microsoft and Red Hat to start off with, and now it's all open to the community so anyone can go contribute and this can integrate in with many, many different resources, so RabbitMQ, file services, Amazon S3, azure, gke, prometheus you name it.
00:07:10.108 --> 00:07:13.418
It's probably got a scaler and it reaches up to these scalers.
00:07:13.418 --> 00:07:16.903
Depending on what metrics you set, it will add extra pods.
00:07:16.903 --> 00:07:22.045
It all works on top of the horizontal pod autoscaler as well, so it's using that Kubernetes stuff.
00:07:22.045 --> 00:07:24.095
It's really good, so definitely check it out.
00:07:24.095 --> 00:07:26.321
It's KEDAsh if anyone wants to have a look.
00:07:29.636 --> 00:07:35.384
So you mentioned before that Kubernetes Rabbit Scalable thing.
00:07:35.384 --> 00:07:42.163
What I do, a best practice for different application on a case for scaling it, yeah, good, good again.
00:07:42.182 --> 00:07:43.124
Another good question.
00:07:43.124 --> 00:07:48.273
So your best practices always make sure you set your request and limits for your CPU memory.
00:07:48.273 --> 00:07:49.574
Always do that.
00:07:49.574 --> 00:07:53.250
Even if you're not sure, set it and then you can always go back and check it.
00:07:53.250 --> 00:08:08.696
Always make sure you have at least two replicas of your application running and you set your like pre stop hooks and stuff like that so if it dies you know it can finish off doing what it's doing and died gracefully and stuff like that.
00:08:08.696 --> 00:08:15.105
So like on the sick term, yeah, make sure you try and do topological spread.
00:08:15.146 --> 00:08:19.132
So in Azure you got zone availability zones one, two and three.
00:08:19.132 --> 00:08:22.536
Make sure you work like a beast spread over all three zones if needed.
00:08:22.536 --> 00:08:32.125
And I know best practice, which is sort of changing for me now recently with the changes that come from Azure but you don't use persistent storage if you can get away with it.
00:08:32.125 --> 00:08:36.270
So if you needed to have storage, do API calls to block storage or something.
00:08:36.270 --> 00:08:45.966
Don't mount that files or Blob into your pod because it can slow things up and obviously you want it to be super quick because it's in containers.
00:08:45.966 --> 00:08:47.888
But they are fixing that.
00:08:47.888 --> 00:08:58.336
They got this new service called Azure container storage and we've now got the ability to use zone redundant storage with our ACS, so the story is getting better.
00:08:58.336 --> 00:09:06.874
I'm getting closer to being happy to suggest it, but yeah, it's definitely something to keep an eye on.
00:09:08.243 --> 00:09:10.326
Okay, so we want to find out.
00:09:10.326 --> 00:09:15.817
The viewers want to find out what inspired Richard Cooper to be involved with a chaos.
00:09:15.817 --> 00:09:18.466
So can you find out A bit more?
00:09:18.466 --> 00:09:21.580
Yeah, inspired you to get started.
00:09:22.501 --> 00:09:23.785
Yeah, again, another good question.
00:09:23.785 --> 00:09:25.529
You've got some blinders here.
00:09:25.529 --> 00:09:28.264
So I've got this admin background.
00:09:28.264 --> 00:09:34.936
I started off on the help desk, worked all my way up working on physical machine servers and then virtual machines.
00:09:34.936 --> 00:09:44.793
So, like you know, hyper VVM, where and then I was working as company, we had a monolithic application and it was hard to get it to scale.
00:09:44.793 --> 00:09:47.758
Basically it was, you know, customers will send us lots of information.
00:09:47.758 --> 00:09:51.206
We need is a scale the app quick, and it was extremely difficult.
00:09:51.206 --> 00:09:59.285
So we started looking into containers and that technology and Kubernetes and it just sort of made sense to me.
00:09:59.405 --> 00:10:07.059
Like I've got this infrastructure background, kubernetes is just a sort of operating system in a way on top of services, like the hyper V is.
00:10:07.059 --> 00:10:10.293
You know, it's like the VM, where it's just Kubernetes.
00:10:10.293 --> 00:10:12.100
It orchestrates my workloads.
00:10:12.100 --> 00:10:15.586
My workloads are now in a container instead of virtual machine.
00:10:15.586 --> 00:10:24.100
You've got hand charts and values, files and all that, which is just like when I had MSI's to install my application with my MSD, my transformation files.
00:10:24.100 --> 00:10:27.623
So to me it just all clicked in my head and made sense.
00:10:27.623 --> 00:10:30.424
So I thought, oh, this is where the world's going.
00:10:30.424 --> 00:10:31.645
This makes sense to me.
00:10:31.645 --> 00:10:36.369
Let's just go all in on it and see where it takes me, and so far this been good.
00:10:37.711 --> 00:10:38.394
Okay, brilliant.
00:10:38.394 --> 00:10:45.817
So before we wrap up with the episode, we want to ask you are you going to any events or future events?
00:10:46.931 --> 00:10:47.591
Yes, yes.
00:10:47.591 --> 00:10:49.816
So we've got a few coming up.
00:10:49.816 --> 00:10:53.583
We've got KubeCon in Paris, which is coming in March.
00:10:53.583 --> 00:10:55.833
I'm super, super excited about that.
00:10:55.833 --> 00:11:00.693
It's where thousands, literally thousands of people are all coming together.
00:11:00.693 --> 00:11:06.980
Microsoft, aws, all these open source companies all come together and talk about Kubernetes in the cloud native world.
00:11:06.980 --> 00:11:08.259
So I'm going to be there.
00:11:08.259 --> 00:11:09.929
Hopefully I'll see quite a few other people there.
00:11:09.929 --> 00:11:20.263
And then we've got experts live in Budapest this year, which hopefully I'll see you again at Nick, because it was awesome to see you there last year in Prague.
00:11:20.263 --> 00:11:29.043
And then, obviously, we've got KubeCon North America, which is going to be in Salt Lake City in November time.
00:11:29.043 --> 00:11:36.410
Then, hopefully I think it goes across this a lot it will be Microsoft Ignite, but we're still waiting for them to announce where that's going to be.
00:11:36.410 --> 00:11:39.879
It'd be good to get back to a full Microsoft conference.
00:11:39.879 --> 00:11:44.318
That's my background, so I'd like to be back there with the people that I know.
00:11:45.590 --> 00:11:46.030
That's brilliant.
00:11:46.030 --> 00:11:49.820
How can do before we close the episode?
00:11:49.820 --> 00:11:53.597
How can the audience learn about AKS and connect with you to stay up to date?
00:11:54.972 --> 00:11:55.855
Yeah, good question again.
00:11:55.855 --> 00:11:59.568
So to learn about AKS, I'm going to permit myself here.
00:11:59.568 --> 00:12:02.139
I've got an AKS course on LinkedIn, so go check that out.
00:12:02.139 --> 00:12:05.052
The Microsoft Learn documentation is awesome.
00:12:05.052 --> 00:12:09.231
They've also got LearnPars all about AKS and the clone of world, so check those out.
00:12:10.215 --> 00:12:13.245
But the best way is just to deploy it and start playing with it.
00:12:13.245 --> 00:12:15.352
It really makes life easier, I think.
00:12:15.352 --> 00:12:22.075
And don't think of it as too complicated, because, yes, it's a massive beast, but it's just like VMware, hyper-v.
00:12:22.075 --> 00:12:26.312
We have to deal with networking, storage, os patching back in the days.
00:12:26.312 --> 00:12:28.578
It's just the same, just a different name for the software.
00:12:28.578 --> 00:12:44.974
And then, yeah, just sort of get on Twitter as well, or X as it's called, and just start following people like myself and some people at White Duck, nico and Phil, and to be to Wesley and Carl, all on Twitter.
00:12:44.974 --> 00:12:50.323
And, yeah, just get involved with the community and talk to people.
00:12:50.323 --> 00:12:51.793
That's also another good way to learn.
00:12:51.793 --> 00:12:55.373
And then, if you want to reach out to me, you can find me on Twitter.
00:12:55.373 --> 00:12:58.259
Or X, pixel, and it's called Robots.
00:12:58.259 --> 00:13:00.331
You can find me on my blog, pixel Robots.
00:13:00.331 --> 00:13:05.474
Find me on LinkedIn, richard Hooper it's got a weird thing because I've got a cloud and stuff in the name.
00:13:05.474 --> 00:13:07.659
So just search for me and you'll find me.
00:13:09.932 --> 00:13:10.634
Okay, brilliant.
00:13:10.634 --> 00:13:15.143
Is there any last few words that you want to say to the viewers, or anything?
00:13:16.051 --> 00:13:16.711
Yeah.
00:13:16.711 --> 00:13:23.332
So yeah, if you're looking into Kubernetes and you're a bit afraid, don't be afraid, just embrace it.
00:13:23.332 --> 00:13:27.248
It's not that difficult If you've got a sysadmin background.
00:13:27.248 --> 00:13:29.779
If you've got a developer background it's a bit harder.
00:13:29.779 --> 00:13:33.215
But if you just follow the learning path, some Microsoft learn, it should be fine.
00:13:34.871 --> 00:13:36.035
Okay, brilliant, okay.
00:13:36.035 --> 00:13:43.919
Thanks for coming into this episode, richard, since you're quite busy, so I hope you're showing a few weeks, a few days.
00:13:43.919 --> 00:13:48.952
It's going to be on Spotify and not the music, so stay tuned.
00:13:48.952 --> 00:13:50.996
Bye, bye.
00:00:09.291 --> 00:00:16.126
Hello, welcome to Microsoft Community Insight podcast, where we share insight from community experts to stay up to date with Azure.
00:00:16.126 --> 00:00:18.707
My name is Nick and I will be host today.
00:00:18.707 --> 00:00:31.088
In this episode we will dive into Azure Kubernetes service, but before we get started, I want to remind you to follow us on social media and never miss this episode, so it helps us reach more amazing people like yourself.
00:00:31.088 --> 00:00:33.645
So today we have a special guest.
00:00:33.645 --> 00:00:38.244
Today, richard Hooper, can you please start introducing yourself, please?
00:00:39.209 --> 00:00:58.810
Yeah, hi, I'm Richard Hooper, also known as Pixel Robots Online, so you can follow me on all socials and on the blog and at Pixel Robots Azure MVP for five years now, microsoft Certified Trainer Hooper of a book called Azure Containers Explained and so much more.
00:00:58.810 --> 00:01:02.268
Probably haven't got enough time, so, yeah, we'll leave it at that.
00:01:03.280 --> 00:01:03.500
Okay.
00:01:03.500 --> 00:01:12.525
So, speaking about your offer about Azure Explained, do you want to give a little brief summary of your book before we get started?
00:01:12.525 --> 00:01:13.046
Yeah, of course.
00:01:13.507 --> 00:01:23.308
Yeah, so the book which is available on Amazon and Appact is basically all about the different technologies you can run containers on inside Microsoft Azure.
00:01:23.308 --> 00:01:45.075
We go into the use case of why you would do it, the pitfalls, the pros, the cons, and then it would build up your application from a simple app all the way up to a multi-tenant sort of multi I don't know how to describe this multiple containers into your app.
00:01:45.075 --> 00:01:54.876
So you've got your front-end, your back-end APIs and stuff like that, and, yeah, so you go all the way from running it on VMs all the way up to AQS and further.
00:01:54.876 --> 00:01:54.977
Okay.
00:01:56.742 --> 00:01:59.108
And I take it this book is available from Amazon, right?
00:01:59.870 --> 00:02:03.268
Yes, yeah, go on Amazon and online Appact as well.
00:02:04.350 --> 00:02:07.480
Okay, so today's theme is Azure Kubernetes Service.
00:02:07.480 --> 00:02:09.807
We just get to the access and question regarding it.
00:02:09.807 --> 00:02:14.250
So what are the most common use case for using AQS?
00:02:15.680 --> 00:02:44.800
So, yeah, the good question, the most common use case we see is where software companies have got an application that's running in web servers and then other apps and they've already, like, slightly decoupled them, and then they want to basically be able to scale this quicker but without having to add a new virtual machine, setting up IIS or Apache, setting up all that web server config and then adding this on, adding that on, and they want to be able to scale their app based on demand.
00:02:44.879 --> 00:02:49.912
So, like when you've got Black Friday or Christmas sales, they want their app to expand.
00:02:49.912 --> 00:02:56.448
But when you've got it on virtual machines you need to add more compute or you need to add a new one into the cluster.
00:02:56.448 --> 00:02:58.826
So it gets a bit complicated and a bit more manual.
00:02:58.826 --> 00:03:26.586
Whereas with AQS you've got your containers running and you can just say, oh yeah, I, just once I've hit this certain threshold be it CPU memory, even maybe HTTP requests or other metrics on service bus or RabbitMQ, it will just scale it up and automatically scale it and then use the virtual machines in the background to automatically scale and you've just got that sort of I wouldn't say unlimited scale, but near unlimited, based on your quotas in Azure.
00:03:27.640 --> 00:03:36.752
Okay, so, speaking of scaling up, how does this Azure Kubernetes service differ from other AQS, like Kubernetes service, because they have different providers?
00:03:37.836 --> 00:03:45.468
Yeah, so it's a good one, because AKS used to just have the cluster auto scaler, which is a Kubernetes thing.
00:03:45.468 --> 00:03:47.979
All of the cloud providers use cluster or scale.
00:03:47.979 --> 00:03:54.741
All of the on-prem Kubernetes distributions will use cluster or scale.
00:03:54.741 --> 00:04:01.187
And then there's a company called AWS Amazon massive big company they got their own one.
00:04:01.187 --> 00:04:09.837
They created this cool tool called Carpenter, which basically is a new and improved in a way auto scale up.
00:04:09.837 --> 00:04:19.805
But it's now being open sourced, donated to the CNCF part of the auto scaler SIG, and it basically can work in Azure now and other cloud providers.
00:04:19.935 --> 00:04:23.749
But what this does differently to the auto scale is you can tell it right.
00:04:23.749 --> 00:04:45.324
I would like to use any VM size in this family and then it will go off find the best resources available to you, the best VM size, automatically for you, based on your workload you're giving it, whereas with the cluster or scale up you need to have your node pools already created and it can scale up and down, but it can't change the SKU randomly.
00:04:45.324 --> 00:04:54.425
So Carpenter is new they call it node auto provision inside AKS and definitely worth a look if anyone's wanting to look it out.
00:04:54.425 --> 00:04:58.384
It's in preview so it can be a bit buggy, but it's good.
00:05:00.134 --> 00:05:08.303
So, speaking of auto like Kubernetes services from different cloud provider, what are the major benefits of using AKS than other Kubernetes service?
00:05:09.975 --> 00:05:29.201
For me, I would say the ease of use, the ease of onboarding the developer experience, the integration to things like Azure, ad, entra ID, where most of you find most of the enterprises will have a mugs of active directory in their own intendants or they'll use Entra ID, so AKS can easily integrate into that.
00:05:29.201 --> 00:05:35.964
But, yeah, the AKS development team and the product management team have put a lot of effort in to make the updates a lot easier.
00:05:35.964 --> 00:05:40.141
So it does pre-validation checks to make sure your APIs aren't depreciated.
00:05:40.141 --> 00:05:53.420
They've invested a lot of time given back to the open source community so they work on the actual Kubernetes source code and all these third party add-ons, give it back to the CNCF and then other people can use it.
00:05:53.420 --> 00:06:03.920
Other cloud providers can use it, whereas other companies like Amazon and that they're not always nice at giving back to the open source community, whereas Azure really is.
00:06:03.920 --> 00:06:04.882
So I love that about them.
00:06:07.254 --> 00:06:16.000
So, speaking of when, again scaling with Azure Kubernetes service, how does AKS handle scaling and balancing?
00:06:17.216 --> 00:06:18.862
Yeah, so good question again.
00:06:18.862 --> 00:06:21.139
So obviously you've got the node scaling.
00:06:21.139 --> 00:06:32.824
So that depends on if I have too much workload for the existing nodes, it will add a new node for me, either using the cluster autoscaler or by using the node access node order provision.
00:06:32.824 --> 00:06:41.384
But when your workloads need to scale, by default it uses the Kubernetes methods, which is CPU and memory and the horizontal pod autoscaler.
00:06:41.384 --> 00:06:46.497
But you have a nice add-on feature which is called KEDA or KEDA, depending on where you're from.
00:06:46.778 --> 00:07:10.108
I always call it KEDA, but this is an open source tool which was actually created with Microsoft and Red Hat to start off with, and now it's all open to the community so anyone can go contribute and this can integrate in with many, many different resources, so RabbitMQ, file services, Amazon S3, azure, gke, prometheus you name it.
00:07:10.108 --> 00:07:13.418
It's probably got a scaler and it reaches up to these scalers.
00:07:13.418 --> 00:07:16.903
Depending on what metrics you set, it will add extra pods.
00:07:16.903 --> 00:07:22.045
It all works on top of the horizontal pod autoscaler as well, so it's using that Kubernetes stuff.
00:07:22.045 --> 00:07:24.095
It's really good, so definitely check it out.
00:07:24.095 --> 00:07:26.321
It's KEDAsh if anyone wants to have a look.
00:07:29.636 --> 00:07:35.384
So you mentioned before that Kubernetes Rabbit Scalable thing.
00:07:35.384 --> 00:07:42.163
What I do, a best practice for different application on a case for scaling it, yeah, good, good again.
00:07:42.182 --> 00:07:43.124
Another good question.
00:07:43.124 --> 00:07:48.273
So your best practices always make sure you set your request and limits for your CPU memory.
00:07:48.273 --> 00:07:49.574
Always do that.
00:07:49.574 --> 00:07:53.250
Even if you're not sure, set it and then you can always go back and check it.
00:07:53.250 --> 00:08:08.696
Always make sure you have at least two replicas of your application running and you set your like pre stop hooks and stuff like that so if it dies you know it can finish off doing what it's doing and died gracefully and stuff like that.
00:08:08.696 --> 00:08:15.105
So like on the sick term, yeah, make sure you try and do topological spread.
00:08:15.146 --> 00:08:19.132
So in Azure you got zone availability zones one, two and three.
00:08:19.132 --> 00:08:22.536
Make sure you work like a beast spread over all three zones if needed.
00:08:22.536 --> 00:08:32.125
And I know best practice, which is sort of changing for me now recently with the changes that come from Azure but you don't use persistent storage if you can get away with it.
00:08:32.125 --> 00:08:36.270
So if you needed to have storage, do API calls to block storage or something.
00:08:36.270 --> 00:08:45.966
Don't mount that files or Blob into your pod because it can slow things up and obviously you want it to be super quick because it's in containers.
00:08:45.966 --> 00:08:47.888
But they are fixing that.
00:08:47.888 --> 00:08:58.336
They got this new service called Azure container storage and we've now got the ability to use zone redundant storage with our ACS, so the story is getting better.
00:08:58.336 --> 00:09:06.874
I'm getting closer to being happy to suggest it, but yeah, it's definitely something to keep an eye on.
00:09:08.243 --> 00:09:10.326
Okay, so we want to find out.
00:09:10.326 --> 00:09:15.817
The viewers want to find out what inspired Richard Cooper to be involved with a chaos.
00:09:15.817 --> 00:09:18.466
So can you find out A bit more?
00:09:18.466 --> 00:09:21.580
Yeah, inspired you to get started.
00:09:22.501 --> 00:09:23.785
Yeah, again, another good question.
00:09:23.785 --> 00:09:25.529
You've got some blinders here.
00:09:25.529 --> 00:09:28.264
So I've got this admin background.
00:09:28.264 --> 00:09:34.936
I started off on the help desk, worked all my way up working on physical machine servers and then virtual machines.
00:09:34.936 --> 00:09:44.793
So, like you know, hyper VVM, where and then I was working as company, we had a monolithic application and it was hard to get it to scale.
00:09:44.793 --> 00:09:47.758
Basically it was, you know, customers will send us lots of information.
00:09:47.758 --> 00:09:51.206
We need is a scale the app quick, and it was extremely difficult.
00:09:51.206 --> 00:09:59.285
So we started looking into containers and that technology and Kubernetes and it just sort of made sense to me.
00:09:59.405 --> 00:10:07.059
Like I've got this infrastructure background, kubernetes is just a sort of operating system in a way on top of services, like the hyper V is.
00:10:07.059 --> 00:10:10.293
You know, it's like the VM, where it's just Kubernetes.
00:10:10.293 --> 00:10:12.100
It orchestrates my workloads.
00:10:12.100 --> 00:10:15.586
My workloads are now in a container instead of virtual machine.
00:10:15.586 --> 00:10:24.100
You've got hand charts and values, files and all that, which is just like when I had MSI's to install my application with my MSD, my transformation files.
00:10:24.100 --> 00:10:27.623
So to me it just all clicked in my head and made sense.
00:10:27.623 --> 00:10:30.424
So I thought, oh, this is where the world's going.
00:10:30.424 --> 00:10:31.645
This makes sense to me.
00:10:31.645 --> 00:10:36.369
Let's just go all in on it and see where it takes me, and so far this been good.
00:10:37.711 --> 00:10:38.394
Okay, brilliant.
00:10:38.394 --> 00:10:45.817
So before we wrap up with the episode, we want to ask you are you going to any events or future events?
00:10:46.931 --> 00:10:47.591
Yes, yes.
00:10:47.591 --> 00:10:49.816
So we've got a few coming up.
00:10:49.816 --> 00:10:53.583
We've got KubeCon in Paris, which is coming in March.
00:10:53.583 --> 00:10:55.833
I'm super, super excited about that.
00:10:55.833 --> 00:11:00.693
It's where thousands, literally thousands of people are all coming together.
00:11:00.693 --> 00:11:06.980
Microsoft, aws, all these open source companies all come together and talk about Kubernetes in the cloud native world.
00:11:06.980 --> 00:11:08.259
So I'm going to be there.
00:11:08.259 --> 00:11:09.929
Hopefully I'll see quite a few other people there.
00:11:09.929 --> 00:11:20.263
And then we've got experts live in Budapest this year, which hopefully I'll see you again at Nick, because it was awesome to see you there last year in Prague.
00:11:20.263 --> 00:11:29.043
And then, obviously, we've got KubeCon North America, which is going to be in Salt Lake City in November time.
00:11:29.043 --> 00:11:36.410
Then, hopefully I think it goes across this a lot it will be Microsoft Ignite, but we're still waiting for them to announce where that's going to be.
00:11:36.410 --> 00:11:39.879
It'd be good to get back to a full Microsoft conference.
00:11:39.879 --> 00:11:44.318
That's my background, so I'd like to be back there with the people that I know.
00:11:45.590 --> 00:11:46.030
That's brilliant.
00:11:46.030 --> 00:11:49.820
How can do before we close the episode?
00:11:49.820 --> 00:11:53.597
How can the audience learn about AKS and connect with you to stay up to date?
00:11:54.972 --> 00:11:55.855
Yeah, good question again.
00:11:55.855 --> 00:11:59.568
So to learn about AKS, I'm going to permit myself here.
00:11:59.568 --> 00:12:02.139
I've got an AKS course on LinkedIn, so go check that out.
00:12:02.139 --> 00:12:05.052
The Microsoft Learn documentation is awesome.
00:12:05.052 --> 00:12:09.231
They've also got LearnPars all about AKS and the clone of world, so check those out.
00:12:10.215 --> 00:12:13.245
But the best way is just to deploy it and start playing with it.
00:12:13.245 --> 00:12:15.352
It really makes life easier, I think.
00:12:15.352 --> 00:12:22.075
And don't think of it as too complicated, because, yes, it's a massive beast, but it's just like VMware, hyper-v.
00:12:22.075 --> 00:12:26.312
We have to deal with networking, storage, os patching back in the days.
00:12:26.312 --> 00:12:28.578
It's just the same, just a different name for the software.
00:12:28.578 --> 00:12:44.974
And then, yeah, just sort of get on Twitter as well, or X as it's called, and just start following people like myself and some people at White Duck, nico and Phil, and to be to Wesley and Carl, all on Twitter.
00:12:44.974 --> 00:12:50.323
And, yeah, just get involved with the community and talk to people.
00:12:50.323 --> 00:12:51.793
That's also another good way to learn.
00:12:51.793 --> 00:12:55.373
And then, if you want to reach out to me, you can find me on Twitter.
00:12:55.373 --> 00:12:58.259
Or X, pixel, and it's called Robots.
00:12:58.259 --> 00:13:00.331
You can find me on my blog, pixel Robots.
00:13:00.331 --> 00:13:05.474
Find me on LinkedIn, richard Hooper it's got a weird thing because I've got a cloud and stuff in the name.
00:13:05.474 --> 00:13:07.659
So just search for me and you'll find me.
00:13:09.932 --> 00:13:10.634
Okay, brilliant.
00:13:10.634 --> 00:13:15.143
Is there any last few words that you want to say to the viewers, or anything?
00:13:16.051 --> 00:13:16.711
Yeah.
00:13:16.711 --> 00:13:23.332
So yeah, if you're looking into Kubernetes and you're a bit afraid, don't be afraid, just embrace it.
00:13:23.332 --> 00:13:27.248
It's not that difficult If you've got a sysadmin background.
00:13:27.248 --> 00:13:29.779
If you've got a developer background it's a bit harder.
00:13:29.779 --> 00:13:33.215
But if you just follow the learning path, some Microsoft learn, it should be fine.
00:13:34.871 --> 00:13:36.035
Okay, brilliant, okay.
00:13:36.035 --> 00:13:43.919
Thanks for coming into this episode, richard, since you're quite busy, so I hope you're showing a few weeks, a few days.
00:13:43.919 --> 00:13:48.952
It's going to be on Spotify and not the music, so stay tuned.
00:13:48.952 --> 00:13:50.996
Bye, bye.
