Dockercon 17 in review - The CTO Advisor Podcast 50

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, so I think we're listening to the big five-volt, episode 50 of the CTO Advisor podcast. I decided to brand podcast at the end of that because there's the CTO Advisor, which is me, and then there's the podcast. Plus, you'll see, especially as Dell EMC World comes up in the next couple of weeks, we're expanding the cast of the CTO Advisor. In the past, we've had Cincy Storch, better known as Mark, on the podcast before as a co-host, but he is accepted the full-time paid, well, actually, I gotta correct that, it's not paid, non-paid role of co-host of the CTO Advisor.

Hey, Mark, go ahead and introduce yourself. Hey, I just wanna know if I can get paid. No. I'm Mark, you can find me on the Twitters at cincystorage, at virtualstoragezone. I'm an infrastructure guy, been doing this for as long as I can remember. I like to talk about stuff and hang out and educate and learn and see where the conversation takes us. All right, so we'll be throwing Mark right into the fire at Dell EMC World. We're gonna try and get in a bunch of interviews, but I'm doing theCube most of the day, all three days of the show, so he'll probably be solo on most of the interviews coming out of Dell EMC World.

So enough of the kind of housekeeping, let's bring on a very popular guest that was on back in his IBM days, which seemed like way yesteryear, only been like six weeks, Tyler Britton. Tyler, reintroduce yourself in your new role. Hey, Keith, yeah, it's good to be back on, I mean, I'm just hearing about this, there's a paid gig here and I would have been putting my name in the hat too if I knew there was money involved. Again, there's no money involved.

Yeah, so yeah, my name's Tyler Britton, I currently work at Red Hat on the OpenShift team doing technical marketing. So real quick, we've heard Open a lot from Red Hat, there's all kinds of, they had this OpenStack thing that they were doing for a while, and well, then they're still doing. What is OpenShift? Sure, so Red Hat, as you mentioned, has the OpenStack thing that's still chugging along, more and more new people coming to it every day. And OpenShift has been around for a while with Red Hat as its platform as a service, and has continued to kind of reinvent itself as a container platform.

It's actually called OCP, the OpenShift Container Platform. It's based on Kubernetes and Docker. So it's really popular right now for a couple reasons. One, because all things Kubernetes and Docker is really popular in the market. And then on top of it, you can still get the kind of PaaS goodies you're used to if you want to automatically package up your code and all that type of stuff. And there's a lot of hooks in it for, I wouldn't call legacy apps, but existing apps, right?

Everything doesn't have to be new from scratch. So I think folks on the podcast can tell why we would want you on this edition of the podcast. Last week was DockerCon 2017. While you're not speaking for Red Hat on this podcast, I think it's relevant for the audience to know that you have quite the, I think, right purview of why containers are important, its role in the enterprise and such. Yeah, yeah, I think DockerCon was interesting for a number of reasons.

And kind of, I would start with what you just said there for the enterprises, right? So I think, and I think plenty of people have this opinion that containers aren't just for the new cloud native-y stuff, right? There's valuable things you can do with containers that may even support persistent data and persistent apps. You know, and existing apps. So there was a big focus on the second day of DockerCon on how do you bring your existing apps into containers? So I think that, they're not the only ones saying that.

Like I say, you know, Red Hat thinks that, a bunch of other companies think that, but there's a big contingent out there that thinks, first, step one, rewrite all your software and then put it in containers. Yeah, so we'll get to that in a few because, and I wanted to tease this out a little bit, the difference between, kind of this pure microservices view that containers first, when containers first hit the market came out. I think famously, or infamously, one of the times that me and you got time to really sit down was, you invited me to a container meetup, out of, I think it was in Seattle, or a microservices meetup in Seattle.

And that was the first time that I kind of really got the end-to-end view of containers, serverless, microservices, and this view that, if you're gonna use containers, there's a way to use containers. I think in DockerCon 2017, we heard something a little bit different message. I had heard these ideas before, but not on the scale that we heard them at DockerCon. So we'll get into that, I think, in a couple of minutes. But before that, I think Mark had a question around OpenStack versus this whole Docker ecosystem that he's burning to ask you.

