Cloud Native & Coffee - Ep. 1

On October 13th, iconic cloud journalist Steven J. Vaughan-Nichols and Mirantis Global Field CTO Shaun O’Meara joined Cloud Native & Coffee for a wide-ranging conversation on cloud pain. What roadblocks are end-users facing in their ongoing journey to make best use of cloud technologies? What blind spots exist in understanding how cloud can work, and how it can be leveraged for ROI? Most important: what steps can organizations take, today, to improve their cloud posture, focus on apps (vs. cloud operations), and avoid the complexity traps that stall so many cloud efforts?

Below is a complete transcript of that conversation. This episode of Cloud Native & Coffee is also available on YouTube (full video) and via all major podcasting services (audio only).

Hi everyone, and welcome to cloud native and coffee for Mirantis – conversations with cloud native experts from around the community and around the world. I'm John Jainschigg, Director of open source initiatives at Mirantis. With me is Shaun O’Meara, Global Field CTO, and today we are joined by iconic … I'm not sure he would like to be called iconic, but that was the first word that occurred to me … cloud journalist, Steven J. Vaughan-Nichols, who in his own words, has been writing about technology and the business of technology since CP/M was the cutting edge PC Operating System, 300 bps was a fast internet connection, WordStar was the state of the art word processor, and we liked it!

Or some of us liked it. Some of us preferred XyWrite, right? Steven was also co-founder and co-leader of the Internet Press Guild at netpress.org. In 2022, the Trade Association and Business Publications International awarded him its gold medal for top e-newsletter for the ComputerWorld Business Critical newsletter. And Onalytica listed Stephen as a 2017 top 25 Cloud and Open Source Influencer, a 2020 Top 100 Cloud Influencer, a Top IoT 100 Influencer, and a 2021 Top Hybrid Cloud Influencer. Also in 2022, he was listed in their Who's Who in Cloud. Finally, in 2019, Information Management Today named Stephen the year's top cloud computing writer.

But this is, you know, just the latest, pruned down version of your CV, right? Steven J. Vaughan-Nichols helped launch and edit Linux Watch and also Web Week, which became Internet World. Along the way he's written for every important computer, internet, and cloud magazine and website in the universe. And you and I were actually distant colleagues for a while at CMP Media or United Business Media or one of those media. We didn’t know one another at the time, but we got paychecks from the same people, right? It all blurs together in any case, after a while.

So our topic for today – and the way I lured Stephen into the room – is cloud native friction. Everything cloud keeps evolving. But as generation after generation of technologies and schools of best practice emerge around infrastructure platforms, application building, operations, and all these generations of stuff overlap and supplant one another, it feels to me like two things are happening, and I’m going to ask for your feedback on this.

One is that there does not seem to be a singular cloud technology anymore. People are having many different conversations about different things, their problems are therefore different, or at least feel different. So even if they have commonalities, cloud use cases are subdividing, people are viewing and describing their pains in different ways, and so that's making it harder to parse this pain, if you want to think about it that way. So my first question is, how would you pigeonhole cloud problems today? How many boxes of pain can we identify?

Oh, an almost infinite number. Now, isn't it? Yeah, it's big. There are some commonalities. So I mean, a few years ago, there was a real fuss over what was going to be the container orchestration platform. And that fight did not last for very long. Kubernetes won out, so at least we have that in common. Or I could say we have that pain in common. Because while Kubernetes is indeed very useful, and it's really good, there are lots of different ways to consume Kubernetes. And it's awesome. It's just really difficult for a lot of people to get their minds around. Which is why, you know, some companies like Red Hat and Mirantis, you know, go out of their way to make life easier for Kubernetes users. But even when you make it easier for them, I don't think anyone would call Kubernetes easy. And it's still, particularly once you start getting into more advanced use cases, it gets quite complicated. And while it does enable you to do some very interesting things with it – for example, I think the only real hybrid clouds out there, in the sense of you can actually run workloads over two or more clouds simultaneously and have them interact – Kubernetes is the only way to pull that trick off without tearing your hair out, in my opinion.

