Search
Follow me:
Listen on:

Day Two Cloud 120: Web Assembly, K8s Rivals, And Other Cloud Computing Trends

Episode 120

Play episode

On today’s Day Two Cloud we talk trends and predictions in cloud computing, including emerging technologies such as Web assembly, rivals to Kubernetes, and the role of GitOps in infrastructure as code.

Our guest is Adrian Mouat, Chief Scientist at Container Solutions. His blog post “10 Predictions for the Future of Computing or; the Inane Ramblings of our Chief Scientist” inspired this episode.

We discuss:

  • Why technology predictions are tricky
  • Which predictions Adrian is most confident about
  • Web assembly and why infrastructure folks should care about it
  • Will GitOps become the dominant way to run Kubernetes
  • Whether cloud repatriation will become a thing
  • More

Sponsor: Aviatrix

Check out Aviatrix’s Flight Training to learn about multi-cloud networking and security. It’s worth your time if you’re defining your company’s multi-cloud strategy or want to nail down your Aviatrix Certified Engineer certification. Get details and register at aviatrix.com/flight-training.

Show Links:

10 Predictions for the Future of Computing or; the Inane Ramblings of our Chief Scientist – Container Solutions

@adrianmouat – Adrian Mouat on Twitter

Adrian Mouat on LinkedIn

GitOps: What You Need To Know Now Ebook – Container Solutions

Day Two Cloud 100: Get To Know Crossplane: An Infrastructure Control Plane For K8s – Packet Pushers

To learn more about WASM, check out any articles and presentations by Lin Clark or Kevin Hoffman.

To learn more about GitOps, follow Alexis Richardson

Transcript:

[00:00:01.030] – Ethan
Check out sponsor Aviatrix’s Flight training to learn about multicloud networking and security from the Aviatrix perspective, Aviatrix dot com slash Flight-Training worth your time if you’re defining your company’s multi cloud strategy or wanting to nail down your Aviatrix certified engineer, Cert Aviatrix dot com slash flight-training.

[00:00:28.190] – Ned
Welcome to day two. Cloud today is an episode about trends and predictions what’s going to happen in the future. And we’re going to gaze into a Crystal ball with Adrian Mouat. He’s the chief scientist over at Container Solutions, and he had a bunch of different things he wanted to talk about. One thing that jumped out to me was web assembly. It’s a thing that I keep hearing about. I hear whispers in the hallways or the virtual hallways as it were, that this is a new technology that’s going to replace a bunch of things.

[00:00:56.750] – Ned
And he set me straight on what it actually does and what it actually might replace. So for me, that was the most interesting thing. Ethan, what jumped out to you in the conversation?

[00:01:06.290] – Ethan
Oh, there are a couple of other things when we got into Kubernetes and what comes next because of some of the complaints about Kubernetes getting complex and so on to implement. So where do we go next? Is it Kubernetes or something else? But then a bigger idea for me Ned, that was the notion of Git Ops and the trend of dealing with infrastructure as code and managing that code in some kind of a version control repository, which enables you to operate with a large group of people that you are doing Ops work with.

[00:01:33.410] – Ethan
And how that looks. That’s been grabbing my attention because it’s a complicated thing, but, oh, baby, it’s necessary.

[00:01:42.110] – Ned
Yes, you need that single source of truth that the environment can draw from and GitOps gets you there. So that was very cool. Enjoy this conversation with Adrian Mouat, chief scientist at Container Solutions.

[00:01:52.790] – Ned
Well, Adrian, welcome to Day two cloud. We’re very excited to talk to you. And the whole Genesis of this discussion was a blog post that you wrote about trends in cloud computing and some predictions. Now I know when we make predictions that can always be a dicey prospect. So I like that. I think you called them more trends than predictions. Can you just start us off with what was the thought process behind writing that post?

[00:02:20.810] – Adrian
Yeah. So at Container Solutions, we actually have an editor to help out with our blog posts and the whole process, and also to go over a post and correct all the dodgy English. I think it was Charles’s suggestion, so I think he’s got background like info queue and other places. I think it was his suggestion to write this blog post. I can’t fully remember slightly lost to the mists of time, but basically what happened is oh, yeah, I can do this in an afternoon, and I had things at the top of my head, and I just started writing in an afternoon.

[00:03:00.750] – Adrian
I had a lot of thoughts, but then it just so spiraled. I mean, it got completely out of control and then people then I show it to somebody and they had so much feedback and said, hey, you should look at this as well. It got ridiculously out of control. And at one point I had to say like nobody else has seen it. It’s done. Now I’ve got enough end of. But regarding the predictions, I did call it predictions. So the official title is Predictions for the Future of Computing, or the Inane Ramblings of our Chief Scientist.

[00:03:34.290] – Ned
You are the chief scientist.

[00:03:37.530] – Adrian
So I did try to take the edge off by sort of saying Inane Ramblings. But yeah, it really felt like sometimes I don’t know how much you write blogs, but sometimes when you start writing, it just sort of flows because ideas at the top of your head and that’s how it started. And that was nice. And then it went from there and was not so pleasant.

[00:03:59.490] – Ethan
It starts with an idea and then you get flowing and then more and more happens and comes to your mind. And the next thing you know, it’s like, this is going to be a 500 word post, and it’s 2000. Yeah. Or more, right.