Well, in listening to some of the keynotes, one thing I noticed was a couple of digs on AWS. And I was really surprised by that. I don't know about you, but I don't see Docker and AWS as competition, but wanted to get your take on that. Yeah, I think it's one of those, which I think we're getting into this industry now, this frenemies or coopetition kind of thing where you compete at certain layers, but work together on others. So as you would think, Docker runs great on AWS, but at certain layers, AWS also has a container service offering.

So those things you're balancing, hey, this is a good place to run. Docker doesn't do IaaS or anything like that. So hey, cool, it's a good place for us to run, but at the same time, hey, we have something that we think is a competitive differentiator against Amazon's own container service. And you see that same thing with Pivotal, with OpenShift, with all sorts of other players, Kubernetes, where it makes sense where you're competing at different layers and then other places where you're a good fit.

Yeah, and I guess OpenStack can be in that same vein. I think maybe it might've been two and a half years ago when I was looking for a job and someone was asking me how would I provide containers as a service in OpenStack? So that idea isn't necessarily new, but I think one of the things that me and you have talked about in the past is for what enterprises need, do most enterprises actually need the overhead of a OpenStack if they just wanna consume containers and build microservices?

Yeah, that's one of those super kind of, and Keith, you've been a consultant before, so you've used it plenty of times, that it depends, right? Right. So there's still the idea of orchestrating bare metal and things like that, and they're playing people that run containers either in VMs, whether it's on VMware or OpenStack, or on AWS on EC2. So the idea, I mean, I think long-term, there'll be a lot of places running containers on bare metal, but you go back to, remember the days of orchestrating bare metal and why you switched to using VMs was, oh, the KVM and the networking and plugging the switch ports and so that's where OpenStack really comes in is it still serves a real strong purpose of giving you an IaaS layer, and then, hey, if you still need containers on top of it, there's a number of ways you can do it, but I think that's kind of the push-pull on, that is the IaaS layer, there's still a need.

So even if you're doing, say, OpenShift or Docker or something on AWS, if you're gonna do it in your own data center, you're probably going to have to figure out some way to orchestrate that bare metal. So before, or at least not before, after the shift to move away a little bit from everyone saying OpenStack is the way to do that, you know, there was, I don't know if there was Docker data center, that's relatively new, and let's talk about that for a little while, this ideal of bare metal and container orchestration.

Help us understand, there's Docker data center, there's Kubernetes, there's Mesosphere, what's the role of these orchestration tools and what's the high-level landscape? So you have to think, and kind of starting at the bottom, when you realize it is the first thing is there's no such thing as a container in Linux. What it is, it's a collection of Linux technologies, one's called cgroups, one's called namespaces, to kind of like how the kernel can organize bits and pieces to kind of do some partitioning. And then basically Docker got really popular by abstracting those into a thing called a container, but it's not like a hypervisor or anything.

So you're still the actual, the actual things that are happening are still the kernel, right? So from that perspective, Docker is more the vCenter than it is the vSphere, from that perspective. There's no exact correlation, but it's more like that. So you start with that layer. So Docker, or now there's Rocket and other container engines and the open container initiative. That's the actual blocking and tackling of the container layer. Well, then that's fine if you're running some containers on your laptop.

If you want to run 10,000, 100,000 containers, you have to network them together, organize them, and that's where the orchestration layers come in. So that's the, Docker has their own called Swarm, Kubernetes, Mesos. There's these other options of ways to manage all those containers at any sort of scale. So those are the, so then there's the, then you take those layers that are open source and then it's what are the commercial offerings from those? So Docker, now they've changed it from data center, Docker Enterprise Edition.

So now they have Community Edition, Enterprise Edition. Enterprise Edition is the, you pay us money and you call us for support and all that type of stuff. That actually helps me out a ton. So Mark, in your day-to-day, where does this fit kind of in the traditional enterprise? Are you guys at your daytime job, are you guys looking at this type of technology beyond lab? We have a little bit deployed actually, and we're moving down the pivotal route right now because we were really looking versus, the buy versus build, right?

We didn't wanna spend our time making something, right? We just wanted to get to the business of consuming it. But at the same time, we're definitely looking at Swarm and Kubernetes and seeing where that fits into our ecosystem and test. So you mentioned, I think, a hot, bad name in Pivotal. Obviously, the Dell EMC family or federation of companies, I don't know what they really call it. I think Dell would call it a family. Yeah, Teleron. This ideal of Pivotal and pre the container hot buzz, there was this Pivotal solution of providing paths.