On the other hand, you are probably still going to tear your hair out. I mean, it can be done though, which is more than I can say for many of the other platforms out there. So, but once you get past that commonality of Kubernetes, things get more complicated both beneath that layer and above it. For example, what containers are you going to use? I mean, yes, Docker is there. But there are other alternatives we have – each has their pluses and minuses. And above that you have, you know, other issues like what network fabric are you going to use? Well, that's a darn good question. And how are you going to secure that? That's a really involved question. And there are many answers to it. And as one disaster after another, like SolarWinds, have shown, we really have to take care of our software supply chains.

And it all gets to be really complex. Particularly if you're looking for someone to do this for you. I mean, you need people who are developers, you need – as always – you need people who are … let's still call them system administrators. So their jobs have gotten much bigger and more complicated as time has gone by. You need your DevOps people, you need your security people, you need your network people who understand networking at a different kind of level than we've been saying before. And it's, so you've got all these balls in the air in this new mega platform that we call the cloud. And there's just lots of pain points out there. It's sort of like, you know, I don't know, it's Thursday, what's our pain point today?

But, Stephen, that's interesting. So if you're looking at Kubernetes right now – and I want to kind of narrow in on something you said – you alluded to this idea of above, and below that, I mean, I'm going to call it above and below the horizon line. We've got Kubernetes as an infrastructure tool, which is essentially that container runtime and an orchestrator. But everything that we do with Kubernetes, everything functional about Kubernetes sits above that – it actually is just a container or a runtime running above that underlying platform. Right? You know, there's one school of thought that says the underlying platform problem is solved. We'll come back to talking about the line in a second. But what do you think about that as a statement, if we look at this?

We're not there yet. We're really not. And also, actually, if anything, the platforms are getting more complicated. I mean, Windows is actually now you can actually do serious things with Windows and Windows containers now on Kubernetes. Now, personally, I wouldn't touch it with a 10 foot pole. But I know there's a lot of companies out there who are investing in the Windows containers universe, and Kubernetes will run with Windows, which is a thing unto itself. And then you have all these different varieties of Kubernetes where you have some people who are integrating it with their operating system, or with other platforms, like say, SuSE with … I'm blanking on the name of the company, they recently acquired someone else. (Shaun O’Meara: Rancher?) Rancher, Rancher, exactly. And you've got Red Hat, who is integrating it with their various programs. So you can very much still end up in a silo as it were, you can end up in the Red Hat silo, you could end up with a SuSE silo, a Canonical silo. And, again, and since Microsoft is now beginning to play a more important role here, you can no longer even really count on Unix, or rather (just my mouth) Linux as the one commonality that you can count on.

Because that's an interesting point, though. I mean, you use this term platform. And that's one of my pet peeves recently, talking to different companies, and they refer to our platform. What does that mean? I mean, what is a platform at the end of the day when it comes to underlying Kubernetes versus what we're running on top of?

Well, in this particular universe, when I think of platform, I'm actually thinking of what's more of a stack. I mean, I want the operating system, what variety of Kubernetes I'm running, what variety of container I'm running. So now that can be defined very much by the vendor that you work with. If you decided to go with all Canonical, though, they'll be happy to give you a complete up up and down the stack as well, SuSE as well, Red Hat,  etc. Or, of course, you can always do it yourself, which is difficult. But you know, companies which have a lot of technical expertise and lots of hutzpah, it takes a lot of courage to try that trick these days, you can, you know, mix and match. But generally speaking, what I'm seeing are companies adopting one stack or the other and they put that for some reason, they prefer to call it a platform, as you just referred to.

It's always interesting to me this whole idea of a platform because we all use this term, for as long as I can remember it in the industry. But right, I think that's a great word, and it clicks when you look at what it takes to run these platforms yourself. The question, which I always ask is, why is any company taking that pain on themselves to do that? Going back to the topic of pain.

What I see are companies that are still thinking of technology, and pre-cloud storage, or even really, almost pre-virtualization terms, deep in their heart, they still think it's a server in our server room in our data center. And it's all very much, it's a physical thing, we have control of it, we need to control the horizontal, we need to control the vertical, and they don't realize just how nigh unto impossible it is to control all those different elements. I mean, you've got to have not just an enormous IT team to even try this trick. You, you have to have, as I referred to earlier, a lot of expertise in a lot of different areas. And as anyone out there who's tried to hire people with cloud expertise of one kind or another knows, there aren't that many people out there who are capable of pulling this off, but still, there's this thought that we can do it.

