Episode 182 – Hands-On Kubernetes on Azure with Nills Franssens

In Episode 182, Ben and Scott sit down with Nills Franssens, a Senior Cloud Solution Architect at Microsoft to talk about his new Kubernetes book, "Hands-On Kubernetes on Azure". Transcript Email Download New Tab - Welcome to Episode 182 of the Microsoft cloud IT Pro Podcast recorded live on June 12th of 2020. This is a show about Microsoft 365 and Azure, from the perspective of it pros and end users, where we discuss a topic or recent news and how it relates to you. In this episode, Ben and Scott hop on a call with Nills, a Senior Cloud Solution Architect at Microsoft and the author of "Hands-On Kubernetes on Azure," which is currently available for free on azure.com. We have another interview episode for everyone today, I'm excited to go through this one. So we have a guest who I've done some work with in the past, through a couple of Microsoft projects that I've been involved with and some community programs over there, like OpenHack. And yeah, he just recently wrote a book too, which having participated and written some technical materials before I very much feel the pain and we can commiserate about that if you want to as well, but Nills, why don't you go ahead and introduce yourself here real quick. - Hi, my name is Nills, I'm a Senior Cloud Solution Architect with Microsoft based in San Jose, California. And as Scott said, I recently wrote and published a book on running Kubernetes on Azure, which was a very fun experience of writing the book outside of Kubernetes. My main area of expertise within Azure is everything related to infrastructure, networking, storage and the general automation of the platform. And I'm actually very happy to be here and talk to Ben and Scott 'cause I'm a listener of the podcast as well. - Alright, well, good to hear it. And did you actually say you had fun writing the book? I think you're the first person that I've ever talked to, that wrote a technical book that actually said it was fun. - It definitely there're periods where it was not as fun, but I think the overall experience was a good experience. It took a lot of time and a lot of nights and weekends, 'cause I think the one thing that I didn't realize when I signed up was I knew Microsoft had a moonlighting policy. So I couldn't write anything during business hours and what I didn't realize was exactly how much time was required to write the book. But if I look back on the process, I find that might not have been the right word, but it's actually a really nice process that I went through. And it's fun to actually have the physical book in my hands right now. And I learned a ton just during the process, both technically and about becoming a better writer as well. - Got it, I can see that, so I've never written a book. I think Scott has helped out on some, but I'm like, it would be, I think from my perspective, it would be interesting to go through the process. And I feel like you've learned a lot 'cause obviously you want the book to be correct and you wanna really cover everything. And I feel like once you actually had that book in your hand, like you said, it would be really rewarding knowing that you went through all of that and wrote it. - Yes, and I think you're absolutely correct and you learn a ton and I think when you're writing a book, you actually need to go back and take a beginner's mindset about the technology that you're writing about 'cause once you're dealing with something and you've been working with something for a couple of years, certain basic things, you don't even consider them and you don't even think about what's underneath those basics. And then once you actually start writing a book, you need to go back to basics and figure some things out. And what I found important was using the right words and the right terminology to describe certain things. And just as a stupid example in Kubernetes, there's this thing called an ingress that you can use to do some layer-7 load balancing. So basically do routing based on the host name that you send. And there's an ingress and an ingress controller, and like I always drew both terms together and I didn't even realize what the difference was between an ingress and an ingress controller. I just mixed the words and when writing the book, I was like, what I'm writing this I actually want to use the correct terminology. And that was some of the things that I researched and learned because when you write a book, you actually want to be factually correct. You just don't just want to be, yeah, it works. You actually want to be correct in what you say. - If you're a good author, yes, that's the way to go. So I make that mistake all the time. I tend to use those two synonymously as well. It's not something that I would very much think about along the way 'cause usually once you're down to the nitty gritty, you're like, what do I actually need to do? I need to set up a deployment for an ingress controller so I can actually get that software or that construct, whatever that thing is out there. So we can start routing traffic for me, now . - One of the things that helped as well for me when I was writing this was I had somebody from the publisher 'cause the book is in self published. I worked with Packt as a publisher and I had... I don't know what the actual term is of the person, but I had somebody working with me who reviewed everything that I wrote. And she wasn't a Kubernetes expert, which was actually perfect because when I wrote something and something didn't make sense to her, she could actually ask a lot of clarifying questions, which I then had to research myself 'cause something's just seems so common sense when you're dealing with something for a couple of years that you don't realize, and then having somebody writing or working with you that actually points out to you, "Hey, why do you use this term and not that term?" Worked, helped me a lot in just tuning my own knowledge and sharpening my own knowledge. - Oh, you should get on board that train. - I am not a Kubernetes guy at all, well, I probably should. So does this book take it from, let's say someone of my level who literally knows just a little bit about Kubernetes from what Scott and I have talked about on the podcast to someone, to your level Nils, where you're like a complete and total expert on Kubernetes, or should you have some Kubernetes experience going into this? What does that level of the book and what is the, I guess the journey or the path that the book will take you through as you work through it or read through it? - The book itself doesn't require you to have any prior knowledge of Kubernetes itself. The main focus on the book is by itself is "Hands-On Kubernetes on Azure." So the book is very practical with a lot of examples in it. And if I think about how we laid it out, there's three sections in the book itself. One is just simple basics where we cover what's Docker what's containers. What's this thing called Kubernetes and why do we even need it to setting up the cluster on Azure, which are like the absolute basics. Then there's a second section, which covers more of the Kubernetes' constructs that you need to know, like deploying the parts, deploying services, doing some ingress folk, how you could potentially secure certain things. So that's section two, which focuses more Kubernetes itself. And it touches on Kubernetes on Azure in a couple of places, for instance, with a cluster autoscaler that needs to interact a little with Azure, but it's that section. I think 90% of that section you could do on an Azure Kubernetes cluster, as well as on a Kubernetes cluster anywhere, let's say you run them, run it on your own laptop, or even on GCP or AWS. I think 90% of that content is pretty neutral. And then there's a third section on the book where we actually cover some more of the in-depth Azure integrations, where we describe how you can integrate with some past services. There's a chapter on Event Hubs, there's a chapter on my SQL databases, there's another chapter where we actually run Azure functions with KEDA which is a pretty new project. As your functions with KEDA on an Azure Kubernetes cluster, you don't have to have any prior knowledge if you wanna start reading the book. And if you actually have no prior knowledge, this is a good way to get you started from level 100 to level 300. The book itself doesn't make you a in-depth experts 'cause there's too much in the Kubernetes ecosystem to fit in one book I believe. But I think if you have no knowledge of it, it's a good way to get started and to get a good understanding of what it takes to build and run applications on Kubernetes. - As IT professionals and the Cloud era. Sometimes it feels like we don't speak the same language as the rest of the organization. So when stakeholders from finance or other departments start asking about a specific project or teams that Azure costs, they don't always realize how much work is involved in obtaining that information. Sifting through cluttered CSVs is a complex massive metadata in order to manually create custom views and reports. It's a real headache on top of helping you understand and reduce your organization's overall Azure spend, ShareGate Overcast, lets you group resources into meaningful cost hubs and map them to real world business scenarios. This way you can track costs in the way that makes most sense with your corporate structure, whether it's byproduct, business unit, team, or otherwise. It's a flexible, intuitive and business friendly way of tracking Azure infrastructure costs. And it's only available in ShareGate Overcast, find out more on sharegate.com/ITPro - Yeah, I think there's a lot that goes into the Kubernetes and that ecosystem. And then there's AKS, which is Kubernetes, kind of,...