So where does, I guess this question is for you, Tyler, where does Pivotal fall into the conversation of containers and Docker? So it's tough out there if you're trying to kind of parse all this and figure it out. So Pivotal has their own, they've had their own, what they call elastic runtimes. Their way of, they're similar. Under the covers, Cloud Foundry, not just Pivotal Cloud Foundry, but all the Cloud Foundry projects basically make containers and run containers. So when you do a CF push or code, it builds it up into what it calls a droplet, but it's basically a container image and then it runs it on host.

The main difference is they've had their own engine, but then once Docker got really popular, they started looking to integrate that. So they switched their backend to a thing called Diego, which is a pluggable scheduler. So then now they do support, it gets really complicated now where you say there's these different layers of containers. So there's the container image spec, there's the container engine spec. So a lot of that's being moved into this open container initiative. So there's this thing called Run C.

So they use Run C to run containers, which is Docker compatible. So you can give it a Docker image, but sometimes some of the things don't translate. This is where I think a lot of this stuff is gonna shake out in the next year or two. So probably in the next year, because there's these different overlapping container engines and container orchestrators are slightly different. And if you're a customer, you don't really care. It's an implementation detail. You either want to give it container images or you want to push a code and let the platform figure it out.

And especially if you're paying money for it, like you said, and it's just turnkey, you don't really want to think about these details. So as you saw, like for example, OpenShift used to have its own similar technology and OpenShift 2, when they moved to 3, they dumped it all for Kubernetes and Docker. And you see some of these other tools making, Daze, who just got bought by Microsoft is all Kubernetes and Docker. So I think you're starting to see, and I wouldn't be surprised to see maybe Cloud Foundry start going this direction.

You saw the first bit of it where they kind of released in an add-on to Cloud Foundry, like a sidecar called Kubo. So that way you could run Kubernetes, but still leverage some of the Cloud Foundry kind of platform services. So it's just something that shakes out. Yeah, so I was just, go ahead, Mark. I think the whole PaaS market is getting really complicated. It's almost like we're gonna need a whole new taxonomy just to talk about PaaS. You can't just say PaaS anymore and mean platform as a service.

There's various types of it. And I think that's complicated for the end users and the enterprise. I don't think they understand that. Yeah, I'm thinking, and we'll get to this actually because they made an interesting announcement at DockerCon, which is, you think about SAP and SAP HANA. So SAP didn't make the announcement, but you can consume SAP HANA as a PaaS. I think that's a completely different PaaS than a Cloud Foundry and Pivotal. Those two things, while they're technically PaaS, from a architecture perspective, you're sitting in the enterprise, you're kind of scratching your head.

Then you're thinking, okay, my infrastructure team built me a Kubernetes-based data center that I can consume and build all these microservice-based solutions. But I want to put Cloud Foundry on top of that. How does that, you start to scratch your head, like, okay, I don't see the, to your point, Tyler, that stuff has to shake out. I don't know if there's a consumer for a Pivotal consumer to a Cloud Foundry consumer of Kubernetes. Maybe it is. This stuff moves way faster than I can follow.

Well, something interesting that you said was that infrastructure built a platform. Is it really infrastructure building a platform? Or is the development side building their own platform outside of infrastructure, which is, I think, really compounding the problem? Which isn't necessarily a bad thing, right? Someone's got to build it. Someone's got to drive that effort. Yeah, I think there's a couple different things going on. There's some, like, this stuff, where you get into the run C and that type of stuff.

There's some real hair splitting in there that gets really in the weeds, which is unnecessary confusion and complication, which I think will shake out way quicker. Then there's the separate sort of marketing thing where Cloud became basically a meaningless word because everything became Cloud. PaaS and stuff like that, I think, came in that same kind of space where it's like, well, technically it's a platform for you to do something, so now we're calling it a PaaS, where traditionally people thought the Heroku, Cloud Foundry, OpenShift type thing was, I push code and it runs it, was a PaaS.

