011 - Life in the cloud with Ned Bellavance

What does “cloud native” actually mean? Are there times when legacy technology shouldn’t be replaced? What makes a good Philly cheesesteak?

Expert Ned Bellavance chats all things cloud in this entertaining episode.

• Ned's Pluralsight author page
• http://nedinthecloud.com
• Ned's Twitter account
• Introducing Azure Kubernetes Service: A Practical Guide to Container Orchestration
• Leanpub
• Day Two Cloud podcast
• Dalessandro’s in Philadelphia

If you enjoy this episode, please consider leaving a review on Apple Podcasts or wherever you listen.

Please send any questions or comments to podcast@pluralsight.com.

Jeremy Morgan:
Hello and welcome to All Hands On Tech, where today's leaders talk tomorrow's technology. I'm Jeremy Morgan. 2019 was a wild year for tech and digital transformations were center stage. Many organizations are moving their operations from the data center in their building to the cloud. The providers of cloud services are innovating at a breakneck pace, trying to outdo each other. Today I'll be talking with someone that lives in the cloud. His website is literally named Nedinthecloud.com. Ned Bellavance has been an IT professional for nearly 20 years. He's a technologist, Pluralsight author, podcast host and Microsoft MVP. He's taught me a lot about the cloud and he enjoys teaching things like Azure, Terraform and cloud migration. So let's welcome Ned Bellavance. Tell us a little bit about who you are and what you do.

Ned Bellavance:
What would you say you do around here? It's a good question. I've been doing tech for almost 20 years now in various different roles. Starting out as lowly help... I don't want to say lowly. As a help desk person. The first line of defense when people have trouble and then advancing my way up the ranks through a systems administrator and then into a consulting role for, I did consulting for seven years. And then very recently, this year, 2019, which is almost over, I decided to strike out on my own, doing a combination of content writing, teaching through avenues like Pluralsight, and then just general freelance consulting. So kind of merging all of those things together which sounds like a completely made up job. I'm going to be completely honest.

Ned Bellavance:
Every day I'm a little surprised that I get paid to do what it is I do. I certainly could not have pictured myself in this position when I started out in tech. There's a couple of different reasons for that. Part of it is when you first start out in a field, you know very little about that field and things that you think you know, are probably wrong. So the things that I thought I knew about tech 20 years ago were very little. And as I got further immersed in the world of technology, I started appreciating that it's more than just the practitioner. 

Ned Bellavance:
So there's obviously the people on help desk and there's the systems administrators, there's developers writing code. Those are all obviously important contributors to the larger technology sphere. But there's a whole bunch of other people that are also contributing there's, the people who write documentation for things. There's people that develop training courses to teach other people how to use all this crazy tech. There's people in technical marketing whose whole job is to make a technology that their company designs, are more accessible and interesting to people who they want to go use it.

Ned Bellavance:
There's product management, "Hey, we want to develop this new product or feature. We're a technology vendor. How do we even do that?" And then there's value added resellers and enterprise versus SMB markets. And I did not realize how complicated the technology world was beyond like, "Oh no, I just like typing on computers. This'll be fun." It's interesting that I ended up here and I'm by no means done on my journey. This is where I am today and it's the thing that fits the best for me at the moment. But I'm certain in 10 years I'm going to be doing some variation on this if not something completely different. And I don't even want to try to predict what that thing is going to be. 

Jeremy Morgan:
Yeah, I definitely understand because there's certain types of people, they're like, "This is always what I've wanted to do and I always knew that this was what I was going to do," but I'm in the same position as you. I started out in help desk. I kind of accidentally fell into programming and then for years I was like, "This is what I want to do. I want to sit in a basement and write code and push it and don't need to talk to people or be social. I'll just sit here and just produce these things." And then pretty soon after a while I'm like, "No, I do want to talk to people. I do want to be more social." And that kind of evolved into something to what I'm doing now, which is worth a lot of social interaction and a lot of things like that. 

Jeremy Morgan:
And if you would've asked me 20 years ago if podcast existed, are you going to be doing a podcast and are you going to be writing articles and are you going to be giving talks at places? I would've been like, "No, I'm going to sit here and write code and be happy until I retire." So I definitely understand what you're saying, kind of evolves and changes. So what does cloud native mean to you? You do a lot of cloud stuff with your podcasts and so that's my big, or my first big question is what does cloud native mean to you? 

Ned Bellavance:
Oh my goodness. And what an over-hyped and abused term it is. 

Jeremy Morgan:
Absolutely.

Ned Bellavance:
So the Cloud Native Computing Foundation has an actual technical definition of what cloud native is and it involves being elastic and scalable with microservices and maybe containers. But I don't like that definition, mostly because it's too technology centric. And for me, cloud native is as much about the operational principles and practices than it is about any particular architecture that you want to adopt at a moment. So for instance, you could have an organization that is using containers and the cloud and doing it very poorly and not really functioning in a cloud native way. Whereas you could have another organization that run stuff on an old mainframe but there are processes for developing new versions of their code, putting it into production, monitoring it and iterating on it, could be all very cloud native and they could be what's referred to as a high functioning organization, meaning that a lot of value is being delivered to the business side of things. And to me that's much more important than, "Oh I've got containers in cloudy stuff." So that's what cloud native means to me.