[00:04:09.990] – Adrian
Yeah. More or less. Sometimes I’ll go to write a blog and I’ll have to research it and work through it and structure it and it doesn’t flow. It’s hard work. But because some of this had been stuff that I was thinking about at the time, it was on the top of my head so I could just let you just sit down and type. But then all the feedback, all the talking to people, all the further suggestions, all the going down the rabbit holes. That was a painful part, right.

[00:04:33.870] – Ned
And you did call out. I think there are ten things total in the list and listeners, if you’re interested in reading the post, it’s on the long side, but it’s super readable. I didn’t realize how long it was until I got to the end. I was like, oh, wow. Okay.

[00:04:48.870] – Ned
I highly recommend reading through the post we’ll include it in the show notes. But I do want to call out some specific predictions that you made just because predictions are tricky in technology stuff is changing constantly. Ten years ago, we didn’t know what a Kubernetes was, and now I guess I can spell it. So I’ve made it that far out of the list of ten. What were some of the predictions that you felt very confident about in the list?

[00:05:18.690] – Adrian
Trying to choose ones I’m more confident about. We’ve picked out some of the more interesting ones, at least. So one was like Kubernetes rivals and some of them that you can see happening already. So a lot of them are less risky because they’re sort of happening already. The big question is to what extent did they happen?

[00:05:37.170] – Ethan
Right.

[00:05:37.650] – Adrian
So one obvious one is like Kubernetes rivals, but we’re definitely already sort of seeing things there. But the question is, will any of them actually overtake Kubernetes? And how long will it take for that to happen?

[00:05:52.170] – Ethan
Well, you can look at those rivals, Adrian, as are they rivals or more alternatives in the sense that some people will need full blown Kubernetes for everything it gives you. But other folks, they tend to complain about the complexity of operating a Kubernetes environment are maybe looking for something simpler. And maybe that’s where rivals and alternatives come to the floor. Yeah.

[00:06:14.970] – Adrian
I think you’re absolutely right. So what you’ll probably see is for simpler use cases. As you mentioned, you’ve got stuff like Cloud Run, AWS equivalent, things where you can just run a container and you don’t have to worry about the whole Kubernetes or whatever. And that’s certainly easier for stuff on the simple side. I think one of the big questions, though, is will we see a platform as a service or a PaaS thing on top of Kubernetes to simplify things? Or will we see people using things that are completely different?

[00:06:53.130] – Ethan
You don’t mean Kubernetes as a service. You said layer on top of.

[00:06:57.330] – Adrian
Yes. And you see us a bit like platform as a service. You see a lot of companies is they might use Kubernetes, especially large enterprise companies, but they use it in a specific way. And you have stuff even like OpenShift. It’s really like a layer on top of Kubernetes. And what we see and we’ll see more of is the company saying, okay, we use Kubernetes, but the way you use it is this and you’ll have their own sort of layers and tops. You’ll define your services in a certain way and they’ll have libraries to help you.

[00:07:29.370] – Adrian
And if you do it that way, it will work a lot nicer. But there’ll be certain things that will be less flexible at the same time. Okay.

[00:07:36.810] – Ned
So Kubernetes Rivals was one another thing that jumped out to me. And I think you’d also brought this up in a previous conversation we had was GitOps. So what about GitOps was a trend or something you’re seeing that you think will advance or mature in the next five years or so.

[00:07:54.630] – Adrian
Yeah. So that’s one. That’s definitely how it happened to now, and I’m just kind of tipping it to become bigger. The question is, will it become the dominant way to run Kubernetes? And I think that’s a good chance. It kind of will. I’m not sure if I should define what GitOps is now or not. Come back to that.

[00:08:15.990] – Ned
We can come back around to GitOps. I want to get the other two items in and then we can expand on all of them. So another one. And this is one that we’ve had conversations on day two cloud about before, but I do want to hear your perspective on it. Is cloud repatriations. Is that something you have actively seen happen, or you’ve just been reading some articles about it and thinking to yourself, yeah. I could see that occurring more often.

[00:08:44.430] – Adrian
Yeah. More or less also conversations with people that are more involved in the industry. So we’re looking at things like oxide computing and where they’re going and the fact that they think there’s a market for building compute. I assume it is set up from the start to work well in a data center environment or on Prem environment that perhaps some of the traditional big iron companies haven’t been doing such a good job of. I assume they’re even more to provide a cloud like experience for on prem users. And I think we’re also starting to see Dell and HP heading down exactly the same road.

[00:09:28.410] – Adrian
And so just based on what the vendors are doing, I think it’s definitely something. And also I’ve listened to Brian Cantrell to talk about it and you get into the things like Capex and Opex and so on. So yeah, I definitely think there’s a good chance that will happen just from conversations. But it’s not something that I can point to specific instances of.

[00:09:49.050] – Ned
Okay. And the fourth one that I saw this was sort of it had its own section, but it also seemed to be sprinkled through a lot of the other ones. Was Web Assembly or WASM I’ve heard it called what about that really has struck a chord with you.

[00:10:04.710] – Adrian
Yeah. I think that’s probably a good answer to your earlier question. I guess that’s what I was really thinking about when I started the Predictions blog post. So I can’t claim to be very knowledgeable about WebAssembly. I’ve only played with it, but even from playing with it and from talking to people, I can see it solves a lot of the issues that we’ve had in computing in the past. And the reason I sort of got into it at the start was because of the comparisons with Docker. Like my history.

