Web Assembly & Docker Desktop – Scott Johnston, Docker Inc.

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Scott Johnson CEO for Docker ink and we're talking about the relationship between Docker and a thing called Wasim also known as webassembly. There's some changes coming down the pike. There's a new software artifact in town and they are compatible with one another in Scott's going to explain how that's all coming together Scott.

Welcome to show. Mike we're glad to be here. Thanks for the invitation.

All right, so Walk us through the fundamentals. I mean people have been talking about Wasim for a while. It's still early days.

Everybody thinks of doctor is the latest and greatest new software artifact. At least two things come together and how do you see them kind of resulting in you know one plus one equals four five six or more? Even more that's right.

No, thanks Mike. And what what's been exciting to see is the evolution of our industry from from the get go right from from the open sourcing of Docker in 2013. And you saw the the rise of micro Services rise of cloud native kind of simultaneous with Dockers rise with kubernetes rise.

And over the years you've seen many different ways in which to implement microservices many different ways in which to implement Cloud native. So, of course it started with containers that's still the dominant artifact that the tooling produces and then all the tooling operates on but then we've also seen the rise of serverless right the rise of lambdas and then most recent as you noted is the rise of wazm as yet another way to implement Cloud native to implement microservices and what we've also seen along the way Mike which is exciting and why we think Docker has a voice to have in this conversation is that the industry has standardized on the the docker oci image format as its unit of work. And so you see of course for a container images oci container images, but also now lambdas are Deployable as oci images as well.

In fact 25% of Lambda is running up on AWS are deployed as oci images. And so with that similar sort of mindset we saw first the community already playing around with Docker Tooling in the Upstream. Open source to how it might be applied to ASM artifact creation and deployment and storage.

In fact, there's hundreds of ways of objects already being pushed and pulled from Dr. Hub and Docker setback. We'd saw that said, you know, what why not help the developer Community take advantage of the skills.

They have using the docker tools take advantage of the Investments. They've made in the tool set themselves and setting up their tool chain setting up their pipelines and allow those allow those developers and those pipelines to operate not only on container images not only on eight of us Lambda images, but operate all so create and build and ship Wasim images as well. And so really that's what this this with this release is all about is bringing that same investment in developer skills same investment in developer tools and pipeline tools and applying it to a new artifact in this case wasm.

And as you said you can run was in container images side by side. In fact, we launched that today and in our free Tech preview of Docker desktop and wazm and it's the same Docker command line. It's the same Docker tool set just happens to be operating on wazm objects instead of container images instead of land images.

So I'll stop there Mike, but that's the long and short of it. And of course the opportunity is as new technologies come and go is to give developers that same ease of use that same ability to take advantage of these new technologies. Do you think that this is an either or situation or will people use Wasim and container side by side for different things and we'll need to create some sort of distributed infrastructure for both.

Yeah, I think as with all emerging tech Mike, I think there's a time frame and there's a specific use case that they both apply to right and so I don't think it's either or I think it's an and and you'll see for example, wazm is is getting a lot of good use case and a lot of good play in browser use cases as well as on the edge deployment use cases, but for example on server side because wazm does not yet have multi-threaded engines on the server side. It's very it's very challenging in the current state to see where's them having any sort of substitution or replacement effect with container images and so it's a good example of like for for The Right Use case use the right technology use the right tool and we think that the the tool chain the skills can be applied to the different objects depending on the use case. Lawson has been around for a while and at least in the form for browsers.

How maturity do you think was them is right now and what needs to be done? And where do you think you guys will be adding some additional? Expertise to help wise and reach the next level.

Yeah, that's a great question it still early days and what one could say it's still early days for the entire Cloud native micro Services industry, right? But we're still in the first first decade of a multi decade build out and that's certainly what we see with our larger customers that are just now starting their Cloud their Cloud Journeys. And so right now there's still needs to be a lot of work at the different levels of the wise.

I'm stack the component model is still undergoing a lot of work as I mentioned earlier. The the runtime on the server side is not yet multi-threaded. And so those are lots of good work good Community activity Upstream activities taking place on those three areas and a lot more.

What is also a big work in progress. And this is where we think Docker can play a role is right. Now.

There's a there's a very disparate fragmented set of tools almost on a prayer language basis and for some languages, there's actually multiple tool chains available. And so if you're a developer that wants to get started and try this It really is a challenging. Endeavor because there's so many options and so many different types of tools you could use you could plug in you could you could mix and match and so what we're bringing to the conversation like to your question is developers already know how to use Docker build developers already know how to use Docker run developers already know how to use Docker compose.

And so with those tools they can use a single set of tools to build lassim images from rust wazam images from JavaScript as an images from the language of their choice and then in the case of the docker tool chain, it's pretty pretty well suited to deliver those whasm objects to Edge deployments. And so there's a number of partners that will be sharing this week that are focused exactly on that deployment use case. And so Docker will bring then kind of no need to get into a mix of tools and worry about plugging in a whole tool chain on your own or DIY duct taping of tool chain together use the same doctor tool set that you use for containers use it on yasm objects and those objects can now be deployed really effectively officially to the edge.