And I think for many of these companies, if they haven't discovered it yet, they soon will. Because it's just … I mean, I like to think of myself as being technically pretty savvy. And I know a lot of really smart people who are much smarter than I am at actually administering and programming and all this stuff. I wouldn't do this, even if they gave me an unlimited budget and said go out there and do it. You know, yeah, I might, there might be some areas I'd want to have control over. Like security. And I feel pretty comfortable with security stacks and that part, okay, sure, but to do all of this on my own, even if you gave me an unlimited budget? I just know, I'm going to go and partner with someone who I feel like I can trust, let them do the bulk of the heavy lifting. That's what I'm paying them serious money for. And I'll just focus on what my business is good at. And because I'm a tech kind of person, I would also go ahead and focus myself on security or possibly networking.

I think that's an incredible point. I mean, ultimately, what are you as a business trying to achieve? Right focus? I mean, I, you know, if I'm a widget manufacturer, I'm not in the business of being an IT provider. I need to do what it takes me to sell widgets. And that's a good point.

Exactly. And, again, this earlier mindset, which is still out there, where some people are still thinking that, you know, servers or another cloud is just a bunch of you know, what's the phrase? The cloud is just a bunch of somebody else's servers? Well, no, sorry. It's not. You may think that way, but it is not a useful analogy.

Yeah. So that's the idea of cloud becoming ubiquitous compute rather than individual servers that I'm leasing. It is a big mind shift. I wonder if that's changing or just maybe not changing fast enough?

Not changing fast enough is my thought on that. Again, I've been at this for a really long time. I make my living from running right on the bleeding edge of technology and looking over the other side reporting on what I see. And even I still occasionally have trouble with just the fundamental concepts, because they're not the concepts I used in the 70s, 80s, and 90s, or even the oughts for that matter.

I suppose it's even a defining moment: what is cloud? What is a cloud? Right? And what your perception of that could be,

You know, really, it tells you a lot. When I talk to consulting clients as well, occasionally, and that's usually my opening question: what do you think the cloud is? Followed by: what do you think it can or cannot do? For you?

The answer to the first question is often very revealing as to whether or not a company’s C level people, anyway, are actually ready for what they're about to do. Or trying to do.

I should say, not to put you on the spot. But what's the scariest answer you've heard to that question?

Well: “It’s just a bunch of servers.” And if that’s true, we won't have to change anything. We'll just, we'll just lift all our applications, including the COBOL on a mainframe, just shift it? Well … you want to talk to IBM about that before you try it?

Not that easy.

Mainframes in the cloud, but that's a whole. That's a very specialized area. Again, go talk to IBM, if that's what you really want to do. But yeah, it's, you know, I actually, you know, that's not only a scary answer, it's a surprisingly common answer. They think of it almost as just being a pure business change, rather than technical. They think it's just a matter of, we're going to just pay for what we use, rather than pay for the infrastructure

Just pay in a different way.

Pay in a different way. And well, yes. But also no. Yes, if you take it to a certain extreme. But in most cases, no, that’s not at all the only thing that changes. So this is a very unfortunate analogy to try to revise your business IT plan around

So what is the problem we're trying to address? It's like, it's that question of what is the problem you're actually trying to address? Right?

Exactly. Exactly.

So continuing where I started off with a question, you know, we spoke about, you know, what's the platform? What's the underlying infrastructure, but one of the pain points that I'd like to understand is what you're seeing out there. For those companies, those forward thinking individuals, I suppose, or organizations that are not treating the cloud, and cloud infrastructure as just another server. And we're talking about the cases, the GKEs of the world, where you have a runtime and you’re loading a workload on top of that.

In that world, what do you think are the key pain points that they're experiencing? Where they don't manage that underlying infrastructure?

Well, a number of things. One is, again, just moving workloads is an early one. Everyone has trouble with it. Yeah, it doesn't seem to matter how well you think you know how you're doing that. You don't know it! Well, at last not until you have actually done it a time or two.

Another thing, actually, a term I just heard for the first time today is cloudflation. And that is: the hyper clouds of the world: the Azure, the AWS, Google Cloud, and so on. They're expensive, and they're getting more so. A lot of companies, their initial reason for buying into the cloud was this will be cheaper. It won’t be here, we won't have to pay as many in-house IT people. And it will be cheaper. And they're discovering that even if you do all the right things with your AWS to make sure that you don't have any idle VMs or idle containers – you know, just sitting there burning up CPU – the prices are going up. And combining with the other economic problems we're having right now. They're, they're getting a little … how to put it … they're upset that it's costing them more than they thought it would, say, even two or three years ago. And they're trying to get their minds around … Well, how can we really reduce our costs now? And which is, you know, it's not easy.