Jeremy Morgan:
And that high functioning organization, that's actually a very good way to put it because I've also been in the consulting world and actually pretty recently I was consulting at a company and they're like, "We need to do this and we need to do this," because everybody on the internet is telling me we need containers and we need... After kind of looking at it and going over some things, I'm like, "These things are actually working very well for you guys and there isn't a real compelling reason to change it. And they're like, "Well the internet says," and it's... I know, but this part's working great. This part isn't working so great. This one we could probably focus on but this over here, you're using older stuff, older technologies, but it's producing and you have people connected to it that are doing their jobs well and enjoying it. So kind of leave it alone. 

Ned Bellavance:
I've heard that referred to as legacy technology or heritage technology, if you want to say something a little nicer. But the shorthand definition really is the thing that is still making money at your company. 

Jeremy Morgan:
Yeah, exactly. 

Ned Bellavance:
For all the new and shiny that's out there, for a lot of established organizations, the big moneymaker, whatever it is they do. If you're an insurance company, the thing that calculates risk and determines what you should, what type of policy you should give to which people, that is probably running on a mainframe or some older regular relational database system using some thick client that was designed 15 years ago and it does what it needs to do. It is accurately matching people to the policy they should have so your company can continue to make lots of money. 

Ned Bellavance:
All the other cool stuff like your website and your front facing things, those can probably benefit a lot from adopting a cloud native technology as well as mindset. But the older products that you have that are still generating the bulk of revenue, there's a lot of room for improvement there but it doesn't necessarily mean moving it to a different technology architecture. 

Jeremy Morgan:
Yeah, exactly. So what are some of the biggest challenges you see organizations facing with moving to the cloud or becoming cloud native, has it worked?

Ned Bellavance:
Because in my estimation, it's more about operations than anything else and the company culture, usually the biggest obstacle is themselves. And that could go one of two directions, right? They are unwilling or incapable of changing their organization to be more adaptive and dynamic and adopt these cloud native principles. So, that's one thing that could be standing in their way and the other one could be technology. It's just that they're not able to adopt the technology components, they're very staid in their ways of how they're going to do things and they're not willing to bring in the new technologies that are sometimes required to adopt the operational principles that we're also talking about. 

Jeremy Morgan:
So do you see a lot of companies using like a hybrid cloud type of situation where their part on-prem, part cloud, kind of in between? 

Ned Bellavance:
That is probably the most common deployment. There was an idea and if you asked AWS, they would have told you, "Only our cloud exists and everybody's just going to move to our cloud." But the reality is obviously more nuanced than that. There are certain things that just run better when they're closer to your people. For instance, if you're running a call center, chances are having the call center system close to where the call center is, is probably going to be beneficial. In that case, you might be running some portion of the call center software on premises and then another portion, maybe the analytics portion of it could be running up in the cloud. And that's a good example of a hybrid type deployment. 

Ned Bellavance:
There are other things, maybe file systems for instance, where archiving to the cloud makes sense, but keeping the file system local or a cashed portion of it local makes sense. The vast majority of companies are going to end up in a hybrid cloud situation. There's going to be very few companies that can go 100% pure cloud, nothing on premises. They'll exist, but the vast majority are not going to be that. 

Jeremy Morgan:
Yeah. Startups mostly, probably. AWS actually just announced Outposts is what it's called and that's their on-prem solution that's connected to the cloud. And as I was reading through some of the comments, a lot of people are like, "What is it? The nineties again? Oh, it seems like they're moving backwards." But that's exactly what I had kind of thought of also is there's a lot of stuff that's really low latency that makes a lot of sense or for security. 

Jeremy Morgan:
There's a lot of organizations out there that still believe if the machine is in our building, then it's more secure than it is anywhere else. Whether that's true or not, it's definitely a perception that I've seen over and over and I've worked with a defense contractor where they had an entire network that was sealed off like air gapped. For them I think even that AWS Outposts probably would have been not good enough for what they were doing. So there's still a lot of applications and I think the Outpost thing was actually a really smart move for some of those companies that are like, "We're not going to the cloud for X reason." That takes away some of those reasons. 

Ned Bellavance:
Yeah. The interesting thing and I'd love to dig into this a little bit more, the whole Outposts idea and some of the other solutions out there. What Outpost brings to you is the operational model of how AWS does stuff. So you've seen a lot of organizations in the past try to develop a public cloud by putting it together, either using something like OpenStack or trying to cobble something together between vSphere and some portal that they've developed themselves and some custom scripts or something like that. But private cloud has always been fairly difficult to achieve because it does require a high level of technical expertise and a lot of care and feeding. 

Ned Bellavance:
Whereas if you bring in something like Outposts, that is managed entirely by AWS, so it lives in your data center, but it requires constant connectivity back to AWS. You manage the actual deployment all through the AWS console. So if you want to spin up an EC2 instance on your AWS outpost, you're going to the standard AWS console. You're dropping down in the regions and you're selecting your outpost as one of the available regions and saying, "Okay, go spin up an instance there." So the the look is consistent, the feel is consistent and AWS is on the hook for helping you in terms of the hardware support and also software upgrades and all the things that are generally difficult to maintain if you're doing this all privately. 

