DevOps Decrypted Ep. 8 - Kubernetes & other stories
Summary
In this months episode of DevOps decrypted we share our thoughts and key take aways from author Gene Kim, DevOps Handbook second edition. Kubernetes documentary, have you seen it? We give our review of the documentary and why its an important story to share. Our latest added value reseller, Docker, and what that means for our clients.
Matt Saunders:
Hello everyone. And welcome to another episode of DevOps Decrypted. This is Episode Number Eight, and we're going to talk about Kubernetes and other stories. I'm not Romy. Romy can't be here today. She's got COVID. So yeah, we hope you get well soon, Romy. We're going to miss you on the podcast, but yeah, COVID comes to us all, it seems, eventually. I've managed to dodge it. A shame Romy hasn't. So I'm here. My name's Matt Saunders. I'm here with Jobin. Jobin, you're going to say hello?
Jobin Kuruvilla:
Hello. Hello. We blame COVID if the episode isn't good.
Matt Saunders:
Yeah. We're going to blame COVID for many, many, many things, including if the episode is not good, I'm fully on board with that. So yeah, it sounds like it's just the two of us today, Jobin, which is a bit of a shame, but hey, I'm sure we'll get some great conversations out of it. Right?
Jobin Kuruvilla:
I'm pretty sure. And I hope Romy gets well soon and she'll be back here with us next time.
Matt Saunders:
Next time. Here's to that. In the meantime, we're going to go through a few things today on DevOps Decrypted. Firstly, I think we're going to talk about the DevOps Handbook, which has just come out with a second edition. Have you read it yet, Jobin?
Jobin Kuruvilla:
I haven't actually, but we have been discussing about a book club. We are thinking of reading it together. Since it is a second edition, I'm assuming it's good. Otherwise, there wouldn't be a second edition. I'm looking forward to reading that. Have you read it?
Matt Saunders:
Yeah, I agree totally. Just for those who are not aware of what it is, it's basically the handbook for operating in a DevOps way from the likes of Gene Kim. Gene Kim obviously wrote The Phoenix Project, the book that's set off books in the DevOps world. Handbook, I think came out about five years ago with lots of stories, lots of tales, adventures of people in enterprises going through DevOps transformations. And I guess it was getting a bit stale, or if not stale, needed updating for what's been going on in the last few years. I've had a flick through it. I haven't read the whole thing yet, but it's basically... And again, I say basically, it's far more than just the basic thing. It's dozens of excellent stories about how to do DevOps in a large enterprise fully updated for 2022, which is great.
Jobin Kuruvilla:
Yeah. I'm definitely looking forward to reading that. I was actually talking to Jon Mort the other day. For those of you who don't know Jon Mort, he's the CTO at Adaptavist. And he pitched the idea of having a book club. There's a lot of folks who are interested in DevOps these days within Adaptavist and obviously outside of Adaptavist. We are looking at launching a book club internally to read the book together and see what we learned from it. Obviously, there's going to be a lot of conversations around it. Everybody has their opinion on everything these days. I'm looking forward to maybe discussing, maybe debating certain things within the book.
Matt Saunders:
I think it's a great idea, especially if you get a nice broad cross-section of people-
Jobin Kuruvilla:
Yeah, exactly.
Matt Saunders:
... in the club because a lot of the time, you see... Particularly when I used to go out consulting, going out to lots of different companies, big and small, you'd often find maybe there's a couple of people who'd read The Phoenix Project or maybe someone has read the Handbook and their heads are full of ideas. And the difficulty with a lot of the DevOps stuff I feel is that it's not as actionable as some of the technical things we can do. We talk about the push towards technology, right?
Jobin Kuruvilla:
Exactly, yeah.
Matt Saunders:
Yeah. It's not as actionable. And even worse than that, it's a bit abstract. We're talking about case studies from big organizations. It's not a thing that says, "This is how you do DevOps." It's, "This is how we implemented it. These are the things that we did. These are the things we might do."
Jobin Kuruvilla:
There isn't one size that fits all, so obviously you're not talking about having a script and following it everywhere we go, that's not possible. DevOps is a culture. It's not just implementing a tool. So you cannot actually have it implemented the same way everywhere. Even if it is a tool, you can't do that. Imagine doing that for a process, a culture, right?
Matt Saunders:
Yeah. Yeah, exactly. And I think that is why I think it fits beautifully into this book club idea.
Jobin Kuruvilla:
Yep.
Matt Saunders:
It's great if everyone goes off and reads the Handbook, but everyone takes different things away from it. And everyone has different interpretations of how you can implement this stuff at your organization. You and me, we're head of departments. We'll read it and be like, "Well, yep. We can manage outputs and change these things with our bosses, manage downwards and change these things with the people who work for us." But you compare that to the people who are on the ground, maybe doing more hands-on and also the people up at the exec level, different interpretations. And I think what's going to be really good is if within a database you can get a broad cross-section. Nothing worse than a new technique or book goes around a few, a small set of people, and they were like, "Ah, we want to do this stuff." And everyone who wasn't part of that goes, "What on earth are you talking about? What's this new fad stuff?"
Jobin Kuruvilla:
Why? Yeah.
Matt Saunders:
And more, the people who have read it, try and implement it, but nobody else has been following along, so it's almost destined to failure. That ain't going to happen if everyone at Adaptavist is reading the handbook, taking away the... I think it's a difference between... I remember at school doing pure maths and applied maths and the pure was all the science and all the algebra and lambdas and things like that. And they applied was actually, how do we actually use this in our life? And maybe one of the big takeaways here is get together a group of people, read the book, read it a chapter at a time, figure out all the NIH stuff. Oh, no, we couldn't do that here because we're not like Nike or we're not like American Airlines.
Jobin Kuruvilla:
I'm certainly looking forward to reading it because having written on a book myself on Jira Development, that is more technical. I know how difficult it is to write a book, but I feel it's a lot easier when it is something as technical as that. But DevOps, I'm curious how much breadth discovered in that particular book can. I'm looking forward to reading it and learning from it, of course.
Matt Saunders:
Yeah. What about the second edition aspect of it? It did surprise me somewhat when it came up with the second edition of the Handbook, because the IT revolution thing, the company that Gene Kim runs to publish the books, their thing seems to be to keep putting out new things. Obviously, based on the success of The Phoenix Project, you build up and have a similar group of authors with some new ones, putting out the Handbook. And then other books such as BVSSH, Better Value Sooner Safer Happier from Jon Smart, Agile Conversations, the Mark Schwartz book around bureaucracies, but then they're going back here. And, and that was an interesting thing I found here because we hear a lot about things like, "Well, we're over DevOps now. We're in a post-DevOps world. The word is poisoned now and means too many different things so we can't use it." And yet here we are going back and revisiting some of the same ideas, but with a modern spin on it. So is DevOps dead?
Jobin Kuruvilla:
You would say so, but again, think of DevOps... Obviously, we have been talking about DevOps for quite a long time now, but at the same time, there is still a lot of organizations out there who are still trying to figure out what DevOps is. I think you take the state of their license report that we did last year, or many of the reports that's coming out, obviously there's a huge chunk of people who are already using DevOps, who think of them, the person in the DevOps area, but then there is also a larger part of the organizations who want to get on the DevOps train, still trying to figure out where DevOps is. I'm pretty sure it can benefit still a lot of the people. And the technology also has evolved a lot. Probably five years back... I don't know when the original edition was out there, Kubernetes was probably not the standard. Since some moved on, now Kubernetes is a standard in container orchestration. That's just one example.
Jobin Kuruvilla:
There was DevSecOps at that time, or at least a term was not coined since security didn't have this much of an importance. Not many organizations were on Cloud. Cloud migration wasn't exactly a thing at that time. I think over this past five, six years, a lot of things have changed. That's probably accounted for in the new edition, but the original fundamentals still remain. Right?
Matt Saunders:
Yeah. Just analyzing the things that you are mentioning there. If we look at all the things that have changed across the three tenants, like the people, process, and technology, most of them seem to be technical. So yeah, Kubernetes.
Jobin Kuruvilla:
Yep.
Matt Saunders:
Yes, more cloud services. And maybe some process stuff, so DevSecOps and GitOps, but then the people aspect, the culture thing is pretty much still the same. And I think that's a good thing because it's all about ideals and about going back to the three ways and the five ideas from the Unicorn Project, those things are still kind of the same.
Jobin Kuruvilla:
That's exactly what I meant when I said the fundamentals remain the same.
Matt Saunders:
Yeah, exactly. I'm reminded of, I spent a lot of time in the car driving up between various places. It doesn't matter. And one of the things I listen to in the car is the IT Revolution Podcast, Gene Kim's podcast. And he was doing a review with some of the original authors of the handbook. So Patrick Debois, John Willis, and Jez Humble, and Nicole Forsgren, who's coming in on the second edition. And I felt a little bad. I thought, I'm not really using my time well here, because these folks are basically just... It's like some old friends who are up in a pub and they're going, "Oh, do you remember when we did this? Or remember when we talked about that. And this is how we all started off. And we did Devopsdays in Ghent," and talking about all these things. I'm like, "Yeah, I want to hear about the new stuff."
Matt Saunders:
But then I started realizing that actually, the reason why those things were noteworthy, things like DevOps Days getting kicked off, things like the Agile Six happening, talks at Velocity, 10 deploys a day, that sort of stuff from Flicker. The reason we keep coming back to those, but without just sounding like old boars in a pub, is that the techniques are moving on, but the principles are still the same. These principles were the groundbreaking things that people started doing back in the day. And it was all cultural. Right?
Jobin Kuruvilla:
Absolutely. That's probably a good segue into our next section. Have you seen the latest Kubernetes documentary that came out? You talk about, talked about the IT Revolution and it is fascinating to watch how Kubernetes has evolved over the years and the story behind it. Did you get a chance to watch it yet?
Matt Saunders:
I've watched some of it. I know you've watched it all.
Jobin Kuruvilla:
I was fascinated by it. Absolutely.
Matt Saunders:
I was fascinated by... I'm terrible at this. I'm looking at the meta about this documentary, the big production values. It's like a Panorama... Sorry. It doesn't mean anything to an outside UK audience, but a current affairs documentary, all good lighting, and people being interviewed like something you'd see on Netflix. And it's a documentary about Kubernetes. Yeah. It was about an hour and a half long, all in all, I think. And I think it-
Jobin Kuruvilla:
You would really be surprised. I was actually looking at who published it. There is a YouTube channel called Honeypot and looking at the channel, there's a lot of tech documentaries. It's not just Kubernetes. Kubernetes was one of it. I see GraphQL, it's so many different documentaries. I'm planning to watch some of it actually. But yeah, this was a really good one to watch.
Matt Saunders:
Excellent. I think my amazement of that is more that this stuff is at a scale now that warrants that, and you can have a documentary about how something technical emerged to solve a load of problems. And it reminds me of just how big Kubernetes have become. You see some of the original people who were involved, people like Joe Beda, Tim Hockin, Kelsey Hightower, et cetera. These are now people who we're looking back at as making seminal contributions to how computer science works. I don't know if you can talk about them in the same language as people like Steve Jobs, Wozniak, Bill Gates, et cetera. But it's that kind of feeling for me.
Jobin Kuruvilla:
That's the beauty of the documentary. It actually takes us through people who develop Kubernetes and who are a force behind it. It's not just the Steve Jobs who are changing the world. It's also people like Brendan and the folks that you mentioned. They're working on a technology that's changing the world and it actually gives us motivation to work on something similar. A technical expert or a DevOps expert like us can also change the world. It's all in our hands. It's small teams who is changing the world, not individuals, I get that. But at the same time, somebody has to be a driving force behind it. There are a lot of technologies out there now. Kubernetes is one of it, but what's going to be the next Kubernetes? Who knows? There's serverless architects that are coming out, there's Lambdas, there's a lot of things floating around. That's why it was specifically interesting for me, it's not just Steve Jobs who should get all the credit. There should be Matt Saunders.
Matt Saunders:
Me standing on the shoulders of giants.
Jobin Kuruvilla:
Yeah, exactly.
Matt Saunders:
That term comes to mind there. I've watched some of it.
Jobin Kuruvilla:
Yeah. There were a few key takeaways for me. How they decided to make Kubernetes an open-source initially on. How they convinced the hierarchy at Google to make it an open-source because obviously, Google didn't want to give it away for cheap. A container orchestration platform that wasn't there or at least it wasn't as big as Kubernetes is today, so there was an opportunity there. Google didn't monetize on it because of how the people envision this to be in the world five years from then. That is huge, I believe, just by making it as an open-source, a lot of collaborators came along. A lot of companies joined later on, even big companies like Microsoft and Red Hat, they all joined Han together with Google at some point to further develop Kubernetes. That was huge in my opinion. I don't know what you think about it. If it was not an open-source originally, probably Kubernetes wouldn't be here, or at least wouldn't be as popular.
Matt Saunders:
I've got skin in the game here in terms of open-source because I genuinely believe that the excitement around being able to download software and tinker with it, even just as an individual, was a massive catalyst for my entire career around this stuff. And people, we've noticed how things like the open-source aspect has made Linux such a tremendous success and all sorts of software around that just by giving people the opportunity. I'm not trying to turn this into, "Well, I was doing this. Blah, blah, blah." But I feel like my experience mirrors how a lot of people would be thinking and not just individuals, but organizations where you get hold of something that does a job and does it really, really well. And you think, "Well, yeah, how can I add to this? How can I make this do some more things that will make things better for me? Or help me, working for the company I work for, to succeed?"
Matt Saunders:
And without it just becoming patents and intellectual property and something where we end up dominating the world to the expense of everyone else, where the answer is that you make it open-source. And it seems like we've been around the block a few times on this now where you have these patterns of people building stuff on open-source and benefiting from the proliferation of people and companies who can add something to that for the greater good, it's not just a complete socialist project, but it always happens to turn out that way. And every attempt by some company to close it down and make money uniquely off it ends up failing.
Jobin Kuruvilla:
Yeah.
Matt Saunders:
Right?
Jobin Kuruvilla:
Another fascinating thing was, even when you talk about opensource, we sometimes think of it as individuals coming together and contributing. But that doesn't seem to be the case anymore. It's big companies coming together. Companies like Red Hat, they are all coming together and joining hands. And they're even spending a lot of money and engaging their own teams to contribute to the open-source product, which is huge. If it was just me or somebody down in the basement, working on an open-source product, that probably wouldn't be enough. But when you have the power of a big company helping you, that's huge.
Matt Saunders:
Yeah. And it's different aspects of the same thing because for every... Well, not for everyone, I don't have any numbers on this, but you get the big open-source projects, things like Kubernetes, but then there's also all these littler things, the smaller things that may be less so come from a hobbyist angle more, but can be individual contributors, individual people. But ultimately, someone is paying for their time. I think it does come down to companies being prepared to let their employees spend time on writing code that then goes off and is free. And the beauty of the open-source is that if it was the wrong thing, or if it isn't actually useful, then it just gets left on the shelf over there. And maybe some company who originally invested in it has the fallacy of the sunken cost around it and keeps it going. But ultimately, it doesn't prosper because it wasn't the right thing. And the more of a right thing these things are, all these pieces of software are for big companies, the more they'll continue contributing to it. Right?
Jobin Kuruvilla:
Yeah. Agree. Yeah. The second takeaway was that they started relying on Docker. Docker was obviously a big thing at that time. It just had become a big thing. That was the main container platform. But what they didn't do was create another beast like Docker. But instead, they relayed on Docker and built on top of it a container orchestration system. That was huge in my opinion, because if it had gone the other road and started competing with Docker, maybe things would have been different. They saw that there's value in Docker. They saw that Docker is doing something really, really well. They just adopted it and built on top of it, built Kubernetes on top of it.
Matt Saunders:
That's interesting because you see these two companies as being fierce rivals and for a long time, there was, which one's going to prevail? They seem to be competing. And from what you're saying here... And I must admit, this is a part of the documentary that I haven't watched yet. Sorry. I think what you're saying here is that Kubernetes almost acquiesced to Docker instead of-
Jobin Kuruvilla:
There is some interesting insight about this in the documentary. Obviously, there was a lot of power play in the beginning, at least Docker thought of Kubernetes as a competitor. But I think on the Kubernetes side, it was not the case. They actually relied on Docker and they didn't want Docker to be a competitor. There was obviously certain aspects of it, which was viewed as two fierce competitors, as you just mentioned. That was the perception I had too before seeing the documentary. But one of the biggest factors they said was about Kubernetes becoming a substance was when Docker eventually came out and joined hands with Kubernetes. That's when they realized that, okay, finally, this has become a reality. Now we are acknowledged by Docker. We are not the fierce competitors anymore. That was a huge milestone for Kubernetes.
Matt Saunders:
It almost feels like I need to quote, I think it's from war games where someone says, "The only way to win the game is not to play." And there was all this huge hype around container wars. I've been to meetups in London where you'll have the different rivalries for container orchestration, Docker, Kubernetes, MiSource, Nomad, et cetera, as a battle. And it's been interesting to see how, because those technologies don't entirely overlap, you've got an opportunity to, well, just exploit the bits of each of them that each one of them does well and let the market sort it out, just let the force of how people end up adopting this and using it. And it seems like the one that's won out, and some people actually may disagree, but it's pretty clear to me that Kubernetes has won the orchestration war.
Jobin Kuruvilla:
It is becoming the standard now, right?
Matt Saunders:
Yeah. Just be open, be pragmatic about it. And it prevails. It could be that the Kubernetes people didn't even see being the dominant orchestration engine as being a goal and maybe that helped them get there. It's absolutely fascinating, isn't it?
Jobin Kuruvilla:
It is. And 2017 in many ways became the biggest year for Kubernetes because Docker fully embraced Kubernetes finally, AWS announced EKS, Microsoft came out with AKS. So everybody adopting Kubernetes within their cloud platform, that was huge for Kubernetes. It finally became the standard that they were hoping for. I remember we had been using for one of our customers ECS for a long, long time because Kubernetes was not officially supported on AWS. When we started migrating our platform or our product, it was a website used by millions, we took it to AWS and there was no Kubernetes available at that time on AWS. It was such a shame. And we actually used ECS at that time. But as soon EKS was made available, there was this huge sigh of relief. I think everybody wanted to migrate to EKS and start using Kubernetes.
Matt Saunders:
Yeah. I find that fascinating. ECS has been around for a while. It's a mature product, but I don't get anything like the kind of positive feels for it as I do when I'm running something that's got Kubernetes underneath. Maybe that's because I'm maybe not a Kubernetes expert, but I'm good at it. And it's a portable skill that I managed to learn by playing with it because it's open-source. And it's almost like there's this unhealthy Alliance. No, no, no. It's a healthy Alliance between Kubernetes and all these cloud providers because the cloud providers know that people aren't necessarily going to go all-in for their propriety technology because they're scared of things like not having the skills in it, prices being jacked up, any sort of anti-competitive thing. And so having this standard thing where you can not only deal with the hypothetical solution where a cloud provider says, "Right, we're going to charge you 10 times as much and you can't move because you're locked in."
Matt Saunders:
But even just having that run-up to it, where before you even start using EKS or maybe after you started using it, but when you want to understand this stuff a bit more or playing with Mini Cube on your laptop, playing with all the individual bits and being able to tinker with them, open-source is an absolute dream. Right?
Jobin Kuruvilla:
That the thing, there's this cloud diagnostic angle to it. So when you look at it from the organization's point of view, they would value that a lot. Your applications on Kubernetes, okay, it is on EKS today. But what if you want to move to Azure tomorrow? That's not a hard thing because your application is already on Kubernetes, so you just ship it on. There is all these IDP platforms, which is helping you connect to multiple clouds at the same time. Maybe even running the cluster on multiple clouds at the same time. Right. Even on on-prem. And you have now solutions coming out like EKS anywhere now, nowadays, so you can even install EKS within your firewall. I think that changed the game. That is where Kubernetes changed the game because you're not relying on a vendor-specific technology like ECS.
Matt Saunders:
Yeah. I couldn't agree more. It's an absolutely fascinating aspect of almost businesses versus free will, and how we've kind of got to this level of state somehow of the balance between the open-source and someone making some money after what we're doing. It didn't come overnight. Maybe we are there now. Maybe we're not. I don't know. But before we get too philosophical, we should probably move on. Right?
Jobin Kuruvilla:
Yeah. I wonder what the future holds for Kubernetes because I keep hearing about a lot of different things. At the same time, I don't know, is serverless going to be part of Kubernetes at some point? What else could be there for Kubernetes? I know it's still evolving but already become the standard. What more can happen in the Kubernetes world?
Matt Saunders:
Yeah. I'm seeing interesting things like almost a subversion, pardon the pun, of the model where we've built things previously. So maybe before Kubernetes, we were doing lots of stuff by building out cloud services with Terraform or CDK. And one of the things we started doing... I've seen out some of our internal teams now starting to kind of ask these questions where they're doing things in Terraform, doing things like building EKS clusters in Terraform. So maybe they're building something in EKS and it's for an application and there's some EKS there and there's also perhaps an RDS, a database, an Aurora database, and some serverless functions. And I slightly mischievously say things like, "Well, why are you using Terraform to build all those things? Maybe just use Terraform to build EKS. And then you can use external things from within EKS, within Kubernetes, and have Kubernetes manage your database for you? And have objects, Kubernetes, objects of Amazon databases and server things with Knative, et cetera? Maybe that's a trajectory. Maybe Kubernetes becomes the dominant plane for managing things inside and outside of Kubernetes. I don't know. That's interesting.
Jobin Kuruvilla:
That's an interesting talk. Yeah. I wonder if that would make it more vendor-specific. I don't know. We'll have to wait and see. It's a good talk.
Matt Saunders:
All right. Let's move on.
Jobin Kuruvilla:
But that's all about Kubernetes. Right?
Matt Saunders:
Oh, yeah.
Jobin Kuruvilla:
What's happening on the Docker side, I hear that Adaptavist now has some level of partnership with Docker. Are we a valued reseller now?
Matt Saunders:
I believe we're a Docker reseller now. Come and buy your Docker licenses from Adaptavist. Sorry. No, we don't get sales pitchy here. As we know, we talked about this a few episodes ago, didn't we, where Docker have started monetizing the product a bit more. There's all sorts of links to the previous conversation here, but ultimately, we felt, or Adaptavist felt we are happy to pay Docker for something we were getting for free before, but actually this has become a really valuable thing for us. And part of me, particularly the open-source part is like, "Well, we shouldn't have to pay for this stuff," but it's a good product. It is a good product. It solves many, many problems. And it's only when you start trying to put together truly free open-source alternatives to all this that don't involve a lot of manual work or people becoming experts in containerization that you see that well, the products are worth paying for.
Jobin Kuruvilla:
You can still use it for free if it is for personal use, I believe. But if you have an enterprise and if you need help with Docker, we are here to help you with services. But if you want to just buy it, we can help you with that as well, or both.
Matt Saunders:
Yeah. I would be surprised if there wasn't more of this, people were becoming resellers for us. Again, I don't want to get too sales pitchy, but Adaptavist is there to try and solve customers' problems. And one of them, one of those problems that we see a lot, especially in your world, Jobin right?
Jobin Kuruvilla:
Yeah.
Matt Saunders:
Is the need to have a fluid and friction-free development process. And if we're deploying stuff into ECS containers, or EKS clusters, Kubernetes clusters in containers, then having developers, giving them access to friction-free and simple containerization tools on their laptops is absolutely vital. Yeah, we'll happily sell you Docker licenses as well.
Matt Saunders:
All right. So that's that. So getting towards the end today, I think. Something we started a couple of episodes ago was this one thing you should be doing in DevOps. Have you got anything on this one today, Jobin?
Jobin Kuruvilla:
I was just thinking since we are talking a lot about Docker and Kubernetes, I would actually say container orchestration, maybe. I know it's not for everything, but if you're thinking about modernizing your IT for sectors, or what are products that you're working on, if you're not already using containers, maybe it is time to start looking at it, is what I'm thinking. At least learn about container orchestration, start looking at it if you're not already using it. If you're already using containers, that's great. But are you using a container orchestration system? If not, why not start looking at Kubernetes? Yeah. We went with small things in the episode. I'm thinking maybe it's time for an upgrade. Start looking at containers if you're not already looking at it.
Matt Saunders:
Yeah. We spend so long talking about the benefits from it, we forget there was a world that wasn't container-dominated. And sometimes I find myself thinking, "Well, hang on a minute. How far down this rabbit hole are we? Is it just, are we kind of gas-lighting everyone else just by always just talking about containers?" And the answer is, well, probably partially. Lots of companies can't do it, but maybe some of those places are now losing competitive advantage because of that. We talked a few minutes ago about things like the friction-free experience you get by running Docker Desktop, and whilst there's devil in the detail and it's not that simple, going off and deploying things as containers into a cloud provider is now pretty straightforward. Sounds like a great thing you should be doing.
Jobin Kuruvilla:
And I know often the places where they do that even for monoliths. It's not just for microservices anymore. Obviously, the original trend was redesign your architects, do everything, break it down into different microservices, one container for each microservice, so on and so forth. But I think times have changed. I hear about taking the full monolith and containerize it and put it maybe in an EC2 instance, maybe in Kubernetes. Who knows. It's like the difference is whether you re-architect your application or whether you just take it and move it. It's like the whole migration to cloud fund, same thing.
Matt Saunders:
Yeah. Sometimes I used to get a short [inaudible 00:35:29] from people where you talk about containerizing a monolith, and people are like, "Well, no, it's massive, but why would you want to containerize it? What's the point of that?" To which the answers now are, "Well, yes, you can run massive containers. There's dozens of reasons why you shouldn't, you should keep your containers lean, your image sizes and attack vectors, et cetera. But actually, yeah, stick that monolith in a container, start moving it around. Once you start moving it around, you can start realizing that actually, maybe you can strip some bits off it. You can strangle it. But just by having it in a container means that you can now deploy that somewhere else. Might take a while if it's 10 gigs, but you can do that." And that's the kind of... and the analogy is going to get quite dubious here, but the ability to shift that thing around the dock in a container starts to give you options.
Jobin Kuruvilla:
That is huge because that way you can now finally take it to the Cloud. You don't have to hide behind your firewall anymore. Granted, it's probably not the best approach, but in many cases, that's the first step that you can take. Baby steps. Then obviously, at some point, you have to think about redesigning the application. I get that. But at the same time, as you said it gives us easy ways to move it around, take it from stage to production. It's not that hard now anymore.
Matt Saunders:
Yeah. When I talk about monoliths now and, of course, I have my personal interests, I think of people who have left an old car in a garage for years and years and years. And you go in and look at the car in the garage and figure out, "Well, that needs changing. The tires need replacing. The fuel lines need replacing, et cetera, to make it more agile, to make move. But actually no, pull it out of the garage and see what starts to fall off as you pull it out of the garage. And it's the same with an old monolithic application. There's almost a fear of touching these things. And if you were to say, "Well, just migrate the thing to the cloud," then what is going to go wrong? Well, you can try it, just sweep the thing up, go and deploy it to the cloud, find out which bits are dangling off the bottom by a thread, and then go start fixing them. And then before you know, it, you've got something that you can drive around in and deploy it to different places. So yeah, let's get those monoliths in the cloud.
Jobin Kuruvilla:
Let's get containers on the cloud. Yeah.
Matt Saunders:
Mm-hmm (affirmative). Okay. My thing for what you should be doing in DevOps, I'm going to pick something that's very timely here in the UK. The UK has currently battened down the hatches because we're in the middle of something called Storm Eunice, which is it's windy, it's rainy, it's terrible. And I've been watching on YouTube on my lunch hour, I was watching videos of massive airliners landing at London Heathrow Airport, and looking at the skill involved in pilots putting those planes down. And things like they're flying into a side wind, so the plane is almost flying along at 45 degrees. I'm thinking, oh my God, that's a lot like DevOps, isn't it? And then I realized, actually, no, it's not. It's not like DevOps at all. That's a really unique situation where you've got a single person, or actually probably a couple of people, couple of pilots in charge of hundreds of people's lives, where the decisions they make, it could be do or die. It could be literally lethal to make the wrong decision in these difficult situations.
Matt Saunders:
And so my DevOps thing that you should be you doing is looking at situations like that, where you've got freak occurrences happening or unusual things happening. And you're now really reliant on key people, the heroes. And that's great in an airplane context, we want the best people running those planes, getting them on the ground. Everything single one went on the ground, brilliant. 20 or 30 of them went around trying to land. They're like, nope, not having this. That's kind of like a failed... What is that? A failed deployment? I don't know. What is that, a failed deployment? I don't know. My DevOps thing for today based on the wind, literally howling around my house right now is don't put your people in that situation. We've got the ability to avoid difficult deploys or a deploy as landing an aircraft on the ground and taking the responsibility of being key people away.
Matt Saunders:
Because being a hero is wonderful, but ultimately, it's fraught with danger. Even in a business context, you don't want to be the person who deployed that piece of software and then you get crucified because it doesn't actually work and you're down, you've lost money. You don't want to put your people into that position. I loved watching those planes landing. My fingernails are a little shorter. And I'm thinking those are all the things you do not want in DevOps. You want the plane on the ground, yes. But this is software we're talking about, not airplanes. Don't be like airplanes.
Jobin Kuruvilla:
I love it. I suddenly do not want to be the person who is deleting the production database. And if that happens, please don't blame me, blame the process. Or who is in charge of the whole situation? I think we talked about in the past, there shouldn't be any cases where an individual or a group of people are in charge of making sure that the production application is up and running. There should be a process around it. And there should be things we should be handling earlier before the production system is down. There should be multiple checkpoints on everything. So many things that you can do. But I really like it. If there is a couple of people or a person in charge of your critical system, yeah, don't let that happen.
Matt Saunders:
Yeah, absolutely. Thinking about this some more and possibly stretching the analogy too far, an alternative might have been, don't fly those planes because they're going to lift off. But then at some point, they're going to have to land and the landing is a difficult bit. And it is a bit like deploying software. We start doing deployments more often and more regularly because they are difficult and they have difficult points. And the more you do them, the easier they get. And so the flip side of what I've just said about saying how DevOps is not like landing a plane, is that actually there's a load of safety systems on that plane, a load of fail-safes that mean that the plane did actually get that far, and you are in the position where with a little bit of skill and finesse... sorry, a little bit, a lot of skill and finesse, those pilots can land the plane due to avionics, sophisticated computers, and systems that are protecting the plane and making sure that everything goes well. And that actually is a lot like DevOps.
Matt Saunders:
And yeah, without wishing to get academic, because we're kind of waxing lyrical now, some of the work of people like Dr. Sydney Decker, who Gene Kim quotes quite a lot, done so much research in plane crashes and stopping planes crash. And we see these planes landing. And part of you is like, yeah, I could be watching a crash about to happen, but probably not because so much work has gone into this to make it safe. And that's a lot like software delivery.
Jobin Kuruvilla:
That's why flying is more safer than being on the road. Right?
Matt Saunders:
It is. And it's due to people working on it and creating environments where you can do these things safely. It's a wonderful thing. All right. I think we're at the end now. It's been a great conversation. Well, I thought I've enjoyed it. I hope people who are listening have. Just me and Jobin today. Sorry, it's only the two of us going on. Hopefully, you found it interesting. That's the end of the podcast for today. We'll be back with Episode Nine soon, but for now, I'll say my big thanks to Jobin. And thank you to myself, I guess for hosting. This has been DevOps Decrypted part, the Adaptavist Podcast Network. Please do go and subscribe to that, and we'll see you next time. Thanks for now.
Jobin Kuruvilla:
Thanks, Matt. Thanks, everyone.
Hello everyone. And welcome to another episode of DevOps Decrypted. This is Episode Number Eight, and we're going to talk about Kubernetes and other stories. I'm not Romy. Romy can't be here today. She's got COVID. So yeah, we hope you get well soon, Romy. We're going to miss you on the podcast, but yeah, COVID comes to us all, it seems, eventually. I've managed to dodge it. A shame Romy hasn't. So I'm here. My name's Matt Saunders. I'm here with Jobin. Jobin, you're going to say hello?
Jobin Kuruvilla:
Hello. Hello. We blame COVID if the episode isn't good.
Matt Saunders:
Yeah. We're going to blame COVID for many, many, many things, including if the episode is not good, I'm fully on board with that. So yeah, it sounds like it's just the two of us today, Jobin, which is a bit of a shame, but hey, I'm sure we'll get some great conversations out of it. Right?
Jobin Kuruvilla:
I'm pretty sure. And I hope Romy gets well soon and she'll be back here with us next time.
Matt Saunders:
Next time. Here's to that. In the meantime, we're going to go through a few things today on DevOps Decrypted. Firstly, I think we're going to talk about the DevOps Handbook, which has just come out with a second edition. Have you read it yet, Jobin?
Jobin Kuruvilla:
I haven't actually, but we have been discussing about a book club. We are thinking of reading it together. Since it is a second edition, I'm assuming it's good. Otherwise, there wouldn't be a second edition. I'm looking forward to reading that. Have you read it?
Matt Saunders:
Yeah, I agree totally. Just for those who are not aware of what it is, it's basically the handbook for operating in a DevOps way from the likes of Gene Kim. Gene Kim obviously wrote The Phoenix Project, the book that's set off books in the DevOps world. Handbook, I think came out about five years ago with lots of stories, lots of tales, adventures of people in enterprises going through DevOps transformations. And I guess it was getting a bit stale, or if not stale, needed updating for what's been going on in the last few years. I've had a flick through it. I haven't read the whole thing yet, but it's basically... And again, I say basically, it's far more than just the basic thing. It's dozens of excellent stories about how to do DevOps in a large enterprise fully updated for 2022, which is great.
Jobin Kuruvilla:
Yeah. I'm definitely looking forward to reading that. I was actually talking to Jon Mort the other day. For those of you who don't know Jon Mort, he's the CTO at Adaptavist. And he pitched the idea of having a book club. There's a lot of folks who are interested in DevOps these days within Adaptavist and obviously outside of Adaptavist. We are looking at launching a book club internally to read the book together and see what we learned from it. Obviously, there's going to be a lot of conversations around it. Everybody has their opinion on everything these days. I'm looking forward to maybe discussing, maybe debating certain things within the book.
Matt Saunders:
I think it's a great idea, especially if you get a nice broad cross-section of people-
Jobin Kuruvilla:
Yeah, exactly.
Matt Saunders:
... in the club because a lot of the time, you see... Particularly when I used to go out consulting, going out to lots of different companies, big and small, you'd often find maybe there's a couple of people who'd read The Phoenix Project or maybe someone has read the Handbook and their heads are full of ideas. And the difficulty with a lot of the DevOps stuff I feel is that it's not as actionable as some of the technical things we can do. We talk about the push towards technology, right?
Jobin Kuruvilla:
Exactly, yeah.
Matt Saunders:
Yeah. It's not as actionable. And even worse than that, it's a bit abstract. We're talking about case studies from big organizations. It's not a thing that says, "This is how you do DevOps." It's, "This is how we implemented it. These are the things that we did. These are the things we might do."
Jobin Kuruvilla:
There isn't one size that fits all, so obviously you're not talking about having a script and following it everywhere we go, that's not possible. DevOps is a culture. It's not just implementing a tool. So you cannot actually have it implemented the same way everywhere. Even if it is a tool, you can't do that. Imagine doing that for a process, a culture, right?
Matt Saunders:
Yeah. Yeah, exactly. And I think that is why I think it fits beautifully into this book club idea.
Jobin Kuruvilla:
Yep.
Matt Saunders:
It's great if everyone goes off and reads the Handbook, but everyone takes different things away from it. And everyone has different interpretations of how you can implement this stuff at your organization. You and me, we're head of departments. We'll read it and be like, "Well, yep. We can manage outputs and change these things with our bosses, manage downwards and change these things with the people who work for us." But you compare that to the people who are on the ground, maybe doing more hands-on and also the people up at the exec level, different interpretations. And I think what's going to be really good is if within a database you can get a broad cross-section. Nothing worse than a new technique or book goes around a few, a small set of people, and they were like, "Ah, we want to do this stuff." And everyone who wasn't part of that goes, "What on earth are you talking about? What's this new fad stuff?"
Jobin Kuruvilla:
Why? Yeah.
Matt Saunders:
And more, the people who have read it, try and implement it, but nobody else has been following along, so it's almost destined to failure. That ain't going to happen if everyone at Adaptavist is reading the handbook, taking away the... I think it's a difference between... I remember at school doing pure maths and applied maths and the pure was all the science and all the algebra and lambdas and things like that. And they applied was actually, how do we actually use this in our life? And maybe one of the big takeaways here is get together a group of people, read the book, read it a chapter at a time, figure out all the NIH stuff. Oh, no, we couldn't do that here because we're not like Nike or we're not like American Airlines.
Jobin Kuruvilla:
I'm certainly looking forward to reading it because having written on a book myself on Jira Development, that is more technical. I know how difficult it is to write a book, but I feel it's a lot easier when it is something as technical as that. But DevOps, I'm curious how much breadth discovered in that particular book can. I'm looking forward to reading it and learning from it, of course.
Matt Saunders:
Yeah. What about the second edition aspect of it? It did surprise me somewhat when it came up with the second edition of the Handbook, because the IT revolution thing, the company that Gene Kim runs to publish the books, their thing seems to be to keep putting out new things. Obviously, based on the success of The Phoenix Project, you build up and have a similar group of authors with some new ones, putting out the Handbook. And then other books such as BVSSH, Better Value Sooner Safer Happier from Jon Smart, Agile Conversations, the Mark Schwartz book around bureaucracies, but then they're going back here. And, and that was an interesting thing I found here because we hear a lot about things like, "Well, we're over DevOps now. We're in a post-DevOps world. The word is poisoned now and means too many different things so we can't use it." And yet here we are going back and revisiting some of the same ideas, but with a modern spin on it. So is DevOps dead?
Jobin Kuruvilla:
You would say so, but again, think of DevOps... Obviously, we have been talking about DevOps for quite a long time now, but at the same time, there is still a lot of organizations out there who are still trying to figure out what DevOps is. I think you take the state of their license report that we did last year, or many of the reports that's coming out, obviously there's a huge chunk of people who are already using DevOps, who think of them, the person in the DevOps area, but then there is also a larger part of the organizations who want to get on the DevOps train, still trying to figure out where DevOps is. I'm pretty sure it can benefit still a lot of the people. And the technology also has evolved a lot. Probably five years back... I don't know when the original edition was out there, Kubernetes was probably not the standard. Since some moved on, now Kubernetes is a standard in container orchestration. That's just one example.
Jobin Kuruvilla:
There was DevSecOps at that time, or at least a term was not coined since security didn't have this much of an importance. Not many organizations were on Cloud. Cloud migration wasn't exactly a thing at that time. I think over this past five, six years, a lot of things have changed. That's probably accounted for in the new edition, but the original fundamentals still remain. Right?
Matt Saunders:
Yeah. Just analyzing the things that you are mentioning there. If we look at all the things that have changed across the three tenants, like the people, process, and technology, most of them seem to be technical. So yeah, Kubernetes.
Jobin Kuruvilla:
Yep.
Matt Saunders:
Yes, more cloud services. And maybe some process stuff, so DevSecOps and GitOps, but then the people aspect, the culture thing is pretty much still the same. And I think that's a good thing because it's all about ideals and about going back to the three ways and the five ideas from the Unicorn Project, those things are still kind of the same.
Jobin Kuruvilla:
That's exactly what I meant when I said the fundamentals remain the same.
Matt Saunders:
Yeah, exactly. I'm reminded of, I spent a lot of time in the car driving up between various places. It doesn't matter. And one of the things I listen to in the car is the IT Revolution Podcast, Gene Kim's podcast. And he was doing a review with some of the original authors of the handbook. So Patrick Debois, John Willis, and Jez Humble, and Nicole Forsgren, who's coming in on the second edition. And I felt a little bad. I thought, I'm not really using my time well here, because these folks are basically just... It's like some old friends who are up in a pub and they're going, "Oh, do you remember when we did this? Or remember when we talked about that. And this is how we all started off. And we did Devopsdays in Ghent," and talking about all these things. I'm like, "Yeah, I want to hear about the new stuff."
Matt Saunders:
But then I started realizing that actually, the reason why those things were noteworthy, things like DevOps Days getting kicked off, things like the Agile Six happening, talks at Velocity, 10 deploys a day, that sort of stuff from Flicker. The reason we keep coming back to those, but without just sounding like old boars in a pub, is that the techniques are moving on, but the principles are still the same. These principles were the groundbreaking things that people started doing back in the day. And it was all cultural. Right?
Jobin Kuruvilla:
Absolutely. That's probably a good segue into our next section. Have you seen the latest Kubernetes documentary that came out? You talk about, talked about the IT Revolution and it is fascinating to watch how Kubernetes has evolved over the years and the story behind it. Did you get a chance to watch it yet?
Matt Saunders:
I've watched some of it. I know you've watched it all.
Jobin Kuruvilla:
I was fascinated by it. Absolutely.
Matt Saunders:
I was fascinated by... I'm terrible at this. I'm looking at the meta about this documentary, the big production values. It's like a Panorama... Sorry. It doesn't mean anything to an outside UK audience, but a current affairs documentary, all good lighting, and people being interviewed like something you'd see on Netflix. And it's a documentary about Kubernetes. Yeah. It was about an hour and a half long, all in all, I think. And I think it-
Jobin Kuruvilla:
You would really be surprised. I was actually looking at who published it. There is a YouTube channel called Honeypot and looking at the channel, there's a lot of tech documentaries. It's not just Kubernetes. Kubernetes was one of it. I see GraphQL, it's so many different documentaries. I'm planning to watch some of it actually. But yeah, this was a really good one to watch.
Matt Saunders:
Excellent. I think my amazement of that is more that this stuff is at a scale now that warrants that, and you can have a documentary about how something technical emerged to solve a load of problems. And it reminds me of just how big Kubernetes have become. You see some of the original people who were involved, people like Joe Beda, Tim Hockin, Kelsey Hightower, et cetera. These are now people who we're looking back at as making seminal contributions to how computer science works. I don't know if you can talk about them in the same language as people like Steve Jobs, Wozniak, Bill Gates, et cetera. But it's that kind of feeling for me.
Jobin Kuruvilla:
That's the beauty of the documentary. It actually takes us through people who develop Kubernetes and who are a force behind it. It's not just the Steve Jobs who are changing the world. It's also people like Brendan and the folks that you mentioned. They're working on a technology that's changing the world and it actually gives us motivation to work on something similar. A technical expert or a DevOps expert like us can also change the world. It's all in our hands. It's small teams who is changing the world, not individuals, I get that. But at the same time, somebody has to be a driving force behind it. There are a lot of technologies out there now. Kubernetes is one of it, but what's going to be the next Kubernetes? Who knows? There's serverless architects that are coming out, there's Lambdas, there's a lot of things floating around. That's why it was specifically interesting for me, it's not just Steve Jobs who should get all the credit. There should be Matt Saunders.
Matt Saunders:
Me standing on the shoulders of giants.
Jobin Kuruvilla:
Yeah, exactly.
Matt Saunders:
That term comes to mind there. I've watched some of it.
Jobin Kuruvilla:
Yeah. There were a few key takeaways for me. How they decided to make Kubernetes an open-source initially on. How they convinced the hierarchy at Google to make it an open-source because obviously, Google didn't want to give it away for cheap. A container orchestration platform that wasn't there or at least it wasn't as big as Kubernetes is today, so there was an opportunity there. Google didn't monetize on it because of how the people envision this to be in the world five years from then. That is huge, I believe, just by making it as an open-source, a lot of collaborators came along. A lot of companies joined later on, even big companies like Microsoft and Red Hat, they all joined Han together with Google at some point to further develop Kubernetes. That was huge in my opinion. I don't know what you think about it. If it was not an open-source originally, probably Kubernetes wouldn't be here, or at least wouldn't be as popular.
Matt Saunders:
I've got skin in the game here in terms of open-source because I genuinely believe that the excitement around being able to download software and tinker with it, even just as an individual, was a massive catalyst for my entire career around this stuff. And people, we've noticed how things like the open-source aspect has made Linux such a tremendous success and all sorts of software around that just by giving people the opportunity. I'm not trying to turn this into, "Well, I was doing this. Blah, blah, blah." But I feel like my experience mirrors how a lot of people would be thinking and not just individuals, but organizations where you get hold of something that does a job and does it really, really well. And you think, "Well, yeah, how can I add to this? How can I make this do some more things that will make things better for me? Or help me, working for the company I work for, to succeed?"
Matt Saunders:
And without it just becoming patents and intellectual property and something where we end up dominating the world to the expense of everyone else, where the answer is that you make it open-source. And it seems like we've been around the block a few times on this now where you have these patterns of people building stuff on open-source and benefiting from the proliferation of people and companies who can add something to that for the greater good, it's not just a complete socialist project, but it always happens to turn out that way. And every attempt by some company to close it down and make money uniquely off it ends up failing.
Jobin Kuruvilla:
Yeah.
Matt Saunders:
Right?
Jobin Kuruvilla:
Another fascinating thing was, even when you talk about opensource, we sometimes think of it as individuals coming together and contributing. But that doesn't seem to be the case anymore. It's big companies coming together. Companies like Red Hat, they are all coming together and joining hands. And they're even spending a lot of money and engaging their own teams to contribute to the open-source product, which is huge. If it was just me or somebody down in the basement, working on an open-source product, that probably wouldn't be enough. But when you have the power of a big company helping you, that's huge.
Matt Saunders:
Yeah. And it's different aspects of the same thing because for every... Well, not for everyone, I don't have any numbers on this, but you get the big open-source projects, things like Kubernetes, but then there's also all these littler things, the smaller things that may be less so come from a hobbyist angle more, but can be individual contributors, individual people. But ultimately, someone is paying for their time. I think it does come down to companies being prepared to let their employees spend time on writing code that then goes off and is free. And the beauty of the open-source is that if it was the wrong thing, or if it isn't actually useful, then it just gets left on the shelf over there. And maybe some company who originally invested in it has the fallacy of the sunken cost around it and keeps it going. But ultimately, it doesn't prosper because it wasn't the right thing. And the more of a right thing these things are, all these pieces of software are for big companies, the more they'll continue contributing to it. Right?
Jobin Kuruvilla:
Yeah. Agree. Yeah. The second takeaway was that they started relying on Docker. Docker was obviously a big thing at that time. It just had become a big thing. That was the main container platform. But what they didn't do was create another beast like Docker. But instead, they relayed on Docker and built on top of it a container orchestration system. That was huge in my opinion, because if it had gone the other road and started competing with Docker, maybe things would have been different. They saw that there's value in Docker. They saw that Docker is doing something really, really well. They just adopted it and built on top of it, built Kubernetes on top of it.
Matt Saunders:
That's interesting because you see these two companies as being fierce rivals and for a long time, there was, which one's going to prevail? They seem to be competing. And from what you're saying here... And I must admit, this is a part of the documentary that I haven't watched yet. Sorry. I think what you're saying here is that Kubernetes almost acquiesced to Docker instead of-
Jobin Kuruvilla:
There is some interesting insight about this in the documentary. Obviously, there was a lot of power play in the beginning, at least Docker thought of Kubernetes as a competitor. But I think on the Kubernetes side, it was not the case. They actually relied on Docker and they didn't want Docker to be a competitor. There was obviously certain aspects of it, which was viewed as two fierce competitors, as you just mentioned. That was the perception I had too before seeing the documentary. But one of the biggest factors they said was about Kubernetes becoming a substance was when Docker eventually came out and joined hands with Kubernetes. That's when they realized that, okay, finally, this has become a reality. Now we are acknowledged by Docker. We are not the fierce competitors anymore. That was a huge milestone for Kubernetes.
Matt Saunders:
It almost feels like I need to quote, I think it's from war games where someone says, "The only way to win the game is not to play." And there was all this huge hype around container wars. I've been to meetups in London where you'll have the different rivalries for container orchestration, Docker, Kubernetes, MiSource, Nomad, et cetera, as a battle. And it's been interesting to see how, because those technologies don't entirely overlap, you've got an opportunity to, well, just exploit the bits of each of them that each one of them does well and let the market sort it out, just let the force of how people end up adopting this and using it. And it seems like the one that's won out, and some people actually may disagree, but it's pretty clear to me that Kubernetes has won the orchestration war.
Jobin Kuruvilla:
It is becoming the standard now, right?
Matt Saunders:
Yeah. Just be open, be pragmatic about it. And it prevails. It could be that the Kubernetes people didn't even see being the dominant orchestration engine as being a goal and maybe that helped them get there. It's absolutely fascinating, isn't it?
Jobin Kuruvilla:
It is. And 2017 in many ways became the biggest year for Kubernetes because Docker fully embraced Kubernetes finally, AWS announced EKS, Microsoft came out with AKS. So everybody adopting Kubernetes within their cloud platform, that was huge for Kubernetes. It finally became the standard that they were hoping for. I remember we had been using for one of our customers ECS for a long, long time because Kubernetes was not officially supported on AWS. When we started migrating our platform or our product, it was a website used by millions, we took it to AWS and there was no Kubernetes available at that time on AWS. It was such a shame. And we actually used ECS at that time. But as soon EKS was made available, there was this huge sigh of relief. I think everybody wanted to migrate to EKS and start using Kubernetes.
Matt Saunders:
Yeah. I find that fascinating. ECS has been around for a while. It's a mature product, but I don't get anything like the kind of positive feels for it as I do when I'm running something that's got Kubernetes underneath. Maybe that's because I'm maybe not a Kubernetes expert, but I'm good at it. And it's a portable skill that I managed to learn by playing with it because it's open-source. And it's almost like there's this unhealthy Alliance. No, no, no. It's a healthy Alliance between Kubernetes and all these cloud providers because the cloud providers know that people aren't necessarily going to go all-in for their propriety technology because they're scared of things like not having the skills in it, prices being jacked up, any sort of anti-competitive thing. And so having this standard thing where you can not only deal with the hypothetical solution where a cloud provider says, "Right, we're going to charge you 10 times as much and you can't move because you're locked in."
Matt Saunders:
But even just having that run-up to it, where before you even start using EKS or maybe after you started using it, but when you want to understand this stuff a bit more or playing with Mini Cube on your laptop, playing with all the individual bits and being able to tinker with them, open-source is an absolute dream. Right?
Jobin Kuruvilla:
That the thing, there's this cloud diagnostic angle to it. So when you look at it from the organization's point of view, they would value that a lot. Your applications on Kubernetes, okay, it is on EKS today. But what if you want to move to Azure tomorrow? That's not a hard thing because your application is already on Kubernetes, so you just ship it on. There is all these IDP platforms, which is helping you connect to multiple clouds at the same time. Maybe even running the cluster on multiple clouds at the same time. Right. Even on on-prem. And you have now solutions coming out like EKS anywhere now, nowadays, so you can even install EKS within your firewall. I think that changed the game. That is where Kubernetes changed the game because you're not relying on a vendor-specific technology like ECS.
Matt Saunders:
Yeah. I couldn't agree more. It's an absolutely fascinating aspect of almost businesses versus free will, and how we've kind of got to this level of state somehow of the balance between the open-source and someone making some money after what we're doing. It didn't come overnight. Maybe we are there now. Maybe we're not. I don't know. But before we get too philosophical, we should probably move on. Right?
Jobin Kuruvilla:
Yeah. I wonder what the future holds for Kubernetes because I keep hearing about a lot of different things. At the same time, I don't know, is serverless going to be part of Kubernetes at some point? What else could be there for Kubernetes? I know it's still evolving but already become the standard. What more can happen in the Kubernetes world?
Matt Saunders:
Yeah. I'm seeing interesting things like almost a subversion, pardon the pun, of the model where we've built things previously. So maybe before Kubernetes, we were doing lots of stuff by building out cloud services with Terraform or CDK. And one of the things we started doing... I've seen out some of our internal teams now starting to kind of ask these questions where they're doing things in Terraform, doing things like building EKS clusters in Terraform. So maybe they're building something in EKS and it's for an application and there's some EKS there and there's also perhaps an RDS, a database, an Aurora database, and some serverless functions. And I slightly mischievously say things like, "Well, why are you using Terraform to build all those things? Maybe just use Terraform to build EKS. And then you can use external things from within EKS, within Kubernetes, and have Kubernetes manage your database for you? And have objects, Kubernetes, objects of Amazon databases and server things with Knative, et cetera? Maybe that's a trajectory. Maybe Kubernetes becomes the dominant plane for managing things inside and outside of Kubernetes. I don't know. That's interesting.
Jobin Kuruvilla:
That's an interesting talk. Yeah. I wonder if that would make it more vendor-specific. I don't know. We'll have to wait and see. It's a good talk.
Matt Saunders:
All right. Let's move on.
Jobin Kuruvilla:
But that's all about Kubernetes. Right?
Matt Saunders:
Oh, yeah.
Jobin Kuruvilla:
What's happening on the Docker side, I hear that Adaptavist now has some level of partnership with Docker. Are we a valued reseller now?
Matt Saunders:
I believe we're a Docker reseller now. Come and buy your Docker licenses from Adaptavist. Sorry. No, we don't get sales pitchy here. As we know, we talked about this a few episodes ago, didn't we, where Docker have started monetizing the product a bit more. There's all sorts of links to the previous conversation here, but ultimately, we felt, or Adaptavist felt we are happy to pay Docker for something we were getting for free before, but actually this has become a really valuable thing for us. And part of me, particularly the open-source part is like, "Well, we shouldn't have to pay for this stuff," but it's a good product. It is a good product. It solves many, many problems. And it's only when you start trying to put together truly free open-source alternatives to all this that don't involve a lot of manual work or people becoming experts in containerization that you see that well, the products are worth paying for.
Jobin Kuruvilla:
You can still use it for free if it is for personal use, I believe. But if you have an enterprise and if you need help with Docker, we are here to help you with services. But if you want to just buy it, we can help you with that as well, or both.
Matt Saunders:
Yeah. I would be surprised if there wasn't more of this, people were becoming resellers for us. Again, I don't want to get too sales pitchy, but Adaptavist is there to try and solve customers' problems. And one of them, one of those problems that we see a lot, especially in your world, Jobin right?
Jobin Kuruvilla:
Yeah.
Matt Saunders:
Is the need to have a fluid and friction-free development process. And if we're deploying stuff into ECS containers, or EKS clusters, Kubernetes clusters in containers, then having developers, giving them access to friction-free and simple containerization tools on their laptops is absolutely vital. Yeah, we'll happily sell you Docker licenses as well.
Matt Saunders:
All right. So that's that. So getting towards the end today, I think. Something we started a couple of episodes ago was this one thing you should be doing in DevOps. Have you got anything on this one today, Jobin?
Jobin Kuruvilla:
I was just thinking since we are talking a lot about Docker and Kubernetes, I would actually say container orchestration, maybe. I know it's not for everything, but if you're thinking about modernizing your IT for sectors, or what are products that you're working on, if you're not already using containers, maybe it is time to start looking at it, is what I'm thinking. At least learn about container orchestration, start looking at it if you're not already using it. If you're already using containers, that's great. But are you using a container orchestration system? If not, why not start looking at Kubernetes? Yeah. We went with small things in the episode. I'm thinking maybe it's time for an upgrade. Start looking at containers if you're not already looking at it.
Matt Saunders:
Yeah. We spend so long talking about the benefits from it, we forget there was a world that wasn't container-dominated. And sometimes I find myself thinking, "Well, hang on a minute. How far down this rabbit hole are we? Is it just, are we kind of gas-lighting everyone else just by always just talking about containers?" And the answer is, well, probably partially. Lots of companies can't do it, but maybe some of those places are now losing competitive advantage because of that. We talked a few minutes ago about things like the friction-free experience you get by running Docker Desktop, and whilst there's devil in the detail and it's not that simple, going off and deploying things as containers into a cloud provider is now pretty straightforward. Sounds like a great thing you should be doing.
Jobin Kuruvilla:
And I know often the places where they do that even for monoliths. It's not just for microservices anymore. Obviously, the original trend was redesign your architects, do everything, break it down into different microservices, one container for each microservice, so on and so forth. But I think times have changed. I hear about taking the full monolith and containerize it and put it maybe in an EC2 instance, maybe in Kubernetes. Who knows. It's like the difference is whether you re-architect your application or whether you just take it and move it. It's like the whole migration to cloud fund, same thing.
Matt Saunders:
Yeah. Sometimes I used to get a short [inaudible 00:35:29] from people where you talk about containerizing a monolith, and people are like, "Well, no, it's massive, but why would you want to containerize it? What's the point of that?" To which the answers now are, "Well, yes, you can run massive containers. There's dozens of reasons why you shouldn't, you should keep your containers lean, your image sizes and attack vectors, et cetera. But actually, yeah, stick that monolith in a container, start moving it around. Once you start moving it around, you can start realizing that actually, maybe you can strip some bits off it. You can strangle it. But just by having it in a container means that you can now deploy that somewhere else. Might take a while if it's 10 gigs, but you can do that." And that's the kind of... and the analogy is going to get quite dubious here, but the ability to shift that thing around the dock in a container starts to give you options.
Jobin Kuruvilla:
That is huge because that way you can now finally take it to the Cloud. You don't have to hide behind your firewall anymore. Granted, it's probably not the best approach, but in many cases, that's the first step that you can take. Baby steps. Then obviously, at some point, you have to think about redesigning the application. I get that. But at the same time, as you said it gives us easy ways to move it around, take it from stage to production. It's not that hard now anymore.
Matt Saunders:
Yeah. When I talk about monoliths now and, of course, I have my personal interests, I think of people who have left an old car in a garage for years and years and years. And you go in and look at the car in the garage and figure out, "Well, that needs changing. The tires need replacing. The fuel lines need replacing, et cetera, to make it more agile, to make move. But actually no, pull it out of the garage and see what starts to fall off as you pull it out of the garage. And it's the same with an old monolithic application. There's almost a fear of touching these things. And if you were to say, "Well, just migrate the thing to the cloud," then what is going to go wrong? Well, you can try it, just sweep the thing up, go and deploy it to the cloud, find out which bits are dangling off the bottom by a thread, and then go start fixing them. And then before you know, it, you've got something that you can drive around in and deploy it to different places. So yeah, let's get those monoliths in the cloud.
Jobin Kuruvilla:
Let's get containers on the cloud. Yeah.
Matt Saunders:
Mm-hmm (affirmative). Okay. My thing for what you should be doing in DevOps, I'm going to pick something that's very timely here in the UK. The UK has currently battened down the hatches because we're in the middle of something called Storm Eunice, which is it's windy, it's rainy, it's terrible. And I've been watching on YouTube on my lunch hour, I was watching videos of massive airliners landing at London Heathrow Airport, and looking at the skill involved in pilots putting those planes down. And things like they're flying into a side wind, so the plane is almost flying along at 45 degrees. I'm thinking, oh my God, that's a lot like DevOps, isn't it? And then I realized, actually, no, it's not. It's not like DevOps at all. That's a really unique situation where you've got a single person, or actually probably a couple of people, couple of pilots in charge of hundreds of people's lives, where the decisions they make, it could be do or die. It could be literally lethal to make the wrong decision in these difficult situations.
Matt Saunders:
And so my DevOps thing that you should be you doing is looking at situations like that, where you've got freak occurrences happening or unusual things happening. And you're now really reliant on key people, the heroes. And that's great in an airplane context, we want the best people running those planes, getting them on the ground. Everything single one went on the ground, brilliant. 20 or 30 of them went around trying to land. They're like, nope, not having this. That's kind of like a failed... What is that? A failed deployment? I don't know. What is that, a failed deployment? I don't know. My DevOps thing for today based on the wind, literally howling around my house right now is don't put your people in that situation. We've got the ability to avoid difficult deploys or a deploy as landing an aircraft on the ground and taking the responsibility of being key people away.
Matt Saunders:
Because being a hero is wonderful, but ultimately, it's fraught with danger. Even in a business context, you don't want to be the person who deployed that piece of software and then you get crucified because it doesn't actually work and you're down, you've lost money. You don't want to put your people into that position. I loved watching those planes landing. My fingernails are a little shorter. And I'm thinking those are all the things you do not want in DevOps. You want the plane on the ground, yes. But this is software we're talking about, not airplanes. Don't be like airplanes.
Jobin Kuruvilla:
I love it. I suddenly do not want to be the person who is deleting the production database. And if that happens, please don't blame me, blame the process. Or who is in charge of the whole situation? I think we talked about in the past, there shouldn't be any cases where an individual or a group of people are in charge of making sure that the production application is up and running. There should be a process around it. And there should be things we should be handling earlier before the production system is down. There should be multiple checkpoints on everything. So many things that you can do. But I really like it. If there is a couple of people or a person in charge of your critical system, yeah, don't let that happen.
Matt Saunders:
Yeah, absolutely. Thinking about this some more and possibly stretching the analogy too far, an alternative might have been, don't fly those planes because they're going to lift off. But then at some point, they're going to have to land and the landing is a difficult bit. And it is a bit like deploying software. We start doing deployments more often and more regularly because they are difficult and they have difficult points. And the more you do them, the easier they get. And so the flip side of what I've just said about saying how DevOps is not like landing a plane, is that actually there's a load of safety systems on that plane, a load of fail-safes that mean that the plane did actually get that far, and you are in the position where with a little bit of skill and finesse... sorry, a little bit, a lot of skill and finesse, those pilots can land the plane due to avionics, sophisticated computers, and systems that are protecting the plane and making sure that everything goes well. And that actually is a lot like DevOps.
Matt Saunders:
And yeah, without wishing to get academic, because we're kind of waxing lyrical now, some of the work of people like Dr. Sydney Decker, who Gene Kim quotes quite a lot, done so much research in plane crashes and stopping planes crash. And we see these planes landing. And part of you is like, yeah, I could be watching a crash about to happen, but probably not because so much work has gone into this to make it safe. And that's a lot like software delivery.
Jobin Kuruvilla:
That's why flying is more safer than being on the road. Right?
Matt Saunders:
It is. And it's due to people working on it and creating environments where you can do these things safely. It's a wonderful thing. All right. I think we're at the end now. It's been a great conversation. Well, I thought I've enjoyed it. I hope people who are listening have. Just me and Jobin today. Sorry, it's only the two of us going on. Hopefully, you found it interesting. That's the end of the podcast for today. We'll be back with Episode Nine soon, but for now, I'll say my big thanks to Jobin. And thank you to myself, I guess for hosting. This has been DevOps Decrypted part, the Adaptavist Podcast Network. Please do go and subscribe to that, and we'll see you next time. Thanks for now.
Jobin Kuruvilla:
Thanks, Matt. Thanks, everyone.