You can, of course, look to other cloud providers. But as anyone who's ever actually worked on pricing cloud services, it is not at all easy to determine what your real prices are. And what do the terms mean? If you're using an … oh, AWS lambda, for example, what the heck does that really translate to? As far as – forget about the technical side – just as far as dollars and cents are concerned? What does that really mean?

And the answer is, well hire a consultant and start working at it because there is no quick, easy answer to determine that. And if you look at say, say you want it to shift to say a smaller regional player, like, say, Akamai and LiNode – now since those two have gotten together, I see them playing an interesting role ahead. But can you? Can you take something that's from hypercloud, and then downsize it into something? I know at least a couple of companies are thinking about that sort of thing. And again, that's not an easy question to answer. And there are no easy answers for it.

And these are not really technical issues, but they’re business issues. And in a way, I guess it's sort of a good thing, because it shows that the cloud has gotten to a point now where there's enough acceptance of it out there, that people are now thinking of it in terms purely in terms of business, and financial issues, on some levels, rather than technology. Now, of course, you can't pull them away from each other. But at least people are beginning to think along those lines. Anyway …

Yeah, I suppose it's driving some repatriation. Sorry, John.

No, I was just gonna say: so cloud arbitrage finally exists. I mean, people have been talking about being able to arbitrage the costs of one service versus another. But it was always apples to oranges. And maybe that's less true today than it has been in the past?

Surely, that's how they're looking at it. Actually, arbitrage is exactly the right word. Thank you for bringing it up. And again, that's never something most people would have thought of three years ago. I mean, sure, people would say, Well, what, when they initially have a buy in, what costs more, what less, and occasionally, a company will get badly burned – usually, because they haven't really worked out how they were going to be using their cloud properly. And then they'll shift over. But in terms of, okay, we're paying X, surely we can do better. Let's look at the other options and decide if we could actually do better than that, on that sort of level seems to me to be new. I think I'll write about that, actually, the more I think about it.

But that idea of arbitrage. Also, maybe driving the repatriation – this is still pretty hard to do. Nevermind, just from a costing analysis. The technology really isn't there yet. I mean, right? I’d like to say, yes. Okay, we can run, what runs on one Kubernetes will run on another. But that's not strictly true. No. In fact, it's completely false in many cases.

Right? Yeah, it would be a lot. I mean, that's, to me, that's one of the great promises of Kubernetes. And I think that by, say, 2026, 2027, you probably will be able to do that, at least in some cases. But we're not there yet. It's still getting way back to the beginning of the conversation. Kubernetes is much more complicated than anyone ever thinks it's going to be. And people usually go into it knowing it's not going to be easy. But even if you think it's going to be hard, it's harder than you think it will be.

And then that makes efficient arbitrage impossible, right? Impossible because you can’t move workloads fluently from one platform to another, for example, because of differences in networking, because of inconsistencies in configuration of target Kubernetes clusters, etc.

Well, it can be done. But it sure isn't usually fast and easy.

But I think it also boils down to this idea of – if you're not building applications to take advantage of what the cloud native actually means. Right? It's going to end up being to a certain extent impossible, right? If you don't build things on a microservices base and take advantage of modern design, versus what we mentioned earlier with this lift and shift model. You can lift and shift from on prem to public cloud. But it’s going to cost you more. Right? Because you're not able to take advantage of those capabilities.

So then, the general feeling I get in listening to both of you is that people actually are saying we're not quite getting the ROI that we expected from this. And, and they're exploring lots of lots of new ways to try to recapture some of the expected return on investment. It seems like the world is still very far from a cloud native applications-oriented world, and needs to get from wherever we are now, this kind of hybrid legacy mindset and practice, to, to a microservices-based model. I mean, this is not to suggest that microservices are the answer for every problem. But fundamentally, applications need to be written to more modern cloud native architectures, and become some more self-operating and all of the rest of that stuff that the bleeding edge endorses.