Ned Bellavance:
But it does require that constant connectivity, which is for some people, like you said, the deal breaker, that government contractor you're talking about that needed an air gapped solution, Outpost isn't going to work for them because it needs to be able to dial back to AWS on a regular basis for management and I'm assuming also for billing.

Ned Bellavance:
Another similar solution is what Microsoft put together with Azure Stack and that's capable of running in both a connected and fully disconnected type scenario because it actually hosts the management console locally as opposed to tying back to Azure for its management. So it's like a slightly different approach, but then it can meet some of those disconnected scenarios. But I don't want to compare apples to apples between the two products. I think they're both going to do very well in the marketplace. I think that the broader message here is people want the cloud operating model on premises and so far it's been difficult for incumbent vendors to deliver that. I've seen HPE try to develop something, VMware's tried a number of times to make something that's fully automated, but it's always been a little too complicated and I think it's because they were pushing the management and maintenance of that solution back on the person hosting it.

Ned Bellavance:
Whereas these newer solutions, the management and maintenance of it is now done by the vendor themselves. So while you're just doing consumption of the model and you're consuming it on-premises, but everything else is taken care of by the vendor. I think going forward, that's probably the model that we're going to see most prevalent for organizations as they kind of cycle down their older hardware solutions and probably deploy Outpost's or Azure Stack or whatever, Google Anthos in their data center. 

Jeremy Morgan:
That's probably going to be one of the best ways to transition because that seems to be the number one thing that I'm hearing from most people right now is we're transitioning to the cloud and that's why I'm working weekends and going crazy and we're kind of trying to figure this out. 

Ned Bellavance:
Yeah. Once you've made that pivot, once you've invested to understand the principles of how some of the cloud vendors do things, but just the higher level principles of IAS and automation and using policies and consistent deployments and infrastructure as code. Once you've mastered all that, you're going to want that on-premises. And I think that's why we're going to see this proliferation of cloud solutions that are hosted in your data center. 

Jeremy Morgan:
So if an organization is kind of early in the process and they're wanting to go to the cloud and they see all of these different options, what do you recommend for choosing what's right for them out of all of those? Like if they say, "Well, we've got three big providers here with three sets of services, a lot of them are really similar. How do we choose which one and which way to go." 

Ned Bellavance:
A lot of companies are going to be tempted to write down a list of here's the services in each cloud compared to each other one and here's a checklist and do some sort of calculus to determine which one they think will be the best. But I think what you really have to start out with at the very beginning is some sort of strategy, some sort of overarching cloud strategy plan. Understanding why you want to move to the cloud is going to inform where you decide to move things. So you have to kind of figure out what are my principles, what are the guiding principles behind my migration? And then follow those principles to their logical conclusion. 

Ned Bellavance:
So I've seen some organizations say, "We want to reduce administrative overhead as much as possible. So our guiding principle is wherever we can consume something as SAS, we want to pick a SAS product that meets our needs as long as it doesn't impact the business side of things negatively." So they'll move their office stuff to Office 365 because then they don't have to maintain their own exchange and SharePoint Servers. They'll move their CRM to salesforce.com so now they don't have to maintain something in-house. They'll move their financial apps to whatever financial app hosted SAS there is, I don't actually no one off the top of my head, but I'm sure there's multiple ones that exist. 

Ned Bellavance:
And then when it comes to their core applications, the moneymakers that I talked about earlier, then it's more of a nuanced conversation. Okay, now does it make sense to move it? Is there a tangible benefit to the business to move this application from where it's running right now, where it's doing great making us money to somewhere else? I need a clear reason to do that and I need to do a risk profile and go, "Do the benefits outweigh the risks of moving this application." Because if they don't, just don't do it. Like we said, hybrid's okay. Just go ahead and stay hybrid. 

Jeremy Morgan:
Yeah, absolutely. That's where the five Y's comes in really well. As you know, in consulting whenever you sit down with executives and leaders a lot and talk with them and that's one of the things that I would do is just keep asking them why, like, "We want to go to this." And, "Okay, why do you want to do that?" "Well, because we want things to be modern and updated." And it's like, "Okay, well why do you want them modern and updated." And you start asking questions as you kind of go along and kind of get to the core of what they really want and well, what we really want is to have this service up all of the time and to not have our engineers going crazy and think, "Okay, we will start from there."

Ned Bellavance:
Yeah. And then it gets back to a, you can get into some of the technical questions then like, well when you say you want it up all the time, how many nines are we talking about here? Okay. And how much will it cost to support five nines of availability and at some point then it gets into a conversation about, "Wow, five nines is really expensive to do and you have to do it proper. Maybe four nines is acceptable. 

