Hey everyone, welcome to today's CNCF On Demand webinar about enabling self-service infrastructure on any cloud with Backstage and Pulumi. I'm really excited for this session. I love everything around Backstage and combining Backstage with Pulumi is really awesome. Now I can give my company, people inside my company the ability to self-serve them, some of the golden path, some of the best practice infrastructure definitions on any time they can just come, can fill out and get the infrastructure created. You can even go further and create templates for day two operations, which is really awesome. So not only creating a new repository for your microservices or a new EKS cluster or AKS cluster, you can even say, okay, let's update the cluster, let's create additional nodes and you guess it, there's much to do. So let me share the slides with you and kick off the session. We have much to cover. So I quickly share my screen and also start with the slides. Okay, so you should see now enabling self-service infrastructure on any cloud with Backstage. Pulumi is the title, shortly to my person. My name is Engendiri. I'm working as a customer experience architect here at Pulumi. I like everything, cloud transformation, enablement. I've worked in different places, always with the same question, how we get the company up to speed, the company up into the cloud and the teams also enabling them to leverage the full potential of what the cloud services offers. So really, really interesting subject. And yes, I love to continue everything from continuous integration, continuous deployment, you name it. You can follow me on some of the social media. So I'm on EKS, I'm on LinkedIn and the most important part, I'm also on GitHub and there you will find most of my work. Let's go quickly through the agenda before we start. So I want to give you a short introduction about Pulumi and Backstage. What is Pulumi? What is Backstage doing? I find this very interesting to understand further what we present here and how we can marry both technologies together. So the gluing part will be all done with the Pulumi Backstage integration. So this is our Pulumi Backstage plugin. I will go into more detail into this. And then we come to the interesting part to say, okay, how are we going to build Backstage software templates? How are we going to build Backstage software templates using Pulumi? Very interesting. And then of course, nothing is done without any action and without any moving parts. So I'm going to show a little demo I presented, I think five, four, five templates, provisioning different services and you will get a good understanding on how to create your own services. And of course, we're going to wrap up everything. So short introduction about Pulumi, it's going to be really, really a short introduction. So what is Pulumi? Pulumi consists of different parts. So we have our build part, deploy part and manage part. As you can see, Pulumi fits perfectly into your existing tool chain, your existing cloud provider and your existing IDE. So your existing CI CD systems. So on the left side, you can choose from the Pulumi supported languages what you want to use. Yes, we are using a generic programming languages to define your infrastructure. So choose Go when you already use Go for your application code, for example. And then you can also define your infrastructure code in Go IDE. As I mentioned, Pulumi is not inversive. You can just embed it into everything. We have even colleagues here at the company who use Vim, for example, to create all their code. So everything works. There is no limitation here. And you can leverage the existing tool chains, existing package managers. When you create a Pulumi component, you want to share with your colleagues. The main part is also our huge provider library. So you can choose not only from the three big ones, AWS, Google and Azure, to create infrastructure. There is also lots more, also smaller cloud providers. So for example, DigitalOcean or Hetzner, you name it. You can create different on different cloud providers. You can create your infrastructure, but not only infrastructure. You can also provision your SAS services. You can provision your databases and so on, very interesting here. On the right side, of course, you can save your Pulumi programs, your code in your use the source code management tools. For example, Git, GitHub, GitLab, you name it. And you can execute this with different parts. You can use Travis Jenkins. You can use Tecton. You can even use a BitOps approach to deploy your applications, to deploy your infrastructure. So very interesting and very easy to combine all these pieces in your program. Some of the features, we will see also in action, but I think it's very interesting to see also a little summary. Yes, most of the clouds, I would even say all the major clouds presented in the Pulumi provider registry. You can use any of the languages Pulumi is supporting. Pulumi uses a state management to save your state. You can self-host it. We will see this a little bit later. You can self-host this. You can even use the free Pulumi cloud service. Secret management is in builds or batteries included, but replace it also if you use a different secrets management, for example, Vault or Azure Secret Manager, AWS Secret Manager, feel free to use this one. You get preview plans, as I mentioned, CICD integration, web folks, the REST API, automation API, very, very interesting parts. Yeah, let's head over to the Pulumi high level view. So, I found this very interesting to show a little bit about the Pulumi architecture. So, as you can see, Pulumi consists of different parts. We have one part is the language shows. This is when you write your codes here. For example, you choose Go, you start to write, you import the Pulumi library, and this is the part which get then executed the moment you say, for example, Pulumi preview or Pulumi app, Pulumi, the Pulumi CLI, let's head over here, takes care to start a service. In this case, the Go service, the Go language service will be started and then communicate with the CLI, translating all the commands, all the resource creations in your code into commands for the CLI. The next piece are the providers. This is, for example, when we use AWS, we import the Pulumi AWS provider, we start to code creating an EKS, for example, when we say again, Pulumi app, Pulumi not only detects now the language, but also which provider and starts also a microservice for this specific provider and then communicates via gRPC codes with the provider to do all the methods, create, update, delete, you name it. Last but not least, when all the commands are created or deleted, what you wanted to build in your Pulumi program, the state of this operations gets all saved in the state backend. So there are different ways for the state backend. Yes, you could use, for example, the Pulumi cloud. You could also self-host this. So for example, if you have an S3 bucket, there are many, many more integrations available. The most common one when people say, hey, I want to host the state on my own is the S3 bucket. So you are completely open for this. And yeah, Pulumi, we define our resource, the resource gets created, the cloud provider delivers us additional informations about resource which gets created and then we save the state in the state backend. Next operation we want to delete, we want to change the number of EKS nodes. For example, we do again a Pulumi app. Now we compare against the state and then do the update, for example, because it doesn't use a new resource anymore. How does a Pulumi program look like? So a Pulumi program always contains a project. And inside the project, we have our Pulumi program. There is also the Pulumi template file, the Pulumi YAML file which defines, which says which runtime to use. For example, if you're going to use Python or YAML, it's everything is defined, the name, the description, some of your config parameter. And this is important for the next piece of our architecture is the stacks. Pulumi defines different types of stacks. You can think about this, I mean, the most common thing which people use in terms of stacks is reflecting their stages. So having a dev stage, having a QA stage or a prod stage, that's the most common way to use stacks. I also saw people using stacks, for example, for ephemeral environments giving them some automated names and then gets created. People do their work, check, for example, yes, that's fine. The new EKS settings, for example, they work as we expected. And then the ephemeral environments gets destroyed again. But the most common thing is using stacks, reflecting your different environments. And here comes also the thing you can now start to override config values, for example. So you can define on a high level, on a program level, you can say, hey, every EKS cluster, EKS cluster has to have six nodes. But then you say, okay, does it make sense in dev? Do I want to save, for example, money or I want to speed up time to create a new Kubernetes cluster so you could say, okay, on a dev cluster, for example, we don't need six nodes or maybe we don't need six nodes with an EKS large setup. So you can override the machine type, you can override every variable. Now we come to the next part and this is the resources. This is our small building blocks where the magic happens. We can start to say, okay, I want to create a VPC, I want to create two different subnets and so on and so on. You can all define like a cooking recipe and all of these resources, they have input and output parameters. And then now you can see, okay, you can take the output from one of the resources as an input of the next resource. So you can say, okay, a VPC, I always need from a VPC, I need the ID to set, for example, a subnet. So getting out the variable of the ID, putting into the next resource and now comes the situation, Pulumi detects this kind of dependencies and creates in the background a dependency graph. And depending on which resource needs the output of a resource as an input of the next resource, Pulumi will then say, okay, I'm going to create this resource in parallel, these resources have to wait when it's finished the other one to get the value out and put it as an input variable in. So that's the thing. And with this way, you can nicely create the graph and really speed up your deployment because most of the resource, for example, which don't have any dependencies, they just create it in parallel and you will get much quicker infrastructure provisioning. Last but not least, every project has on its own the way to define project outputs and project inputs. So you could say, for example, I create a project for the database team, the owner or the database team, they define whatever they need inside, but me as a developer, for example, I just want to know the URL, for example, of my database and the user name and the password and all the stuff. So the infrastructure team and now we come back also to the backstage part so I can just provision, for example, a new database code is written from the database team. I don't know what they are doing inside, but what I know is this is when the project is done, it will give me as an output the database world or the database password. And there's also an interesting part, we can reference to this. So not only you can run the Pulumi program and take the values, copy paste them into your next program or in your config files, you can combine two Pulumi programs and say, hey, it's called stack references, please Pulumi, look into this specific Pulumi program with the specific stack, for example, the DevStack, and get me out the database URL and the database password. So everything is highly automated and I don't need to copy paste where I use around different stacks or worst case communicate via ticket or something like this. So, hey, what is the database URL? Okay, so that's it about Pulumi. Of course, there's much, much more and the documentation of us is full of many, many use cases and many things you can apply. But now let's head over to Backstage. What is Backstage? Backstage is an open platform for building developer portals. That's very important. Backstage is not a developer platform on its own, it's just a framework, a way to build developer portals. It was created by Spotify and it is donated to the Cloud Native Computing Foundation, so it's completely free. You can be sure that as part of the foundation, there will be no license changes or something around this. So you can really commit yourself on Backstage and start to build your internal developer portal around your internal developer platform, for example. And I just mentioned this, yes, you get unified tooling for services. You can create documentation, you can use see who owns which part in the company. So having the way to model your whole company inside a tool is very, very interesting. Because you could say, okay, I have, for example, the LDAP service, every company has looking up a directory of employees, for example. So I can use Backstage now, search for a specific component and say, okay, is there a component? Is there something around LDAP, for example, or internal directory? And then I see, hey, there is already a component and these are the owners and it's part of a bigger project. So you can really create the whole relationship of your company, of your different products, of your different development teams inside Backstage. So that gives a very, very powerful tool in the hand. And now we see also the three, let me say, the three bullet points which collide. So we want to increase speed. We want to scale out. So nobody wants to wait for information of somebody. You don't want to write a ticket or you don't want to write a mail to say, hey, who owns the LDAP service, for example, or how can I consume the LDAP service? And one part, and this is the thing we're going to discuss also in this webinar, is you want to contain also the chaos inside your company. So go to your company, tell 10 different teams, hey, create me an EKS cluster, for example, whatever programming language they're using or whatever IAC tools they're using and you can be sure everybody creates or every team creates a slightly different version. And this is the thing, you get a high fragmentation of different ways but this is not something you would like. What you want to is, okay, you want the deterministic way when you say, this is the way we order an EKS cluster we provision an EKS cluster. It's me who's ordering or maybe the next team is tomorrow or tonight you could be all around the world and there will be every time somebody ordering a new piece of infrastructure, you can be assured that they will always get the same way because you create now a specific way to order this and this highly helps also speed up the need for speed. And here we can see what is in the middle. Yes, it's backstage and when we want to provision our infrastructure, of course, there's also Pulumi. Okay, we just talked about this and was creating new software, completely fine new software, new infrastructure. You have a centralized location to manage everything very, very cool. And of course you can explore existing ecosystem inside your company and then this helps also not only the whole inner source movement but also the way to collaborate. So when you know, for example, who is the team behind the software XYZ you are using to order something or you're using to print out your bills or whatever. Now you can also approach them and say, hey, this is the team, this is the persons inside the team. I can ask them, I can contact them and say, hey, can we talk about this new functionality or which is also nice. There's also the git repository connected to in backstage, for example, so you could go when you have access in some kind of inner source movement that everything is open and visible. You can just create a pull request on this code and improve the code, for example, very, very powerful. Architectural-wise, and now this comes also why we're having this webinar, you can extend backstage with plugins. It's built on a plugin architecture and the Pulumi created a plugin around this and that's very, very cool. It's built on material design, type script and React. So something I would say not uncommon and you should be able to quickly come into the whole backstage code and start to change the backstage code, for example, extend the backstage function to your needs because everything is in a fairly standard way written and it should be easy to extend everything. I did it and I'm 100% sure that you also be able to change this and to extend backstage to your needs. Okay, that's not the same slide. You can see our plot of this in the background. So let's talk about the backstage Pulumi plugin. Okay, the backstage Pulumi plugin consists of, let me put this here, consists of two components, two independent components, we have one component is the scaffolder backend module and the next component is the backstage plugin itself. I put the QR code on top of it where you can see the code, where you can have the detailed instruction on how to install the backstage, the Pulumi backstage plugin. It's also available here, as you can see on Rody when you want to use a managed backstage, for example, and as you can see on the left icon here, it's also listed in the official backstage plugin catalog. So you can also browse this through and then just click on explore and you will be redirected to the GitHub repository where you see the detailed instruction. Oops, so, okay, let's have a look into the Pulumi scaffolder backend module. This contains currently, as we're speaking, of two new actions. So we have the Pulumi new action and the Pulumi app. If you maybe worked with Pulumi, this should be very familiar, you should know about the commands. So with the Pulumi new command, you can use templates. So self-created templates from your company, you could use the template library Pulumi's offering and you could say, okay, create from this template, for example, the EKS Go template because you want to use Go, the Pulumi program and with the Pulumi app, the second action, you could then just apply everything and deploy it. So Pulumi new creating a new project. If you have already a project, you don't need to create the Pulumi new. What you can do then is just call Pulumi app, for example, when you just already created this one and it's part of your scaffolder skeleton or your scaffolder template. We will see this, what I mean in detail. The Pulumi new has many configuration possibilities. So you can define which stack, which Pulumi cloud organization you are using the name. Template is very important. Let me use the laser pointer to, where are you? I don't find this. Okay, so template just define, for example, the building template name or the URL, it doesn't matter. So just point what you want to use description and then you have additional configuration parameter to set the config. And if you want to use secret config, so they are automatically encrypted with the Pulumi secret provider, you can just say, okay, secret config and this object is the map just use them and it will be automatically encrypted additional arcs and then of course the folder to run Pulumi in. Next one is the Pulumi app has similar properties. So stack organization deployment and so on and so on. Very interesting. One part to mention is currently you can also use here in the Pulumi app command, Pulumi deployment. So just set the flag, it's, you can say it true or false. If you use true, it's going to use the Pulumi deployment. So you don't need to, for example, it will not be executed on the backstage server. For example, you don't need to provide the backstage server, all the SDKs of all the languages you're going to support. You don't provide, for example, different, the Go versions or C sharp or something like this, everything will be executed in the Pulumi cloud. This is really interesting and highly recommended that you check our documentations about Pulumi deployment as it will help up to avoid any CI infrastructure. Now, second component of our Pulumi backstage integration is the Pulumi plugin. The Pulumi plugin currently displays all the information from the Pulumi cloud back into your Pulumi and your backstage components. So you can see which organizations belongs, which programming languages behind this and so on and so on. And the second part is also the Pulumi activity. So when you're navigating inside your component, you can then just see, for example, all the runs you had and then you can jump from this to the Pulumi cloud. So this is the Pulumi card element in the component overview. As you can see, you see the organization repository, the runtime and the deep link to the Pulumi console. Second part is on a system overview. And again, you can change this when you want to create, you integrate this, for example, I created the Pulumi card here on the system because my assumption or my modeling is to say, okay, a Pulumi backstage system corresponds to a Pulumi organization. And I want to see all the informations of the whole Pulumi stacks inside a Pulumi organization on a system level. And as you can see, but you can change this if you say, okay, we want to differently, that's the beauty of backstage. If you want to use a different way to model your backstage entities, you can change this and then just assign the Pulumi plugin and say, okay, I want to show this maybe on a resource level. And last is the Pulumi activity view where you can see when a Pulumi run is executed and then you have all the informations here and you don't need, for example, to jump out of backstage. Okay, that's the Pulumi plugin. Before we dive into our demo and we will be shortly there with the demo code some words around the backstage software templates or software templates are a tool that helps you to create components inside backstage and it will execute, for example, all your code you put in your skeleton folder, for example, and you can gather all the variables so you have a way to collect informations to interact with your users, ask them for specific questions and depending on the input, you then just render different code. And also interesting is, okay, you just don't want to give people now a zip file and say, hey, here's your Pulumi program or here's your microservice program. You can also connect it to two different locations, for example, GitHub or Github, Azure DevOps is also supported, so you have a way to render the template with the variables and then automatically uploaded to your system to GitHub, for example. Writing templates, templates are stored in the software catalog onto the kind, the template, you will see this in the demonstration, templates are written in YAML and contains metadata input, what I just mentioned, input and then a list of actions you want to execute all the scaffolding actions, for example, also with Pulumi. Adding a template is also quite straightforward, so you could just go to your app config YAML, for example, and then you use the static location configuration and there are two ways to add the template here. One is the static location configuration, as you can see in the screenshot underneath. This is from my example. You can also use the catalog import endpoint plugin if you want to do bulk import stuff, so there are two ways to import your templates. Okay, let's head over to our action and see some of the code. So some explanation about the demo architecture. So again, I created here a so-called developer platform. It consists of two parts. So we have our Github's infrastructure, so because now we can use, for example, Flux in conjunction with the Pulumi operator to define infrastructure and deliver it via Flux in a Github's way. There's an example in our demo code for this. And the second part is our backstage infra itself. It will be hosted on Fargate using an elastic container registry and RDS and everything you need to host backstage. Here in this example, I didn't want to host it on the Kubernetes itself. You could also, for example, deploy it on your Kubernetes and then run it there, but I found it more convenient just to use a service. So there's one thing less to worry about. We're also going to use the Pulumi cloud because we want to upload our state files to the Pulumi cloud. And that's what we use here. And it's not really visible here, but the whole company infrastructure, the whole company definition is inside a Github organization. So we're going to model our company in the Github org and this is in the below part. So how is the interaction going on? We have the dev team. The dev team heads over to backstage, choose from different software templates, choose what kind of infrastructure or what kind of service they want to create. Backstage runs, in our case, creates the infrastructure, uploads everything to the Pulumi cloud and feedbacks all the necessary informations back to the development team and creating everything in Github. So it will be, for example, creating an infrastructure. You will get the Pulumi code automatically generated in your Github organization to then continue. So you could say, okay, from there, I'm going to use Github workflows, for example, or I'm going to use a different way to do my CI part. So this is just a reflection here. Or when you're going to use, for example, the Pulumi operator, you can just change the code and the flux will detect any code changes and will then execute the deployment and Pulumi operator will then execute the new the changes in the infrastructure. Okay, so let's open up our infrastructure. So here we have our backstage instance. Just press reload. It's our demo organization. We use all the time inside Pulumi. It's our Sapphire Archiotec Emporium and they created a software catalog. As you can see, there are already some components inside. So we have fluxes already installed on our Github system. The Pulumi operators installed. We have external secrets installed and the AWS load balancer is everything on this Github's infrastructure. We just saw in the beginning. So when we have a look into, for example, flux, we can see here is our Pulumi card and the organization name and the repository name, the runtime which everything gets executed. As you can see here, there are already some runs here and we can see much more runs here. So very interesting and you can drill down to every piece of them. Okay, that's so far the existing infrastructure. We have here our Github's infrastructure. There is a YAML error. That is not that important. We can check this later. So, and let's see, now it's still consistent here and then we see also what I mentioned before with the resource that we can see currently in the resource, all the providers which are used and how many resource are created using this different provider. You can see AWS, for example, is 116. Okay, so let's create new infrastructure. So here we create, we see here different templates. So we have, for example, a new EKS cluster. We can create a new Lambda function. We can create a microservice on Kubernetes. We can create a static website and create also a virtual machine. So this is completely made up from these services I defined which will be useful inside my company because we deploy plenty of stuff still on a virtual machine. So let's have a look into the code. How does the code look like? So let's pick this here. For example, the virtual machine. How does the code look like? So we drill down in our scaffold template. So as you can see, I told my backstage instance here using the backstage. So I use this backstage resource called location and I say to my backstage instance that, hey, point to this specific repository to the specific YAML file and location will consolidate everything. So I can say, okay, I define, this is everything under my template. So I named, for example, my location templates because this is everything template related. But you can use locations also for different backstage resources for backstage component resources and so on and so on. So you can really create your service catalog. In my case, all the templates gets generated here, aggregated using the location. And now let's have a look with the first one with the simple static website. How does a simple static website look like? So as you can see, I have here a folder. I want to group everything and inside the folder, I have my template folder. This is completely made up for me. You can name it as you wish. That's not the thing. But everything underneath this template folder is already possible to template, to use a template engine. So everything, it's similar to the cookie cutting process. So backstage has a template engine underneath. Before it was the cookie cutter, I think they changed it now to a similar approach. And you can see it will generate a folder and with the using the name I collected from the user. And this is also for file names. So everything inside the template folder gets rendered and the magic happens here. So this is our first template, creating a simple static website and S3 bucket. So all the meta information we just mentioned before description and so on, make it easy for the users to understand what is behind this. Every template has an owner. So if I have, for example, a question, something is missing in my template, I can just look up the owners here. In this case, it's a group, the infrastructure group, a specific type. So in my case, I gave it a serverless, for example, but you can also change the name. There are also some well-known types you can use. I, in my case, I said, okay, this is a template around a serverless infrastructure. And now we come to the next step where we define the properties. So the parameters, sorry. So we can define now the different pages that the user will be guided through. So we have our first step. We collect some informations, the name and the content. You will see this in an action. And I collect the name, the content, because this is a funny service. You can just write the HTML content inside Backstage and it will automatically generate an index HTML. It's very important to say, okay, this will be hosted on our S3 bucket. So where is the S3 bucket located in which region? I can define a default answer, collecting all the informations. We can also say, okay, which system belongs this and who's the owner? So I can choose our owner. I can say, okay, this is the infrastructure team, this is the team. So I just went here on group. You could also go on user and define, okay, it has to be a specific user. Next point are the steps and here where we execute all the scaffolder actions. So here in this case, we say, okay, fetch template is our first action. And as you can see with the URL, we say go into the template folder. You need to transform the template folder. As you can see, names are changeable. It doesn't need to be named template. And now I can pass to the templating process. I can pass all the specific us name. We just saw folders and file names are using the value name, content, region, and of course here the stack. So which organization to use? Next point is then the publish step. So in my case, because this is here a GitOps approach, I want to create a pull request because the ops team, for example, they needed to look on it before they approve it. So we have a pull request flow going on. And I still have here my spelling error inside. And the next point is then I just want to give feedback to the users to say, look at this pull request, for example, and when the pull request gets approved, you will get your static website. So let's head back to our backstage instance. And now we can say, okay, let us use now the static website. So let's say, let's see, a webinar. And you can say, hello. Okay. We want to deploy the development stack here in this case. And I'm going to choose an owner here. I say, okay, I'm part of the development team. So here you can see, I will just get some informations of the input I collected. And now I can say, okay, please create this for me. And as we can see, it starts. And when we go to the PR now, we see backstage created a PR for us in the repository with the infrastructure where our Github's operator is looking at. So the Github's operator is configured to just check here on this side. And we can now review everything. So let's imagine I'm not the platform team and I have to review this. I can say, okay, there's a component called CNCF webinar going to this project that's completely fine. And this is the code that looks also very good for me. Here's some, the references to the credentials for AWS, very good. So I say approved, looks good to me. So, and now I can squash this one. Okay. And as we don't want to wait too long for our flux operator to run, we can also say to the flux operator to say, okay, let's kick this off. Okay. And we can see here the CNCF webinar is created. Currently there is no reference because it's not executed on Pulumi slide. Let's see in the Pulumi cloud. If it's, yeah, we can see it's already executed. And we should now get hopefully our S3 bucket generated. So it's going to create here the stack. Okay. We let this run through. Okay, that's fine. So it should be, okay. And we have here now the link and we see hello CNCF webinar, very cool. So first story is completely done. So let's head over to the next one. Say, okay, we want to create a different one. So let's say, for example, we want to create a virtual machine. So let's look also into the virtual machine scaffolder code. So again, we go into the virtual machine, also created from the platform team, same pattern. We have the template definition owner and now additional informations we want to collect owner and so on. And here we define now the Pulumi template again. This will be a second view. I can define some required properties and then again, collecting the organization which Pulumi organization to use the region. And now we come to some interesting part. We can collect the instance type, some network cider. We can discuss, is this something I want to expose to the team or is it the infrastructure? Is it the DevOps person inside a cross-functional team who maybe provisions this for everybody inside the team? And he has more knowledge about the whole networking subject. It's really, it really depends on the team structure. There are different programming language supported here. So we can say, okay, depending on the team and on the approved language inside an organization, we use an enumeration. And because to give it better names, we can use the enum names and then overwrite it otherwise you could just see TypeScript or YAML. You can make it a little bit more appealing for the user's stack selection. GitHub repository location. So we can define where to save the code. And now we've come to the next point with our Pulumi plugin. So here we're going to use the Pulumi new command. And as you can see, collecting again the informations. So name, stack, organization, we just saw. And here's the interesting part. We use a template here. So in this case, the VM AWS template because we're going to deploy everything on AWS. And we set some of the Pulumi conflicts. I just talked about the Pulumi architecture in the beginning. So we collect the region, the instance type and the VPC network slider. Wait a couple of seconds. Sometimes there's a race condition going on with the transformation of the code. And now we can execute the Pulumi app command and say, okay, we're not going to use the Pulumi deployments. Again, setting the name, setting the repository URL. And here the repository project path means where is the Pulumi code? Sometimes it could be that you put it into a sub folder because you want to run a monorepository in your site and say, okay, application code is in a folder, infrastructure code is in a folder. So you can now define where to put this. And we want to get out some of the outputs. We want to display to the user some outputs. In this case, the URL of our service which runs inside the virtual machine. We render again the template. We publish it now with all the pull requests. We publish everything, the whole Pulumi code in GitHub. And then we display the informations. Okay, so let's create our virtual machine. So we say here, as VM, let us call it CNCF. VM. VM. VM. The owner is this time again, the development team. So I'm going to use my organization inside Pulumi, as you can see the organization here. Oops. And let's head back here. I can choose now the region. I take EU central. I choose a medium one. This can stay as again, if there's no need on this one, you don't need to display this. I will use Go, use the deployment environment to define it's a deployment. Giving my organization, my GitHub organization. And let's give it a, so test VM. Now it's the name of the repository. We can see now all the informations gathered again. Click on create and it should all up and running. So we head over to the Pulumi cloud. You can see now, hey, the CNCF webinar is here created. Okay. And it should also now start to deploy everything. Oops. So we deploy, the VM gets created. This can take a couple of seconds. You can also see that it's what it's going to do in the background. So it's going to create a VPC, a subnet internet gateway. So there's much going on and our instance and the same goes here. Okay. So now we publish this to GitHub. That's very good. And everything is deployed and registered. So we have now the feedback from Pulumi with the URL. I'm going to open this one. Let's maybe take a couple of seconds. We get the IP address. We can see the code in GitHub. You see everything is deployed here in our GitHub repository. The code is now visible. I can now work on this. And I can see also that some of the properties, the default properties is set. And let's see. And yeah, here is it. Hello world from Pulumi. The service is up and running. And we can also watch this here in our service catalog. We see that the card is displayed. And we should also see for this component, the activity. And we can then jump from here back to the Pulumi cloud. Okay.  So now we want to maybe want to deploy something bigger to say, okay. So now we use some deployments. Can we see something more sophisticated? Maybe to say, okay, what is with application code? So let us open this in a new tab. Again, I think for this one, I need a Kubernetes cluster. Okay, I got. So again, we have our template definition. Nothing changed before. We collect some of the properties. We configure the infrastructure. We can now define, for example, additional functionalities here. I want to enable also a configuration scanner. And here I'm using, for example, 3V. You can add additional tools and then you can extend your GitHub pipeline, for example. Choosing again a repository. What we do here now is, I want to deploy this on a Kubernetes cluster. So here in this case, I say, okay, I want to deploy a Kubernetes cluster of the type resource. Please show me everything of type resource. And then I'm fetching the information because I attached to this Kubernetes cluster some informations about the Pulumi organization because we want to use stack references. We want to get the informations out. Then we render again the different templates. So we render the flux template because we want to tell the flux operator, hey, here, look into this Git repository, that you find the application code to deploy. And after this, we also render the real application code of the application. And let's see, so this is one part, as you see again, using the code for flux defining a Git repository, defining a customize to say, okay, please look inside this Git repository. We just created look in the customize folder. There you will find the Kubernetes manifest you need to deploy. So it's my assumption again. So when we look into the template folder of the code itself, you can see there's a customized folder. And inside the customize folder, there's a simple Kubernetes deployment, a simple service. And here we have the application code, a simple hello Pulumi backstage world. Okay, so now we can choose this one, can give it a name. So we say microservice or let me say sales, microservice and we say the owner is the development team. And then we can say here again, as a cluster, we use the EKS cluster development. Let's choose 3V as a scanner. That's fine. I use again our demo repository. So, and we can so now create, okay. And perfect. So two things we created here. We created a pull request. You can look into this pull request for the Git apps repository. So it created inside the flux apps folder. It created the sales microservice application YAML with all the stuff here inside, which gets executed from flux. So creating a Git repository, creating the namespace for the application. So I can approve this pull request. And when we take a look into the next part, we can also see the application code. So this is the application code. We created a microservice inside. There's a Docker file. And we can see automatically that the GitHub workflow is creating a container. So a new Docker container gets created. It will also create the customized file with the SHA ID. So this will also generate it and set inside the customization YAML. That's very interesting. So when we have a look, we should see now on commit on the customize. So here is our microservice. That's cool. Microservice is up and deployed. And hope, yeah, we see that the customize also calculated from this container image and set it the new tag, the SHA number of the tag. So we have a 4E here. And if we take a look here, we see, yeah, 4E, that's the version we have. So everything is set up completely fine. Let's have a look into the 3V part, for example. So where is login, built and push, da-da-da-da-da, post build? Where was the part we activated? Workflows build, oh, I think he didn't collected the 3V part. Okay, I did an error in the code. So let me have a look into the template definition. So why the 3V did not render, generate, generate. Okay, here I wrote 3V. It should have printed the scanner. So let's have a look into this. How did I collect the 3V variables? Scanner should be set template flux. Scanner should be set, not sure why he did not generated the stuff. Interesting. So let's see what did we collect it here. It's not, it's not visible. What did I collect it? Probably let's click on start over next. Okay, I selected 3V. Not sure why it did not render the 3V part. Yeah, here's it. No, no, that's not, that's, here's it. Here's the 3V stuff. Okay, he used the 3V config check, my fault. So it's part of the action. So when we go to the 3V action in the generate, it's not an extra step. So maybe that should have been. So we have here the run check for misconfiguration and we can see some plenty of information here. Wow, I should have fixed this. Okay, but at least gives me feedback. Every time when I run now my microservice, I get feedback that there is something to change. So I applied also a compliance development team gets all the tools already installed and just don't need to care that, for example, a misconfiguration check will be happened. Everything is also registered here as we can see. And yeah, so that's it. I think the Lambda one, we can just quickly check here. Lambda, so we will quickly skim over this and then we can also again set the properties. We set the language, the stack, and then the Lambda webinar create. Again, create the Pulumi new, download the properties and let's see that it gets deployed. So let's have a look into the Lambda deployment. So we see update number two is running and this should deploy now all the Lambda resources we need. So just give it a second. And yeah, we can see the role is created and so on, so the Lambda function gets created and it should give us as output the URL of the Lambda. So let's see that this gets created.  So everything people really don't care and maybe, yeah, I'm not able to do this in this quality. Like for example, the platform team would like to have it. So we defined this in our code. We will have a look into the template again. So we see it's deployed. We get the URL also. So here is the URL for the Lambda. Serverless with Pulumi, we get the current time out, perfect. It's working, bam. And we can see the code. So this is our Lambda function and so on, this is the website which gets delivered with this stuff. Okay, now I have a quick look into, yeah, the Lambda is also here, perfect, fine. And let's have a look into the template definition. So again, as I mentioned before, kind template. Let's have a look into the Lambda, into the code. And we see again, properties gets collected, all the informations, region, language, and so on, where to save the stuff. And here we call again Pulumi new. We use the template, the inbuilt template of Serverless AWS. We set the region and then we execute Pulumi up and as an output, we want the URL and the URL gets then displayed here, perfect. Okay, that's fine. So let's close this and finish our slides. Okay, so follow up, wrap up. We just saw how to define backstage templates. We created backstage templates. We registered the backstage templates to our backstage instance using the static location, the static location configuration to say, okay, here is our template. We used the kind location to bundle several templates together to say, okay, these are all my paths. I want them all deployed. You could split them also. So there's also many, many possibilities. And yeah, the QR code for the Pulumi code for the Pulumi backstage plugin is on the top and some resources I found very useful for to dig into the backstage in general and Pulumi looks if you're interested into it and again, the backstage plugin. Okay, so with this said, thanks all for watching. If you're interested more into backstage, just let us know. I'm more than happy to show additional content around backstage and how to combine different deployments inside Pulumi or how to use, for example, the Kubernetes plugin inside backstage to see information of your Kubernetes deployment or multi cluster deployments and so on and so on. So many, many interesting things. So hope you liked it. And I will say thanks for watching and see you next time. Bye.