But now, I think that's getting kind of, that's where the waters are getting muddled. I think there's an interesting kind of thought on that last piece is, as Mark said, like, who's looking at where's the PaaS coming from? You know, is it the developers? And there was, Brian Graceley did an article for Wikibon, I want to say early last year, maybe late the year before. True Private Cloud. No, no, no, basically structured PaaS versus unstructured PaaS. Okay. So you're basically talking about how, like, for example, Pivotal, Cloud Foundry's a structured PaaS, right?

Yes. You follow Cloud Foundry's rules and it does the thing, right? Whereas if you say, oh, we don't use PaaS, we use Docker containers, like, okay, cool. Like, well, how's your code get from there into the container? It's like, whoa, we have this thing and then we built the script that does this and then it packages it up and it runs it through Jenkins and like, there's all these steps. You're like, well, that's a PaaS. Your developers still just push code, but you've built your own PaaS.

So you're going to end up with a platform of how you get apps out the door. It just, are you going to take something that's completely turnkey, something that's maybe a little customizable, or are you going to kind of build it yourself? So all of this sounds fairly futuristic versus a nice, comfortable, familiar face at DockerCon this year, which was Oracle. And this goes back to your opening statement or set of comments when you talked about, people are now talking about running traditional apps into containers.

Tell us a little bit about that story. Not necessarily the Oracle part, but this increased, you know, I think I talked to the guy from Google, who's my, the people said, hey, your doppelganger just went to Google. Kelsey. Yeah. You're a little taller though. Yeah, I'm a little bit taller. Just as bald, but just a little bit taller. But I talked to Kelsey a while back ago. This had to have been, this is almost two years ago.

And he was talking about people are, to get to containers, people a year and a half or 18 months ago, was talking about taking their monolithic apps and then running them in containers because there was some value there. Can you talk through kind of what's the predominant line of thought when it comes to that? So I would say, I would follow it under kind of the perfect is the enemy of the good, right? In a perfect world, we'd write these super modern applications, kind of the, you know, API contracts, microservices, scalable, continuous integration, like that is the promised land.

But, you know, that's fine for if you're a startup, you have Greenfield, if you're a large or old organization, you probably have a lot of stuff that's been running for a while. I mean, even heard at DockerCon, MetLife was one of the keynotes and they talked about how they have stuff, code that is running live in production right now that was written in 1982. Just to kind of like set the kind of tone of, hey, everything can't just be rewritten or isn't a good business choice to be rewritten.

So I think under that kind of, you know, setting that foundation, there's values that containers can, I mean, if you think about the average enterprise probably has some sort of Java based app, right? And you say, well, how do you people, how do you folks bring this from code to production? Okay, well, you know, we put this here, then creates these jar files, and then we have these VMs that we use Puppet to build VMs that have, you know, JBoss installed and we push our jars through some script and like they have this process.

The two things that containers bring you in that type of environment is efficiency, right? I don't need entire OS images just to run a jar file. So I can just package up in a container. Plus it's a lot easier to automate as part of a build process. So that way, every time your developers hit, you know, commit in Eclipse, that it pushes through your pipeline and gets code out faster. So those, I think those are like the very basic pieces.

But then from there, you know, it's like, well, why, why do I need this whole construct of a VM for certain things? And I think you're starting to see the edges of that, just like we saw in the early virtualization days, right? There was, hey, test devs fine for VMs, but production has to be on bare metal. And then you just saw bigger and bigger VMs and more features that made it more production ready. I think you're seeing that with containers now where, hey, this is an easy management unit.

So yes, at the beginning, containers were just ephemeral, but now it's pretty easy. Kubernetes, Docker, I think even Pivotal just added or Cloud Foundry just added, you know, persistent volume support from the idea of like, hey, I have a container. If it's going to be, say, an Oracle database, well, guess what? I need that storage to be persistent. So I can have a volume, I can disconnect it, I can update the container. And then, you know, reconnect it to the volume.

So I think that's really where you're seeing it start to go where it's like, yes, it'd be perfect if we rewrote this app, but if we can gain some business value, whether it's time to market or efficiency or something, why not do containers today? Why wait for tomorrow? And I think one thing that I've seen in a couple places is using containers for legacy applications for lifecycle management. I've seen this a lot with Windows 2003 coming off support. Some people have just moved them into a container, not because they needed agility, not because they needed elasticity, not because they needed any of that, because the next time they have to remediate, you know, an old operating system, it's a lot easier just to not have to deal with that if you don't have to deal with the operating system anymore.