[00:10:35.970] – Adrian
I wrote a book on Docker. I’ve been involved a lot with Containers, and this is famous like Tweet by Solomon Hikes, who was the founder of Docker, where he says if we had a web assembly, we wouldn’t have needed to create Docker. And it’s all about basically portable computing.

[00:10:52.470] – Ned
Okay. Yeah. That’s something Containers definitely gave us, but it’s still reliant on the construct inside of Linux, the way that it’s wrapped up. It really took existing tech and just made it easier to use. Right?

[00:11:05.430] – Ned
That was Docker’s whole claim to Fame was, hey, we took this complicated thing and made it easier for you.

[00:11:11.910] – Adrian
Absolutely.

[00:11:12.690] – Ned
So this is a good place to dig in more because WASM was at the front of your brain for writing this post. What is WASM? I don’t necessarily understand what it is and why it matters from an operation and cloud perspective. Is this just like a developer tool?

[00:11:34.290] – Adrian
Yes. Well, probably not. So WASM or web assembly standard joke is that it’s neither web nor assembly, which is kind of true. And from the Web part of that, it certainly goes beyond the web. So it’s actually got some pretty nice use cases just for, like, on laptops or machines that aren’t even necessarily connected to the web. It doesn’t have to be in a browser, although that’s kind of where its origins are. And the assembly part is an interesting one, because technically it’s not an assembly language because it doesn’t target hardware.

[00:12:13.770] – Adrian
It targets like a virtual machine, if you like. But it’s a very simplified virtual machine. So in some ways it’s like a cross between Java bytecode and real assembly. I do also wonder if somebody creates hardware that runs Web Assembly. Does it then become an actual assembly language?

[00:12:34.890] – Ned
I would give it a pass. Yeah.

[00:12:38.070] – Ned
So in a way, it’s very similar to what Java was trying to be, which is having a JVM for each operating system. But in some regards, is it faster, more efficient, more secure than Java? I know Java has been plagued with security issues for quite some time.

[00:12:56.670] – Adrian
Right. So that’s kind of exactly. I gave a talk, like a couple of months ago on web assembly, and that’s kind of exactly the approach that I took comparing to Java because I think that gets at the heart of a lot of what it is because, of course, Java had this write once, run anywhere idea. So we’re talking about Docker containers a minute ago, and the thing with Docker containers is you still have to target like hardware, which is normally X 86 64, but there’s no reason you can’t have Arm whatever containers, RISC-V containers or whatever.

[00:13:27.630] – Adrian
But then you’ve got to compile things for that given architecture. With web assembly, it’s a Byte code. So as long as you have a virtual machine for that architecture, it will run, which is the same as Java, I think that’s the right way to think about it. If you compare it to Java, it’s a lot simpler byte code. I mean, the thing with Java, the Java byte code was never really intended as a target. I set for the Java programming language, whereas WebAssembly is actually much simpler to implement than that would be to implement to target some JVM or even implement a JVM for a new platform.

[00:14:10.350] – Adrian
Yeah. So I think you also there’s a question, but is it like a language or framework or a platform, and it gets a bit complicated in some ways. It’s all those things because one thing. Okay. We have this web assembly target, but it traditionally needs a browser to run in. It needs some way. There’s no sort of input output defined. The way you do it input and output in WebAssembly is you just have a flat section of memory, basically a big array, and you can write to that and you can read from that.

[00:14:41.070] – Adrian
And that’s it. So you need some way to interface with the outside system. You need to go between the sort of flat memory and the OS or the browser, and that’s where all support and web assembly libraries and frameworks and so on come in.

[00:14:56.430] – Ethan
But it isn’t a language, though. As of the reading I was doing on it. Adrian, it felt like an environment that supports potentially a variety of languages. And I think most of the examples I read show JavaScript being executed in a WASM environment. Can we at least make that delineation?

[00:15:16.410] – Adrian
Almost? I would say to be perfectly Frank. I’ll give you some links for the show later, but one of the really cool things I found you can write WebAssembly, and it’s interesting. It’s very informative to write web assembly, and there’s a book I’ve got somewhere here by Kevin Hoffman, who wrote a really nice book on web assembly, and it opens. It starts with showing you how to write raw web assembly, but there’s also like this really nice small examples of, like WebAssembly that you can run directly in the browser, and it’s all pretty cool stuff, so you can write web assembly, but you probably don’t want to. It’s almost like writing X 86 assembly.

[00:16:02.610] – Adrian
It’s not.

[00:16:03.210] – Ethan
Very low level, but.

[00:16:05.190] – Adrian
It’s very low level. It’s very informative to help you understand what webassembly is, but it’s very low level. So this is partly for the lie of WebAssembly is a little bit. So generally you’re going to be compiling to WebAssembly from another language. So the big ones there are JavaScript and TypeScript and Rust, and those languages have really good support for compiling down to web assembly. One problem with JavaScript is it’s like a garbage collected language, and you don’t have a garbage collector or anything like that in the WebAssembly specification or virtual machine.