Jeremy Morgan:
I think a lot of it is tied to talent also, which is great if you're an engineer of some type. But a lot of that's tied to talent because I've worked for organizations, like one organization I consulted for them, but I was also an employee for them for years and years, huge tech company, tons of talent. And it was one of those things like, "Oh, we need to infer engineer. Okay, well we have this person." "Oh we need somebody who's really great at Bash. Well let's shoot off an email and okay now we've got a Bash expert." And there's just huge pool. So they had their own internal cloud I would say probably six or seven years ago. A really nice kind of internal cloud because they had millions of engineers and developers.

Jeremy Morgan:
But then if you go to a place, like you're saying an insurance company where they have a ton of insurance experts, they have people that are great in business and accounting and all of these different things, but their tech department is small and tiny. So they're really constrained by this, the small group of engineers. And so I think that dictates a lot of the decisions as well as far as farming it out and building it in-house type of thing. Would you agree with that? 

Ned Bellavance:
Yeah, absolutely. And that's part of that strategy conversation is understanding where you want to go, why you want to go there and what will it take to get there. And in some cases when you've got your guiding principles and what your organization is capable of, you can say, "Hey, it would be really amazing if we could run our own internal private cloud and maintain it and all that jazz." But we don't have the skills in-house to do that and it doesn't necessarily make sense for us to develop those skills, that's not adding value to the business. Whereas if we took that same amount of money that it would cost to hire six full time employees to run our private cloud and invested that in six full time employees to develop and to move us to the public cloud, there's greater value to be achieved there. So let's go find those people or develop them in-house.

Jeremy Morgan:
Yeah, absolutely. So I guess skills is still important either way. But yeah, your strategy is kind of dictated by who you have or who you're able to get and like you said, whether it's worth it, that insurance company may not want to hire a team of 10 engineers to do this thing when they can call up AWS or Microsoft or Google and say, "Hey, do this thing for us." 

Ned Bellavance:
Yeah. I like to make the analogy back to something like plumbing, let's say. So if you're a sufficiently large enough organization that owns multiple buildings and plumbing is essential to the smooth functioning of your organization, let's say you do some sort of manufacturing and processing that involves a lot of movement of water for a cleaning and whatever, you're probably going to have plumbers on staff because that makes sense. It makes sense. It makes more sense for you to pay to have that person as a full time employee with all the skills and and cost that requires because there's enough work to keep them busy. And it would be more expensive to try to bring in a plumber every time something goes wrong with your plumbing.

Ned Bellavance:
In the same way it makes sense to, if you're a large enough organization and trying to maintain a vast private cloud to have one or more really talented cloud engineers on hand because that's part of your business value. But for the smaller organizations, it just doesn't make sense to have a plumber on staff to maintain your one bathroom, you can just call someone if something goes wrong. 

Jeremy Morgan:
So let's talk about the big buzzword, the big hot thing right now with cloud, Kubernetes. At what point do you decide that you need Kubernetes as an organization? Like what's a good indicator that it's time to at least consider it? 

Ned Bellavance:
Oh, does anybody really need Kubernetes? It's funny, if someone asked me five years ago if I was going to be saying some random word that someone came up with that was difficult to pronounce, like Kubernetes, I feel like that's ridiculous. Why would you name something that? But whenever someone creates a new open source project, they should name carefully because if it blows up, people are going to be saying that word constantly. Well, so here we are. It's five years later. Yes, that is correct. Kubernetes is five years old. And the question is, do you need Kubernetes? And I would say, I want to get back to my favorite thing, having a strategy. If you understand what your business needs are, where your company is trying to go, and how you're going to try to get there. And within that strategy you've drilled down and said, "Executing this strategy is going to require using containers and deploying them using an orchestrator," then Kubernetes is for you.

Ned Bellavance:
If you don't have that compelling business use case where you're all in on containers and orchestration, maybe wait, maybe that's not what you need to do right now. There could be other things to focus on that will provide more upfront value to the business and I want to own a back off on the business value thing for a second and say, "When I say business value, I don't necessarily mean making more money," because not all businesses have the same goals. If you're a nonprofit, your goal is probably not making more money, but all businesses want to be successful at the goals they have. 

Ned Bellavance:
So when I say you're providing value, I mean that whatever the goals of a business are, whether that's making more money, opening more hospitals teaching more kids to read, whatever your goal is as an organization or a company, if you're providing value, you're moving the company further down the path of achieving whatever those goals are. 

Jeremy Morgan:
Some of these things and I know you know this as well, some of these things are driven by the engineers themselves. Like we want this cool thing because it'll make my job easier or it'll just be cool to do. And I was that engineer too early in my career. I'll totally admit it. I am like, "This is so cool and awesome and I want to work with it so I'm going to convince my boss that we need it." And you of course grow out of it. I mean, I would assume most people kind of grow out of that as they move on through their career. But that was the big turning point for me is like, "Is this actually going to help the business." Now sure if I get to use this and play with it every day and our team gets to do it, then that's awesome, but is it actually going to help the business?

Ned Bellavance:
Well, maybe not.

Jeremy Morgan:
And you kind of go through that evolution I think everybody goes through that in their career. And so sometimes if you have a really loud and ambitious engineers who are doing a great job at what they do and they're very effective as soon as they say we need this thing. A lot of times leadership is like, "Well, I trust this person, they've done great work. They're doing great things, so sure we'll spin up this huge thing and do this thing and maybe you don't need it. 

