Understanding Containers at the Edge with ZEDEDA

Good morning everyone. Good morning, panelists. Uh, my name is Manny Calero.

I'm a consulting solutions architect, dita. We're an edge management and orchestration platform to help our customers solve business and technology challenges at the Edge. Today, we want to jump in and talk about understanding containers and, uh, workloads at the edge and different approaches.

So let me start with a question. Do all edge workloads really look the same? And the answer is really no.

Some workloads are large, heavy, distributed cloud native applications that may require Kubernetes, and Kubernetes is fantastic for those. But, um, some edge workloads are smaller. Maybe a connector, single analytics engine, IOT broker, or perhaps a lightweight multi-service application.

For those maybe Docker composed makes a lot of sense, and that's the right tool. It's fast. Familiar developers, um, are used to, uh, using Docker compose locally on their laptops ideal for Brownfield or, you know, resource constraints sites.

So to the point we support both, um, and you can choose with, with our platform, you can run either Kubernetes where it makes sense or Docker composed where that's a better fit. And, um, now let's talk about if developers are already using Docker compose, why is it important that we bring that to the edge? So one of the biggest challenges, um, at the edge is diversity of workload.

So in most environments, um, you don't have one type of application. You typically have many. Um, you've got legacy VMs running, you know, that have been running for years to, uh, maybe Windows machines.

At the same time, your developers are delivering modern containerized apps, often defined with Docker compose and looking ahead, there's always new container frameworks that are being introduced and services that are being introduced. So, what makes us unique is that we don't force you to choose one model. We support them both.

And instead, uh, we provide a platform where you can run all of those workloads side by side and on the same edge node. So the bottom line is whatever workload you you have today, and whatever you add tomorrow, we will support it and we can orchestrate them. So here's the, the real strength of our platform, and it comes down to flexibility.

Um, most edge environments are often clean slates. Um, you've got legacy applications that are still running in VMs. Uh, you've not containerized apps, but some are defined in Docker, composed for those that are containerized.

And, uh, you may also have other, uh, modern container frameworks that are emerging. So with us, it doesn't make you choose one model. Um, and whether you have 10 nodes or 10,000 nodes, we'll provide the same zero touch provisioning and policy-based orchestration to make sure everything's consistent and scalable.

So repeatable architecture is really important to us, and to be able to bring scale, uh, to the edge is really important, which is kind of what Docker composed lacks. And it's get the scalability piece, and that's what we bring to the table in, uh, delivering a Docker composed solution. So whatever workloads you have today, and, you know, whatever you bring tomorrow, we can help you and our platform can orchestrate them.

Hey, Manny, it sounded like you said that most edge deployments are clean slates. Is that what you Said? Thank you.

For point of note, they're not clean slates that we typically have a lot of legacy apps running And, and devices and devices that you wanna reuse if you can. Okay. Yeah, and that's one of the cool things I think Mor Borg mentioned is, uh, about, uh, EVOS, which is, it can run on very, you know, very lightweight, uh, very small form factor, uh, type of hardware.

Um, so it's really powerful in that sense to support legacy, um, smaller applications. So let's talk about how this works, uh, from the user perspective. So typically it'll be either a developer or enterprise user.

They're deploying, uh, containers, they're creating their apps, they're containerizing it, and then they're typically using Docker Compose. That's a very simple tool. It's very powerful.

It's very quick, very streamlined. Um, and then from, from that perspective, they'll create the application. They'll have their YAML file already defined, and then from our Mac marketplace, what they can do is they can, uh, from the global market base import into their local marketplace, what we call a, a Docker composed runtime, and then they can deploy their apps on there.

So the runtime is in our app, it's maintained by zaida, so it's very important, right? We patch it, we update it. The whole lifecycle management is care and fed by Zaida.

Um, and then once it's in place, the user can simply take their docker compose YAML files, their existing, uh, configurations that they're using today, and deploy them in the runtime. So the result is the applications are instantiated and running on the edge, fully orchestrated and supported by. So from the the customer's point of view, it's a straight and simple flow user marketplace.

Put your YAML files in an app and orchestrate it, um, on the, um, on the runtime. So the benefits that we see and how we make it, uh, scalable to, to our, you know, our customers is speed, right? Uh, fast onboarding in minutes, uh, same YAML files that they're currently using.