[00:16:41.790] – Adrian
So you have to put that into your own code. So if you write JavaScript code and target web assembly at the moment, you end up with quite a large file because that file has to include the web assembly has to include, like, a garbage collection and so on. That’s one reason that Rust is really popular because Rust doesn’t have a garbage collector. You can end up with a smaller mix of WASM file. Now if you look online, you’ll get people claiming that there’s, like, 20 different languages that compiled WebAssembly, and it’s sort of true.

[00:17:19.110] – Adrian
But in reality there’s only like a handful that really makes sense, primarily being Rust and your TypeScript.

[00:17:25.830] – Ethan
Because if you take those languages and use WebAssembly as the target, you’re saying some of those it’s going to be what inefficient WASM that’ll result or just kind of pointless.

[00:17:34.650] – Adrian
Both of that. The other big thing is just how mature they are. So Rust has very mature support for web assembly, and so does JavaScript and TypeScript, and some of the others don’t. And I think Go is coming along. I’ve not played with that much, but I think Golang probably has good support. But again, Golang has this need for garbage collection. However, my understanding I’m not really up to date on the current situation, but I think we are looking at including garbage collection in future versions of Web Assembly.

[00:18:09.570] – Ethan
So WASM feels like a compiler to me where you’ve got some higher level language you’ve written in. It gets compiled down, in this case, to WASM code instead of whatever code it would have been native to your processor. Let’s say the native, quote, unquote environment we’re compiling to is WASM. Is that a fair analogy?

[00:18:31.530] – Adrian
Almost.

[00:18:31.530] – Ethan
Almost again. So close.

[00:18:36.210] – Adrian
So you absolutely do compile to WASM. It’s a compiled target. The thing is, what you use to compile to WASM is left to the community. So like the Rust compiler itself is what you use to target WASM. I just have to tell Rust my target’s WASM and it creates the WASM for me, right.

[00:18:53.610] – Ethan
Okay. Yeah.

[00:18:55.770] – Ned
Okay, yeah. That speaks to why there would be different levels of maturity for different languages, because someone has to write a compiler for each language to get it down to WebAssembly, and then WebAssembly can take over.

[00:19:06.570] – Ethan
So then that WASM object that we get as my target. I’ve compiled my code down to that’s like any other web object. I can ship that across the Internet as a dot WASM, get it in my browser. And if my browser knows what to do with that, then I can execute that object.

[00:19:23.550] – Adrian
Yeah, exactly. So it’s almost the same as a Java jar file, and it can be used on any platform. It can be used in IoT, so you can get relatively small WASM files. So IoT is like a big use case and any browser on server back end, et cetera. Yeah, it’s great.

[00:19:43.950] – Ned
That actually leads into my next question because I’m trying to think of where this would be useful. And right now everything seems to be like leaning on JavaScript, at least in the web world. Like back ends written using JavaScript front end is using it. Is WASM and WebAssembly going to replace some of those components or just make the existing JavaScript run better, because maybe you can take what you have and compile it for web assembly instead.

[00:20:10.230] – Adrian
Yeah. Exactly. So I think it’s mainly going to be symbiotic I think is the word there. It’s not that WASM is going to replace things. It’s like you’re going to use WASM alongside. I think more. So you might find, to run in the browser you have to use JavaScript to run WebAssembly. Javascript provides effectively the interface between WASM and your browser. So JavaScript is actually essential to WebAssembly. So it’s an argument you’re going to end up with more JavaScript you can potentially use WASM to replace, like computationally intensive parts of existing JavaScript libraries, et cetera.

[00:20:52.050] – Adrian
And that’s the web side of things. But there’s also a lot of use cases like IoT, as I mentioned, or on the server side, where you might not need JavaScript at all, or you don’t need JavaScript at all.

[00:21:05.490] – Ethan
[AD] I’m rudely cutting into this conversation to ask you where you’re at with your multi cloud networking strategy because a few different multi cloud networking vendors, they’ve come on as podcast guests and they’ve shared their approach here on the Packet Breakers Podcast Network. One of those vendors is today’s sponsor Aviatrix. In fact, you heard from Aviatrix engineers and a customer as Ned and I nerded out with them on the Day Two Cloud Podcast episode number 113. We covered their data plane that’s common across all the different clouds, giving you consistent network operations.

[00:21:34.470] – Ethan
Now, if Aviatrix isn’t a company name, you know very well, don’t just blow them off. I challenge you to consider all vendors that might solve your problems, and Aviatrix is going out of their way to make it easy for you to include them in your upcoming multi cloud networking Bake off. First, they are well funded, so they’re going to be around for a long time. Tell your boss, Aviatrix just closed to $200 million Series E funding round if you get asked. Second, Aviatrix is also offering Nerdy deep dives for you, the engineer, so that you can make an informed, nuanced decision about whether Aviatrix is the right multi cloud networking strategy for your organization.

[00:22:10.710] – Ethan
They call it flight training, and you can go for a 90 minute, hands on lab, a five hour deeper instructor led hands on experience and even prep for the Aviatrix Certified engineer certification. So give Day Two Cloud Episode 113 a listen and then visit Aviatrix dot com slash flight-training to find out more. I’m hoping to take the five hour flight school training sometime myself soon if they can find room for me again, that is Aviatrix dot com slash flight-training and let them know you heard about it on the Packet Pushers Podcast network.And now back to today’s episode. [/AD] [00:22:48.030] What are the major use cases for WASM? What are they going to settle out to be? Everybody is talking about what a big deal it is. But as I was admittedly, doing a light amount of reading compared to the amount of reading I could have done to prep for this, speed kept coming up as the big thing, the efficiency of it, the ability to run something faster. So is that the big driver for WASM, Adrian, or is it other capabilities we get in addition to this performance?