USS New York changed home ports from Naval Station Norfolk to Naval Station Mayport, December 6th. New York is part of Iwo Jima Infimius Ready Group, or ARG, which includes USS Iwo Jima and USS Fort McHenry. They will also change home port to Mayport. The ARG will replace Mayport's frigate slated for retirement. And, in Bahrain, SECDEF visited Fifth Fleet December 6th as part of a regional visit to the host nation and sailor's station there. He reassured our Arabian Gulf allies of continued US support. SECDEF also visited sailors, marines and merchant mariners aboard USS Ponce during a tour of the ship where you thank them for their service and wish them happy holidays. Read more about these stories at navy.mil. From all hands, update, thanks for watching.


Crazy, crazy, right? Like, I don't know what the best way is to deal with someone with a knife or a machete, but from what I understand with a machete, the best way to do is not pull back but to go into them, right? With a knife is a different story, because when a machete is really long, don't take this, the Elder God will know better. Elder God, you correct me if I'm wrong or anybody correct me if I'm wrong. If someone's coming to you with a machete, because it's longer, it's not a good idea to go like this because they can lunge at you and hit you, right?  That's my understanding of it, and that's what I have in my psyche, which I've never had anyone to talk with a machete, so I've never had to actively test this theory, and I hope I never do.  But if they have one knife, my understanding is you go for the knife, the hand that's holding the knife. Don't worry about anything else, you're going for the knife. If you're going to engage them, run better, but if they run faster than you, they can stab you in the back.  You go with the knife if you're if you're blocked, right? Elder God, machete, getting close. Attack with elbows and knees, nice. Yeah, and for me, I'm lucky. I'm good with that shit, right? I took wrestling, I took jiu-jitsu, and I have a berserker attitude towards me. Bertie here, best this practice cardio and run. The kicker is this, right? When people are high on adrenaline, they can get bursts of energy and it can take them through the second wind that they need, right? And if you're not fast and they're faster than you, then they can come up behind you and do damage. So, Cheryl, don't try to grab the knife. Grab arm and say, yeah, yeah, yeah, grab arm. Don't try to grab the knife because they can go, shh, you're going for this part, right? Or this part, right? Not even this part, this part you're going for, from what understand. Thank you very much for the follow, Dr. K4pa. K4pa. I don't know how to pronounce that. But only after practice. Thank you, Cheryl. Touching Jason. Been doing jiu-jitsu since last October and absolutely loving it. I wrestled in high school and never thought I'd get back into the mats in a meaningful way again. Yeah, yeah, I wrestled in high school too. Some of the best training to self-defense there is. I love you more. Salutations, hope you're doing well. Elder God, knife. Make them overreach in an attack. Use a bar technique. Okay.     No ifs or buts or anything like this, right? This is not life advice. And I do not recommend engaging anyone. I do not recommend killing anyone. Birdie here. I think if you had to engage and they had a knife, a heavy tip, tip would be on the best defense. May take a stab in the leg.  When I was in long time ago, decades ago, Aldegard armlock, the knife becomes their enemy. Nice. Grappling. Here's a story that I heard when I was in my teens or something like this. And this is a true story. There was a guy that in my neighborhood, this is like three, four decades ago, right? Who pulled a gun on someone, right?  The guy took the gun away from the guy, the other person, right?  The guy was a fucking, he just got out of prison, right? For not good stuff, right? He threw the guy on the ground, took the gun, put the gun to the guy's head and went click, click, click, click, click, click, click, click. Now the guy who pulled the gun didn't have the gun loaded, right? Lucky for him to a certain degree.  Nothing happened.   And not life advice. Do not pull any weapons on anyone.   But in many areas like New York, you can be charged with a crime. Yeah, in Canada as well. All right, so you better have your story straight. Oh, I look God, I haven't done this about 12 times in the last seven years. Damn. I love you more. Like they say, if you pull it out, you better use it. If you pull it out, you better know how to use it. Right? And don't pull it out.   In Canada, it's not. You could seriously end up in jail. Touching Jason sometimes, unfortunately, even having your story straight is looking for a guilty party. Yeah. Got got a not so fun personal story on that matter. Laugh out loud. Randall, Cheryl, woke up real quick. Cheryl woke up real quick. Remember, who's commenting? I love you more. Fun. I like it. I love you more. You're not posting crazy things. You're engaging our community. I like it. Welcome to our stream, brother. Hello, God. No such thing as tough. It's trained or untrained. Yeah. Sometimes it's lucky as well. Luck has a lot to do with engaging, unfortunately. Brady here, martial arts is super important for things like that, because arguably the most important aspect in the situation is understanding distance. Yeah. Cheryl had a phone call. Amen. Amen. Salut. I'm going through the cigar fast. Loving it. I've been looking forward to the stream by the way. But like pimp, self-defense classes in school would be a great idea indeed, but they don't do. Thank you very much. Thank you very much for the follow. Salut, salut.  Yeah. Time for some to pack now. Thank you. Yeah. To pack.  Brilliant. Hong Kong. Hong Kong. Salut, salut. Fun gang. What do you guys say? Should we do a comic book haul? Should we do a comic book haul? Like a 44 comics here. Twitching Jason. Thank you very much for tier one sub. Salut, salut. Subscribe for three months. Woohoo. Kitty cats. Kitty cats are just roaming around. They're very happy to see me by the way. 44 comics. We've got to finish the cigar. We'll finish the cigar after we finish. We do. First time chat. Buffing. Buffing. Thank you very much for the follow. Salut, salut. And thank you for the kind words. I just do what I do. After five plus decades on this planet, you better, you better know how to live it I guess.


