Show 3.1: Kubernetes – What it is, Why it Matters, and How to Get Started - Part 1

Podcast transcript:

Jim Scott:

Hi! My name is Jim Scott, the host of Data Talks. Today's guest is Michael Hausenblas, with Red Hat, and Sebastian Goasguen, with Bitnami.

Guys, thanks a lot for participating in today's podcast. I'm personally extremely excited, because today's talk, we're basically going to be covering a lot of really important issues around Kubernetes, and data operations, that impact them on a daily basis.

Before we get into the plethora of questions that I have, Michael, I was wondering if you could tell the listeners a little bit about yourself.

Michael H.:

Hey, Jim, and thanks for having us on your brilliant podcast. My name is Michael, last name unpronounceable, in contrast to Sebastian's. Actually if you remember, we used to work together, at some point in time, at [Narfar 00:00:54] and I actually remember those times as pretty interesting and very, very influentual time. I then moved to Mesosphere, and now I'm at Red Hat. I'm still doing the same developer advocacy, hanging out at events, putting together demos and articles and tooling and whatnot. Working when the [inaudible 00:01:18].

Jim Scott:

Fantastic. I wasn't going to admit that we used to work together. But I guess, since you brought it up, I don't have a choice now. Sebastian, can you tell the listeners a little about yourself?

Sebastien G.:

Sure. Good morning everyone. Sorry, I've got a ... I'm under the weather, a little bit. I'm the senior director of Cloud at Bitnami. Basically that means that I'm in charge of all things Kubernetes related, and yesterday I just updated my LinkedIn profile ... I erased everything and replaced it with startup founder, product owner, product manager, developer advocate, developer ... so, a bunch of things that I do. I write books, one of them with Michael. I give trainings. But basically I love technology, I love Kubernetes, and I try to create great software around Kubernetes, and then promote them and get other people to like them.

Jim Scott:

That's fantastic. I'm really glad ... Again, thank you for coming on the show. Michael was really happy to make this introduction because of the work that you guys are doing on Kubernetes. You guys are doing so much work around Kubernetes, and, quite frankly, I think it's got to be one of the most popular technologies that's in existence right now. I feel that the adoption rate has been just growing, kind of at a ridiculous rate. How long do you guys think it'll take for the adoption rate of Kubernetes to reach 50% in the marketplace?

Sebastien G.:

You want to take that, Michael?

Michael H.:

Sure. Happy to. That pretty much depends on what you define as the market.

Jim Scott:

Let's say for anyone that's using orchestration management tools to effectively utilize the resources that they have at their disposal.

Michael H.:

Right. That also reminds of, back in the good old days, where DUP was hyped as much as containers are nowadays, leaving of course things Bitcoin and all the other things aside. Essentially, how do you actually measure that? Is it the number of containers that you're managing? Is it number of clusters? Is it the size of the cluster? Is it the stuff that it's running on your laptop or whatever locally in terms of development environment? No matter how you measure it, I would argue that, in 2018 ... We're in the beginning of 2018 ... That effectively Kubernetes is way beyond 50%, right?. I can look at different statistics or surveys taken by [inaudible 00:04:03] or others ... of course they're biased, because they're asking people who are already in that space. But, if you're asking people who are doing, who are developing containers to Kubernetes, then the Kubernetes part is more than 50 percent. In a sense, in a nutshell, it's already there.

Jim Scott:

Basically, what I'm hearing you say is that we passed the 50 percent mark. So, when do you think it will hit that 75-80 percent mark?

Sebastien G.:

Let me jump in and give my view here. You use Kubernetes only if you have applications that have been containerized. You may be using other people's apps, coming from a repository of application, of course. But, otherwise, you need to build a pipeline internal to your company, where, instead of creating traditional artifacts, you're now generating containers. That's the first thing. You need to have that. So, when we say adoption of Kubernetes, we also need to look at the adoption of containers. Do we generate containers in the IT groups? Now, if you compare the orchestrator and you're trying to say is it more Kubernetes or is it more Swarm or is it more Mesos, or Nomad, or Rancher? Things like this. I think it's fair to say that over the last six months, Kubernetes has totally won the orchestration war. One of the signs that I always site is that Rancher has been rewritten entirely in GO, and, on top of Kubernetes. So, Rancher has actually become a distribution of Kubernetes, just like Tectonic from CoreOS, Docker has also moved to integrating Kubernetes in Docker for Mac, it should come in Docker for Windows pretty soon. So, even Docker has acknowledged that Swarm is on the decline and probably, I'm expecting to see, that they will totally abandon Swarm, when you look at the velocity of the project. Looks like definitely Kubernetes has won. The only projects remaining are Nomad and Mesos. Again, when you look at the surveys from the new stack like Michael mentioned, or Gardener, or things like this, the adoption in terms of container orchestrator, is 60 to even more Kubernetes. Now, in Kubernetes, if you include Rancher, Tectonic, and also Open Shift from Red Hat, now you have a huge portion of the market. Probably 75.

Jim Scott:

If we put this perspective for people, if, you were using something like Mesos or Docker Swarm, if you're not already looking at how to migrate over to a Kubernetes, you're probably way behind. Given that I have heard adoption rates of Docker Swarm degrading below about one percent of the orchestration tools, so it does certainly seem like something that's going to disappear very soon. And Mesos is the same thing. People I know that started using Mesos about three to four years ago, they've been either abandoning or in-process of trying to figure out how to move onto Kubernetes. That's really interesting. Let me throw one ... or sorry, go ahead Michael.

Michael H.:

Just one thing. Those one or two expressions that obviously true. However, one needs to look at the bigger context and still say container orchestration as such, if you look at the overall workloads, you'll find your traditional enterprise ... I don't know, I don't really have the numbers. But hunch is, a few percent. So, we're not talking about 60, 70 percent of the workloads in any given Fortune 500 or whatever, is actually running on Kubernetes. We're talking about within the containerized setups, people who are [inaudible 00:08:02], are using container images, are using [inaudible 00:08:06], whatever, are using Kubernetes. Just [inaudible 00:08:13].

Jim Scott:

Absolutely. And things that are, let's just say, more modern, are more likely to be built and operated in a containers' environment than things that have been sitting around for three, four, five years because people don't have to worry about going through and doing regression testing and figuring out how to make everything work there when they want to spend their time on the new things. Right?

Michael H.:

Right.

Sebastien G.:

That's important to make that difference, because that's what I said earlier, you have to look at companies that have embraced containers and that have put that in their day-to-day software development lifecycle. We're back to talking a lot about SDLC and how that plays inside your dev-ops mindset in your companies. But Michael is 100 percent right. The actual adoption of containers, if you look at IT worldwide, generally is probably still extremely low. Traditional workloads are still a huge majority of everything you find out there, and that's why a lot of people talk about lift and shift, cloud migration. Things like this. Where we're talking about, "hey, how do you take a traditional application in the data center and move it to containers and onto Kubernetes and onto the cloud?" Even Docker mentioned that they created a brand new program on top of that, they call it Modernizing Traditional Application. I think it's a terrible name. It's not really exciting. But that's what it is, that's what it's about. How do you move traditional workloads onto containers on the cloud.

Michael H.:

Yeah. I'm not going to get ahead of myself here, I'm pretty sure Jim will come back to that later on, but the question then is actually do you go for something like [inaudible 00:09:57] or do you essentially skip that and dare to go for [inaudible 00:10:00]?

Jim Scott:

So, that actually is a big topic and we will get there shortly. Let me just ask one more question when it comes to adoption rates here. There's this other, let's call it tool, out there, that was born out of the Apache-Hindu product, called YARN. Where does YARN fit in this? Do you think Yarn has a leg to stand on when it comes to the competing priorities of Kubernetes?

Michael H.:

What's that? Yarn? How [crosstalk 00:10:32]

Jim Scott:

[laughter] All right, let me just pause that question for a moment, let me change the question a little bit. If Apache Spark were already running perfectly on Kubernetes, do you feel that anyone would retain understanding what YARN is at all?

Sebastien G.:

Do you want me to go, Michael?

Michael H.:

Sure.

Sebastien G.:

The way I like to look at this is to think in terms a little bit history and lineage of the technologies. Because it's difficult to take technologies out of their environment, you need to understand where they come from and so on. The entire big data ecosystem really, that is governed inside the Apache software foundation, 90 percent of it, this all evolved pre-Kubernetes, pre container, in the Docker flavor. All of that ecosystem developed earlier, and then developed around ... there was the beginning with Adieu, and also Mesos played a role in there, because a lot of those big data solutions were developed inside Adieu. You see this, inside Mesos, sorry, you see this ecosystem there. But it's important to remember that Mesos was actually inspired by Borg thinking. Engineered at Google, and then the guys that created Mesos at Berkeley, they were talking in terms of efficient scheduling, efficient resource allocator, better scheduling algorithms. So, Mesos is born out of discussions with Borg, or at least that's my view on things. Mesos is not container native. It also indulges more traditional applications. And, now that you have Kubernetes that comes in on the side, 100 percent geared towards containers, now you're going to see big data workloads actual adopt the container model as a compute unit, and then start running on Kubernetes, which is a new, probably better, system. You could argue, maybe on the scale or the scheduling, but overall I think it's a better API that's more geared towards modern workload. Spark is an example. I think you're going to see other workloads adopt Kubernetes, so YARN ... I don't even know what the N stands for. It's Yet Another Resource -

Jim Scott:

Negotiator.

Sebastien G.:

Negotiator. Yeah. Sadly, I wouldn't put too much future on YARN. Except in the very niche, big data, eco system.

Jim Scott:

All right. Michael, what exactly is Open Shift, above and beyond Kubernetes?

Michael H.:

Can I quickly comment on YARN? Just one throw away line.

Jim Scott:

Go ahead.

Michael H.:

Because ... Generally I agree with Sebastien here. And to phrase it like we had three kids ... Pretty much teenagers, and they would say, "YARN is so 2011." Right? It's really born in a time way before containers, especially Docker, became a thing. And really, in the sense, does not fit in the modern way of thinking, the cloud native way of thinking and handling these workloads. So my expectation, my hope would be that people [inaudible 00:14:21] at some point in time wake up and say, "Okay, let's crash that and let's also back on Kubernetes." But that's a different discussion. Coming back to open shift, you asked what's open shift. Open shift essentially is an enterprise distribution of Kubernetes. There are a couple of things where Kubernetes is not opinionated, and that ... Where you essentially either have to provide parts of it yourself or find someone else doing that. It's very much the same as in the '90s where a lot of people were rolling their own Linux distribution. Then at some point in time someone said, "Hey, why should we actually pay our folks to roll our Linux distribution?" There's this thing there ... There were people who just made their money putting together a Linux distribution. Testing stuff, bundling it, and so on and so forth. And nowadays, I personally don't know a lot of people, maybe there are still people, 5% or whatever ... That actually roll their own Linux distributions. In the same we now see creatives, right? We still see, I think more than 50% of people rolling their own Linux distribution, and in five years time I would say it's 80-90% using [inaudible 00:15:41].

Jim Scott:

Well and I think ... If I can add my two cents on top of that ... I think part of it is that, when you look at the open source community, people say, "Well I can get this for free." And then after people get some experience around it, they realize how much time they have to put into building, managing every little aspect of it. And for most businesses, being able to focus on the core competency of your business is fundamentally more valuable than spending your time figuring out how to manage/tweak every little detail.

Michael H.:

Absolutely. Not even talking about the security [crosstalk 00:16:13]

Jim Scott:

Oh not even.

Michael H.:

[crosstalk 00:16:14] and make sure that everything is secure and you know, works nicely together. You think things like service broker, Helm, any kind of integration there. There is so many moving parts, not even talking about the low level stuff, for example the networking bits. You need to come up with something there, you need some kind of SDN, some software defined networking. All these moving bits that you need in order to actually use Kubernetes. That's what a distribution actually does for you. And open shift traditionally already had these past layer ... A way to express an application, what is an application, and how you actually set on up and what that translates to to deployment and services in Kubernetes. OpenShift 3, what we're currently are on, is essentially a rewrite on top of Kubernetes. So at some point in time at Red Hat, I made an early bet on Kubernetes and said "Alright, Kubernetes will be the future." A couple of years ago, and we wrote OpenShift, the past on top of Kubernetes ... That's essentially what we're [inaudible 00:17:20] off of now.

Jim Scott:

Alright, really great to know. Sebastien, there's a certain tension I've been feeling here I want to bring up. Does Bitnami leverage OpenShift at all or just straight up Kubernetes?

Sebastien G.:

So let me answer that in a indirect manner. In 2012 actually, I went to a MongoDB Days and I met a guy named Grant Cheeply, who is I believe the lead developer at Red Hat for OpenShift.

Michael H.:

He's my boss, yes.

Sebastien G.:

Yeah, he's your boss Michael. So he gave a talk on OpenShift. That was 2012. He ran an application which was a beer ... Something like a beer ranking app or something. That was quite fun. But the point I want to make is that, at that time, it was the beginning of OpenShift, it was the beginning of Parse, and that was OpenShift ... Might have been OpenShift 1 or OpenShift 2, I don't remember the timeline exactly, okay. But what Red Hat has done, which has been amazing and I really want to compliment Red Hat on this because their foresight has been amazing ... Is that they decided to totally rewrite OpenShift in golang and to make a bet on Kubernetes. So when we talk OpenShift right now, we're talking about OpenShift v3, and basically it is Kubernetes plus other OpenShift specific things. So it's a distribution of Kubernetes, plus all the past API and the past tooling that they've worked on over the last many years. So it's been an amazing sight to see that Red Hat bet on Kubernetes early 2013-14, when it restarted. And they took a really big chance on rewriting OpenShift entirely. I didn't like the first OpenShift because the scaling actually didn't work, but by adopting Kubernetes, they really made an amazing strategic move there. So now back to your question. Since Bitnami generates application, we package application, that's our core business ... That's what we've been doing for a long time. We populate a lot of the marketplaces of the major [inaudible 00:19:43] in the US, Google, Azure, Oracle Cloud, Huawei Cloud. So we package a lot of open source application that we deliver for those clouds. And with the containers, being originated by Docker ... We started packaging all those apps as containers, and of course, we're making sure all those applications run on Kubernetes. So they all work on Kubernetes, that's why we're very involved in Helm and we're not developing Kube apps. But of course that means that OpenShift is definitely a prime target for us, because OpenShift represents the production deployment of Kubernetes. Needless to say that Red Hat has a lot of enterprise customers that run work loads in production ... So we definitely target and test our packages to run on OpenShift and that's where Michael and I have some discussions, because OpenShift has a huge security focus ... So for our containers to run on OpenShift properly, with a low barrier of entry to users, they need to be packaged a certain way ... Like good security practices, non route like containers, and then it opens the door to a lot of additional tweaking. So yes, that's what I said indirect answer. Yes we ... All our apps, all the Bitnami apps run on OpenShift. We're trying to do even more, and kudos to Red Hat for betting on Kubernetes and building OpenShift.

Jim Scott:

Alright. Well we're hitting on some pretty heavy stuff so far, so maybe while we let the listeners soak some of this up ... We can start discussing some cookbooks. I heard you guys have been working on writing a cookbook together and I'm not referring to Betty Crocker style. We're talking about Kubernetes. So how'd you guys get connected to come up with working on this book?

Michael H.:

I think Sebastien is the right one to lead here.

Jim Scott:

So Sebastien, how'd you guys get connected to start working on this book together?

Sebastien G.:

Yeah so I've been lucky to write the Docker cookbook, that's how I got into containers. And since I have a past ... I spent a lot of time in academia ... To learn a tech, I like to actually get my hands dirty and test things and learn things. So when Docker came out, I was very surprised. Why are people getting excited about containers? And I said, you know what, I really need to dig into it to understand why now. Because we've had containers for a while, so why are people suddenly becoming excited about containers and Docker. So I contacted O'Reilly and I said, "Hey, how about I write you a Docker cookbook?" And they said, "Yeah sure.". So I wrote the Docker cookbook, and that was one book. And then after Kubernetes came out, I put all my efforts into Kubernetes early, late 2014. And then I contacted O'Reilly again and I said, "Hey, how about I write you a Kubernetes cookbook?" And originally it was supposed to be just a Christmas deal. I said, "Hey, I'm going to write you a mini book. Like 30 pages, it will be quick. In and out. Book done." And of course they came back and they said, "Hey, how about a full cookbook?" So now I was on the hook 450 pages, which was totally different than the original 30 pages I anticipated. And you know, life got in the way, and I knew Michael of course and at some point I said, "You know what, I cannot do this on my own. I need help!" And who better than Michael. So I called him up and I said, "Hey, are you interested to work with me on this?". So now we're co-author on this book and finally it's out. It's going through the last steps. And the book should be out in the coming weeks.

Jim Scott:

That's fantastic! So the book sounds like it'd be pretty helpful for those focusing on implementing good data ops practices ... Being a cookbook. So for those who might not be extremely familiar, Michael can you explain to them what exactly does data ops mean to a business?

Michael H.:

Okay so ... Data ops. There is this tendency now that we propend ops to a lot of things. There is GitOps and there is DevSecOps and what not. I try to interpret ... From my point of view, in this context ... If one can create an environment that allows data engineers and data scientists on the one end, and people who are ... For example a Kubernetes administrator or whoever is on the operations side of things ... Allows them to work together in a way, using small batches, which means nothing to do with Hadoop ... Essentially meaning, small, very small delivery packages. Essentially feedback cycles that the people who are involved here, [inaudible 00:24:58] can come together and quickly get something out in production and learn very quickly if something goes wrong. In the extreme, it's essentially a developer, data engineer, data scientist [inaudible 00:25:11]. Then this is essentially the foundation for data ops for me. And you might have noticed something, and that is I ... Almost no where really said, "Oh you have to use a CNCD pipeline, or you have to use Kubernetes." Or whatever. It is first and foremost a organizational thing. A thing ... A way of thinking and having your shared responsibility. For example ... That thing might be a self service analytics thing, that might be a streaming thing, that might be ... Whatever it is that processes data in a timely manner. It is really that part that makes it really really tough because we can only provide the tools. The tooling around that and the heartbeat, and that is changing the mindset of people out there. I honestly don't have good answers, maybe Sebastien does.

Jim Scott:

No that's a pretty good answer, and I'll just again, add my two cents on top of it, which is ... I think dev ops proved to be this resounding success for people to learn how to scale out their platforms and be able to manage their business at scale. I think the opportunity around data ops is that of, oh by the way, all these operations you do, they all rely on generating and using data ... So you should really pull that into fold and, to reiterate your point Michael, it's cultural thing. You've got to get people working together on it, and so it's really critical that they figure out how to do this in the world of my data is growing exponentially, what do I do now?

Michael H.:

Right, and I've been talking in the abstract a bit. Maybe let me give you an example of what I mean by that. There was actually ... When I was still at Map Hour, it was I think a customer prospect in Germany without naming names there ... Where I was on site, and they were ... I had sessions with two crowds. The one hand were data scientists who did an awesome job with R. On the other hand they were ops folks who used map R and had the spark. And it was really really hard to actually get the stuff bottled that the data scientists wrote in R, and said, "Look, it's working right." It's working right here in my machine ... Into making that happen in their spark environment. And that was the first time ... A couple of years ago, four years ago whatever ... Where I was like, "Hmmm, how can you actually ..." Of course the tooling helps and supports you there, but how can you actually make these two groups work together. Because it's not just the responsibility of the ops folks, not just the responsibility of the data scientists, the data engineers to deliver that. It is a [inaudible 00:27:57] responsibility.

Jim Scott:

Fantastic. So Sebastien, how do you think the topics in this cookbook will help people be able to deliver on a successful data ops strategy for the business?

Sebastien G.:

The cookbook is not really specifically about data ops. It's really a community's cookbook and it's more introductory for all the ... The basics of Kubernetes and onboarding into Kubernetes. So you have to put the expectation in the right place there. In terms of data ops, I must say I'm a little bit skeptical with that term, and we're seeing a proliferation of ops terms. Of course dev ops, but then there's app ops, no ops, chat ops, data ops, and I ... I understand the differences, but the bottom line to me is what Michael just said is that it's a shared responsibility between ... Whether it's the data scientists and your storage guy, storage person. Or whether it's shared responsibility between the developer and the system administrator. So all those star ops terms, it's really a culture issue of building an environment in your enterprise where the ownership and the responsibility of the application and the success ... Even the business success of an application is really shared by everybody. And that's really the big challenge. So under the hood of course you're going to have a lot of tooling, but the tools are not the end of the thing. If you go back to all the basics of dev ops and the dev op books and so on, the Phoenix project ... You see clearly that the goal is the business success. Delivering value wherever that value is. Whether you are a retailer or whether you're doing a genome sequencing or whatever. With IT, we have to deliver value to the end customer. And to do this these days, we need to have this shared responsibility, this shared development. We cannot throw stuff over the fence. We cannot throw containers over the fence just like we throw our files, which are files. So that's a little bit more of a dev ops discussion. The cookbook itself really is just all the basics of Kubernetes for now. I'm sure Michael and I will expand the book and it will grow to a 400 page book. And in there we'll try to put a data ops chapter.

Jim Scott:

Excellent. So let me throw my two cents on top of this, because I think you both made some really good points on here. And I'll start with the throwing stuff over the wall. So I used to be in digital advertising, and that's when the dev ops practices that I used to participate in really took off was ... We finally got sick of the throwing stuff over the wall, watching things break, not knowing how things were going to fundamentally operate in the business. And so I think the ... All the different ops terms, I'm in complete agreement with you in that ... Well I personally find many of them ridiculous. The only three that I like are ops, dev ops, and data ops. And it's because to me, it's literally a layering. I've got my operations team, and then I've got my dev ops, which is hey, let's stop throwing stuff over the wall and actually work together to make sure that we've got good feedbacks and that we know what's going on. And then the data ops I really have a deep appreciation for, because when I was ad tech, the entire business was driven off of logs. Event streams. And we had horrible processes in place at the time that the organization could have benefited from by having some good examples, good best practices to be put in place around how to manage that data in coordination with the software being developed and put out there. Because so many times models were broken right? Oh we've added something to the logs and now all these other downstream processes break. Or better yet, you bring the data science folks in and the things that they were doing aren't working properly, now they have to jump through hoops to figure out how to make the new data work with the old data. And that's where I see the big value prop coming in for data ops, is tying them together. Just layering on one more depth to the complexity here. And it really is a complex thing. It's very cultural in nature. And my hope was for this cookbook, to be able to point people to it who they've made a decision that they're going to go with Kubernetes. So I see a pretty significant value for people to get up and running and to formulate what their ops practices are around the development of their software, the deployment management of it, then how to coordinate that with their data across the different teams. So my hope is that this book can help those types of folks move forward at a more rapid pace. And then they still have to deal with all the cultural issues. So if we move on from here, and we look out in the industry, are there any speaking engagements that our listeners can expect to see you at in the next few months, Sebastien?