Ned Bellavance:
Yeah, maybe you don't. But then again, you might, so it gets back to understanding where you're trying to go and is Kubernetes going to help you get there? Maybe. It depends. The old consultant answer. 

Jeremy Morgan:
The great consultants slash attorney answer.

Ned Bellavance:
Yep. 

Jeremy Morgan:
I definitely have seen... There's a couple of organizations that I've worked with where I've seen them just start to implement Kubernetes and I could see where, once they hit a good pace it's going to work very well for them. And those kind of organizations that they had a lot of smaller, I wouldn't say there were microservices, but they're essentially small applications and services. As it spreads amongst this huge organization, you have everybody kind of doing things their own way and it kind of goes crazy and you don't want to build an actual server for them. Even if they're VMs, you don't want to build a big giant server for this one little angular app that's doing this thing in claims processing or whatever.

Jeremy Morgan:
So I could see the value in certain organizations if it's, like you said, if they take a good strategy and step back, look at the big picture and start to drill down, I can definitely see where it could be helpful but I don't think every organization necessarily needs it. So you went to KubeCon recently. Am I pronouncing that correctly? 

Ned Bellavance:
I've heard multiple ways to pronounce it, KubeCon, KubeCon, KubeCon, [inaudible 00:27:22] whatever you want to call it. It was the Kubernetes conference and CNCF, which Kubernetes is part of the CNCF and yes, it was hosted in San Diego this year. And so I got to go to beautiful San Diego, which for me it rained almost the entire time I was there. I was like, "What's going on? Aren't you supposed to be sunny?" Apparently not. I was wrong. But the day I was leaving the sun burned through the clouds, it became absolutely gorgeous. And I walked into the airport. 

Ned Bellavance:
Yeah, no, I went to KubeCon and watched the keynotes and talked to a whole bunch of different vendors and people at the show. And there were definitely some key themes and takeaways that I walked away from KubeCon with. And in the very first day one keynote, it was mentioned that Kubernetes is a very young project. It's five years old. It's practically a toddler. And so that means it still has a lot of growing up to do and I don't think anybody would dispute that. The good news is a lot of what is core to Kubernetes has started to harden and mature. 

Ned Bellavance:
So the core APIs that back Kubernetes at this point, we're past the 1.0 release, there's probably not going to be any vast changes to that. So everything else that happens with Kubernetes is going to come from the surrounding ecosystem for it and incremental improvements in the core product itself. Kelsey Hightower said that Kubernetes is done and when he said that he didn't mean like no one's going to write any additional code for Kubernetes or update it but what he mean is like the core of it is done in the sense that there's not going to be the see changes in how it does stuff. You can confidently roll out Kubernetes in a production environment and know that the APIs that you're writing against are not going to change vastly in the near future. 

Ned Bellavance:
And a lot of that has to do with the fact that they managed to stay very focused on the core functionality of what Kubernetes needed to do and just assume that the other components around it would continue to evolve on their own, make calls out to those components, but let them continue to evolve. A good example of this is the cloud provider components that were part of Kubernetes had been spun out of the main project. So before, every time Azure or AWS or Google wanted to rev their version of the cloud provider, it meant that the entire Kubernetes version had to rev, which, that's kind of a pain.

Ned Bellavance:
So it meant the two were in lockstep to a certain degree, which slowed down the maturity of the cloud providers because they couldn't move as fast as they might want to. By separating out those cloud providers now AWS can iterate on their version of Kubernetes, the EKS side of things much more rapidly because they're not held to the versioning and the speed at which Kubernetes gets updated and patched. So that's good on their side and they've taken that approach to many other components, tried to move as many things out of the core of Kubernetes into their own thing. They did that more very recently with storage as well. 

Ned Bellavance:
So the container storage interface, same sort of idea, let's move that out of the main tree and have storage vendors develop their own storage plugins but provide a common interface for Kubernetes to use, to talk to those plugins. 

Jeremy Morgan:
That's one of those things where they're kind of focusing on one thing, doing one thing and doing it well and then kind of relying on the ecosystem to pick up the rest. I guess that's the spirit of open source pretty much personified right there. That makes me pretty hopeful. I think like if I were still an engineer and kind of implementing that or considering that, then that would definitely give me the signal. It's like, okay, we can actually invest some time in this and we can build some things to this because it's not going to change out from under us and have us refactoring everything next year. So yeah, that's pretty cool. 

Ned Bellavance:
To a certain degree, Kubernetes now provides sort of a platform to build platforms on, if that makes any sense. Well it's just a really good orchestration platform and a solid API and it's extensible through things like custom resource definitions, so you can devise your own operator and custom resource definition and plug that into Kubernetes and when an event happens to trigger it, it will go out and invoke your operator and that will do whatever it needs to do. You get to write those things and snap them into Kubernetes or maybe not you, but a vendor gets to write those things and snap them in. You're still using the same API, you're still using the same declarative model. That's so nice when it comes to Kubernetes. It's still your custom code and whatever you need to achieve. So it's sort of a, here's an abstraction layer that you can build on and it's extensible. Go build something and we'll see what we all do. 