Uh, we're flexible, um, because we could not only support VMs and, uh, Docker composed runtime, but also Kubernetes, uh, when needed. And then the, the really important part that, uh, and the gap that we fill is the scalability piece, right? If there's one missing piece to, to Docker compose is the fact that it's, it doesn't scale very well.

It works very well in local environments, you know, maybe small, you know, five, 10 sites. But as you start to scale, uh, in the distributed edge, it becomes really important to have platform that can take that repeatable architecture across geographies, and then maintain that single control plane, roll out updates, roll them back, keep visibility across a fleet, and then of course, consistency, uh, repeatable architecture. So taking the same, uh, YAML files that you may be, you know, compiling on your, uh, on your laptop.

And take that to, uh, there's adida orchestration, and then create those predictable outcomes across dev test production and lower, you know, the operational risk that makes, uh, adoption frictionless. So now I wanna show you just a quick diagram. Um, I'm gonna run a demo and, uh, after this slide here, and what I'm doing is from this adida platform, I'll be orchestrating onto two edge nodes, um, the same application.

So to show you kind of how we de deploy across the, the fleet, um, so you can see it in action. And then I'm gonna sprinkle Terraform in that as well. I love Terraform, and that's, we're very proud of our Terraform provider.

So, um, I'm gonna be doing some of the deployment through that. Um, I'm gonna show how, uh, I can deploy the infrastructure to the point where we deploy the runtime, and then I'll kind of stagger it a little bit, deploy the runtime, and then deploy the apps, and then show you what they look like, um, in the, in the, uh, the marketplace. So here, I'm gonna start the demo, and this is what our, our UI looks like.

So we log in here, the first thing I want to do is, uh, show our, um, our dashboard, and then go through the different sections to show that there's no elements created. Uh, there's no networks, there's no edge nodes, um, there's no marketplace apps. And then the first thing is show the Global Edge apps.

So if you go into our global marketplace and you click ZA data, you're gonna see that we have three Docker composed runtimes. Um, there are different flavors. I'm gonna go ahead and import the large flavor into our local marketplace.

So now you'll see if I click on here, there it is. Uh, and then once I go inside, you can see some of the particular elements within that runtime. So, four CPUs, eight gigs of memory, storage size.

And then what I typically like to do, and especially for the demo, is I clone the app. I don't necessarily have to use that. I can clone it and make some changes.

In this case, what I did is I, I cloned it, and I'm going to reduce the persistent storage size of 20 gigs. The original had a 200 gig, but it shows that we can kind of tweak, uh, those applications in terms of sizing, and then I'm gonna keep all the defaults the same after that. So here, I've got a cloned, uh, application.

So now what I'm gonna do is I'm gonna pull up my Terraform code here. I kind of show the, the diagram again, of what I was gonna deploy. But, um, I'm gonna go through the, the Terraform code and kind of walk through what it takes to build the infrastructure.

So it starts with a project that's kind of the umbrella, and then everything falls under that. You have, uh, your images, you have your storage repositories, of course, your edge nodes for onboarding, uh, and then of course, the applications where you define them, the, uh, the network instances and all in, you know, a single Terraform file. And then I, I'm gonna deploy it to the point where I'm gonna have my projects, my data store.

This is where, uh, I would store applications, the image, this is where the, the package would be. And then, uh, a couple of networks and, and, uh, the applications that you're gonna see in the marketplace that I'm gonna have, uh, deployed through here. And these are the YAMA files.

I don't know if you can see it on my screen, but I feed the Yama file to the Terraform, and then the end result is in the marketplace. You're gonna see the application, and then you're gonna see the YAML file. So here I did a plan and apply, and then I'm going to show you how I created a couple of edge nodes.

I created network instances for those, and for the run times, I created the Edge apps. So I created four edge apps. I created, you know, very common apps that we see, like Grafana Ignition, uh, and Splunk.

And then within those, uh, the YAML files are, uh, are configured. Uh, here, I'm gonna wait a little bit. Uh, it takes a couple minutes for, um, the, Yeah.