So, welcome to this special CUBE Conversations. I'm John Furrier and Palo Alto at the CUBE Studios for special conversations during tackles. General Manager of Dataos IO, part of Rubrik. Last time I interviewed you, you were the CEO. You guys got a choir. Congratulations. Thank you. Thank you, John. Very happy to be here. How'd that go? How'd the acquisition go? Excellent. You know, excellent. It was, I met Bipol, I think, you know, about August of last year. And, you know, it was, it was sort of perfect managed waiting to be happened, right? You know, we both were going after, after the broader, addressable opportunity of data management. I've enjoyed our previous conversations because you guys were a hot growing startup. And then you look at Rubrik, if you look at the success that they've been having, just the growth in data protection, the growth in cloud, you guys were on that with it from the beginning with Datos. Now you got a management team, you got all this growth. It is pretty fun to watch. And I'll see you locally in Palo Alto. So it's been interesting to see you guys. Huge growth opportunity. Cloud people are realizing that this is not a side decision, it's got to be done centrally. The customers are re-architecting to be cloud native, they're on-premises. We saw big industry movements happening with Amazon at VMworld, announcing RDS on VMware on-premises, which validates that the enterprises want to have a cloud operation for on-premises and in cloud. How has this shaped you guys? You have big news, but this is a big trend. Yeah, no, no, absolutely. So John, I think you rightly said the pace of innovation at rubric and the pace of market adoption is beyond everybody's imagination. And when I said that it was sort of a marriage waiting to be happened, is if you look at the data management time, it's close to 50 billion dollars. And you need to build a portfolio of products. You need to sort of think about the classical data center applications because on-premise is still there and on-premises is still a big part of spending. But if you look at where enterprises are racing to the cloud, they're racing given digital transformation, they're racing customer 360 degree experience. Every organization may be financials, may be healthcare, may be commerce wants to get closer to the end customers, right? And if you look underneath that macro trend, it's all this cloud native space, whether it be Kubernetes and Docker-based containers or it could be RDS, which is natively built in the cloud, or it could be, you know, hey, I want to now run Oracle in the cloud, right? And once you start thinking of this re-architecting stack being built in the cloud, you enterprises will not leap and spend those top dollars that they spend on-prem if they don't get a true durable data management stack. And one of the things that really was impressed when you started a data-house now, it's part of rubric, is you were a cloud up and down the stack. You were early on cloud. You guys thought like cloud native. Your operations was very agile. Everything about the company beyond the product was cloud. This is a critical success now for companies. They have to not just do cloud with product. Correct. Their operational impact has to be adjusted, how they do business, the supply chains, the value chains. The licensing, the pricing, right? This is the new model. And so this is where the data comes in. This is where the support comes in. You guys have some hard news. Datos, IO 3.0. What's the big news? Yeah, no, so John, as you said, you know, we've been very squarely focused on what we call the NoSQL Big Data Market, right?  Just think about that. Take, you know, if you take a guess on number one database in Amazon native, it's not Oracle, it's MySQL. Number two, it's not SQL Server, it's MongoDB. So if you look at the cloud native stack, you know, we made this observation four years ago, as you said, that underneath this was all NoSQL. We really found that blue ocean, as we call it, the green field opportunity, and go build the next veritas for that space, right?  Once you find an island full of gold coins, you don't leave that island. You go double down, triple down, right? You don't want to distract your focus. So 3.0 is all about us focusing, you know, really sort of the announcements are rooted around three vectors, as we call it. You know, number one, if you look at why Rubrik was so successful, you know, you went into a pretty gorilla market of backup, but why Rubrik has been successful at the heart is this ease of use and simplicity. And we wanted to bring that culture into not only Datos team, but also into our product, right? So that was simplicity. You know, large-scale distributed systems that are difficult to deploy and manage. So that was the first part. Second part was all about, you know, if you look at Mongo, Mongo has gone from zero to four billion dollars in less than 10 years. Every Fortune 2500 global 2000 customer is using Mongo in some critical way. Why is that? I mean, people were always, I mean, of course we love MongoDB, but people were predicting their demise every year. Oh, it's never going to scale. I've heard people say, and again, this is competition. We knew who they are. But why is the success there? What, I mean, obviously no sequel and unstructured data is big tsunami and there's more data coming in the ever before. Why are they successful? Why are you guys done right now? That's why I enjoy being here. You know, you go to the why, not the what and the how. And the why is rooted for why MongoDB is so successful as application developers. Like we've all read this book, developers are the king makers of IT, not your IT and storage admins. And Mongo found that niche that if I can go build a database which is easier for an application developers, I will build a company. And that was the trend they built a company around. Fast forward is stock that is trading at $80 a piece to four billion plus in market capital. You know, I think the other thing I would just add, just riffing on that is that cloud helps because we're MongoDB horizontally scales. Elastic. The old critics were saying, thinking vertical scale, cloud really helps that. Absolutely. Absolutely. You know, it's, cloud is all about elastic resources, right?  So, you know, what we found in the first, as you know, in the last two to three years journey of 1.0, 2.0, that we were having a great reception with MongoDB deployments and again, consolidate your gains towards Mongo. So that was the second vector, making data was get scaled out for MongoDB deployments, right? Number three, which is really my most favorite, was really around, you know, multi-cloud is here. Like no enterprise is going to really bet only on one form of Amazon or one form of Google Cloud. They're going to bet it across these multiple clouds, right? So, we were always on Amazon and Google. We now announced data was natively available on Amazon. So now if you have enterprise customers doing no SQL applications in Amazon, you can protect that data natively to the cloud, being that your cloud. So which class are you guys supporting now at 3.0? Can you just give the list? Yep, yep. So we supported Amazon from very early days, AWS. Majority of customers are on Amazon. Number two is Google Cloud. We have a great relationship with Google Cloud team, very entrepreneurial people also. And number three is Azure. The fourth, which is, you know, sort of a hidden Trojan horse is Oracle Cloud. We also announced data's on Oracle Cloud. Why you may ask? Because if you look at again, no SQL and data stacks in Cassandra, we saw a very healthy ecosystem building for Cassandra and Oracle Cloud for obvious reasons. And it was very good for us to follow that tailwind. And it's just that Oracle yesterday for a briefing and not kind of revealing a confidential major because it's all on the record. They're heavily getting into cloud native. They have to. They have to. There's no choice. You know, they cannot be like tiptoeing. They have to go all in.  This is something that you guys now have focused on. Talk about the microservices. How does that fit in? Because you look at Kubernetes, Kubernetes is becoming that kind of TCP IP moment for the cloud world or TCP IP powered networks and created internet working. The inter cloud or the multi cloud relationship. All the cloud net. Kubernetes is becoming that core catalyst. Got containers on one side, service measures on the other. This brings in the data equation, stateful applications, stateless applications. This is going to change the game for developers. Absolutely. Now you have a backup equation. How do you know what's the backup? Correct. What's the data? Correct. What's the impact to you guys? So the announcement that we announced just to cover that quickly, is we were seeing that trend. If you look at these developers or these DBAs or database admins who are going to the cloud and racing to the cloud, they're not deploying OVA files. They're not deploying, as you said, IP network files, right? They want to deploy these as containerized applications. So running Mongo as a Docker container or Cassandra as a Docker container or Couchbase as a Docker container. And you cannot go to them as a data management product as a age-old mechanism of various bits and bytes. So we've announced two things. Datos is now available as a Docker container. So you can just get a Docker file and run your way. And number two is we can also protect your NoSQL applications that are Dockerized or that are containerized, right? And this really our first step into what you're seeing with Amazon EKS, right? Elastic Kubernetes service. If you saw NetApp announced yesterday a acquisition of Kubernetes as a service, right? And so our next step, now that we've enabled Docker container of Datos, is to how do we bring Kubernetes as a service on top of Docker? Because Docker to deploy orchestrate managed by itself is a little bit still a challenge. Yeah, containers is a stepping stone to orchestration. You need Kubernetes orchestrate the containers. That is correct. That is correct. All right, so summarize the announcement. If you had to boil it down, what's the 3.0? Yeah, no, so if I were to come back and give you the sort of the headline message, it is really our release to go crack open into the Fortune 500 global 2000 enterprises. As you remember, our 60% of our customers were already, what we call it internally, R2K global 2000 customers. So Datos, 60% of our customers were large Fortune 500 customers. They're running mission critical. And they're mission critical. So you're supporting mission critical applications? Absolutely, some of our biggest customers, ACI worldwide, one largest financial leading organization Home Depot that we've talked about in the past. Palo Alto Networks, the world's largest cloud security networking company. If you look at these organizations, they're running cloud-native applications today. And so this release is really our double down into cracking open the global 2000 enterprises and really staying focused at that market. And multi-cloud is critical for you guys. Oh, absolutely, any enterprise software company without a, especially a data company, right? At the end of the day, it's all about data. Theron, talk about why multi-cloud is so important. I'd love to get your expert opinion on this because you know, Kubernetes, you see what's coming around the corner with service meshes and all these, it's cool. So because it impacts the infrastructure with multi-cloud, certainly what everyone's asking about hybrid and multi-cloud. Why is multi-cloud important? What's the impact of multi-cloud? Great question, John. I think it's rooted in sort of three key reasons, right? Number one, if you look at what enterprises did back in the day, like history repeats itself, right? They never bettered only on IBM servers. They bought Dell servers, they bought HP servers. Never anybody bought bettered only on ESX as the virtual hypervisor platform. They're bettered on KBM and others, right? Similarly, if you look at these enterprises, the ones that we talked about, Palo Alto Networks, you know, they're going to run some of the applications natively on Amazon, but they want DR in Google Cloud. So think about a business use case being across clouds, that's the one, right? I want to run some applications in Amazon because of elasticity, ease of use orchestration, but I want to keep my DR in a different site, but I don't want to do a colo, right? I want to do another cloud. So that's one. Number two is, you know, some of your application developers are, you know, are in different regions, right? You want to enable sort of different cloud sites for them, right? So it's just locality, we're being more of a reason. And number three, which is actually probably, I think the most important is, you know, if you look at Amazon and what they have done with the book business, what they've done with others, e-commerce organizations, you know, like eBay, like Home Depot, like Foot Locker, they're very, very, of betting the farm on a retail organization. You know, fundamentally, Amazon is a retail organization, right?  So it's like vertical, which vertical is prone and or more applicable to a particular cloud, if that makes sense. And so having multi-vendor has been around for a while in the enterprise, so multi-vendor just translates to multi-cloud. There you go. Yes, yes. All right, so how about what's going on with you guys? Next week is Microsoft Ignite, their big cloud show from Microsoft.  So what's going on with them? You're co-selling together, they joint develop, what's the update? You know, Ignite, so Microsoft, you know, giving an update on Microsoft and then Ignite, you know, as you know, John W. Thompson is on our board and, you know, fundamentally, you know, the product that we have built, you know, Azure team working with them, they've come to realize that it's a great product to bring data to the cloud, right? And we get you a very good strong product relationship with Microsoft. We have a co-sell, meaning their reps can sell Rubrik and get quota retirement. That's massive, right? Think for both the companies, right? And companies don't make those decisions, John, lightly. Those decisions are made very strictly. Quota relief is great. It's huge. Salesforce for you guys. Exactly, yeah. For us, specifically on Ignite, you know, with this release, we announced Azure. You know, we worked very closely with the Azure storage division. And, you know, when we pitched them, hey, we are now, Datos is available on Azure. The respect that we got was amazing. We had a Microsoft court in our press release and at Ignite next week, we have dedicated sessions talking about no SQL backups on Microsoft, natively being protected on Azure cloud. It's good for them, good for us. Huge announcement next week. It's good. You guys have done the work on the cloud. And it's interesting that early cloud adopters get some dividends on that. Just to summarize the chat here, if you had to talk to a customer who's watching or interested and sees all this competition out there, a lot of noise in the industry, how would you summarize your value proposition? What's the value that you're bringing to the table? How do you guys compete on that value? Why, Datos? Perfect, thank you. You know, if I were, you know, it's very, again, simple to do in one, two, three, right? Number one, we're helping you accelerate your journey to the cloud, right? You want to go to the cloud, we understand Fortune 500 enterprises want to race to the cloud. You don't want to race without protection, without data management. It's your data, it needs to be in your control.  Number two, you are buying a truly cloud native software, not a software that was built 20 years ago and shrink wrapped into a cloud. This is a product built into technologies which are cloud native, right? Elasticity, you can scale up Datos, you can scale out Datos, just like Amazon Resources. So you're truly buying a elastic, technologies-rooted data management product. And number three, you know, if you really look at cloud, cloud to you as a customer is all about, hey, can I build, not lift and shift cloud native? And you're adopting these new technologies, you don't want to not think about protection, management, DR, those critical business use cases. And thinking differently about cloud operations. Great to see you, Tarun. Thanks for coming on and sharing the news on Datos 3.0. Appreciate it. I'm John Furrier here in Palo Alto Studios with the general manager of Datos. I owe now part of Rubrik, formerly the CEO of Datos. Tarun Taksher, thanks for watching. I'm John Furrier, thanks for watching theCUBE.