Jeremy Morgan:
And so there's a lot of companies I know that require a VM for a certain application, like an actual hard tenancy type thing. And then some of them, we can run it in a container and pass it around everywhere. So one of the things I actually spoke with Kelsey Hightower earlier this week and one of the things he was talking about is kind of the mix of VMs and containers and how Kubernetes will be or is currently embracing both of those patterns. A lot of the things I've read online are like, containers are going to take over everything. We're never going to have VMs again and then you can Google again another query and you'll find a bunch of people that are saying it's all going to be VMs. Kubernetes is going to turn into a hypervisor, containers are gone. So it's kind of nice to see that they're embracing both of those things. Is that kind of how you see it also? 

Ned Bellavance:
Yeah, so there's some interesting examples there. One is that with Project Pacific on VMware, they have decided to use Kubernetes as an interface for deploying things on vSphere. And of course that's still in like private beta or private alpha, I don't even know but the core thing that they were talking about is they've extended Kubernetes through CRDs to be able to deploy virtual machines as well as deploy containers. So if I am a developer and I prefer to work through Kubernetes and that API, I can create a deployment that includes containers and also includes virtual machines and VMware will go make that happen basically.

Ned Bellavance:
So, that's one sort of take on it, the other thing that I've noticed is all of the major cloud providers are not using bare metal for their Kubernetes worker nodes. They're all using virtual machines. Obviously there's some... And VMware's big claim at VMworld this year was that there was actually a performance improvement by using virtual machines. Now that's a very nuanced conversation and if people want to go read, like Rob Hirschfeld has a really good post on why that might happen and how it's probably not a permanent state of affairs. But what I think is more interesting is kind of what AWS is doing with their firecracker, deployment where it's a micro-VM that runs a very, very stripped down VM and that VM can run a container and I believe that's kind of what they're using for land and Fargate. 

Ned Bellavance:
Now is just, instead of being a standard container running on a big worker host, it's this super stripped down virtual machine that is just capable of running the container workspace and nothing else. It creates a more secure sandboxed environment, but it also allows the virtual machine to spin up at the speed that you would expect a container to be able to be spinning up. You are talking microseconds instead of 60 seconds. 

Jeremy Morgan:
Yeah, that's a very interesting concept. One of the things that I've been playing around with recently is Intel's Clear Linux and it's basically, they've taken the Linux Kernel and started to optimize it for Intel and AMD processors actually, and they've done a lot of optimization in the speed and it seems like one of the big ideas is that they want people to take these and put them into virtual machines to run Linux workloads and have it be very performant, but also be as container hosts like you mentioned. So it's very stripped down, very small, very optimized Linux extensions that they can use just for running containers, that's the only job that Linux system will have is it's going to sit in a VM and then run containers out of it. Or you'll have a whole set of VMs that are Linux VMs that do one very specific thing. 

Jeremy Morgan:
And it's very interesting. As a benchmarking shows that it is quite, that kernel is quite a bit faster as far as processing things. So it's very interesting to see where that goes and if the cloud providers start to really adopt it. It'll be interesting to see kind of how that model works having this really lean and mean operating system that you could never boot up a desktop or anything crazy like that, but if you need to run engine X then you'll have just exactly what you need to do that. And not only, and that's a very interesting model and anything that moves towards efficiency in that area is super interesting. 

Ned Bellavance:
Generally operating systems carry a lot of assumptions with them about what they need to provide, whether it's drivers or supporting hardware or supporting the user interface. So if you think about a standard operating system, it probably still includes drivers for like a floppy disc. They're there, they don't need to be there, you can get rid of them. They also still carry drivers for a keyboard. Well, what if you're in a situation where you deploy this thing in an immutable way, the config is carried by something like cloud in it and there will never be a user interface, not even like a typing user interface, let alone a gooey. Well, okay, now I don't need a keyboard driver. I don't need fonts. I don't even need a fonts folder. I don't need any kind of desktop or graphical interface bits. I don't need any of that. I don't need to reserve space for a graphics card when I'm laying out my memory format. Like all of that goes away if it's super purpose built.

Ned Bellavance:
I mean, obviously there's a challenge there but I think some of that is being answered by this, there was an idea of unikernels that got floated, I want to say about seven or eight years ago, which was like a really stripped down kernel that runs a single process and that's all it can run. And that never really, I don't know that that ever really took off because it was fairly hard to do, but a lot of tools got developed to create these type of unikernels and I think those tools are probably now being more broadly applied to create, strip down versions of operating systems to be a container host or something similar. 

Jeremy Morgan:
Yeah, and I think that'd be pretty awesome because if you think about that, like you said, the fonts and things like that, well now we're multiplying that by a hundred because now we just spin up servers and BMS nilly willy all over the place. So it definitely tends to add up when you have your USB mouse drivers in there and things like that, that you'll never use times a hundred. Flip side of that and like a whole other conversation is how do you debug something if that, if you stripped it, everything out, right? And so then it gets into a conversation of how do you observe what's going on in that system, debug it if something goes wrong and log it out to something that's persistent if you're deploying this in an immutable way, and that's, that's a whole other conversation about observable observability but it's certainly an interesting thought exercise of, well, I can't log into this thing now at all. So how do I figure out that something's gone wrong? You have a book coming out soon, or maybe it's out now. 