[00:23:12.930] – Adrian
I think that’s where it started. I mean, I don’t know, I’m not an expert in history, but I think that’s basically where it started was this idea that we need to do something fast for browsers like games and stuff like that. So doing things fast in a browser.

[00:23:28.110] – Ethan
Ah, you just reminded me there’s a Doom three Port that was done in WASM. I guess it’s a bit early, but it’s kind of a proof of concept.

[00:23:34.410] – Adrian
Yeah. So that’s where the speed part comes from. But there’s an argument that it’s going to be if I’m writing in Rust and I target WASM presumably the WASM is going to be considerably slower than if I created, like a native executable for Rust because it got to go through the WASM virtual machine. I don’t really. It’s not something I’ve benchmarked, but presumably there is a hit there. But regarding use cases, there’s a lot of different use cases. IoT is an interesting one. I’d be very interested to see if that one happens because of the platform independent nature of it.

[00:24:11.770] – Ethan
Well IoT why? Just because WASM lets me do something with minimal amount of computation and memory power, that kind of thing.

[00:24:20.470] – Adrian
Yeah. Well, it’s just the whole Java thing where if I create something in WASM, I can run it on. I don’t care about the architecture of the thing that I’m running on. So hopefully I can support a bunch of different platforms, and they’ve got something small and relatively efficient for, like, lower powered things as well.

[00:24:40.810] – Ned
Right, and I think you sort of compared this to Docker, where Docker is architecture dependent. So if I want to run a Docker image on X 86, I can’t run the same image on some Arm processor in a Raspberry Pi or something. But if you’re developing for IoT, it might be Arm. It might be X 86. It might be RISC-V. It might be some future new architecture that we don’t even know about yet, but it sounds like if I do it in web assembly, it’s going to run on any of those architectures, and I might not have to redo my code at all.

[00:25:13.750] – Adrian
Yeah, exactly. Hopefully. And that’s kind of why I compared to Java because the promise of Java that was never really fully realized. So I sort of wonder if WASM’s the spiritual successor of Java.

[00:25:28.210] – Ned
Sounds like we might have to do a whole completely separate episode just on Web Assembly. Let’s move on to GitOps. So we mentioned GitOps a little bit. And for folks who are not as familiar with GitOps and Git and kind of what’s going on there, can you just explain a little bit about what GitOps is and what it’s intended for?

[00:25:49.930] – Adrian
Yeah. This is a bit embarrassing. I’m doing a training on GitOps next week. I guess the time this podcast comes out, I’ll be like last a few weeks ago, but yeah, I’m not really an expert. So I’m currently trying to get up to speed, basically, especially with Kubernetes. We define our systems in declarative like YAML files. And so this is obvious thing about saying, okay, it’s in YAML. Yaml should be version controlled. And when you get to that stage, you’re like, well, if it’s version controlled, we can start using the GitHub style of operating on things with, like, pull requests and vetting changes and using that model to push out changes and literally have control over the changes that are happening in our cluster.

[00:26:38.470] – Adrian
And also it gives you a bunch of other stuff like you can audit things, you can see what changes made, who they were made by, and you can make sure outside changes aren’t made by accident and things like that.

[00:26:49.570] – Ned
Right, You can run git blame and see who made that change. That broke production.

[00:26:53.710] – Ethan
Freakin’ Ned1313. Again. Why did you do it, Ned? Why?

[00:26:59.710] – Ned
Because I can, Ethan. So I guess that sort of answers my question of how this trickles from Git and developers, because typically when someone says git or git and I usually think of GitHub, but I know Git is its own thing. I usually think of developers, people writing code for applications and stuff. And now that seems to be moving into operations. And oh, GitOps. Okay, now operations is involved. But you said this at least starts with Kubernetes, which uses that declarative syntax, which I can store in version control somewhere.

[00:27:33.790] – Ned
Does GitOps extend beyond the Kubernetes ecosphere? Are people using it for something that’s not Kubernetes to manage an environment?

[00:27:42.370] – Adrian
Yeah, that’s a really good question. So I think the approach is appropriate for all sorts of declarative platforms. I don’t know what the word is. So as long as you have YAML or some equivalent that defines where you want your platform to be as opposed to the steps you take to get there. So it wouldn’t work for something like CDK or Pulumi, which is code. Well, I guess it does, but it’s a bit different, but it would work, I guess, for more one place you already see it, I think is a lot of people that are doing GitOps, I think also covered the TerraForm. Right. So the actual code used to spin up and define the cluster is also covered with GitOps. Yeah, I think is appropriate. And we’ve all set you to the place I was going to mention, I guess, stuff like CloudFormation, potentially, I’m winging it a bit here. I’m not really 100% sure.

[00:28:38.710] – Ethan
There’s a small number of network operators that will keep some sort of a code base tied into Git being a repository of code snippets that are a source of truth for various aspects of what they’re doing. And yeah, that could be playbook or YAML kind of stuff, but it also could be just straight up. It’s a Cisco box I’m managing. I’ve got some Cisco iOS paragraph, some stanza in here that accomplishes something. And I’ve interviewed folks that they’ll use that as again their source of truth and run code periodically to compare.

