Stark & Wayne
  • by James Hunt

In this, our first real episode of the Rent, Buy, Build Cloud-Native podcast, James and Brian discuss Docker, containerization, and what options are available under SaaS, licensed, and DIY models for container execution and container runtimes.

Episode Transcript

James Hunt
You're listening to Rent, Buy, Build, the cloud based podcast where we talk about all the bits and pieces of cloud platforms and discuss whether you should rent them, buy them, or build them yourself. I'm your co-host, James Hunt. I'm the Director of Research and Development here at Stark & Wayne.
Brian Seguin
I'm Brian Seguin. And I'm the COO of Stark & Wayne, at any point, I may choose to fire James over what he says on this podcast. So that is a disclaimer.
James Hunt
Yeah, today we're gonna talk about Docker, and to a larger extent containerization. So it's in the news everywhere, you can't, you can't turn around on a tech site without turning into running into something, container or container related. But I wanted to do a real quick technical history.We're going to start back in the 70s at the beginning of time, and move all the way forward to 2020 and 2021. So we'll start with mainframes, Unix system 7 actually, back in the '70s. Were the I think Unix was it was '79, I believe Unix was about 10 years old. And this is original Unix, right? We're not talking Linux, or Solaris or any of that stuff. Originally, Unix added the chroot system call, which was designed to allow system operators to change the root filesystem of a single process. So this is novel because computer operating system kernels exist to broker access to shared resources. That's why we have them things like disks, network, process space user definitions, users and groups. And what terete did is it said, Let's take one of the processes on a big Unix box. And let's make it make sure that it can't see any of the other files, domain sockets or anything on the same host, we're basically will isolate this process kind of off in its own, they called them chroot jails. And the reason for that was because hardware is expensive. And the the Unix process model makes it possible to co locate lots of stuff. When I was at the web startup way back web hosting started back in the late 90s, early aughts. We had one Dell 6430 it was a huge 8U server that we we actually used it in the office to keep warm in the winters. We we put everything on that thing. We put our email we put our web hosting, and the only way it worked is because we were able to to route things. And I'm going a bit long winded James,
Brian Seguin
I'm confused. So yeah, you're talking about a technology from 1979. Is that correct? Correct. So we're talking about this mainframe technology and these chroot jails with sounds like something that sounds scary. But so you're saying that this is actually the first form of containerization back in '79.
James Hunt
The first form we'd be familiar with - mainframes themselves AS400s, z-series, they've always had some form of process virtualization to where you would be able to allocate one of the core processors in a mainframe to this one batch job. But those in general are so foreign to modern audiences, I don't usually talk about them much. Really Tarun is where we start to see the micro microkernel, the Unix kernel being used to co locate lots of workloads together without the workloads being aware of each other.
Brian Seguin
So the concept of containerization is actually been around for over 40 years. Wow.
James Hunt
It's actually quite old. The problems with chroot is that the if you if you consider that an OS kernel brokers access to disks, devices, file systems, network, and user information and process information, six things cheroot only really addresses one and a half of those. When you're a true routed process on a Unix Linux box, you can still see all the other processes, but you can't see all the files that they can see. And that was the primary concern. So the canonical use case for chroot is bind named D, which is a name server that if it gets popped remotely, if someone breaks in to the chroot, jail, the the true root itself is designed to limit the blast radius, right. But it was a security primitive, designed to keep your name server from being compromised and causing the database server to lose data. So isolating off that file system.
Brian Seguin
Another way to kind of reword this and way oversimplify it you're you're you're creating blocks of code and associating specific hardware to these blocks of code in an effort to not have the code burst and bleed into other code that's running.
James Hunt
right but primarily from a security aspect, but the main problem that true jails have was there was no way to there were no primitives to build these chroot jails, you had to build up the file system yourself. If you needed a device inside the chroot namespace you had to build it yourself as an operator. And they were very hard to get right. But there's a lot of history across the early aughts of processes escaping their chroot jails and then continuing to wreak havoc across the rest of the server.
Brian Seguin
So it's not more about when you say security, it's not more about hackers actually infiltrating these things, because I don't think that happened a lot in the 80s. But I could be wrong. It's more about them just running over other processes--
James Hunt
Oh, no, it's 100%. About the remote security posture.
Brian Seguin
It was a thing in the '80s. Yes. So Wow, this is awesome.
James Hunt
As soon as we connected computers to one another, we had the Morris worm, right in the early '80s. That went around through telnet and and just spread through the early ARPANET like crazy. Um, but yeah, so chroot hits the scene. It gives us some security purposes, but that's about it. Right in, in a was it in 2000. So fast forward about 15-20 years. The BSD folks, the Berkeley systems distribution team. They have a Unix like operating system that actually came out of AT&T giving their code off to the Berkeley University. And in 2000, the BSD kernel team implemented a stronger process isolation and containment system that they called jails. And each jail would corral a set of processes along with all of the resources that the kernel was managing. So you couldn't actually tell if you were inside of a jail, you couldn't easily tell that you were being contained. You couldn't see other processes that were running on the same hardware. You couldn't see other file systems, you had your own IP address. Right? Everything was virtualized, but on a single host.
Brian Seguin
So where does Stockholm Syndrome come into this? Because you're saying that you can't you're not aware that you're in jail here.
James Hunt
It's a lot like the matrix right? a prison for your mind that you cannot see smell or taste. Okay. And BSD jails. Honestly, if BSD had taken a foothold in cloud computing, in a much we'd be in a much different world now because jails were eight years ahead of the Linux teams on on a process isolation. So in 2008, we see the public release of LXC, the Linux containers project, and that really kicks off modern containerization in the cloud world that we inhabit. Docker is not possible without Aleksey container-d, CRI-O, Kubernetes, Nomad, Mesos, OpenShift. All of these technologies owe their very existence to this project being done. And LXC was, "hey, jails are neat. Let's do that in Linux." And let's take all the other resources that the kernel manages, and let's isolate those as well. in between there, you actually see there's a company called Virtuozzo, that they provided the same things as Linux containers, but it was proprietary. LXC is really the open source, open sourcing of that technology. Fast forward about six years, about 2014 Docker hits the scene, a momentous and historic occasion that most tech people didn't pay that much attention to. And what Docker did is they made LXC easy because even-- so LXC still gives you all the security and containerization and everything, but critically lacks the "image" concept, right. And when we talk about containers, we always talk about containers, and images. And I think a lot of times people conflate those two terms. But a container is an execution, something actually running and doing things usefully on a CPU and putting stuff in memory. And speaking out across the network. An image is all of the bits and pieces that make that happen.
Brian Seguin
So Docker is combining the concept of an image plus, plus an actual container.
James Hunt
Right. So LXC had images and called them templates.
Brian Seguin
But when most people are actually talking about Docker containers, they're actually oversimplifying what it's doing.
James Hunt
Right, and it's a useful oversimplification, right. It's an abstraction that makes it much easier to talk about the things we're now able to do. What Docker did that made life easier, better and 1000 times more capable was the introduction of the Dockerfile, the Dockerfile being that ubiquitous, usually less than 30 line recipe that says: start with Ubuntu, run these commands, create this user, put this code in there and BOOM, call it myapp:latest what the Dockerfile and the Docker build process did was make it so that not only can we run the containers, but we can build an asset that other people can use to run the containers without all the knowledge that we as the builders have. And that's the key distinction. That's what unlocks the power of containerization in the modern world, and it starts with Docker. So, when we talk about why it's important, why is everybody -- why are all these devs, and all these engineers and all these architects -- why are they so enamored with containerization? The answer is that it comes to an abstraction. Right? There's an image out there that I use on an almost every deployment of anything I build. It's the nginx image. nginx is a web server that we use all over the place for things like serving up static files, proxying to dynamic application server back ends. And nginx is a fairly straightforward proposition. Right? If someone says, "hey, let's throw an nginx proxy in front of the thing we're building", it's usually not a controversial architectural decision. And it's not hard to pull down the software, right, the config file and go, right. But there's an image out there on DockerHub, the nginx image already does all that. And all you have to do is supply your specific configuration, which means as an architect or as an application owner, designer, developer, implementer, all I have to do is know that I'm using nginx, and provide my little piece of the pie, and the rest of the configuration is there. And that is intensely freeing. And it means I don't have to get mired down in one or two Sprint's of figuring out how to get the proxying to work. And that's why you see so much press and so much ink about containerization and Kubernetes and other things. Because from a business perspective, it allows the reuse of other people's components at a higher level.
Brian Seguin
So if I'm gonna summarize my understanding, you know, back in the late '70s, early '80s, containerization, was just to keep code isolated and processes isolated for security purposes. But it evolved into a need for a repeatability and a common install, right, where you're actually taking this checklist of, of scripts. And you're you're doing it to say, Hey, we need to repeat this process. So we're talking apples to apples in every single container situation in this kind of, is that the the picture of like the modern containers is that?
James Hunt
Yeah, very much so. And it's, I think it's more than the need for packaging has always been there. But I think Docker by building out the Dockerfile, and I don't know, if they knew what they were doing when they built it. I don't know if they knew the impact it would have on the overall ecosystem. But the need for packaging, a good solid orthogonal packaging system has always been there. And Docker finally gave us the thing that would work everywhere, you could run Docker.
Brian Seguin
So now the modern container has all of modern containers, I would assume would have isolation and repeatability just coming standard with them. So anytime that we're talking about containers from here on out, it's going to include those two concepts.
James Hunt
Yep, yeah, and OCI image format, a registry to put the assets in for distribution and a runtime for executing them. That is the basis of every container orchestration system under the sun. Okay. So if we want to talk about the build, rent, buy aspects, I think that that comes down to because you're building or you're creating your own container images, the build / rent / buy is more about where they run. So from a rent perspective, if you're, you're trying to utilize a SaaS offering, or you don't want to be bothered with running the the orchestration layer, or any of that, you're looking at things like Lambda, Google Cloud run, or FaaS.
Brian Seguin
So that's something that's that that basically containerize it for you and just throws it out there is that you bring the containers, and they run the containers, but you don't have to the whole iceberg of everything under the container is handled for you by the SaaS offering.
James Hunt
So if I want to say I build a really cool application, as a set of three containers, a database container, an application container and a web thing, in nginx, or Apache or something, I can take those three images, and I can give them to Google Cloud run and tell Google Cloud run, here's how I want all these things to interact. And they'll take care of finding a CPU and disks to run those on. So I don't have to buy hardware, lease hardware or rent hardware.
Brian Seguin
So my my developers, though, I'm assuming there's got to be some form of restrictions as far as they can only code in this particular manner for these systems, because because I would assume they would just limit what you can actually do. As far as--
James Hunt
Right - as you move up stack. There are there are limits because the stack implementers make decisions for you that you're then held to and that's why we get down the rest of the The rest of the spectrum of build / rent / buy, right? Yeah. Rent / buy / build is really about freedom and obligation, right. But the rent side of Cloud Run of Lambda is if you play by the rules of the provider, you're freed up from having to do a whole bunch of stuff, you have no obligation, but you trade the freedom of flexibility. And oftentimes, that's fine. So if you focus on your app concepts, and not any of the infrastructure, Cloud Run Fargate, Lambda, these are all really good platforms for you.
Brian Seguin
So I mean, if I have a bunch of go, Java, or .NET developers in my organization, and I say, hey, let's just go do this lambda thing. What's the learning curve? for them? I mean, are they going to be able to just pick this up and say, Hey, I can read deploy my code here?
James Hunt
Fairly steep. Given that a lot of a lot of traditional non container development doesn't take into account a lot of things you have to do as a container. In the Cloud Foundry world, we have the 12 -factor app, as the gold standard for how to design an application. And one of those factors is that you don't control you don't contain any state. If you're a Java developer, or PHP, Ruby, Perl, Python, whatever developer, you've probably, at some point in your career, built a project that relied on the file system, for caching purposes, for work, scratch space, something, those are the kinds of things that have to be walked back when you move into a containerization strategy.
Brian Seguin
So if I don't already have existing team members that that know this or I'm not looking, I probably actually have to hire one, if I'm looking to to utilize this type of solution.
James Hunt
If you're trying to rent, yeah, you probably need somebody with some experience with Lambda and all the different pieces and parts are how Cloud Run does the scale to zero and all that stuff. And
Brian Seguin
if that's not how we do it today, it's probably better to choose another path.
James Hunt
Sure, containerization isn't for everybody, there are good-- there are some success stories of people doing lift and shift with existing stuff just being containerized. I like to say that when people say, "containers will solve this problem". If you've replaced the word containers with "processes lugging around a file system", and it's still true, then you are correct. Right? So if someone says to you, hey, containers will solve our delivery problem? Probably not. Right containers aren't going to solve how things get deployed, because they are just a process with a file system. Containers will solve repeatability and deployments. Yes. Because the two things that change the code that runs and the environmental file system in which it operates are coming with the container. So you have that repeatability. Okay,
Brian Seguin
so let's talk about buying. I mean, what, what kind of options are out there for buying something that exists or getting a license of something that exists out there?
James Hunt
The best case for buy is probably a managed Kubernetes. Unless we're considering that or rent. That's it. That's a good question.
Brian Seguin
So it seems like the in the in the containerization space in the container. So I think we're seguing into containerization runtimes. Right. So there's a difference here between the actual container itself, which is a, you know, a Docker image, or like, Are there different flavors of Docker image? I mean, maybe that's not the realization.
James Hunt
That's one of the great things about the OCI spec. Right. The open containers initiative, sat down and said, Look, we're about to have a massive explosion of people interested in containers, we really don't want lots of competing standards on how to ship these reproducible things. Just like the namesake in shipping, traditional shipping right on boats across oceans. The A1 container format is heavily standardized and heavily spec'd so that different shippers and shipping equipment manufacturers can all build systems that work together. OCI is that spec, which means if you're talking the conversion of an application and its processing configuration into something that can be deployed on a container orchestration platform, OCI is the only game in town, which is really good for the ecosystem.
Brian Seguin
Okay, so then the discussion is not about which containerization tool to use, it's which, which tool do I use to run my containers.
James Hunt
Right, execution is where you're gonna see the value spectrum manifest itself, you're gonna see the, the much -- the no obligation, no freedom, angle on the rent side with cloud run, and FaaS and all those things where you have to do things the way the platform wants you to do them. But you don't have to run or own the platform. If it takes an outage. Your vendor handles it all the way to the other end of the spectrum where you can have complete control over how containers execute and what security primitives they have. Access to and all that, but you're building the VMs, you're making the container runtimes work, you're keeping them updated and patched and running and happy. And you have on call staff and all that the freedom to make the changes to the overall architecture comes with the obligation to support that architecture yourself. And then somewhere in the middle, in what we're calling the buy, right, where you're buying, you use the house analogy, the homeownership analogy, or the the rent is an apartment where you don't get to make any changes build is here's the plot of land and a bunch of 2x4s, go make whatever crazy house you want. The buy is really, we're talking orchestration systems that are available today. Kubernetes, mesosphere, Nomad, openshift; those are all you give up a little bit of freedom, because you know, you're constrained to the primitives that they provide, right? You're doing in Kubernetes, you're doing deployments and services and pods. In Nomad, you're doing other things like you have constraints on what you can build. But you don't have to write the code and fix the code. And that's the key point, you don't have to fix the Kubelet software, when it has a bug, there's a larger community of people maintaining and testing and inventing and fixing and proving that code base on your behalf. Right. So that's why I say the managed or the buy is, is either a managed case, which kind of gets into the rent, or a Kubernetes, you run on your own, like a Rancher or an OpenShift platform. And then the build is kind of off in left field with container execution. Because I don't know of too many people who look at the current array of the smorgasbord of orchestration runtimes and go, those are all nice, but I'm gonna go build my own because I have millions of dollars in r&d budget, and nothing to do with it. So I don't see a ton of people doing but we have had, I have worked with companies that have strikingly different models of how they want their developers to understand the underlying execution, I worked with one company that they built their own containerization orchestration platform on top of another one, make sure that's clear. They didn't they didn't go from, you know, silicon on up. Thanks. Yeah, I mean, with a runC.
Brian Seguin
In theory, you can, you can take these different components that are out there from Kubernetes, the open source version, deconstruct them and customize it into a different way that suits your needs.
James Hunt
Right, now you can you can take containerd, and I have a fun little pet project where I'm trying to do-- to bridge the gap between Docker compose and Kubernetes with a little bit more of fleet recognition. And in doing so I'm using containerd, because I don't want to build a runtime. But I want to control how the container execution takes place. So there's a little bit of customization that I would put firmly in the build camp, but I don't see a lot of, of successful businesses doing their own low level stuff in the same way, that means writing their own operating systems anymore. And
Brian Seguin
unless they're, they're only in business to make software and to resell this operations, orchestration layer to customers, like, like a like a VMware, or, you know, an IBM, they might not actually be deconstructing Kubernetes to read his region, actually, even. Even IBM doesn't actually reconstruct Kubernetes. Right,
James Hunt
Right. I mean, and they have enough budget if they wanted to, they could write the analogy with no one writes their own operating system is actually pretty apt, because it's the last, quote unquote, custom operating system I've seen that made any real headway in adoption was illumos, which was a Solaris fork by the Joyent folks. And the reason they did it is the same reason that CoreOS went out and built their own Linux distribution, because they were building a larger product that depended on having their own operating system. Like you said, it was a core competency of theirs to deliver that. And most businesses are not selling containerization to their customers, they're selling self service web applications for financial transactions, or they're, they're selling the next great social media network or the next Yelp or whatever, and they don't care what's underneath. And that's where you get into the rent versus buy.
Brian Seguin
So I guess in the build space here, there's not many options for most companies to do a build but if they want to do a bi space, right, they're probably starting with some form of a foundation whether it be Docker swarm, Kubernetes, or some other container runtime. But most cases these companies are actually buying a a already prefab home right? a prefab framework, whether it's a home or apartment complex depending on what their sizing needs are right? And or off or a skyscraper right like, because I think there are container runtimes out there that are designed to be a skyscraper today. have massive amounts of capacity, right? I think Cloud Foundry is probably one of the most right? Well, well known ones that has massive amounts of workload capacity. But I think from this space, you're really talking about buy, unless you're a very small company, and all you really want to do is just consume very specific use cases, and you have the knowledge and, and wherewithal to, to go to a solution like lambda, or even even some of those managed Kubernetes distributions where you're just consuming their their platform. But you still have some operations to do in that space. So I think those are the your two options really for rent. But I think most organizations are kind of going into that bi space where they're finding the distribution. And they're saying, okay, because out of the box, most of these distributions are solving problems, you're going to need solved anyway. And you don't want to actually recreate that inside of your own organization, unless you have a, I don't know, 30 person operations team, right?
James Hunt
Right. And even if you have a 30 person ops team, right, the obligation to then support the thing you've built is not a small thing. It's not a trifle. It's definitely something to put a lot of thought and a lot of math behind. Is this really worth doing. So
Brian Seguin
then it really comes down to which distribution of container runtime is best for my organization. Unless you just want to manually run all the containers yourself, which does exist out there, right? Like,
James Hunt
yeah, there are so
James Hunt
like, I personally, I run a fair number of infrastructure is on top of Docker Compose, because it gets me most of the way to what I need on the repeatability space, without having to worry about storage providers and overlay networks and all the complexity of a clustered dynamic runtime. But I want to go back to what you said about the the suitability of rent. And and I think there's actually a couple of, of large scale personas of larger than a single company personas that benefit from that rent of either Lambda, or Cloud Run, or in the rent space, it's usually called scale to zero. Because you're not running the platform, right, you're on a, you're on a platform with everybody else. Ultimately, like Google Cloud run, you're on Google's servers, and Lambda, you're on AWS' machines, and you're not paying for those machines, you're paying for your usage of those machines, which means that the overall platform can scale your stuff down to zero. And that's important. Because if I go out today, and I say, look, I need a five node 40 gig linode Kubernetes engine, that's going to run me $200 a month, whether I use it or not. If I do zero transactions in the month, I paid 200 bucks. If I -- you know -- if I run a million transactions through whatever app is on there, I still pay 200 a month. If your usage is bursty, you're usually better off in a rent situation, because you're leveraging the fact that the provider has massive resources that you don't have to pay for until you go to use them.
Brian Seguin
I mean, granted, granted, if your actual business logic code can be re factored in a way that equal 100 to those standards. And I think--
James Hunt
You have to build it to FaaS. I mean, that's a very important distinction.
Brian Seguin
I mean, FaaS has been such a massive buzzword in today's day and age because like, Oh, it's even use it. It's even using less of the cloud, because you're going to turn it off. But I think it really is only 1% of what most business logic code.
James Hunt
Yes.
Brian Seguin
Unless you're running batch, even if you're running batch processes that that run once a day, you still have to code it in the right way, you still have some refactoring and work to do and you might not actually have the team that has a skill set to do it.
James Hunt
And it's important to remember that human hours are much more expensive than three cents an hour of compute execution time.
Brian Seguin
Right.
James Hunt
So. But yeah, that's that's kind of it with with containers and containers being the touchstone or at least the the cornerstone of most of the rest of the stuff we're going to talk about on this podcast. We have a lot of stuff to cover in the coming months, from Kubernetes to apparently FaaS, that'll be fun. We'll get some, some FaaS offerings in and talk about what you know what you actually need to do to build a FaaS offering what it looks like from a lift and shift, migration standpoint, all that fun stuff. So yeah, join us next time and we'll probably be talking about Kubernetes in more detail.
James Hunt
You can find all episodes of rent buy build online at https://rbb.starkandwayne.com, or wherever podcasts are sold.
Find more great articles with similar tags rent-buy-build containers kubernetes