Tracy Ragan, CEO of DeployHub, clarifies the difference between containers, microservices, and Kubernetes including use cases, challenges, and business benefits.

The lightly edited transcript can be found below.

Intro:

You’re listening to the Humans of DevOps Podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas, and learning, or the SKIL framework. Here’s your host, dev ops Institute, CEO Jayne Groll.

Jayne Groll:

Hi everyone. I’m Jayne Groll, CEO of the DevOps Institute and I’m delighted to invite you to another episode of the Humans and DevOps podcast. I’m joined today by one of my favorite people, Tracy Reagan of DeployHub. And the topic we’re going to talk about is clarifying Kubernetes as many of you know, and maybe some of you don’t know, there is a migration towards moving monolithic applications into a microservice architecture. You might be hearing a lot about containers or even the term Kubernetes. Tracy and I were at Cube-Con last November in San Diego, where 12,000 of our closest friends were focusing on the topic of Kubernetes and micro service architectures. Tracy has been really helping to lead the way on the continuous delivery foundation for which DevOps Institute is a member. So welcome Tracy.

Tracy Ragan:

Thank you. Thank you so much for inviting me. I appreciate it.

Jayne Groll:

And we appreciate your insight as well. So let’s start with the basics, Tracy. So let’s assume some of the folks listening to this, maybe hearing some terms, but they’re really not sure what the difference is, say between Kubernetes, and containers, and microservices. Can you help us level set?

Tracy Ragan:

Absolutely. Yeah. Sometimes when I say Kubernetes, other people say Gesundheit, but it’s not a sneeze. It’s a real thing. So Kubernetes is really a natural sort of outgrowth of both the cloud movement and the agile movement. If we think about how we got here, it helps understand what Kubernetes is. So we have gone through a shift from having physical servers running our software to having virtual machines. Virtual machines was sort of the beginning of Kubernetes if you really look at it. When we went from a physical server to a virtual machine, it really cleaned up a lot of the problems that we had with just managing, literally a warehouse of servers. Now while there still is that the end user sees these as virtual machines now virtual machines change the way we think about deploy software because now we could spin machine up pretty quickly.

As opposed to having somebody from the networking team go and rebuild a brand new machine from scratch, with diskettes at one point in our lives. So when we did that, we started getting excited about what we could do with a virtual machine. And if you think about what Kubernetes is, it’s basically an extension of VM. So what we did was in our growth from a virtual machine sort of world to a Kubernetes world, there was the container that fit in the middle of it. Since we had a virtual machine, could we create a really, really tiny one? One that only needed enough of the operating system on it so that it was really, really small, sort of a micro operating system. And the answer was yes. The folks at Docker really brought this whole idea of a container, which is a really small virtual server to the forefront.

Now what the idea was, was that we need to make our mini servers more encapsulated where they’re not impacted by another change in another piece of the bigger server environment. So all of this really was, were ops questions that were being answered when containers came about, but the idea that applications could look like this evolved over time. So when you think about what a container is, that it has a micro operating system in it, and many people at first, instead of going… They went from the cloud to a containerized application, which means take your big Fat application, your monolithic application you’re very comfortable with and install that into a container, and then the container can run in your cloud environment. Well when we started doing that, we also realized, “Hey, you know what? This could be really cool if we didn’t have to have a big Fat application running in a container, but we could have a lot of little functions running in containers to further insulate changes to the application.”

So instead of having one big jar file, one big binary, you’re going to have lots of small ones, and that’s what a microservice is. Well, when you have lots of containers and lots of microservices, what you need is a platform to sit that on that wasn’t just the cloud. Kubernetes is that platform. Kubernetes is really part of the VM world, sort of the virtual world that sits on top of it that allows containers to sit on top of that, so containers can be managed, and if you have just one or two containers, they don’t necessarily need Kubernetes. But if you begin really branching out and using Kubernetes in the way it’s intended, and containers in the way they’re intended, and you build on microservices, then you need to do something about managing all the thousands of containers that you have running in your environment. That’s what Kubernetes does. So Kubernetes is at the lowest level, the operating system. Containers is a midpoint, almost like an installer, and microservices are what sit inside the containers and decompose applications so they’re now functions instead of very large monolithic solutions.