Quick question, while this is, while this is coming up here. Yeah. Um, let's say I'm using some orchestration, uh, software that's not Terraform based.

Can this be consumed with a API, right? Can I drive the Zita dashboard and cloud from that API? Yeah, Absolutely.

So Zita is 100% API driven. Even the web UI that you see there is driving an API on the backend. So we have our, our API is, uh, published, so you can leverage, uh, Terraform, you can leverage our rest, API, um, and also we have our ZCLI.

So it's, it's a very flexible platform. Many ways of configure it. I happen to love Terraform, so I, that's the way I kind of orchestrate all of my, uh, uh, my environments.

And then here, uh, you can see the, the edge nodes came up. So they're green light, that means they're onboarded. What a typical experience for a customer is, this gets shipped to a customer, they plug it in, turns on phones home, it's registered, and then that becomes a registered endpoint where you can start deploying apps.

You can deploy your runtimes from that marketplace. So here I'm just showing a, some details around the, uh, the edge nodes, uh, the adapters that are available, uh, some detail on that. And then here, what I'm gonna do is now that the edge nodes are up and running, I'm gonna go ahead and deploy the runtimes.

I can still do this from the marketplace just by launching it. Um, I wanted to show the flexibility of our platform. So I'm doing, I'm doing it through Terraform.

So I just do, uh, a plan and apply here. And then as we go back to the dashboard, you're gonna see that Now I've got a couple of run times that are coming up. There's one that's already downloading, and then within a couple of minutes, they're up and running.

They're green light. That runtime is ready for you to execute those YAML files that I mentioned before, um, that I also created. So once they're online, you can deploy your apps here.

Now, you can deploy straight from here, and you can see as, as I click on, on the application, you can see the YAML information in particulars for each, uh, for each app. And then you can deploy it straight from here. I'm gonna go ahead and deploy it through Terraform just to show the automation piece of this.

Um, right after I show you this last YAML file for Ignition, um, ignition is very popular app for our manufacturing, oil and gas customers, very common application, um, automotive, uh, plants. So here is where I start deploying the app. So I'm gonna deploy the, the application across the two, uh, edge nodes.

So both, uh, Grafana, uh, Splunk, and of course Ignition as well. And through that single entry for each one, it's gonna spray it across the different Edge nos. So I'll just do a simple plan and apply again.

And of course, I can do this with a single swoop, but that would be kind of a boring, uh, boring demo. So, um, I kind of staggered it a little bit. So now you can see that the, uh, the apps are, are being deployed.

Those are the yamo files that I showed you. And now you can see how we can scale this. I don't have to go to each Edge Noe and run a Docker compose command to make the application come up and run.

I can simply do it from a centralized location like I'm doing here. I chose to do it through Terraform. You can also do it through, uh, the marketplace here.

I kind of went in the CLI to give you an idea of what it looks like on the Edge node, and you can see that the, uh, um, the container image is being pulled, and then they start to come online. Uh, now they're all loading, and then eventually all these will turn green, and then you'll have a, a running application. So here we got a couple that's already came up.

And then, uh, in this next section, I kind of went through the, the, uh, the UIs to kind of show the apps running. Um, I wanted to then pull the each runtime and show the IP address that's on there. So I have a one, a 1 5 8 address, and a 1 0 6 address.

So that would be the target of what application you want to access. So what I'm gonna do here is to show you the URL is I'm gonna open up all these apps. I kind of sped up the, the video on a little bit on this one to get there.

And then you can see 1 5 8 was my first node, and I can access Grafana, the application's available there. And then I went in, uh, node number 2, 1 0 6 logged into Splunk. So basically, both apps are running on both Edge nodes.

Um, and then of course, ignition here. Um, I show how we can automate the deployment of Ignition. It already pre configures with a username and password, and I can take it further and configure, um, you know, MQTT endpoints.

And that is my demo. That concludes what I'm showing in the demo here. I have a question regarding sequencing.

It seems like you have to install Docker compose on the edge nodes before you can install all those apps using Docker Compose. Is there something intelligent on the node side that understands the sequencing of the dependencies, or is that something you have to put into your Terraform configuration or your, your script? So our, our system is built to cue things.