We've been talking about you know write ones deploy everywhere forever in a day. Is this the finally the time when we achieve that goal and if we get there what exactly is the benefit the developers do you think I mean, is it going to really matter to them immensely or is it just kind of a nice to have Yeah, and I think so. It's an exciting option for it for sure Mike and again for the for the right use case because it truly is like choose the language of your choice right at once and then deploy it to the edge eventually deploy it to the server side.

Once there's multi threaded there deployed to the browser side. And so I think it's a it's a very good candidate that's looking very promising for right ones deploy. Any the the promise for developers, of course, is that right wants deploy any right so they don't have to keep rebuilding there's another promise that's coming along.

It's still very nascent in in the component model that you'll have pre-built prefab. If you will whasm some components sub functions that you just kind of plug in make some match and go so developer no longer has to conceptualize or think of their entire their entire stack or their entire Cloud native application the third one, which is we talk a lot about it's the security benefits of ASM now developers doesn't want to think about it, but the beauty is with with them and as well as with some container tool chains, The the security is kind of built in from the start because it's a very minimalist build of just enough functionality just enough technology that you need for the application itself. And then finally the fourth is of course its size.

The the size of Wasim objects can be a tenth right in order of magnitude smaller than a similar other container objects are certainly, you know, several orders magnitude smaller than VM VM objects and that gives benefits in terms of startup times as well as just deployment over the wire as well as storage of course and so developers will benefit from all four of those and depending on the use case. They'll find more benefit than others. What's your best advice to folks about how to get started?

I mean, they're there things that you see developers doing today that kind of get their feet wet. It seems like you know, a lot of folks might be starting from zero. So where is the beginning of the beginning?

Yeah, well appreciate that. That's a softball buying appreciate that like we we intentionally wanted to put this out there to make it more accessible make was and more accessible for a wider range of developers. There's obviously several thousand developers doing very very well with Pleasant today and but they're having to assemble their own tool chain.

They have to do a lot of Googling and a DIY together. So our belief with this release is that doctor desktop plus wasm out of the box will give developers a tool chain that they can just start from zero and successfully build a whasm app intended to deploy on the edge with literally within five 10 minutes. And so that's a way to get started to see see the smaller size of the object to see the smaller surface area that it that it persists on disk and over the wire and just to see the benefit of this the fast startup time on the edge and so we are intentions that with another an hour they can use this release and all the examples that we ship with it to see the real benefits to their own tool chain the benefits to not having to call them together their own tool set.

As well as the benefits of the output itself. The lassimobic itself is being a much lighter more secure and faster faster object. But but really important Mike sorry, sorry jump in but but compatible with the tools that that they all are using today.

So we have a application that's part of this release. That's a Docker compose application that starts a container image and starts as an image side by side and and they just talk over the wire to each other and so it shows the interoperability the compatibility of one one technology with the other. What do you think the ultimate impact of all this is going to be on devops workflows.

Is this another artifact that I got to manage within that context? And are we going to see, you know, every cicd platform the planets start adding support for this as well. And you know while you're at it, you know taking out your crystal ball.

Where are we going to be a year from now? Yeah, yeah, you mean both with crystal balls. Maybe we could retire after that.

So I don't know you might you might want to scrub that Mike from the final look the benefit and again, that might be a nice softball Mike which appreciate is I'm Because most devops tool chain ci/cd tool change today are already oci image compatible, right? They're already operating on container objects. Guess what like the wasm object also being packaged in in the docker release and many other form factors.

Sorry many other partners as well already being packaged as an oci image, those those devops tool chains those ci/cd tool chains can just interoperated on it as is meaning there's no rip and replace forklift upgrade required here for those Downstream from developers to successfully interoperate and and execute on these on these whasm whasm objects that are being produced by developers. So that's that's a big win. We think and again help we believe it'll help the industry move forward faster because the friction of having to redo your tools and replace your tools.

We're gonna lower that we're gonna lower that now, you know ASM is not are not containers. And so I'm sure there's gonna be nuances and tweaks and 10% 20% that needs to be rethought or redone, but the intention is Is to allow organizations to reuse much of the tooling they've already deployed for their oci container images that are already in as you know in production today and in some cases been in production for six and seven years, right? So that's one your question in terms of out a year.

Look I think this and all the interest it will bring to the developer community and all then the feedback that developer Community is going to be giving into the wasm community. I think it's just gonna accelerate progress Mike on many of these issues and in particular I'll say because so much of the the docker oci container image world as a server side world. I believe the focused feedback on the server side wasm conversations that are going on for example around multi-threading again to go back to that.

I believe those conversations are just going to accelerate and the use cases are going to become clear and the high frequency ones that matter a lot the ones that don't matter as much like Industries gonna have a very quick sort on that. So our again our desire is to come in help to listen and ideally accelerate much of the work that's being the great work that's being done on to help make it even more practical and usable by the end users. All right, folks, you heard it here.

There's a new kid in town and we're gonna see what happens with all this was and stuff. But hold on to your seats. A lot of interesting things are about to happen.

Hey, Scott. Thanks being on the show. Mike, always a pleasure.

Thank you. All right back to you guys in the studio.