Jayne Groll:

That’s an awesome explanation. Thank you for that. And just one more question. So our listeners may be hearing a little bit about the Linux Foundation and the Cloud Native Computing Foundation. What role do they play in Kubernetes?

Tracy Ragan:

So Kubernetes was born they… So Google initially wrote Kubernetes and they gave that code base over to the Linux Foundation and the CNCF as a governing board to manage this very large open source project. It’s one of the largest open source projects in the world. We’re talking thousands of contributors and users now that are running it. You think about Linux, Linux is probably one of the other largest open source products in the world. And the Linux Foundation was formed to manage and govern Linux. The Linux Foundation now has expanded and they are managing and providing governance and collaboration across teams and across companies for lots of different open source projects. Kubernetes is one and as you know, the Continuous Delivery Foundation was created primarily from CloudBees looking for a home for Jenkins because of the size of it has gotten to.

Jayne Groll:

Which is really interesting. We’ll talk a little bit about the Continuous Delivery Foundation and CDF in just a bit. So that really helps to level set what’s the difference. And I would assume that part of the benefit of moving into a container environment, microservice breaking down those big Fat applications into the sum of its parts also makes it easier to manage and to make changes to.

Tracy Ragan:

And that’s why I said it’s sort of a outgrowth of agile. What our goal was with agile was to do things on an incremental basis. You make small changes and you release small changes. So agile was really teaching us that. Whether it be, whatever a method of agile you were pursuing, taught us to make smaller changes and get them out to the customer sooner. But in the monolithic world, the concept of making a small change to the source code, that was easy. But when we push it through the life cycle, the first thing we do is recompile the binaries. And every time we would make one small change in the source code, we would recompile the entire set of source code and we would rerelease everything all at the same time.

So while our developers were writing code in an incremental or in an agile practice, in reality we never incrementally did builds. We’ve never incrementally done releases. Microservices supports that. It is what I would call the last mile of agile because we are now able to build an architecture in which we can have these independent functions moving across the life cycle without carrying the entire load.

Jayne Groll:

All right, and you know, small and fast, right? So if we look at agile as being incremental and iterative, where we’re constantly doing smaller iterations, and then the release cycle becomes a lot faster. Then it goes down into the pipeline so that it can be tested faster. It could be secured faster, it could be deployed faster. Now it’s like reliability engineering it can be operated in a smaller way as well. It makes a lot of sense to organizations, but some organizations still are on-prem or hybrid. So how does this all apply to them?

Tracy Ragan:

There is… I don’t believe there’s going to be a single organization that doesn’t have a hybrid environment. These decisions are generally made based on how often an application is being updated. This is how we’ve migrated from one platform to the next ever since going from the mainframe to a distributed platform solution. So what we’re… We’re seeing this now with companies where they’re looking at building out new applications under a more of a Kubernetes microservice architecture. These applications may still need to talk to applications that are running in a Fat mode, but regardless, they’re being put into a container. So when you containerize an application, there’s things you have to do, some minor things you have to do to allow it to run in that container. And at that point in time it can start talking to other applications via APIs. So we’ll have some companies who are running a mix of applications that are still monolithic, and applications that are microservices, and even they may share information.

Jayne Groll:

When you said it before, the original concept on a container was to take the Fat application and put it in the container. Like squeeze it into it. Right?

Tracy Ragan:

Well it’s super helpful, because if you think of a company like ours, we used to have, literally, a very large room of every version of Windows with a server, with every version of Windows, with every version of Linux in order to be able to test our application for all these different environments. Putting our application in a container, not decomposing it, but just putting it in a container so that we can distribute it prevents us from having to do that, because the container itself prevents us from having to say this is the version they’re running on SUSI and this is a version running on AIX. So that’s what containers originally brought to the table was the ability for us to create a different way of installing software.

Jayne Groll:

And so if I hear you correctly though, regardless of whether an organization is decoupled its applications into smaller microservices, they still can start exploring containers, right? They can still start taking those first steps towards that. It’s funny because you know what you described about the variety of different servers, each running a different version of Windows and different version of Linux and that’s my old life.