[00:29:11.110] – Ethan
That what they’ve got built out of the infrastructure and what is in git, the golden code, match and then make it so, if it’s not. So it is a form of declarative, if you will, to make that happen. But I guess my question for you, Adrian, is, do you see lots of people on the operation side taking this get off approach, like there’s a movement where we’re heading there? I mean you marked it as a trend but to me, it still feels pretty cutting edge because operators are trying to get their heads around this way of thinking and how to use these tools.

[00:29:38.890] – Adrian
Yeah. So I think it is, but that could be because I live in a bubble. So a lot of my background is with Docker and so on. So I’ve talked to people or I hear talk to people like Alexis Richardson from Weave. He started or named the movement, at least, and we’ve Flux, which is one of the major tools in GitOps, so possibly because I’m in that Echo Chamber. I hear about it a lot more, but it certainly seems to be to be picking up. People are interested in it.

[00:30:12.430] – Adrian
Like I said, we’re doing a training next week. Yeah, it certainly seems to be gas and steam as far as I can tell, and we certainly see it at some of our customers. Our customers are certainly interested in it. I couldn’t say how many of them used in production, but yeah, in my view, it’s getting there, right.

[00:30:32.950] – Ned
You’re seeing it in the experimental phase now and then a couple of years down the line. Oh, look, that experiment ended up in production. I hope it works.

[00:30:41.470] – Adrian
And also, I think a lot of smaller companies are using it in production right now. I think they’re seeing a lot of gains by it as well. I think it’s definitely going that way.

[00:30:51.310] – Ned
Okay.

[00:30:51.490] – Adrian
I probably get an angry, like message from Alexis. Now tell me I got completely wrong.

[00:30:57.490] – Ned
Alexis is welcome to come on the podcast and correct all of us. Let’s get back to the wonderful world of Kubernetes. Not that we ever left. I feel like we’re living it’s a Kubernetes world, and we’re just living it. But at some point, it might not be a Kubernetes world, and you were sort of indicating that you think there might be something beyond Kubernetes. So what do you think of as the next evolution beyond Kubernetes? What would it include that Kubernetes lacks today?

[00:31:30.410] – Adrian
Well, I think the problem is Kubernetes doesn’t lack anything at all. It’s like the kitchen sink, everything has been thrown in there. So what I see is the next evolution is really simplification. And I guess that’s what these things tend to go in almost like circles or spirals or something. So one thing comes up as a reaction to what was there before, and I think that’s possibly what we’ll see is like a next Kubernetes that fixes the mistakes of Kubernetes in the same way that Kubernetes fixed there’s, like stuff like Mesos and so on before Kubernetes, and they learnt a lot of the flaws or shortcomings from previous cluster orchestrators.

[00:32:10.790] – Adrian
We talked about this before. I mean, I’m really not sure what we’ll see or what will be the next dominant thing. I just feel like Kubernetes has become too big and too complicated for the majority of people and we’re seeing Google trying to have to simplify it with their automated offerings. And so on.

[00:32:30.050] – Ethan
I mean, too complicated because we nerdy engineers like to flip on all the switches and throw the levers and turn the knobs, or, in other words, it’s there, and we’re using it because it’s there. We could use it in a simpler way. Or is it just become too much of a beast to operate?

[00:32:46.670] – Adrian
It’s a bit both. I mean, it’s interesting because I seen it evolve from the start, and I really liked it at the start. There was a few concepts to get your head around like pods and so on to say, I should say, I still do like Kubernetes. It’s just grown into a bit of a beast. There are so many different options, and people use it in so many different ways. To the extent that if you’re used to one Kubernetes cluster doesn’t necessarily mean that you can understand your next company’s Kubernetes cluster straight away, and that’s it like everybody that picked up Kubernetes said, oh, this is great.

[00:33:20.450] – Adrian
We just need to change this one little bit. And so they created a PR. And the changes got.

[00:33:26.390] – Ethan
As opposed to project leadership, maybe taking a more opinionated view of where Kubernetes needs to be, which some of the competing projects have been more opinionated. And it’s like it works this way or it only does this and it’s bounded in that way.

[00:33:42.410] – Adrian
Yeah. And I think that’s a strong argument sort of against what I said, isn’t it because, well, if what I was saying is true, why isn’t Swarm more successful from Docker or why isn’t? Well, I think HashiCorp’s are doing quite well with Nomad now, but Nomad still certainly an order of magnitude less used than Kubernetes, for example.

[00:34:02.270] – Ethan
That could be as simple as branding and marketing. Honestly.

[00:34:05.090] – Adrian
Yeah, maybe. There’s also we talked about it a little bit before, but this idea of are we going to see more platform as a service offerings on top of Kubernetes, and I think I can’t remember the names of the company. So we mentioned a few, and I mentioned a few in that blog post of companies trying to build on top of Kubernetes.

[00:34:25.370] – Ned
So that’s something that I’ve been thinking about, because the way that Kubernetes gets rolled out is it kind of lives on other platforms that came before it. So most of the deployments I’ve seen are running on virtual machines. They’re not running on bare metal. So it’s a layer of the stack below Kubernetes that needs to support the nodes that are going to run Kubernetes. And now you’re sort of talking about.