For example, I can create an Edge node and deploy network instances. It knows that the edge node isn't up. So it, that job, once the Edge Noe is up, then deploys the application.

Same applies here. Uh, when I deploy the, I, I can, with a single code, I can run the entire thing, and it knows the Wake four, it's kind of a staggered approach. It has to, it knows that it has to wake four, um, the, um, the, the edge node to come up, then the runtime to come up, and then the application to be deployed.

So it, it knows how to queue up, uh, jobs in sequence. And the, the different compose options you were showing, like the small, medium, large, that determines the size of the, I guess it's a virtual machine on the edge node that gets provisioned for running the docker compose apps, Correct? Yeah, that defines the sizing.

So the small, medium and large. So if you have a very small edge compute, um, you can deploy the smaller. Now those are predefined.

However, as you saw, I can clone it and I can edit and even make it smaller, you know, kind of reduces the footprint of the storage, um, you know, even ad networks and, and kind of tweak it in a way. Uh, the, the, the, the remaining element that stays consistent is the actual software that we manage in Care Feed. So that would be the, the operating system is gonna run the Docker.

What degree can I, uh, change the size of that, that VM without any downtime? Or does it require, if I want to add a network interface or change the number of CPUs, does that require rebooting all the apps on that node? Um, so you can make those changes.

And then the apps would, uh, kind of go into like a halted state and then kind of, uh, come back online and redeploy. Uh, what, what sort of, um, uh, SDLC capabilities can you support here? This is a powerful deployment and rollback tool, but I'm just wondering, um, uh, if there's anything inherent in the platform or if, or if, uh, it would be a partner or some third party using, uh, using the API to enable that for, for, for developing and, and managing the lifecycle Of, of an Edge app.

Um, so that can, you know, that can be a, a, a customer directly doing it from their themselves, their IT department, their developers, um, or, you know, we have partners that are in the ecosystem that are trained and, uh, are fully ready to support, uh, customers in our platform. Um, so we have it covered end-to-end. And then, uh, we have a very, um, a very talented, uh, customer support team that kind of takes over, um, as the, they go into production.

Um, so they're, you know, full end-to-end support, either through the ecosystem of partners or, you know, from, uh, our own CX team, which is always involved. Hi, my name's Chris Clark. I'm a, uh, solutions architect, uh, for the data.

I'm based outta Kansas City, and today I'm going to be discussing the Data Edge Kubernetes service, and when you would want to, uh, use it. So that's really what I wanna start with today, is when do you want to use Kubernetes, right? It's, it's very complex.

There's, there's a lot of moving parts that go along with it. And so, uh, really, if, if you look at your stack, is it, uh, a complex application that needs to be to, needs to be managed? Is it a distributed workload that needs to run across multiple nodes?

Do you need a high scalability? Um, then you're probably gonna want to deploy on some, like Kubernetes, if not Kubernetes itself. And, uh, one thing I do like about Kubernetes is that it has a very active, uh, community and of developers, uh, around it.

So it's very easy to support. And, uh, there's always new features that are coming out. Now, ZE Data has our own Kubernetes service built into the platform.

Uh, I'm gonna go through a demo of that here in a minute, but before I do that, I wanted to show you guys just very briefly, the architecture. And the reason is, uh, a, just to let you know all of the, the hard work that went into it, but, uh, b, that, uh, we made, uh, it very simple to use. So while this looks very complex, it's very point and click, create a cluster, deploy an application.

However, if you don't want to use the as a data cloud to, um, interact with that cluster, you can do it directly with your, uh, cube CTL commands. Uh, or you can use Cube CTL via ZA Data Cloud. Uh, and there's, there's a lot of, um, ways to interact with that, whether you're using ZA Data Cloud itself or using the Kubernetes API directly.

So let's jump over and take a look at how to create a, uh, cluster. So what you're looking at here is the ZA Data cloud, and there's, there's a whole lot that we can do on the left hand side, but we're gonna focus in solely on the, uh, Kubernetes service. So when I hover over that, you'll see that we have a bunch of different options.

We can create clusters from the cluster section. There is a Kubernetes marketplace, uh, section where you could, uh, import applications. You can see what applications have been deployed.