Ned Bellavance:
The book is Introducing Azure Kubernetes Service, and I wrote it with Steve Buchanan and Janaka Rangama, two other Microsoft MVPs, we all met through the MVP program. At the time there was no book about Azures Kubernetes Service and we thought, "Hey, there should be one." So we wrote it.

Jeremy Morgan:
Awesome. 

Ned Bellavance:
This was my first book. I have never written a book before, but it was definitely on the bucket list of things to do. In many ways it was a lot like writing, just general technical documentation when, you know, you've been in consulting for years, so I'm sure you've written hundreds of pages of like technical documentation when you're creating deliverables for a client.

Jeremy Morgan:
Yep.

Ned Bellavance:
In many ways it's very similar to that process except you have to write it for a broader audience and make a lot fewer assumptions about what that audience is going to know. I was responsible for writing three of the chapters in it. Which also meant I had to learn some stuff about the things I was writing the chapters on because just like anyone else in tech, I don't know everything and stuff changes all the time. So writing the documentation, writing the chapters for that was as much me learning to write in the format that the publisher wanted, getting up to date on all the things that I'm talking about. And of course now that it's publishing, it's already out of date because they've introduced new things on EKS. 

Jeremy Morgan:
Yeah, I can imagine that's a big challenge for authors right now. Writing actual books is the way these things change so much.

Ned Bellavance:
We certainly waited till EKS went generally available before we started writing it because generally speaking, once something goes GA on Azure, the core constructs of it and the main concepts are not going to change significantly. Yeah, they're going to add some new services and features, but overall, core concepts are going to stay the same. So for instance, I wrote a chapter on Helm. Helm is still something you use to deploy on EKS that hasn't changed. Helm two has been subsumed by Helm three so that's now the preferred deployment, but there's plenty of charts that only work on Helm two so still need to use Helm two for a bunch of stuff.

Ned Bellavance:
So I did that chapter. We have a whole chapter on just the general features and layout of EKS and the backend resources that it creates, which if you spin up an EKS cluster, you'll notice all these additional resources that get created on Azure. And it's like, well why is it creating those and what are those used for? That's all explained in the book as well. So I think even though the moment I typed something on the page, it was probably already out of date, the core constructs and concepts that we've included in the book will be valid for at least a few years. 

Jeremy Morgan:
What was your experience like with the writing process? Would you do it again? Are you running from it as fast as you could go? 

Ned Bellavance:
That's a good question. I am not running from this as fast as I can. I will say I have started writing another book of course. This one is going to be a study guide for the coming Terraform certification. There's a Terraform certified associate certification program that's going to be launched next year by HashiCorp and I am going to be writing a guide for passing that exam or at least studying for it. And I'm writing it with two other authors. So similar sort of situation. The main thing that we decided to do with this one was to write it through Leanpub. So I don't know if anybody, if any of your listeners have ever used Leanpub. With Leanpub you can write a book entirely in markdown using a private GitHub repository. And so you're writing the whole thing in like your code editor or whatever you'd like to use for markdown. 

Ned Bellavance:
You're committing it to the repository and then you can have Leanpub generate the PDF and the EPUB and all the various different versions of your book on the fly to see how it looks. And once you've accomplished... Once you've finished writing it, you can then make it available for people to buy or you can actually make it available for people to buy and read before it's done publishing. Or before you're done writing it, people can just buy it and then as you write it and publish updated versions that are more complete, they'll just get the more complete version as a PDF EPUB or however they're reading it aside from print obviously.

Ned Bellavance:
And then at certain point, when you're done, you can say, "Okay, this book is complete and it'll show up as completed." And then if you need to do a revised version in a year because they've changed a bunch of the certification goals or something, published and updated version and people will get the newer version of the book. So it's pretty cool. And I think I'm enjoying this writing process a little bit more because I don't have to use Microsoft word. 

Jeremy Morgan:
Yeah, absolutely. Leanpub's one of the ones that I've looked at for one of my 10,000 book ideas, but I haven't... And I think that's going to be the new model of technical books. I was recently kind of a technical reviewer on a book and I can't say which one it is yet. It's not out yet. But that was one of the things that we discussed as they're going through and getting iterations and I'm being sent PDFs and then the conversation was, "Well, we're going to publish this Q1 of 2020 and then we're going to keep revising it online and keep revising." So they wanted that commitment like would you be willing to come back and look at it in a year or six months? And I think that may be the new model for books, especially the electronic versions of them, is just to keep iterating. 

Ned Bellavance:
Nigel Poulton did his, I think his Docker Deep Dive through there and I think also one of his Kubernetes books is on Leanpub or maybe they all are and that he has kept them relatively up to date, publishing new versions as things change in the ecosystem. And for me that's been great because especially the Kubernetes one, just going back and rereading the chapters as they're updated to see what's new or what has changed that I should actually be aware of is super helpful to me. So I think it's a good publishing model. I don't know if there's a way to sort of pay the author again if you feel they've provided enough additional value, but it'll be kind of cool if there were, 