[00:34:48.350] – Ned
Okay. Now Kubernetes becomes another layer in that stack. And above that will be Platform X, whatever platform X is. And that’s the thing that developers and even maybe some operations folks will interact directly with. And you’ll have this layer cake of Kubernetes and virtual machines that sit on some sort of hardware that’s managed by a cloud. And I see Ethan is just getting more and more upset about.

[00:35:16.610] – Ethan
Abstractions leak. There are unexpected consequences of all the layers. And I do fear sometimes that we’re getting too far away from what’s actually happening, and when it breaks, none of us are going to know how to fix it. And I don’t know, we’ve been saying that for years and we’ve had hypervisors, and now that’s a normal thing. And what is that other than a layer that keeps us very far away from what’s really happening? I don’t know.

[00:35:39.050] – Adrian
Have you seen stuff like Crossplane? And was it the cluster API for Kubernetes? This is basically a way of saying, well, hang on. We can just have a Kubernetes operators and definitions. What’s the word? Custom resource definitions that define the hardware for our cluster?

[00:35:58.430] – Ned
Yeah, we had Daniel Mangum on the show a couple of months ago from Crossplane talking about sort of his model of how it works, and he was relating it to LLVM and how that works. That was a really interesting episode, we’ll include a link in the show notes for that one. But, yeah, he was sort of talking about. Okay, you’re just going to treat you’re going to build platforms using Kubernetes, which you could then use to build more Kubernetes clusters. So it was this sort of, like, Oroboros of technology platforms eating each other.

[00:36:32.210] – Adrian
Yeah.

[00:36:33.410] – Ned
I got confused quickly.

[00:36:37.350] – Adrian
That’s really crazy, isn’t it? It is.

[00:36:40.230] – Ned
Do you think? And I’m just going to throw this out. Is there an opportunity to simplify? And maybe that’s the future where we’ve got web assembly that can run on kind of any architecture, but you still need. And we’ve got GitOps, which lets us define our desired structure in GitOps. So I’m going to try to tie it all together. I’m going to try to do it, Adrian, but you need something that reconciles and implements web assembly on a target using GitOps. So I guess what I’m thinking is what we really need is a new orchestrator, scheduler, reconciler kind of kind of thing that maybe isn’t Kubernetes.

[00:37:17.790] – Ned
Does that line up with your thought process at all?

[00:37:20.850] – Adrian
Yeah. Potentially. Well, there’s a couple of things I want to touch on now. I realize you’re trying to get me to wrap things up.

[00:37:28.410] – Ned
No, just throwing ideas on the wall. I want to see what you pick off.

[00:37:33.810] – Adrian
So there’s two things there.

[00:37:36.450] – Adrian
Yeah. I think one of the big things Kubernetes gave us is this idea of a reconciliation loop. It’s actually quite a simple, elegant way to do a lot of things in distributed computing, just having this idea reconciliation loop and controllers that just constantly sort of look at things and try to bring things into the place they’re meant to be, which is a bad description. But I think probably most of our listeners are aware of ideas of reconciliation. And so yes, I think we’ll start seeing that idea being used in a lot more places like Crossplane are saying and are saying basically, we’re going to use Kubernetes itself to do that in a lot more places.

[00:38:19.710] – Adrian
I’m not sure if that’s the case. Perhaps you will see newer and simpler implementations or perhaps just parts of Kubernetes being pulled out. The other thing I want to mention, though, you got into WebAssembly there is something really cool called the Krustlet, which basically lets you use web assembly instead of containers in Kubernetes.

[00:38:41.550] – Ned
Yeah. That’s something we didn’t actually get into is how you typically package web assembly once you’ve compiled it. And I think Ethan, you mentioned a dot wasm file, but I guess there’s other ways that you could potentially package and distribute it. Is that kind of what you’re talking about? Adrian.

[00:38:59.310] – Adrian
Kubernetes, you run a container, right? Instead you. And a container is just. Well, you don’t want a container you want a Docker image, right. And you give it up to, like your container runtime to run this image. And that’s traditionally was handled by Docker. Now it’s handled by container D, or let’s say Podman. That’s not right. It’s whatever the,

[00:39:21.270] Cri-o?

[00:39:22.830] – Adrian
Yeah. So Cri-o all you just run C, doesn’t it? Anyway, to get into details. I didn’t mean to, but you can out on Kubernetes. There’s something called a Kubelet that sits on each of your nodes and is basically responsible for taking instructions from the Kubernetes control plane about what to run in that node. And then it tells the runtime to run whatever. And so as well as having a container one, you can have a web assembly one. And instead of taking container images, you’ll take WASM files, and they’ll be run not by a container runtime, but by a web assembly virtual machine.

[00:40:01.290] – Ned
Okay. So would it still use the Pod construct? But what’s inside the pod is instead of containers. Is there a fun word for WASM containers? I guess krustlets.

[00:40:17.590] – Adrian
See, this is only something I’ve read about, something I really want to play with, but I’ve not done it. So I’m not sure if there is official terms, but yeah, you got it.

[00:40:25.630] – Ned
Okay.

[00:40:27.070] – Adrian
The pods host WebAssembly programs instead of.