We breathe air to live, each of us over 3,000 gallons of air every day. Normally, we don't think about the next breath where it comes from or what's in it. You take it for granted, except on smoggy days. When along with the oxygen we need, we often get air pollution. Sometimes you can see it, that telltale haze. It's not just Los Angeles or the Bay Area in the north. It's in much of California's central valley and high desert too. We see the visible haze, but there's more to smog than meets the eye, or irritates the eye. Smog takes a big toll on our health. 90% of all Californians breathe unhealthy air. In Southern California alone, 3,300,000 workdays are lost each year due to smog health effects. State-wide, air pollution causes over 6,000 premature deaths each year. Many thousands more are forced to visit hospital emergency rooms on smoggy days. Through years of research, we've only discovered some of the effects of smog on the body. But before we look at these effects, let's define the problem. What is smog? You can think of smog as an atmospheric soup of harmful gases and very small solid or liquid particles called particulate matter. The most prevalent gases are ozone and oxides of nitrogen, NOx, called NOx. Carbon monoxide and sulfur dioxide are other air pollutant gases, but we're going to focus on ozone, NOx, and particulate matter because they're California's worst air pollution problems. NOx gases come from just about any kind of source where fuels are burned. From cars, trucks, power plants, and factories. Natural oxygen and nitrogen in the air combine under high temperature to make NOx. Every morning, thousands of tons of NOx and hydrocarbon gases are spewed into the air. Hydrocarbons come from fossil fuels, mainly gasoline and diesel when they are burned. They also come from the evaporation of fuels, chemicals, and solvents. Together, hydrocarbons and NOx gases react under strong sunlight to form ozone and other hazardous air pollutants. Ozone by itself is a colorless, invisible gas, but the smog-forming process also generates very small particulate matter, which contributes to the haze everyone associates with smog. As evening approaches and sunlight weakens, less ozone and particulate matter are formed and smog levels drop. Over the past 30 years, we've made progress cleaning up the air. Ozone and NOx levels have come down, but not far enough. Ozone and NOx are still big problems, but today particulate matter is taking center stage. Smog is not the only source of particulate matter. Other particles come from the combustion of fuels, small, nearly invisible toxic particles of smoke and soot. Many of these particles are so small, they can stay suspended in the air for days, even weeks at a time, traveling many miles before settling to the ground. You know when you see visible dust that it's a good idea to stay away from it, but it's what you can't see that can get you. So how small are we talking? Well this is a human hair about 70 microns in diameter. And here is a piece of small particulate matter, about 10 microns in diameter. Particles 10 microns or less are classified as PM10. Things like pollen, windblown dust and tire rubber particles are size PM10, which is small enough to penetrate into the small airways of the lungs. Some particles formed by smog or from smoke and diesel soot are even smaller. This piece of particulate matter and smog is about 2 microns wide. Very small particles less than 2.5 microns in size are called PM2.5 and are more dangerous because they are small enough to penetrate into the deepest parts of the lung. The worst particles are those under one-tenth micron in size, the ultrafine. Found near fresh emissions from cars, trucks and buses, they can number more than 100,000 per cubic centimeter. When we breathe smog, we breathe a mixture of ozone, NOx and particulate matter from a variety of sources. Even though we can't see ozone when levels are high, it gets our attention. Eyes may burn in water. There can be wheezing and coughing. The throat is irritated and feels scratchy. The chest might hurt. There is a shortness of breath. Unconsciously, the body shifts to a shallow breathing pattern similar to that caused by fear. When we breathe polluted air, our bodies begin a series of natural steps to purge the pollution. The nose removes half of the ozone we breathe. Ozone reacts with tissues, killing cells and damaging the nose. Our airways are lined with cells that are covered with tiny hairs called cilia. They beat in a rhythmic pattern, moving mucus up to the throat where it is swallowed. Mucus is important because it sweeps up harmful particles as well as bacteria and viruses. Ozone and particulate matter paralyze cilia, making them move less or not at all. They can't do the job they were designed to do. Clean out the lungs. This makes us more vulnerable to disease. Like ozone, NOx irritates mucus membranes. Scientists have found that people exposed to high levels of NOx have more colds that settle in their chests. They develop chronic wheezing and cough, bronchitis and episodes of respiratory illness. Animals exposed to NOx and lab experiments become more susceptible to viral infection and are less able to ward off bacterial infections.  With every breath, air moves through the bronchial tubes down to the lung space. Deep in the lung are tiny sacs called alveoli, where oxygen is transferred to the blood and waste carbon dioxide is removed. An average adult lung has 300 million alveoli. If they were to spread out, they would have a surface area of 6 to 900 square feet. PM2.5-sized particles sneak past fine hairs in the nose and cilia in the respiratory tract to penetrate deep into the lungs, reaching the alveoli. Here, special cells called macrophages roam around eating up particles, bacteria and viruses, but smog can damage the macrophages and they can't do their job. Scientists are also finding that there is a link between fine particulate matter air pollution and heart attacks, even sudden heart failure resulting in death. Here's a comparison. This is a healthy open airway. And this is what an airway on smog looks like. Inflammation swells the tissue, restricting airflow. This is not good. Ozone damages the delicate, thin-walled cells in the alveoli. Within a few days, damaged cells are replaced, much like the way skin peels after a sunburn. Laboratory tests show that healthy people breathing smog can lose up to half their breathing capacity. Researchers fear that repeated episodes of lung inflammation may cause permanent lung changes and long-term health effects. Some people think they adapt to smog because symptoms may disappear after a few days. While symptoms may in fact go away over time, it doesn't mean they develop a resistance to smog. Smog continues to cause lung damage even when outward symptoms disappear. A constant cycle of damage and repair may lead to premature aging of the lung. Over days, months, or years, the damaged cells are replaced with thicker, stiffer cells, scar tissue called fibrosis. Scar tissue won't allow life-giving oxygen to enter the bloodstream. When we can't get oxygen, we're in real trouble. Ask anyone with emphysema what it's like simply trying to breathe. Three groups of people are more vulnerable to smog health effects. The first group are people with chronic obstructive pulmonary disease, which includes respiratory diseases such as asthma, emphysema, and bronchitis. 11% of all Californians fall into this category. They suffer the ill effects of air pollution sooner, and at lower pollution levels than healthy people. When smog levels are high, asthmatics can develop serious health problems, many serious enough to require medical attention. Up to 1,300,000 asthma attacks each year in California are aggravated by air pollution. The ozone in smog also makes people more sensitive to allergens, such as dust mites, pet hair, mold, and pollen. The second group at high risk includes babies and small children. Their lungs are still developing and are more sensitive to smog. They also breathe in more air pollution because they breathe faster, bringing in three to four times more air per pound of body weight than adults. And smog reduces a child's breathing capacity even more than it does in adults. Because children have smaller airways, more particles stick to airway walls. Particular matter may increase the incidence of sudden infant death syndrome. Children living in smoggy areas have more respiratory infections, and studies show that they are more likely to develop poorly functioning lungs later in life. Even when children active in unhealthy air don't show symptoms, they are still likely to suffer loss compared to children who grow up in cleaner air. Research is showing that children who live in areas with high particulate matter levels are at risk for poor lung development, making them more susceptible to lung disease as adults. Research also shows that active children living in the most ozone-polluted communities develop more cases of asthma than children in other areas. When ozone levels peak, kids miss more school days. A third group is at increased air pollution risk, healthy adults of all ages who exercise or work hard outdoors. During exercise, we breathe in as much as 10 times our resting volume of air, exposing us to 10 times more air pollution. We breathe through the mouth instead of the nose, bypassing filters in the nose that otherwise would filter out half of the particles inhaled. We're learning more every year about the harmful health effects of air pollution, so it's important that we continue to reduce smog levels. To do this, we need answers to questions, such as how much smog is too much smog. Air quality standards have been established for the main ingredients in smog, ozone, NOx, and particulate matter. These standards are the concentration levels in the air environment that have been determined as reasonably safe for most people. Air quality standards give a number that planners and government can target to reduce air pollution to healthy levels. Hundreds of air pollution monitoring stations are spread across California, continuously monitoring the air, recording air pollution levels. Air quality agencies use the data to see if air quality standards are being achieved. How can people find out about air pollution levels where they live? Well, there's a simple way. The Air Quality Index, or AQI, gives people a gauge of air pollution severity where they live and work. The AQI takes into account levels of ozone and sometimes other air pollutants. Readings of 0 to 50 indicate good air quality. 50 to 100 is moderate. When levels reach 100 to 150, it's considered unhealthy for sensitive groups. 150 to 200 is unhealthy for all groups. And 200 to 300 is very unhealthy. When air quality worsens to unhealthy levels, what can we do to protect our health? First of all, try to stay indoors. Reduce any outdoor activity that requires heavy exertion, such as running or heavy labor. Walk instead of run. Because small levels are usually lower in the early morning and evening, you should schedule outdoor exercise during these times. Children should avoid strenuous outdoor play. For some air pollutants, any amount is too much. We call these pollutants air toxics because any measurable level can impact your health. California has nearly 200 chemical substances on the list of air toxics. To be on the list, the substance must be one, an irritant. Two, a carcinogen, a substance that increases the likelihood of getting cancer. Or three, a reproductive toxin. Air toxics can be localized around fixed industrial sites, and people who live near such sites can be more at risk. Other air toxics are not localized to a specific area. Benzene, which comes from gasoline and diesel exhaust, affect people over a wide region because they're emitted from cars, trucks and buses. Scientists have found increased risk of lung cancer among people exposed to diesel exhaust particles. Exposure to air toxics causes over 300 cases of cancer each year in California. It's the subject of intensive research. The health effects of air pollution produce serious economic consequences. Air pollution means increased health care costs, increased doctor visits, increased hospital admissions, babies born prematurely or with low birth weight, babies born with developmental defects, children who can't go to school or have trouble doing well even when they're there. It means workers who don't go to work, families who pack up and look for jobs somewhere else, suffering and premature death to the most sensitive. An Air District study in Southern California discovered that smog causes nearly 18 million person days a year of headaches, sore throats, coughing, chest pain and burning eyes. The human ill health effects of smog cost us over $9.4 billion every year, and that's just in Southern California. These are the real costs that everyone pays for. Smog not only harms our health, but it hurts the economy, today and for future generations. But the good news is that fighting air pollution pays off. The US EPA figured the cost and benefits of fighting air pollution nationwide between 1970 and 1990. Cost of fight? About $523 billion. But the benefit in terms of sickness and premature death prevented was about $22 trillion. The net benefit to the country was about $21 trillion. We've made a lot of progress cleaning up the air over the past 50 years, but we still have further to go. Industry and transportation will continue to run cleaner. But there is also a role for each of us as individuals. How you get to work, to school or to the store makes an air quality difference. Choose a carpool, take the bus or light rail, walk or ride a bike if you can. Your clean air choices are critical in the fight against air pollution. With every breath you take, you can be part of the fight for clean air. Thanks for watching.