Sebastien G.:

Next few months no, but I'll be at Go2 Amsterdam in June. That's the earliest so far. Usually I got to First Den every year in Brussels, which is the number one event for open source in Europe. It's a huge event with 6,000 people. It's totally vendor neutral. It's an amazing event. But this year unfortunately I'm going to have to miss First Den, so I won't be there. I'll be at KubeCon of course, Kubernetes conference in Copenhagen in May, but who knows if the papers are going to get in because there was 1,300 submissions to KubeCon, so this is huge. That's another metric that shows you Kubernetes is really booming and being adopted. You see so many papers submissions to a conference.

Jim Scott:

That's fantastic. Michael what about you? Do you have any conferences coming up?

Michael H.:

Yes sir. I think maybe ... Personally for me, the most interesting one is beginning of February, the first Monkey Grass in London [inaudible 00:34:32]. And I'm very sad to hear that Sebastien doesn't plan to go there. [inaudible 00:34:37] is certainly a big highlight in terms of open source. Later this year ... Definitely be around at KubeCon in Copenhagen, beginning of May. And in San Jose, at Velocity in June. We were training there on my computer networking. Yeah so no matter if it's at events or twitter, feel free to hit me up there, whenever you see me or online or whatever. Reach out, I'd like to talk.

Jim Scott:

Fantastic. So the next question I've got for you Michael is ... Kubernetes, it's hot. People are looking at it, they're evaluating it for a lot of use cases. Is there a use case that you believe Kubernetes not only dominates in, but you might tell someone, "If you're not using Kubernetes, you're kind of missing the boat." Maybe not to the point that you'd get fired if your boss discovers that you could've been using Kubernetes instead of building something on your own. Is there any use case that comes to mind?

Michael H.:

I'd say any kind of state less ... [inaudible 00:35:51] whatever, that is state less is a low hanging fruit where you can't really do anything wrong or whatever. Kubernetes comes with pretty much anything on board. In certain cases, like ingress for example, when you expose your servers to the outside world, it requires a little bit more [inaudible 00:36:12] if you don't have a [inaudible 00:36:13]. But generally everything is there.

Jim Scott:

[crosstalk 00:36:20] Nice plug.

Michael H.:

In general, everything is there. So if you don't do that, there is really little excuse not to put it there in the first place. If you have something ... If you don't want to manage your Kubernetes environment yourself, there are many many offerings that can just use Kubernetes as a service. [inaudible 00:36:42] Google Kubernetes engineers. Their code now originally [inaudible 00:36:47] engine, which pardon my French confused the shit out of me when I tried to align that. Now it's GKE Google Kubernetes engine. And Azure and now soon also AWS, all of them have managed environments, as does Red Hat with [inaudible 00:37:08] online, by the way. So you don't even have to manage Kubernetes yourself, you just go there and pay by the hour or whatever. So there is really very very little reason not to use any kind of state less apps with Kubernetes.

Jim Scott:

That's all the time that we have for today. Please join us for tomorrow's episode when we continue this discussion with Michael and Sebastien, in which we'll take a deep dive into server less, also known as function-as-a-service ... Container technologies, and the all important yet ever elusive solutions for actually storing your data. One of the most critical components for any enterprise in order to build solutions with Kubernetes. There are a couple additional resources available that are worth mentioning. Kube Apps ... And I also wrote a book titled A Practical Guide to Micro [inaudible 00:37:57] and Containers, which can be found at MapR.com/ebooks. For all of us here at data talks, id like to thank you very much for listening. I'm Jim Scott, on twitter @kingmesal. Be sure to tell all of your friends, your aunts, your uncles, brothers, sisters ... Anyone that you think might be interested in the data talks podcast.

Subscribe to the Podcast

Be the first to hear our newest interviews and other DataOps topics

Subscribe Now

Data talks - A Podcast to Help You Drive a DataOps Culture

Subscribe