Uh, you can take a look at cluster grouping, and you can even add your Git repositories. Um, so it's really very an all-inclusive system. Now, the creation of the cluster is quite simple.

We click that. I'll notice that we have a number of clusters already created here. And the data cloud, I can add new up in the upper right hand side.

We'll just give it a name test, go next, select one of our projects, and from here we select one or then three or more nodes to add into that cluster. So we'll just kind of grab three random nodes there. We'll tell, uh, the, uh, the configuration, which network adapters to use for this particular cluster.

Once we do that, we hit next, and then we can finally edit it down below. Now, it will take a couple of minutes to deploy. So in the interest of time, we're gonna just jump right back to the clusters here and utilize one that's already installed this Edge AI cluster.

So if we wanted to see additional details, we could actually click into this. But before we go that deep, I wanna show you the actual application deployment. So here's the Kubernetes marketplace I was talking about a moment ago.

Uh, from here, it's very similar to what you, uh, saw with, uh, Manny's presentation. Uh, so it's a very streamlined, um, uh, experience between different technologies. So if we wanted to come out down here, we could take a look at something simple like, um, I guess book, right?

We could select that, and you'll be presented with all of the options that can be changed. This is done with the helm chart. We can see all the different versions that are available to us, and we can click install there.

Now, if you don't want to use that, uh, marketplace, and you'd prefer to, uh, use your own helm charts, you can, that can be done, uh, by bringing in your own git repositories here as a data source. And we can actually see all of the applications that have are already installed. So we have this HelloWorld application.

If I select that it's gonna bring up all the information, and we see that there's a service associated with that, uh, of a kind deploy, or excuse me, service down here, then we have a service account associated with it. And then we have a, uh, deployment above that. So this is the, the basic functionality of deploying a Kubernetes cluster.

It's, as you can see, it's very, very simple. It's not as, uh, big and complex as, uh, you're probably used to with, uh, Kubernetes clusters. And we can even take this, uh, one step further down into the weeds.

We can go back to our cluster and click on it. And without ever leaving the data cloud, we can, uh, see all of the details about all of the pods, the services, the storage, the policies. Um, so we wanted to take a look at some events that are occurring.

We'll go ahead and click that. It gets presented here, right in the web ui. We can select those to get additional detail.

Maybe we wanna go over here to the workloads, take a look at what CR jobs are running. Maybe we have a, uh, a pod that, uh, is, uh, thrashing that we wanna, uh, investigate or we wanna delete one so it gets rebuilt. We could take a look at all of those from here as well.

Uh, here's the service discovery section. Uh, like I said, you can take a look at the, uh, storage. So you have your persistent volumes, your storage prices.

I mean, this is very, very, uh, all inclusive. So from the data cloud, you can go from no Kubernetes cluster to your very own Kubernetes cluster in a matter of minutes, and then attach it to your GitHub repo, bring in your own helm charts, deploy applications, and you can start development work, uh, I mean, within 10 minutes. Yeah.

Question about, it sounds like you're getting ready to, to offer up q and a there. Yeah. Um, so quick question on the scale, you know, sometimes when we're thinking about edge clusters, right, we're not thinking very large scale, but I wanted to ask about that.

Like, if, if we're thinking of pod scale, can we go up to say half rack of nodes, full rack, multiple racks? What's the, what are kind of the upper bounds of what we think of that Zaida can do in the, the scale of running a Kubernetes cluster? Um, that's a weird question.

I don't have the numbers for that on, on hand, so that, I'll have to answer that offline. It looks like it can go pretty far, right? If we're just talking about the orchestration side, and like you said, we can bolt it into our current GI ops and Yep.

Go from there. So I'd have to imagine it's pretty high. Yeah, yeah.

For balance there, other than just how much do you wanna manage, right? Yeah. And it really, all it's doing is managing that, uh, the, the cluster, right?

There's VMs that are actually, uh, clustered together. They're doing all the, the communication back and forth with one another. So there's really not a whole lot of overhead.

Uh, so I imagine there, yeah, the, uh, the upper limit is, is quite large. I think that that highlights one of the things about scalability with Edge solutions, it tends to be a very large number of sites each with a relatively limited amount of resource. So you're not right.