Yeah, I think that's the key thing. I've heard plenty of people talking, I may have even been Kelsey, you know, think about containers less as like the new VM, but it's more of a application and dependency packaging tool, right? So it's not just, if I install my Java app, it's not just the JAR file, right? It's like, what version of the JRE are you using? What, you know, other pieces is, you know, it's capturing the state of that. So whether it's a Docker file or what have you, you have a full state of what this app needs to run, but I don't need a whole VM to capture that.

So that's really where it can bring a lot of value. Yeah, Mark, you make a good point, both of you guys, that, you know, years ago, I don't know if the correct name of the app was App-V on the Microsoft side, VMware had a version of this, where on the Windows side, you could containerize the application. So let's say it's Office 97, for whatever reason, you have this business process that's stuck to Excel 97, you just can't get off of it. But obviously, if you're running, you know, Windows Vista or Windows, some modern version of Windows, with a modern version of Office, you needed a way to containerize that app and keep it separate from the OS and have all of these legacy dependencies on it.

Same concept, and it's nowhere near as heavy as a VM, which is some of the things that I heard consistently. And I think Tyler, you hit on which, you know, the jar example, it can be just, you know what, I'm running 10 Oracle instances, and I just want, and this is a weird, you know, use case, but, you know, I'm running 10 Oracle instances, and I just want instance isolation. Obviously, I could do that in Oracle, but you know what, I have this Oracle Docker container I can get from the library now and have it running on the same kernel.

Security isn't necessarily a huge concern of mine because I've put that bare metal server in a security zone for databases, so I'm not overly concerned about connectivity issues. I just want to optimize for hardware resources. Yeah, I mean, I think the, that's, you know, that's the key with it is finding that, looking at these things and seeing that, you know, there's a lot of things that you can do here that makes sense that just don't have it in your mind that this is the only way to do it.

This is the only thing you need, this is the only thing to do and yeah, I remember the first time I see, you know, I just had to look it up, ThinApp. You know, when the first time I started playing with ThinApp and you saw that VMware had it when they acquired it, it was like, watch, I'm going to run like eight different versions of Internet Explorer on the same, you know. Right. It's like, wow, this is pretty cool. So I mean, that's, you know, not just that use case, but conceptually, that's where it can bring a ton of value.

I mean, on the efficiency perspective, there was a really good article, I want to say a couple months ago, talking about a large number of Amazon AWS customers that were using EC2 for various things that switched to running Kubernetes on EC2 and then move those EC2 VMs into containers and save between 30 and 40% on their monthly Amazon bill by getting more efficient. Wow, yet another use case for running containers inside of VMs. So Tyler, we're about to end. Anything that you want to make sure that you speak about, anything at the conference that, because you were there on the ground, we were watching it remotely.

Was there something that you wanted to comment about the conference, whether it's culturally, in atmosphere, the majority of the conference, or just from a use case or technology that you saw that, you know, that really surprised you or caught your eye? Well, I think there's always that tug of war between, you know, technologists, you know, stuff that spins our, you know, the propeller on our hat, exciting stuff, and then the stuff that's maybe not as exciting, but important to be done. And I think you saw that kind of in, you know, DockerCon last year, it was like, watch, we put Swarm, it's built in.

There was a lot of big wow demos. I think a lot of their focus probably, you know, on purpose was on security and, you know, the type of hardening things that a big enterprise would want to feel comfortable with Docker. So it was interesting to see, you know, even their keynote speakers, they weren't some hot new video game company, it was MetLife and, you know, and Visa and stuff like that. So I think you're seeing that transition. The other thing that was really interesting that was announced during the conference, too, is one of the confusions around Docker, which, you know, I don't know if it would, you know, there'd be better to do it differently earlier or not, but, you know, there's always this constant confusion.