And one of the problems with that is that it's a very … cloud native is a moving target. I mean, I, you know, I get paid to keep track of cloud data. And I honestly, I mean, this is one of the main things I do, and I can't keep track of all these projects. We look at the Cloud Native Computing Foundation diagram of all the things and it's just, wow, I can't even name all those projects. And I mean, I can probably name the most important ones. But what's going to be the most important? What's going to be like, the next hot thing in network fabric or security? I don't know, at this point, because there's a whole lot of competition going on. There's an enormous amount of change. How can you have best practices, when the software that you're considering using isn't even fully built? It's still in beta. I mean, not just beta and usable. I mean, in beta and it will bust on you at times. But you know it's going to be the future.

All that software that was written by one individual in their garage and made open source. And it might be a great piece of software, and tech companies are using it as the core of their offering.

Now, this is true. I mean, you don't, that's usually the case, especially with smaller bits of code. Like the famous cartoon with, you know, the one guy in South Dakota, his garage, that everyone depends on that one program. Which is both funny and also scary as hell, because that's true. It's not really an exaggeration at all. But even say, like blanking on the name of the company, Slim.AI – a company doing some really interesting work on security with a different mindset about how to secure containers. But it's still beta, it's still a small team, I think they're on their Round A of funding. So I think there's a reasonable chance that they're going to be a difference maker, I also think there's a reasonable chance that others … ChainGuard comes to mind – will also have their own take on how to secure containers, and so on. And which of them is going to win out? I don't know. Only the future will tell but both of them are very interesting approaches to securing containers, both of them have a lot of promise. I really look forward to seeing how they're going to work out. But if I'm having to decide today, what am I going to do? I probably would just continue to build containers off of Alpine Linux myself, because at least it's got a track record. Well, a track record of sorts, anyway.

He raises a really interesting question. You're talking about AI and AI type based companies. Oh, wow. There's a plethora of them starting to crop up, all doing one or two unique things, right? I mean, I have a certain fascination with the idea of operational … AIOps. But I also see, again, everybody is doing or saying they're going to do something. But everybody seems to be in a mode where they're learning this product. Right? Do you think we're going to see anything practical in reasonable time?

I think we will see practical programs. But what I see is very vertical kinds of things. Like I think that we will have, you know, self driving cars, I really think that that is going to happen. By the end of the decade anyway, sorry, Elon. But you know, we're going, we still have a lot of work to do there. But there's enough resources, enough money being put into that area on enough models. And frankly, though, making a car drive itself automatically with a bunch of other cars out there that are not driving automatically. Well, that's a tough problem. But at least it’s a definable problem.

But if you're talking about, say, anything to do with how people react to each other and say, oh, social networking, what's the word I want? Not censorship, but monitoring. Because that's a miserable job for humans. And it's not working out. Well, it would be great if we had a machine learning model that could pick up and really spot people who are doing fake news or doing whatever it is that you don't want on your social network. But we're nowhere close to that. There are a lot of models out there. There's a, I'm blanking on the name of the company. But there's a company working on labeling and machine learning, not in the sense of labeling this process or that process, but trying to identify prejudice, and trying to be able to spot it and give that concept a label. But it's proving, as you would guess, very difficult to pin down. And this is a step in that direction. But we're not there yet. I think, individually, we're going to see some really great stuff coming along.

But I don't see any … What's the word I want? I don't see a sea change happening with AI and machine learning that's going to transform the world. There's a lot of conversation now about how machine learning and AI might change programming so that we won't have to have developers anymore. And my reaction to that is, okay, you're going to be able to let this AI with this machine learning database behind it decide on something … You still need to describe the problem in such a way, in such detail, that it's able to actually solve the problem you're working on. Now, what do you call it? When you figured out what a problem is? And you write …

… very detailed instructions to solve it … you might even say …

There are managers out there who might argue with that, but yes …

It's still a program, you're still gonna have programs for at least another generation, probably. Sorry.

I think we're at the stage with I mean, I personally think it's still at the stage of glorified automation.

Yeah, I mean, it's like, DevOps certainly transformed how we did system administration, but we're not yet where AI is impacting programming anywhere close to where DevOps has transformed system administration. It's just, we're not. And that's really just a lot of automation using a lot of different languages. Again, can't avoid the languages you know, even if you do make it “easier,” and I just don't see that. Yeah, I just don't see it. It will get lots of ink. I'll get to write about it some, but I don't see it transforming the world yet. A lot of people …