Tracy Ragan:

Exactly. And containers got rid of that mess for us. That’s what I was talking about. All these physical machines, containers fix that for us.

Jayne Groll:

Yeah, and the other interesting thing about it, I think, is from a testing perspective, again, taking a walk down memory lane for me, is that because we didn’t have good testing environments, either the company wouldn’t legitimize creating a mirror site or it just wasn’t logistically possible. A lot of things went into production that were minimally tested because the environment wasn’t available to them. And it seems like this migration towards containers and then ultimately being able to go smaller and faster is helping with it. It may not solve all of the problems, right? But it’s helping with it.

Tracy Ragan:

It solves a good number of the problems to be quite honest. I mean it really does take a big bite out of the kinds of problems that we had with basic interoperability issues between Windows 8 and Windows 10.

Jayne Groll:

Right.

Tracy Ragan:

It solves a lot of that and that caused a lot of headaches, a lot of costs, and a lot of risk for organizations who needed to move… shift over the operating system. That means every single application had to be recompiled. Every single server had to be upgraded. That was a massive expense and containers addresses that really head on.

Jayne Groll:

And you know, a lot of organizations waited, right? So instead of being able to move forward, they stalled. I know in my experience either through my own environment or some of my colleagues in other organizations, the move from say eight to 10 was a big project. I had to get a special budget for it and we likely waited a year after 10 came out in order to be able to make that move. But speaking of challenges, so what kinds of challenges or rabbit holes are happening to those that are starting to move in that direction?

Tracy Ragan:

So first of all, there is a learning curve that the data center the… So we’ll talk about the devs side and the ops side. We’ll start with the ops side. One of the challenges on the ops side is that, I hate to put it this way, but oftentimes you’ll find older people on the operation side of the house, and that means they are slower to change, especially when they have spent so much time building out a data center structure that is stabilized. Now we’re being asked to make drastic updates to the way we are managing software in the future. So in my experience working with companies, I see a cultural shift that the operation side of the house need to address in order to get on board with this new architecture. I tell them all the time, the reasons why you want to go to this new type of architecture is because your entire career has been focused on building out a data center that is both fault tolerant and highly scalable.

Fault tolerance is something that if you’ve been in software for the last five years it’s always a discussion. How do you keep your environment always running? There are two really big reasons for the op side of the house to want to learn this new platform, but it’s also a big change. And just like we saw from the mainframe to the distributed side, a lot of those mainframe ops people decided to retire and not take on that new distributed networking platform. Some did and some came along. So I think on the ops side, that’s the bigger… That’s a big challenge. There’s some cultural stuff that has to happen on the ops side. Again, I tell people, think about what you’ve tried to do your entire life. This is going to allow you to do it and then retire. Achieve fault tolerance and high scalability and then you can say you’ve done your job because that’s what we’ve always wanted.

Jayne Groll:

In the early days of DevOps, ops folks were hearing terms like no ops, which was not intended to be disrespectful, but I hear no ops and I hear no job. Right? And so digging your heels in, whether you’re the organization or the operator to say, “Wait a minute. No way.” Right? It became a little bit of that stubbornness so some of it may be human, right? I have to unlearn before I can relearn. Some of it may be organizationally, “Wow, what a hassle.” We do what we do, and we do it well, and I’ll just put a blinder on to what’s happening in the rest of the market. I think hopefully those blinders are coming off and I think hopefully some of the folks that realize that making this transition is good for them intellectually, and professionally, as well as organizationally. We’re moving the word no ops to new ops. Thanks to my friend Thanks to my friend Andi Mann, who’s really been carrying the term forward so that we’re not looking at no job, no respect.

Tracy Ragan:

Yes, exactly. Then there’s a level of just being tired too. I mean these professionals on the ops side have gone through so many different iterations to be quite honest. They’ve just gotten people moved over to the cloud and now they’re going to build another layer on it. So if you’re at an enterprise, if you’re working for a large enterprise like a bank, or an insurance company, or even a retail, and you’re being asked to make these shifts, we’re talking about long days and a lot of hard work.

Jayne Groll:

Yeah.

Tracy Ragan:

And I understand, they’ve gone through so many of these shifts and I think that’s one of the reasons why in terms of the cultural changes we’re seeing that we’re hearing the term called site reliability engineer, because the site reliability engineer is a person who sits between who really is… Most of the time they live on the dev side of the house and they work with the operation side of the house.

So it appears that there are more and more development teams that are starting to have their own operations person that can do some of that a heavy work and make sure that the site stays stable. Now that’s not to say the operations is going to go away, but I feel like that is a really good cultural shift to have that person define working on each team.

Jayne Groll:

Absolutely. And cyber liability engineering is a little bit of a passion area for me coming from operations. Also coming from IT service management, because I think SRE represents a new approach to managing changes, managing incidents, managing service levels, and above. We’ll have to do another podcast about that. But speaking of development teams, so you said that it represents for the ops and for dev. So what about that?

Tracy Ragan:

So developers are going through a really… They’re really having a get down to your soul moment here with microservices, because they are never… They don’t have to be faced with big shifts often. Software’s always been built in a pretty similar way. You write code, you have a version control tool, whether it be on the mainframe, or in Unix, or it doesn’t matter. It’s pretty much the same. You check out your code and when you check out your code, you identify what versions of the code you want to check out. You make hardcore decisions about how to link the source code together with external libraries using library management solutions and you create your binary. Your binary is then like a diamond. It’s protected. You carefully move it across your dev test and prod states, with containers, if you were able to put your entire application into a container, you didn’t have to worry even about what version of the operating system, that was already handled for you. So it got simple With cloud, it really did, and containers.

But when you talk about microservices, it changes the way we write software. We go from pieces of code that are literally thousands of lines long. Where we have branching and merging as our big discussion and which version to check out to compile, that problem goes away because you have small pieces of code that are maybe a 100 to 300 lines long. I always say think functions. I don’t know how many people will be too worried about branching and merging on a piece of code that’s at most 300 lines long. It may happen, but it’s not going to happen often. When you build it, you don’t compile on Linkit, you basically create a container image, right? And you register your container image and that’s your build. So the configuration management that we used to do around compiling versioning code, and compiling code, and making these very distinct decisions about what source code we’re going to use and how are we going to link it, that goes away, which changes the way we think about how we write software.

And where that all happens is at run time, because what you’re… And the concept of an application goes away too. You’re not writing an application, an application is something that is a collection of microservices that’s running in production-

Jayne Groll:

Right.

Tracy Ragan:

Or in test or in dev. So the application doesn’t really even exist anymore. Now you might have application teams that take advantage of external microservices, and then they write their own microservices, and they may manage those in a single repository, and they may release them all at the same time, but those microservices are going to use shared microservices. That’s when we start changing the way we do business. You really have to wrap your head around it and have one of those moments that you say to yourself, “Oh, okay, I have to start thinking differently.” In the same way as the operation side of the house has to start thinking differently, the dev team has to start thinking differently as well, because the pipeline looks different in a microservice architecture than it does a monolithic where everything’s compiled and linked way at the early state of the devs dev side. And a developer runs it and makes sure it actually executes before he even sends it out to somebody who’s doing some level of unit testing sitting at the desk next to him. That goes away.

Jayne Groll:

Well, right, exactly. I think you know that we’re starting to coin the term hybrid human, right. So the hybrid DevOps human, particularly as the developer not only needs to write the code, and they have to test the code, and they have to build the code, test the code, secure the code, potentially release the code, and maybe even operate the code. Right? So it takes the skillset or the skills portfolio.

Last year we talked a lot about T-shaped. So that a test-driven developer is the beginning of T-shape, where their core competency is the ability to write code, but they need to know enough about testing or they need to know enough about security. When we start to look at how all of this plays into this future, this microservice future, looking at the ability to operate within containers, being able to write smaller pieces of code where you may not necessarily see the big picture as much as you used to, but from a business perspective also not waiting three years for the next release really changes the dynamic, not only of the cadence of software to delivery, I think it changes the cadence of society at some point. Right? Cadence of-

Tracy Ragan:

It’s going to require a shift in how developers perceive their code. Collaboration is going to be essential in this new architecture. You’re not going to be able to just be worried about, and focused on your own build, and that’s it. It’s a huge shift for developers. It’s a bigger shift for developers I think than the operation side of the house. The operation side of the house, they really just have to say, “Okay, we’re going to do one more big lift and do one more big migration from a purely cloud. We’re going to start learning Kubernetes, understand how to run it, start managing containers.” They’ve done that so many… They’ve had to shift so many times they’ve got this figured out. On the developer side, this is new. This is a very new way of writing software. It’s far different from anything.

I mean people used to say writing code on the mainframe was different than writing C code. It’s not, all of the structure is still the same. You still have a version control. You still compile your code, you still have a link step. You still have to push it out. You manage the whole application and developers are very protective of those builds and how the those builds are put together. They’re even protective of their repositories. I mean, we did a class with a GitHub and they were trying to encourage more collaboration. It’s one of their prime messages to their user base is to be more collaborative. They talked about how hard it was to get people convinced to open up their repositories to other developers, even within the same organization, because they want to keep it, they want to hold onto it, they’re going to have to let go. That’s a big change. That’s why I say it’s such a harder… It’s going to be a harder shift.

Now the good news is a lot of these developers are coming out of school, they’re super excited about it and that’s what kind of lifts it, but it is a shift.

Jayne Groll:

And they don’t have to unlearn. It’s funny, the DevOps Institute’s Upskilling the Enterprise DevOps Skills Report is publishing on March 10th, and so for the second year in a row, we look at what used to be called soft skills, we now call them human skills, and collaboration, 2019, 2020 keeps growing, and growing, and growing. I think people don’t understand what the term collaboration actually means. It isn’t just we sit side by side, or I share my code, or I open my repository to you. There is a certain level of trust that’s associated with it. I ask your opinion, I ask for your review. I ask that… I respect the fact that you may be as smart as me even though we don’t necessarily do things exactly the same way. There’s a whole dynamic around human skills right now that I think when we see the results of the data that we collected and certainly indicators in the market that, that’s something we’re going to see a lot of as well.

So let’s wrap up and talking about the business case. So what is the business get from all of this move to the cloud, and decoupling their architectures into microservices, and starting to look at containers, and of course, orchestrating through Kubernetes. What’s the bottom line on that?

Tracy Ragan:

It is essential for modern software, AI, machine learning. It’s essential. The best way I can describe this, the first time I ever saw a… This is not running under Kubernetes, but it was containerized running in AWS. It was for a company here in Santa Fe and they work with a handful of pharmaceutical companies on patents. And they need to be able to search a massive database of molecular structures basically to see if somebody had patented that structure, say aspirin, and they talked about how hard it was to be able to do that in any period of time, because it took so long to go through and do all the pattern matching with a handful of servers. Well, they showed a demo that they started out with I think around 14 or 15 GPUs, graphical processing unit. Think of that like a server. It’s a container.

So they had these GPUs running and when it went to go do then pattern matching, they spun up to around 14,000, in an instant, in an instant.

Jayne Groll:

Wow.

Tracy Ragan:

And they were able to make the match. Now, if you think about some of the new stuff that we’re hearing about. I think geographical maps, the mapping software and being able to say, over time, we know that this area is going to have a flooding issue, or these farmers, we can tell them that they’re over watering in certain sections, because we’re able to do massive pattern matching and to do these comparisons to have intelligence. Anything that we do in AI requires a lot more processing power than a handful of servers can bring us. So these types of applications are going to be… They’re available to us now because of the ability to be able to build out a highly scalable application that can scale in seconds, not, I’m going to scale this out in 10 days. It’s scaled immediately. That is the primary driver of this architecture.

Now, you may not be writing ML or AI applications, but you may be having problems just handling Christmas time, for example.

Jayne Groll:

Right.

Tracy Ragan:

And instead of having a warehouse of physical servers that says you got to be here because six weeks out of the year we use you. That is a bean counters dream to be able to get rid of that and say, Hey, we can use microservices, and Kubernetes, and containers, and solve this problem. We don’t have to have all of this software, all of this hardware, and all of this expense just because we need to be able to maximize in six weeks during the end of the year. Same sort of problem, except one of them, they sort of limped along and they had these big, literally these big data centers, that said we have all these extra servers so we can scale when we need to, but you know, Kubernetes, and microservices, and containers solves all that.