We always say little D Docker and big D Docker, right? So there's Docker, big D Docker is Docker Inc. It's the company. Little D Docker is the name of the open source project, which Docker Enterprise Edition, Community Edition come from, or downstream from. So what they did, what they announced basically was moving those upstream bits into a new project called Mobi, and then also opening that up to allow people to kind of break, because it became a Docker, it's the Docker engine itself became a bit of a monolith, right, a lot of pieces were built in.

So they're kind of trying to break them into more pieces, which will, I think it'll be less confusing for users, you know, Docker versus Mobi. And then it also opens up other partners to do other things with it. But at the same time, you know, it'll be interesting to see the reaction was good and seemed to turn to more mixed to negative as the week went on. But I think it's a lot of, you know, prognosticating, it's too early to say how it all shake out from a greater community perspective.

And then on the question of community, you're pretty tied in with the open source community and wow, did they change the governance or just the, you know, the name and some of the rules of the governance as they run it? So no, so they don't, there's no foundation or anything like that with Docker, they have contributed some of their projects like container D and stuff to CNCF and some of the other foundations, but the actual Docker and now Mobi projects are fully controlled by Docker Inc.

So nothing's really changed on that front. The only thing is I'm imagining that, you know, with that split, and if you take the Mobi bits and build it into something that's basically, you know, a Docker clone, you can't call it Docker anymore, right? Because it's not, you build it for Mobi and then Docker Inc. is the name of the company and Docker is their product. So I imagine that you get, you know, you get that brand wreck, that breaking brand, someone can say, oh, container solution built on Mobi and Docker can always say, hey, this is Docker.

Yeah, so I mean, think about like CentOS or Fedora with Red Hat to some degree, right? Where it's like, you can build, you can take the open source bits, they're fully open source and you can build yourself basically a total, you know, binary equivalent for Rail, which is pretty much CentOS was, but you couldn't call it Red Hat Enterprise Linux because it wasn't. So I think that's kind of the similar kind of, I think that was even the idea, maybe just to make this more kind of clear, but who, you know, who knows how it will affect the community downstream, long-term.

So just to clarify that, basically Docker's transitioning all of its open source stuff to Mobi, right? So this is the tough thing of, right? No matter how far downstream you get, it's still open source, right? That's the top of the stream. So Docker Community Edition, which is their, theirs, if you will, you know, their brand, their thing, you get the binaries directly from them. It's still technically open source. The source that they built it from is out on GitHub and all that kind of thing.

So this is where it gets kind of like murky of your definition. So it's not, so nothing has been closed that was open. It's just kind of a reshuffling of where they keep the bits, the different open bits. And most of the contributions, if you go on Docker's GitHub, you'll see that most of this stuff was in the, what we call Docker-Docker, the Docker-Docker GitHub. com slash Docker slash Docker, which is now redirection to Mobi slash Mobi. And I think the most important part of that is that from a contribution and control perspective, Docker still controls Mobi.

Docker didn't move Mobi or the Docker engine into CCNF. They move, they still control it. It is more of a optical change than it is a governance change. Yeah, yeah, there's no governance change or ownership change. I think it'll be as kind of, like you said, as time goes on, be interesting to see how, trademark rules or naming type stuff goes. But I think it'll end up being good, good for the community. Will it be, will there be some bumps and bruises?

Will it actually be good for Docker Inc long-term? It's, I think there's just no way to tell at this point. All right, so let's close out. Mark, where can people find you? Are you gonna do, are you traveling anytime soon? I'll be at Dell EMC World, I think, what's that? Week and a half, something like that. And then maybe Interop, haven't quite decided that yet. All right, what about you, Tyler? Yeah, I'll be next week, I'll be at Red Hat Summit in Boston.

And then I'll be turning right back around, coming right back the following week for the OpenStack Summit. All right, and then I'll be at Dell EMC World. I actually have theCUBE duty all day for all three days. And then I'll be back in Vegas, I guess, fortunately and unfortunately, the week, the next week, a week after for Interop. I have two sessions, one on hybrid cloud and the other one on serverless computing. So check those out. For the rest of you guys, you can check out the podcast on your favorite podcaster.

Rate us in iTunes because it does help. And if you're at your mom's house, go to her podcatcher, subscribe to the podcast on her podcatcher. Regardless of if she's in technology or not, because we like to see those numbers roll up. For the rest of you, we'll talk to you guys next episode of the CTO Advisor. Thanks.