You, You wouldn't typically have multiple racks in, uh, uh, in each location unless it was somewhere like an oil and gas exploration. That's a kind of use case where you might have more capacity in that, um, in the crawler. That's still in the geotech stuff.

Yeah. Would you, is there, is there an option to even bolt in, like from from a CNI perspective? Like can I, can I roll my own CNI in the solution?

Or is there something else that is already baked in from a networking perspective? Uh, the, the deployment itself, it's already baked in from what I understand, but, uh, the, I, the, uh, I have not messed with any of the other CNIs, but I, I think it's baked in from the actual creation of the cluster. And then you were highlighting, uh, something about, uh, edge Hardware that I really like about this solution is I think that Kubernetes really does a very good job at, uh, complimenting edge hardware because it's super easy to swap in and out new nodes or ag capacity and scalability, uh, with something like this, you know, have evos on there, you know, plug it in, have it check in, add it to a node, and then you have additional capacity, right?

So this is a zaida, a Zaida cluster manager. Um, how, how does this compare? I mean, I containers is kind of where it's at right now, and edge's like right, the most active development.

Mm-hmm. But I imagine quite possibly the majority of your customers right now are still running PMs mm-hmm. Whether ESX or KBM mm-hmm.

Or acorn. Um, and I'm just wondering how this experience compares if, if, if it's okay to ask that. Um, and no one's gonna start a religious war with me about it.

I'm just wondering, like from a, from, from an enterprise standpoint, wherever they're at, they, they're often doing both, right? Um, whether they're moving or not moving, um, from one to the other. So I'm just wondering how the experience compares, um, if there's multiple pain of cla pains of glass now, and if that's inevitable.

Yeah. So, uh, I, I think that the experience with this Kubernetes piece is, um, much better for developers because they, even though it's being managed by the data, they still have the ability to, uh, utilize the tooling that they're, they're used to, right? So you have, uh, your, your admins, uh, managing the cluster and the ZA data side, and seeing what data sources that we're, they're allowing to bring Helm charts in from.

But the, uh, at the same time, the developers are able to, uh, use their cube CTL or, or whatever they have integrated with their, uh, their IDs. So, um, you have multiple streams kind of going at once. Um, right.

So I, the experience I think is, is very robust in that regard. Um, when you bring over the, the VMs, uh, from, uh, somewhere else into the data, you, you have to bring 'em in and it's managed and everything's done inside of here. So, uh, that's a little bit, um, uh, of the contrast between the two, which is why I like this quite a bit.

How, how it, uh, allows you to use the tooling that, that you wanna use. Well, that, that's endemic to, to the platform when it comes to VMs. It's, it's a, I I think it's a genuinely a feature of the V of vm.

And, and that's why it's not really religious war, it's just a question of, uh, right. What you're trying to accomplish. Mm-hmm.

So Think, um, that what we talk to customers that the VMs are a necessary evil for them today and will be for the next few years. 'cause they have invested a lot of IP and some of those applications that are running, uh, on those, um, on those VMs and a number of, in very old versions of window. So they're looking for the ability to continue to use those.

But I think obviously, um, everything they're doing that's new and future looking, they're trying to containerize. So all their focus is on putting new apps in some cases, um, rewriting existing apps and putting 'em in, in a container or running them in Kubernetes. So it's a combination of we, they want to be able to deploy both types of, uh, runtimes, uh, for the next few years as they migrate from the VM to a, an all Kubernetes or an all containers type of, um, architecture.

The Kubernetes, um, version and the image, it looks like it's using K three SI, I assume that's correct. Um, correct. Is that how close to the current version of Kubernetes, do you have burdens available in the marketplace and could someone roll their own instance of Kubernetes and deploy it to the, the cluster nodes if they didn't wanna use the data's version?

Yes. The answer is, um, um, the, how close we are to the most current one. Uh, I think we're one or two versions behind, um, when it comes to rolling their own, yes, they could.

And, and there's a, there's a number of different ways we can support, uh, deployments of Kubernetes at the Edge. One obviously is one where we provide kind of a end-to-end management. The other is where we provide them with the ability to deploy the Kubernetes one time themselves.

And that is basically where they get to choose which version of Kubernetes they want to deploy. So that option exists, yes.