[00:40:31.510] – Ned
I think I’ve heard them called modules. That was the terminology I saw because one start up that I was doing some work with. They set up a WASM registry, which was basically using a standard Docker public registry software. But instead of hosting container images, it was hosting WASM modules. And then you could just pull one of them down like you would pull an image and load it. And I think they were using it with Envoy, which is how they were pulling it down and then dynamically Loading it into an Envoy config. But yeah, you could do the same thing with Kubernetes if you had the right runtime that knows how to do that.

[00:41:09.790] – Ethan
This is bleeding edge stuff, though. If you look up WASM modules online, you’re talking about draft work being done in August of 2021. It’s not like this has been around a while.

[00:41:21.130] – Ned
Yeah, I did say it was a startup. Right?

[00:41:22.810] – Ethan
Right.

[00:41:26.270] – Adrian
So one thing is like WebAssembly, you had to define all the system calls. Right.

[00:41:31.010] – Adrian
So like I said, all you had with the WebAssembly specification core specification is all input and output. It’s just like a flat section of memory, like a big array. So if you want to make I had all these interfaces on to make Linux system calls effectively, which is something you didn’t have. So they’re still really working through all those specifications. Web assembly system interface. I think it’s called, but the work being done there is really interesting. It ties back to the questions and comparisons with Java because they’re actually sort of doing it from very much security first perspective.

[00:42:04.610] – Adrian
And it’s really interesting to see what they’re doing there.

[00:42:07.010] – Ned
Yeah, I know that was definitely a concern in the early days of Kubernetes was could a pod escape to another pod running on the same host since it is all just processes and cgroups and whatnot? And I think there definitely been some exploits that do that and then they’re patched. But I guess if WebAssembly is being engineered in such a way from the start make that really difficult. That’s a good thing. I could support that.

[00:42:34.190] – Adrian
Yeah, I think it’s what it is.

[00:42:35.510] – Ned
All right. Well, I don’t think we’re going to get back to cloud repatriation because we sat on some cool stuff here between GitOps and Kubernetes successors and WASM. So why don’t you just take a moment if you could, Adrian, to sort of summarize a few key takeaways for our listeners out there.

[00:42:53.630] – Adrian
I think it all comes back to Web Assembly, I worry that it’s just because I personally find it fascinating. But I do think it is worth looking into WebAssembly and seeing if you can make use of that. I wonder if it’s one of these things that will just be underneath the surface if you like, rather than in most people’s faces. Actually, GitOps is probably an easier takeaway. I definitely think that if you’re using Kubernetes or you’re looking at using Kubernetes, you should look at GitOps. That doesn’t mean you have to use the tools like Flux and ArgoCD and so on.

[00:43:30.410] – Adrian
It just means you need to think about how you’re going to manage changes to the YAML in your cluster.

[00:43:37.130] – Ethan
The point being not by hand.

[00:43:39.710] – Adrian
Basically, but that’s kind of what normally happens at the minute. Right? People just go in and run kubectl commands to fix things or change things to update things when somebody else comes in and they’re running them at the same time. And that’s fine for maybe you’ve only got two or three Ops people in charge of that. But once you get beyond that, you need some controls in place. And Git gives you a good way of doing that. I was going to launch into another point, I was like, don’t control yourself, Adrian.

[00:44:14.610] – Ned
Those are two good takeaways. If Web Assembly has tickled your fancy. Definitely. Go check it out. I know there’s some resources online to get started and a lot of reading that you can do. And if you haven’t already checked out GitOps. I think you said Weaveworks was one of the at least one of the ones that sort of coined the term. I think they have a whole blog post or a guide on how to get started with GitOps. So that would be two good places to get started for folks out there.

[00:44:40.710] – Ned
If people want to know more about you, if they want to follow you, do you have a social media presence or a blog? You’d like to point them at?

[00:44:47.730] – Adrian
Yeah. Twitter is by far the best way to find me at the minute. Also, I mainly write on the Container Solutions blog at the minute. Okay, say Hi on Twitter.

[00:44:58.770] – Ned
Cool.

[00:44:59.370] – Ned
We will include those links in the show notes as well. And Adrian, thank you so much for appearing. I know it’s towards the end of the day for you, you’re starting to wind down a little bit, so we appreciate you taking the time out to talk with us today on Day Two Cloud.

[00:45:13.350] – Adrian
Thank you very much. I really enjoyed being here. It was a good hour for me.

[00:45:17.670] – Ned
Excellent. And hey, listeners, thanks to you for listening all the way to the end. Virtual high fives to you for tuning in. If you’ve got suggestions for future shows, we would love to hear them. You can hit either us up on Twitter at day Two Cloud show, or you can fill out the form on my fancy website nedinthecloud dot com.

[00:45:36.270] – Ned
Did you know the Packet Pushers podcast network has a slack group for IT professionals? It’s true. It’s true. And you can sign up at PacketPushers dot net slash slack for free and we will see you in there. Until next time. Just remember, Cloud is what happens while IT is making other plans.

More from this show

Day Two Cloud 153: IaC With GPPL Or DSL? IDK

On Day Two Cloud we’ve had a lot of conversations about using infrastructure as code. We’ve looked at solutions like Ansible, Terraform, the AWS CDK, and Pulumi. Which begs the question, which IaC solution should you learn? A Domain Specific Language...

Episode 120