Jeremy Morgan:
So you've got a couple of great podcasts going right now. What kind of inspired you to create podcasts or a podcast? 

Ned Bellavance:
I think there's a couple reasons I wanted to do a podcast. One was I just like learning new things and sharing what I'm learning with other people. So the whole idea behind podcast for me is sharing information and stories and stories are just a different way to package up and convey information. So for me that's why I started podcasts. The other reason and I didn't realize this right away, but podcasts are an extremely good reason to talk to someone cool that you don't know. So if you're someone who's like, "How do I even approach this person?" I mean, you want to talk to, you mentioned like Kelsey Hightower, he's kind of a rock star of Kubernetes. Why would he talk to me? But wait, I have a podcast.

Ned Bellavance:
Okay, well now I have a reason to reach out and be like, "Hey, I really want to talk to you about this topic. I have a podcast, let's chat." And let me tell, I have met so many amazing people through podcasting because I just reached out and asked them to be a guest. And a surprisingly small number of them have ever turned me down. Most people are just really interested in sharing the knowledge they have and just enlightening the larger community about a particular topic and I think that's a testament too at the tech community at large, 

Jeremy Morgan:
It seems like a really good way to network teachers, exerts... As you get into tech, like I said, it kind of in the beginning I wanted to be the coder in the basement that just built things. And then after a while I realized like I really like teaching people and that's what I've noticed like about all of the authors that I meet through Pluralsight, other tech people, they're teachers, people that really enjoy teaching things. So that's definitely an interesting take and that you can meet other teachers who are wanting to share and if somebody goes on a podcast and then they're likely going on there because they want to share knowledge and information and so it's a good way to network all the crazy teacher types out there.

Ned Bellavance:
Yeah, there's a surprisingly large number of us. 

Jeremy Morgan:
So I have one final question for you for the podcast. 

Ned Bellavance:
Sure.

Jeremy Morgan:
It's a personal question, a very personal question.

Ned Bellavance:
Oh my goodness. It's pronounced GIF not GIF.

Jeremy Morgan:
Oh no.

Ned Bellavance:
That wasn't it. Okay. 

Jeremy Morgan:
We just extended the podcast another half hour to talk about this. What kind of cheese goes on a Philly cheesesteak? In your opinion.

Ned Bellavance:
Can I give the consultant answer and say it depends. 

Jeremy Morgan:
You can.

Ned Bellavance:
Okay. So I'm not a Cheese Whiz person. If you're going to put cheese on a cheesesteak, if you go on straight cheesesteak, I like American. But if you're doing a pizza steak, it's got to be provolone under and Matteson. 

Jeremy Morgan:
Nice. That's an excellent answer. So this is one of my favorite sandwiches in the world. And since you're from that area, I wanted to get that opinion. Here on the West coast we don't use Cheese Whiz like if you order a Philly cheesesteak at pretty much any restaurant, it's going to be American or provolone, which is what I prefer. And then at one point somebody had come to me and said, "You know that the original Philly cheesesteak is Cheese Whiz." And I'm like, "What? Are you kidding me?" And like I look it up. I'm like, "Wow, that's amazing." I've been eating the wrong Philly cheesesteak my whole life, but I'm okay with that. 

Ned Bellavance:
No man, you've been eating it right. Trust me. The thing that actually makes the cheesesteak is the bread. I don't know if most people know that, but bread makes or breaks the cheesesteak for me. If it's got good bread, I mean the steak has to be good obviously and a decent cheese, but the bread has to be there. 

Jeremy Morgan:
Absolutely. So what's your favorite bread? 

Ned Bellavance:
Amaroso is really good, but there's actually a place called Dalessandro's in Philly and I don't know where they get their bread from, but it is fantastic. So if you happen to be in the Philadelphia area, Dalessandro's, don't go to gyms or Pat's or whatever, go to Dalessandro's, get probably the best cheesesteak in Philly. 

Jeremy Morgan:
Awesome. Well thank you for that. Sure, it's definitely sold. And thank you for talking to me today. 

Ned Bellavance:
Absolutely.

Jeremy Morgan:
Been very good. Anything you want to talk about? Any projects or anything? 

Ned Bellavance:
No. I mean if people want to catch up with me, they can always find me on Twitter. It's Ned1313, my DMs are open. Hit me up with whatever questions you have. My main podcast, I know we mentioned that is called Day Two Cloud. It's on the Packet Pushers, family of podcasts, you can find that at daytwocloud.io and two is spelled out two, because that's grammar, grammatically correct. And my blog is nedinthecloud.com. But that's it for me. Thank you for having me, Jeremy. 

Jeremy Morgan:
Awesome. Well, thank you very much. Thank you for listening to All Hands On Tech. You can find out more about Ned at his website, nedinthecloud.com. You can catch his podcast Day Two Cloud at packetpushers.net. If you like this podcast, please rate us. You can see episode transcripts and more at pluralsight.com/podcast.