… Do, though. Interesting. Well, maybe, watch the space and see what happens. Maybe it'll be entertaining. Yes, for sure.

It may end up, however, transforming many lives. I've been looking at the work that people have done around DALL-E. My brother is an artist who teaches at the Rhode Island School of Design and has been tasked with coming up with an institutional response to large language models and their use in image generation. And that's a thorny problem, a lot of artists are, in a practical sense, likely to have their work significantly changed and impacted by that kind of AI. Or all the truck drivers in America. You know, truck driving is the number one job people report as the job they have. And self-driving trucks are absolutely going to change that. So there will be you know, the future will be here before we think for some people, and not evenly distributed.

It is already in many ways, just your artistic example. Twenty years ago, photographers retouched things using paint and masks. As of 10 or 15 years ago, they were using Adobe. Today, they load a picture and say, remove the red, change the background, and they just pick up the baton and suddenly they've got these perfect images. (Shadow falls across Shaun O’Meara’s face.)

Weird. In the second that you said that, some sort of shadow came across. Like the lights went on and off. I'm gonna leave that in the edit. We're not editing that out. It was Word from Above.

That's an interesting point, though. John. I didn't see Waymo coming in (Google’s former name for its self-driving car project). And that makes such a difference, because you had that guy in Colorado who won the prize. And that really kicked the conversation off. But yeah, it is going to be a transformative experience. And I will be very interested in seeing how that goes. As far as truck driving, well, it's a very common job. It's also a job that's aging out. The average age of truck drivers is really quite up there. It's – I think – I haven't looked at the numbers recently. But it's well into the 50s. So I expect that will certainly transform things. But I don't see it transforming the job market that much. But there doesn't seem to be that many young people becoming truck drivers. That is going to be interesting, because I'm old enough to remember when just the idea of Photoshop, just using Photoshop was just oh, you can't do that. I mean, how can you be a true photographer, if you manipulate your image? Now? There are a few photographers out there who don't use it, but they're darn few.

So I think we've exercised some of these questions, we've identified some of these pain points. Can we, in a final couple of minutes, enumerate some ways forward? Where are the low hanging fruit in helping people get to the next step towards better ROI, being able to spend more time developing applications, less time worrying about what's under the application line – platforms and infrastructure – but without relinquishing control? People have rational objections to loss of control as well as perhaps legacy, you know, objections. So what are things that we need to do, industry wide, to innovate?

I think they have to learn to let go of control a bit. You really need to, unless your business is being … Okay, software is eating everything. We know that. But there are many businesses where you don't have to worry about that part of it. Like, oh, I don't know, if you're a widget maker, worry about widget software that will make your widgets more speedily come out of the factory or what have you. That was awkward, but I think you get the idea. Sorry …

I started with the widget thing earlier.

It's a great word,

Spacely Sprockets.

There you go. Spacely Sprockets. Oh, I like that. I must remember that. I mean, the Jetsons didn't just turn 60, I think, the other day, and it was a scary thought.

But they look marvelous. They do. They really do.

It's amazing what being made of ink will do for you. Anyway, but okay, so yeah, focus on the software part that you actually care about. Otherwise, find the expertise you need outside your organization. If you're Spacely Sprockets, you really don't need to be cloud experts, you certainly don't need to be Kubernetes experts. But find a partner who can do that for you. Or at the very least, find someone who you will buy the entire stack from, from start to finish. Let them worry about that part. Take a deep breath, you can't do everything. Worry about what you can do, and what's good for your business – what will work well for you in the long run, and find the expertise you need outside, and use that expertise. That will save you a lot of wear and tear on your nerves. You know, and also, in the end, save you a lot of money.

Yes, spend some money upfront to save you money in the longer term. Yeah. Really focusing on what you should be doing. Right? Experts handle the rest. Like we're gonna get a better economy of scale like way, no matter how you look at it, right?

Yep. And I guess that's all she wrote. That's our show for today. A huge debt of thanks to Steven J. Vaughan-Nichols for joining us. Thank you, Shaun. And of course, thanks also to our colleagues: producer Nika, and to Luis and DJ on social and video. We're available in podcast format on all the major platforms. And you can also join us live every other Thursday at 1 PM Eastern through, the Mirantis LinkedIn page. Thanks to you for listening and we'll see you next time.