Jayne Groll:

And none of those servers is like the other, right? So the variance, when you start to look at managing large clusters of servers, the concept of a snowflake.

Tracy Ragan:

Yeah.

Jayne Groll:

So there’s lots of support, as you mentioned, Kubernetes is open source. It’s managed by CNCF. Tell us a little bit about DeployHub?

Tracy Ragan:

DeployHub is a… We’re laser focused on this microservice problem and we’re focused on the problem that I described around when developers no longer have a compile and link process. So DeployHub is an inventory management and configuration management solution for microservice deployments. We track all of the deployment data related to a single microservice so anyone can find it and reuse it. We provide that collaboration platform with what we call domains. So you can publish your microservice in a domain and when somebody goes to use it, it’s already got all of the information needed to actually do the deployment. The helm chart, the SHAW number, the Git Commit that created it, all the way down to… We already know it’s running in the cluster, all you have to do is use it.

Jayne Groll:

And do you help provide guidance on taking a microservice approach?

Tracy Ragan:

On the domain side, we do. So if you start studying anything about microservices and building out an architecture, one of the first things that you start learning about is something called the domain driven design. This is not new to microservices. It is a topic that came up during object oriented programming and has had discussions in the past, but microservices make it essential because what you have to do with your microservices is to create patterns. Those patterns are based on what’s often called the problem space. So you have security and you have… These are microservice that would fit into that problem space and they have particular patterns to them. That is what a modern application really looks like. It is a set of microservices that are… The application itself is a logical view because it’s a collection of these microservices that are being reused. So when you go… In our old world, I kind of, I like to use the analogy of a junk drawer.

Jayne Groll:

Which we are.

Tracy Ragan:

You know, every house has one. I’ve never been in one that doesn’t. And oftentimes in our old monolithic way, we had one really smart person who put the application together. They knew how to open up the junk drawer and organize it so that it could be used, and it could be compiled, and it could be linked, and it could be pushed out to the end users. You can’t do that with a microservice. You can’t just throw everything into one repository and assume somebody’s going to know what it is. So a domain driven design is going to be critical as companies begin this collaboration shift that we’ve been talking about, so that you can find and share these functions. And DeployHub has a domain structure to help with that cultural shift.

Jayne Groll:

And if somebody listening wanted to get in touch with DeployHub, how would they do that? Obviously go to the website, but what’s your Twitter? Is there any other contact information you want to share?

Tracy Ragan:

Yeah, @DeployHubProj is our Twitter handle and we post quite a bit of information about anything we’re learning about microservices, any new information that we get, any case studies that I might see on somebody else’s Twitter feed. I try to share as much of that educational information as possible. Going to DeployHub.com you’re going to find quite a bit of information about just the general problem set. There’s two good white papers out there. There’s one that’s on the problem set around versioning. Versioning microservices and what you need to version of a microservice because you’re not going to do that in your regular GitHub sort of repository. And there’s another one on how the pipeline changes and those can be found from the DeployHub front page.

Jayne Groll:

Awesome. Thank you. Well Tracy, thank you. You know the title of today’s podcast is Clarifying Kubernetes, but I think you went above and beyond and helped us all understand not only Kubernetes, but the value of moving into a microservice architecture. Certainly understanding a lot more about containers. I certainly learned, and I didn’t know this before, that big Fat applications can be squeezed into containers as well. So I come away with some new knowledge myself. So thank you for that. And as always, thank you for supporting the Humans of DevOps. The DevOps mission is to advance the human elements of DevOps and it’s talking to thought leaders like you that really help bring that to light. So I appreciate it. So again, welcome to the Humans of DevOps podcast. We’ve been spending some time with Tracy Reagan of DeployHub, also one of the leaders of the continuous delivery foundation. Thanks again, Tracy.

Tracy Ragan:

You’re welcome. It was my pleasure.

Jayne Groll:

All right, and stay tuned more episodes of the Humans of DevOps podcast will be coming up in the next several weeks.

Outro:

Thanks for listening to this episode of the Humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember you are part of something bigger than yourself. You belong.