 Why hello everybody welcome to another cloud native live episode from cloud native TV My name is Mario Loria. I'm a CNCF ambassador. I've been an ambassador for a few years You might have noticed me in the community are tweeting weird memes around Kubernetes and cloud infrastructure. I Really enjoy this space and I'm so happy today to have Lee Briggs from Pulumi He's gonna be talking about some exciting things. I don't want to give too much away but really quickly Pulumi is an application for building deploying and managing infrastructure. I've been following them since day one They've kind of become this alternative to what it looks like of creating or to create infrastructure from scratch and giving you more options In terms of building that infrastructure, of course and managing it right very similar to terraform in some ways But very different and some really really nice ways as well Check them out at Pulumi.com And I think one of the goals for me this session is to help you understand the concepts and the methodologies That lead Lee is talking about. So please ask as many questions as you can in whichever platform You're currently using right now and I will help to facilitate and make sure that Myself and Lee get to those questions to make sure you're getting the best information And getting the the correct answers to understand and one up your skills So I'm really excited Lee has experience at AppTO and Yelp He's a dev advocate at the Pulumi corporation right now And I'm pretty sure I've heard of him in a few other circles as well I think he's he's a bigger deal than he's gonna let on for sure, but so We'll see we'll see I'm talking them up a little bit, but I'll let him prove it to you So Lee take it away. Thank you so much and everybody please ask many questions. Go ahead Thank you very much Mario, I really appreciate the kind words I would not necessarily describe myself as a as a big deal But you know, I have been active in the cloud native community for a long time now and I think a lot of people know me for a Expletive written blog post a little while ago about templating YAML which you can see on my blog Leebriggs.co.uk. So I'm actually here to talk about something similar to that One of the things that I have really kind of leaned into in the last few years especially as cloud native technologies have taken off is the idea that user interfaces are super important and While a lot of these cloud native technologies are extremely empowering They are often in my experience not always the most user-friendly because they are building blocks because you are Supposed to layer your you know your beautiful Experience on top of them. So the title of what I'm going to talk about today is Humanizing your cloud native platform I'm going to whiz through some slides and then I'm going to do a demonstration And then we should hopefully have some time for some questions at the end Depending on how much I ramble away, but before I do that Let me first just introduce myself. I work at Pulumi. I've had several roles at Pulumi I like to change jobs every six months and I like working at Pulumi So I just changed my title now and I occasionally blog about random things I post on Twitter and it's usually related to technology and I have a github which is full of terrible code. I'm originally from the UK As you can probably tell by the accent and so It's really pained me to have American eye spelling in a lot of these slides So for example, humanizing with the Z is not my my preferred way of spelling it But just because I live in the United States now I have kind of leaned into it So what I'm going to be doing is talking a little bit about platforms Platform is such an overloaded term, especially in the cloud-native community. It's thrown around all over the place So before I actually talk about platforms I'm going to give my definition of a platform in this particular context So what I'm talking about here is the automated Opinionated batteries included mechanism that allows you to deliver infrastructure and applications So if you think about cloud-native technologies, you think about things like Prometheus You think about open tracing. You think about Kubernetes and all of the things that kind of wrap up in that cloud-native software to me all of those things are You know building blocks to build a platform and certainly I before I worked at Pulumi built an unnatural platform with us some wonderful colleagues for my old employer that Incorporated all of these different things Into a mechanism for our software engineers to deliver applications really like really seamlessly and I learned a lot during the experience of building a platform and a lot of the things that I learned actually looked like You know a lot of those things that I learned actually started to become apparent as I joined Pulumi Before I actually talk a little bit about The humanizing part of this I want to talk a little bit about like the platform adoption This is from the 2020 state of DevOps report And I saw this last year and thought okay I thought we were all crazy for building these complex platforms But it looks like a lot of people certainly in the cloud-native community are having similar ideas Which is we're going to build this mechanism To deliver software and infrastructure in a way that allows our users to not really have to think about it And I think this is really kind of like the uptake in these different platform building mechanisms are really Really starting to show through Especially when you start to think about how Kubernetes and another related software really makes this easier for you within your organization Why might you do this again? We talked about streamlining application and infrastructure delivery But for me, it's about empowering developers your software developers If you're on the cloud-native side of things and you're more of an infrastructure person like myself Your job is to help your developers deliver software and deliver features to your users as fast as possible So that you can increase the business value that they experience by using your application And we like to at Pulumi talk about this being a competitive advantage, right? Like you if you can get your features in the hand of your users as fast as possible Your users will love your application because let's face it. We all love shiny new things And we all love to kind of experience new features And being able to abstract a lot of that complexity away is Really the bread and butter of what a platform can do for you and is why you might experience might might think about building one So let's talk a little bit about what automation means in the context of a platform So I'm gonna have a multiple XKCD comics in here because I really think that they capture What it really means to actually work in technology But ultimately like really the the point of automation is to make sure that you get more free time back often in In certainly in the cloud native experience I have found that this it looks a little bit like the second of these boxes in which you start to build a cloud native platform You input you incorporate Kubernetes and Prometheus and all these different things into your environment And then what actually ends up happening is you spend most of your time managing that platform and managing that automation to make Sure, it works correctly and what I personally experienced and this may not be the experience of everybody watching today But I personally experienced was that that ongoing development meant that I really didn't think about what the experience of people consuming that platform Had I didn't think about how They enjoyed using that platform Sure, it was easier than it was before when they had to do a bunch of manual deployment processes or a manual bunch of manual release Processes but the ongoing development and upkeep keep of a platform can really mean that you end up like not focusing on what the user Experiences and ultimately if you're building a platform The user experience should be one of the most important considerations because you're really trying to make your people's lives easier So here are some One of my colleagues Paul asked me is this a quote or a statement? I'm like it's a statement. We're gonna try and make it a quote a good Infrastructure platform should allow you to continuously deliver your applications and continuous delivery and platforms are inextricably linked If you think about continuous delivery if you've heard that phrase a platform is really helping you to like build a Pipeline for to continuously deliver your deliver your applications And as I already mentioned being able to continuously deliver your applications means that your users get features and your The people that you actually are trying to sell your business to will be ultimately be happier And this is just a slide from a talk that I watched by charity majors I'm sure everybody watching today is at least heard of charity majors Which I think is is really really important to kind of consider that shipping is the heartbeat of your company And actually delivering application features to your users really should be the thing that happens most often Platform will help you do that via automation if you think about what a really good platform would look like You start the process and at the end of the process your users have something in their hands that they can use So that's a little bit about automate automation, but I'm gonna now go on to the discussion about Automation accessibility What does automation look like in the hands of your users and how usable is it? And I already talked a little bit about the idea that I built a platform and I look back on that platform And I'm not always super convinced that it was accessible to use and easy to use for those people Continuous delivery as we also mentioned is not only inextricably linked to a platform But continuous delivery is often paired with continuous integration and you often see those two acronyms used together CI and CD and if you think about how a lot of Automation platforms or delivery platforms look they often start with a git push and You know it's certainly in the cloud native in the cloud native community GitOps is becoming a really kind of big deal this idea that your git repositories and your source code repositories are the source of truth for your deployments and your pipeline and My personal perspective on this is that because git is not always the most user-friendly tool to actually use And again, you this this xkcd comic really kind of makes me You know look at this and think git is not always the most user-friendly of these tools But if git and your CI pipeline the question that I asked myself is is git and your CI pipeline the most user-friendly interface into infrastructure like is this the way that you could make your deployment and delivery processes user-friendly is this a human way of actually getting applications into your You know into your user's hands and it is a user-friendly way for people consuming any platform that you build and Actually using it and delivering that delivering value. Well Here's a couple of pros and cons. I know I could probably Talk at great length about this and I do have a blog post Which is very clickbaity title that I hope to publish by the end of this week but some considerations that you might think about in terms of using Git or using your version control as the interface into your actual delivery pipeline It allows you to see every atomic commit and the history of your actual changes If you do it if you do it correctly You can make these things rip reproducible and we see things in the cloud native community around building images and building containers Which will really help you, you know What would really help you make those deployments? Reproducible my personal perspective is that the feedback loop for Git ops and get delivery pipelines Is really not an optimal way to actually deliver software like you don't always Get the opportunity to push something and then it just shows up Into your actual into your actual infrastructure You're often looking at you see ICD pipeline You're often looking at you know refreshing a page looking at you know Git lab pipelines and and GitHub actions pipelines and I personally have experienced this and found it to just really not be an Excellent feedback loop. However, those tools are familiar and so we gravitate towards them because it makes our lives easier So Now we'll get to the actual point of what I'm trying to say Maybe there's a different approach to all of these things and of course I'm a Pulumi employee So I am going to talk a little bit about how Pulumi can help here with a demo and an example towards the end But I'm trying to think what I'm really trying to do is start to make you think about When you're building delivery pipelines, especially for myself as an infrastructure engineer The most important part about humanizing these things is to think about what your users want to do and every single Organization is different like I we all love these opinionated platforms But you have to actually fit them within the context of your your company's compliance needs with the context of your company's application and how it's been built and Humanizing these things the most important thing and it's a term that we throw around all the time when we talk about DevOps The most important thing to think about is empathy What do my users want and it's a really hard difficult thing in technology because we all have strong opinions And we all have different approaches that we want to kind of incorporate But if you think about what the people using your platform really want then you can start to humanize things So I like to think about Building delivery mechanism using APIs because APRs are interfaces that most software developers Which is what we are at heart can actually understand and use they allow you to create flexible mechanisms to actually consume your platform They create a communication format that says is essentially universal. It goes across languages it goes across programming languages and The final thing is it creates a documentation mechanism that you know can really help People who come along after you to understand why you did something So everything you know one of the reasons that I think that Kubernetes has really exploded in popularity is not only because it's a container orchestration Mechanism but because it has a an API that's well documented. That's easy to consume and is published You know basically everywhere you might want to use Kubernetes So, you know, you can go and read the API documentation You can go and actually have a look at what the API is doing and get an idea of what's actually happening inside a Kubernetes cluster so The final part of this that I want to talk about Before I stop boring everybody with slides is I want to talk about how you might build on those API's to make the API's consumable for your users and I'm also gonna, you know shamelessly talk about how Pulumi can help you with these things Building on API's is is really helpful in the sense that it actually will make you start to think about What mechanism the users of your platform will want to consume those API's so of course they can use the raw API They can go directly to the Kubernetes You know the Kubernetes API and they can even if they really want they can define the YAML Infrastructure or the YAML definition of that API, which is what a lot of users seem to do But is that the end be all and end all in terms of humanizing your API because a lot of times especially when you're using Configuration file formats like YAML you end up with a lot of repetition And you end up with you know hundreds of lines of code when often that repetition is not needed So what I believe is that the right way to build on those API's and the right way to humanize your platform It's to think about what your users want and then Abstract that API away into an easy-to-use mechanism And there's a few ways that you can do that and I'm gonna show you examples of how you might do that within Within the context of Pulumi So the first way that I think is really undervalued and really not looked at as much as it should be in the cloud-native community is that SDKs are your Software engineers bread and butter they use them in their application Pipelines they use them when they're building their application Libraries npm modules new get packages go modules python pit repositories these are the things that your Users of your platform that I eat the software developers delivering value These are the things that your users are using every single day And if you can define software FDK SDKs for your platform and your infrastructure delivery We have seen at Pulumi that the amount of the amount of Velocity your users get when they are able to consume those SDKs can often far outweigh The idea that you would say hey We have this Kubernetes platform go and learn this YAML format and start to understand how it works And then you'll be able to have a really great experience Building software SDKs and building things in languages that people understand is one of the first steps in my experience of Humanizing that platform and making it user-friendly for the people who want to consume it The second thing to think about is that the people who might want to consume your platform The people who might want to deliver software and not always software engineers or technical users I've certainly worked in environments where less technical users do need it to be able to actually deliver features and software and Web portals if you think about some of the major cloud providers, they all provide web portals web portals can be a super Super-valuable part of deploying software and infrastructure and delivering value And if you think about some other cloud native technologies like Argo Argo and Argo workflows they provide these web interfaces that allow you to actually operate on your on your Kubernetes infrastructure to really help users actually deliver value and then the final thing is is that you know I'm personally a command line user command line interfaces can really help power users feel effective and command line interfaces don't always need to be the be all and end all But a command line interface can help those users that are consuming your platform Especially in an automation context if you can abstract some of the some of the things away But leave them with command line flags for example that can help them Understand how they can manipulate things and change things command line interfaces is another way of humanizing your platforms Pulumi Pulumi I'm going to show you a little bit more about Pulumi in a second But Pulumi is an infrastructure code platform that allows you to choose one of our supported languages to actually define Infrastructure and application delivery pipelines. We support the no JS ecosystem. We support Python We support go we spot net my favorite language to use of these dotnet language is a visual basic because let's be honest it's been around for You know nearly 20 years at this point and anything that's been around 20 years must be a good thing But you can actually choose the languages that you consume your infrastructure in with Pulumi and Deliver value to your users using that language and it also allows you to choose your workflow We already talked about web services and command line interfaces with the Pulumi automation API Which we're going to see a little example of in a few seconds with the Pulumi automation API You can actually start to fit your platform and all of the parts of the platform that you've built You can actually start to fit it into the context of your organization and build your workflow that makes sense for your users So I've talked a lot. I've talked for 20 minutes now and I don't want to keep talking about these slides What I actually want to do is put my money where my mouth is and show you an example of what this might look like This is gonna be a live demo if I make mistakes. I'm just gonna just figure it out as we go along So let's let's take a look at what this might look like Mario I've to be talking for 20 minutes now I don't know if you how I want to jump in with any questions before we start looking at how this might look in practice No, yeah, this is fantastic and Lee talked about a lot of things there I want to highlight a couple the state of DevOps report put out by puppet is a really important thing to keep your eye on I think that There's a lot of good information there in terms of trends and what's going on in terms of these adoption rates and how many teams are realizing value out of the the kind of landscape out there, right? And then the other the other thing I wanted to mention is I have really been Diving into developer experience over the past few years in my own career So everything Lee is talking about and it might be hard to grasp, you know UX and focusing on You know my developers and you know running the platform like what does that have to do? Like I'm an SRE like I just want to make my cloud infrastructure better But I actually what ends up happening and I've been an SRE for a while and I know Lee Obviously has worked in SRE as well like you actually become a support person and more so and I'm not saying this in a bad way I'm saying that you end up finding so much of your work ends up being ad hoc work And it is work that is the need of a developer who says I'm just trying to do this I'm just trying to get my thing deployed. I'm trying to fix some pause I'm trying to figure out my resource requests and what ends up happening is They don't really know and they're gonna go to you You're you're just you're that kind of dependency and you're really a blocker in the chain and in that way They they look to you and so that is where the stopping comes in and the asking comes in and the having to solve these tiny little nuances, right but what what Lee's actually saying here is Why don't we solve the underlying problem that the platform and the semantics for how we ship applications how we manage applications and the flexibility and the shift left of focusing on the developer and what their Workflow is we can actually solve a lot of those problems and we can make it really self-service Which is what we're looking for And we can make it you know make sense and fit into our policies and fit into our security and fit into what our goals are For our platform, right and so that ends up turning around and changing the paradigm Where s3 actually becomes what s3 is meant to be as people that are automating the toil away Maintaining an amazing platform and maybe helping even to extract other elements of the platform in terms of other realms You know security or latency or whatever it might be, right? So I love everything you mentioned Lee everything there is really strong We had a question on what are the prerequisites? I think you can get into that in the demo a little bit as well Yeah, what are the prerequisites that leveraging? Pulumi and I think what we're really starting to see is is the Enablement and like you said empowerment of developers to do more of this on their own with SDKs with APIs and with tools like Pulumi I love crossplane and Backstage from Spotify Ambassador DCP like these kind of control plane and centric elements where developers don't actually really need to know Kubernetes And it's all about getting them to know less so they can do their jobs faster and actually produce more So I'll stop talking now Lee, I'm really excited for this. Holy the demo works I just wanted to just kind of add something as well like and I something that I kind of had You know, I have these I've had these moments in my career These kind of epiphany moments where you start to realize that everything you've been doing the last few years is really not the Right way and I had a conversation with it with a developer in my old The old company that I worked at and I was trying to get them to adopt this infrastructure tool That had a learning curve and I'd spent like six months like learning how to use this infrastructure tool And I was talking to the software developer and I went to them Specifically because I knew that the software developer was super smart super capable Like they were the person who I would go to get a let get a bunch of answers and I was like look we're gonna build this platform and we're gonna make it we're gonna build it around this infrastructure tool and You know, I'd really like you to be an ambassador for the platform and all that kind of stuff and their response the software developers response was like It's really great that you've had six months to learn this tool But I've also got other things to do right like I've got a deliver features to my users I've got to actually get things in the hand of people And I don't really have six months to learn this tool, you know what I mean and I had realized I had spent six months building something and learning something and that was my full-time job But the software developers who actually wanted to use the platform. They were like I don't have time to do any of this it's really cool and it's really exciting but when I'm at like I Don't get to put six months of sprint work to learn this new tool so that I can help people be an ambassador And it really changed my perspective and it really changed the way I think about things And I've been thinking about that for two years and it's really culminated in this particular talk Because when we talk about humanizing things you really have to think about what your end-users have to do in order to Actually consume the platforms you're building with cloud native technology And I really love like backstage is a great example You brought up there Mario of a thing that has come up around these different needs, right? Like the consumers of the people who own and manage backstage They get to actually build something and then the consumers just get a really nice experience And if you think about where all the really great cloud native technologies are the ones that give those interfaces that are kind of flexible and buildable are really really Really taking off and really starting to see their usage explode and again I think this is one of the reasons why Kubernetes is so popular I know it's a polarizing piece of infrastructure like you you know every week There's a new Hacker news article that says we don't use Kubernetes and we love it And I'm like great, but what about all those people, you know, you know What are they one of those people that aren't using Kubernetes gonna do after this? So yeah, I think you know I think hopefully the idea is that I'm talking about again along but let's see it in practice, right? Let's have a look what this might actually look like From a user interface perspective. So you probably saw a link on the screen earlier There's a github repo with some Pulumi code in it That I kind of threw together yesterday evening that uses three features of Pulumi that will allow you to really I think Let your users consume things in a you know in a really nice way and we can either show it now I'll show it at the end But what I'm gonna do is quickly like Go through what I've actually built. So let's just switch the screens here But this is my VS code window and what I've done here is build a very very Lightweight example of building a software SDK for delivering infrastructure to a platform built on Kubernetes, right? So what I'm gonna do is just quickly show you through what this might look like I've written this in our go SDK And it you can probably if you're a Kubernetes user or some of this will look very similar So you have a namespace you have a Kubernetes deployment and then you also have a Kubernetes service and of course You know the idea here is to you know, just suspend your belief for a second About what a production ready application might look like But what we're doing here is is using our the Pulumi go SDK to actually like create consumable SDKs in all of Pulumi's other supported languages and this like this really this this ability to do this is one of the most strong things in terms of humanizing platform Accessibility because if you're working in a software engineering environment You probably have a back-end language and a front-end language. It might be the same You might be using node for both But I've certainly worked in environments where you know users will use go on the back end And they'll use TypeScript on the front end or they might use, you know You might be a window shop and be using dot C sharp and F sharp But being able to actually allow your users to consume your infrastructure in software languages that they feel familiar with and comfortable with but not having to make them choose I think he's a really really strong part of You know creating a humanized platform. So as I said, I've created a an example production ready application That will that is written in go, but it compiles into all of Pulumi's supported languages So you we have dot net we have go we have no JS and Python libraries that can be used From this production ready application And if you think about what this might look like in practice when you as an infrastructure platform owner want to update what a What a production ready application looks like perhaps you have decided that the three replicas in a you know in a Pulumi Sorry in a Kubernetes deployment three replicas is no longer acceptable for production ready and you want it to be five instead You know you can update this you can version it like software and you can ship it to your users And they just consume it like a normal software library that they're already doing in their software development lifecycle And again, this is actually creating software development libraries in through in four different ecosystems So your users no longer have to set choose to learn a new language or a new configuration file format or a complex DSL that they're only going to use for the deployment mechanism And they can actually consume it in their languages that they're already using in their application lifecycle So Lee I have a question really quick. I want to I want to unpack this a little bit So what you're saying is that we can issue a library being the SRE team being the platform team We can issue a library that has some of these Kind of expected defaults are best practices that we want for applications being deployed on our platform And we can write this out We can obviously have it reviewed by our co-members and and other developers as well And we can issue it as a library and then kind of what you're saying is you know what that library is a go library So anyone writing their their microservice in go-lang can actually pull in that library and now get the best of all worlds Right they get everything that we intended in terms of you know, what the platform should look like what? Applications should look like running on the platform, right? And they also get a little bit of basically Automation if you will yeah, the the work has been done for them There's nothing they don't have to go dabble in deployment spec YAML, right? They don't need to write a config map They don't need to handle secrets maybe and maybe we get the secrets later. That's a tricky one But it seems like you know, I guess you're taking some of that extra configuration that we actually end up Replicating in so many repos with values files and in home charts and when you have microservices and there's 40 of them You're really just copying the same same things over and over It sounds like this being issues a library that maybe you tag Is this how most teams that you've worked with are Doing this they basically write these libraries in these languages and adapt them into their services And then they got basically everything they need Yeah, absolutely. That's you basically hit the nail on the head And what I'm going to show you is three different ways of consuming this library, right? So the like we talked about You know different mechanisms of humanizing these libraries the building block of those are humanized eight of that humanization Is building these reusable libraries, right? Like you start here You start here with like an SDK that other the other users can consume and then they get to choose And I think we all love choice like Choices one of I think choice is one of the foundations of the cloud native foundation But allowing users to be able to choose how they consume these things is really powerful And I've actually got examples that I'm going to show you of consuming this particular library that I've created In three of our different supported languages So let's look let's look let's look at the first one, right and I'm going to start with A traditional infrastructure as code workflow, right? So this is our this is the typescript library And you can see here it builds an npm package called palumi production app And you can see that the actual like the actual implementation of all of this go code is Four lines of typescript, right? I'm going to specify an image I'm going to say what image that what port that image runs on and then it's going to basically return me a url from my minicube cluster Which you know, if you think about the user experience of what that looks like You know for a typescript developer or front-end engineer This is just a very standard workflow for them like import a package write a couple lines of code And I'm going to get an expected end end point And so I'm going to deploy the kuad example app to a minicube cluster And let's take a what that looks like and again I think this is for most people doing infrastructure as code Or most people in the cloud native community This is a workflow that they'll feel familiar with like you define something and then you run an external command line tool to actually deploy It might be kubectl. It might be you know, any of the other infrastructure as code You know things that you might be familiar with but this is one example of a workflow It's a little bit more human because instead of having to you know, define 200 lines of yaml or figure out how the helm templating system works Instead you're just using native code. So it's still a little bit more human, but it's not a huge A huge amount different to what your current workflow is. So Let's look in my example repo. So in samples node j s and just make sure that I have an index file here That type of course and you can see I have a little tiny kubernetes cluster Locally just a micro kubernetes cluster And so I want to get my production ready application onto this cluster. So what I would do let me just bump this up a little bit There we go What I would do is run pollumi up So think about this in terms of kubectl apply or something along those lines And you can see it's going to deploy my namespace. It's going to deploy my service and it's going to create my deployment So hit yes again very very familiar kind of workflow We talked earlier about feedback loops I think this feedback loop is really really good because if you think about how kubectl works Like you just send off a api request and then you have to do a bunch of debugging commands to actually let you know If any of that actually worked or not But you can see it's created my namespace my service and my deployment Um, and it's just returned me the url of what my service is running on. Um, and I can actually verify That that is created. You can see I have an example namespace And in that example namespace you can see I have my three replicas, right? So Um, this my production ready application has been defined and is running and it allows me to as an upstream platform owner It allows me to define those different. Um, you know those different things Um, and again like if we imagine what this might look like From a downstream consumer perspective Let's use the example that I uh mentioned earlier All of a sudden our infrastructure team have decided that we want to have five replicas as a production ready application So i'm going to go ahead and update this to five replicas And i'm going to rebuild my library. So we'll just wait for a second and you know Let you imagine some elevator music right now while we you know while we wait for our uh library to build Um, I could talk a little bit about what this is doing, but it's essentially generating the stk's For go for dot net for python. Um, and you can see it's actually creating a bunch of python packages It's creating my yarn packages my npm packages Okay, lee. So this this is like the example of basically us as Developers of this library issuing a new version like a new tag that other developers can then say oh, there's a new tag I want to pull that in to my service And adopt that and those changes are inherently just are automatic Yeah, exactly deploy you can actually see the version here So obviously if you like, you know use proper semantic version in in node packages or python or all that kind of stuff you might update the Version to you know 1.0 or 0.0 0.2 or something like that You know, we're essentially just updating. Um, we would release this as a new version Again, your downstream users would decide when they want to pull this in so again, it's their choice You know, there's nothing worse than somebody breaking You know breaking things in production or a lot kind of stuff. Um, so again, it's just going to generate these things I think I ran it twice because uh, you know, um, but oh well, um So it's generating all of the different packages that we're actually going to consume. Um, and then Again, your downstream users are going to be able to rerun their application And because I've automatically yarn linked into into here the actual Package what what would actually happen is your users would take the dependency and do an npm install in this typescript example But if I rerun my plumey up now We should see that we're getting a difference in our actual infrastructure deployment So if I look at the details my replicas have now gone from three to five Um, and you again, your users are able to actually experience this in a more kind of relatable workflow to them, um, you know And even though we're using imperative languages even though we're actually using Um, you know, no j s you'll notice that this is a declarative process if I rerun my plumey up It should say there are no changes. Um, because we've already actually defined our infrastructure So again declarative like kubernetes already is but using an imperative typescript language that allows us to actually You know feel like we're actually using things that we already feel familiar with so I think this is I think this is a super powerful workflow um, but We didn't just talk about using, uh, you know typescript and all those kind of things we talked about going an extra step um, we talked about actually making um You know making this relatable not just for our software engineers, but for other users within our organization as well so The next thing that I want to show you is again another example of consuming Excuse me another example of consuming this particular Uh software library that we've created um, and what I've done inside this repository is I have created a power user command line interface using plumey's automation api So, um, if you are a go developer, this will look pretty familiar to you I'm using uh the kingpin cli library and you can see I'm importing Um our go stk. So again, this is the same Um, this is the same library that I'm con that I was consuming in my typescript earlier But now it's using the go stk. Um, but I'm and I'm creating a command line tool That I could distribute to my users within my audit within my organization and they can consume my platform Using a command line tool that is again abstracted most of the complexity away But still allows them to choose the image. They want to deploy on the part that they want to choose. So A lot of this is kind of uh, and you'll see when I run the tool a lot of this is actually just um Uh mechanism to make this look pretty fancy. Uh, but most of the actual The stuff is actually here. Uh, you can see Really quick. I'm interested. So is this basically us abstracting away plumey itself a little bit? Or like we're actually optimizing for the ux of how we want our developers to be able to work with Uh, our our abstractions. Yes, exactly So we're not going to have to run plumey up on this program because that is going to happen inside our go binary, right? So, um, this is using plumey's automation api. Um, and again, if you if you if I open up the Um examples that I had earlier, uh, the no gs example You can see we were creating in a production app because that's our import deployment And in our in our command line interface example It looks it's basically the same we're specifying an image of specifying a part like the actual consumption of this itself Is very very familiar Um, and it looks very familiar over different languages when I started at plumey. I'd never written a single line of typescript Um, I am now, uh, you know, not a good typescript developer, but I certainly am way better than I was a year ago um, but the the This is kind of leveled up my skills like this cross compilation capability and cross compilation is not the right terminology by the way But this cross sdk Um functionality has helped me to understand different languages. Uh, and helped me to understand. Yeah, this is fantastic Yeah, awesome. Okay continue. This is this is sweet. I want to see the cli in action So let's so um, let's um, let's have a look at this. So let's look at the cli And I'm actually going to rebuild it. So I'm going to do go build minus o production app If you are a go developer, this will look pretty familiar. Uh, and I've just noticed that uh, my um I think my, uh The the tag is actually going to cover up what I'm going to run. So let me very quickly Do this Like that There we go, um Yes, that moving it to the right side would be super helpful. Thank you very much mario um So, uh, I built my go binary Like so And you can see it's called prod app like this and I can actually Look up the help and you'll see that I need to specify a name and I have a deploy command and a destroy command Um, so let's have a look what our deploy command actually does So what my required flags are I need to specify a name for the deployment I need to specify an image And I need to specify a port that that image runs on and you can also see because I'm using the command line interface and go I can actually You know set defaults, um You know, I can actually specify that port 80 is the default for these different things So let's run My prod app and I'm going to specify a name of example cli And then my image i'm just going to run the nginx image for this particular example like so And again, if you think about if you're a cli power user, um, you know what image you want to run, um, you know what, um You know, you know what you want to call the thing that you're going to deploy. So let's run this um Unknown long flag image excellent. Well, you know, um, oh, I haven't actually specified a command that will help won't it Um, so I actually need to run the deploy command Um, that would probably help. So I'm going to run deploy Um, and the name and the image like so and I've built this this and I'm saying I'm but my actual wonderfully talented colleague Kamal Ali I actually built this this a beautiful UI And it's going to deploy my kubernetes deployment my kubernetes service and my production My actual deployment and the polumi stack And it's going to actually do all of the polumi stuff that we did in our polumi up And I haven't invoked polumi at all Um, I haven't used the polumi cli in any way at all Um, and I can verify again that this is actually deployed by getting my namespaces and you can see I have this production app namespace that it's actually going to create Ctl get p.o minus n production And here's my five replicas. So I updated my library earlier. I rebuilt my, um, you know, I rebuilt my command line tool with the new dependencies that I have and I've been able to deploy my infrastructure In a way that my my organizations command line users feel comfortable with and feel familiar with And if you wanted you can stick this directly in your ci pipeline, right? Like you can abstract all of this away and you see i pipeline, um Without actually having to worry About all of the different steps and all that kind of stuff your entire infrastructure portal has been bundled into a Command line interface that you can just throw into a ci pipeline This is literally amazing. So I actually have a use case for this in my organization. We're building a singular tool Uh, that tool we're building to solve for local, uh local development and eventually remote development ephemeral environments, right? And plumi here can provide So much right like we can build plumi into that tool We don't have to have people learn plumi as well and plumi up, right? It just everything's kind of built in an integrated, right? So I think like this is one of those things where if you're getting to the size and you're saying, okay We need to abstract away this complexity provide a single kind of streamlined path to do these things Right and and something that encapsulates all of the the things we care about whether it's like security, whether it's um Linting whether it's like certain configurations for our monolith that gets deployed, right? And that's all into one tool that you you maintain and manage And then you just slipstream, you know, plumi Configuration and you're kind of de facto library for what deployments and managing those apps looks like like this is incredibly powerful I think, you know, if you're a startup, you're probably not necessarily using this depending on on what you're doing. Maybe Go ahead. Sorry. Yeah. No, I 100% agree like we're not we're not necessarily talking about hey You know, I'm just trying to get off the ground. Um, you know I'm just trying to get my my application from a to b. This is a lot of You know, there's a lot of work in those situations But in those larger organizations where, you know, you've already built a working platform And what you're now thinking about is how this looks for your users. This is such a powerful way to do things Um, you know, um, and then there's one final thing that I want to show you and I'm just conscious Well, we talked about I mean command line interfaces and software sdk's or one mechanism for actually Delivering infrastructure. Um, but we also talked about those users who are very used to web applications and consoles um, so again building off the Of the work that a very very talented colleague of mine called Kamala leaded and I'm just going to extend this so I can switch screens Um, I've also embedded this into a python flask web application. So if we take a look in our In our source code here Again, we're going to consume our production application inside a web application Um, and I'm going to import my deployment and deployment arcs. And again, remember I've only written this code in one language, right? Like I haven't written I haven't had to maintain four different languages here. I've written it in one languages and it's generated sdk So I mean four different languages I can now create a very simple flask web application That does a plume deployment within the web application itself And there's considerations here for example like timeouts like web timeouts and all that kind of stuff like Infrastructure provisioning can take a little a little while sometimes. So like um building this into web applications has different considerations that you might want to think about retries and all that kind of stuff But um and actually retries is not a great example But you may want to do things like dispatch to a worker for example Like a kubernetes pod is one thing that I've seen a pattern of where a web application will dispatch a kubernetes pod Which runs polumi. Um, but again like the polumi Um, like the actual polumi is three lines of python, right? Um, it's just a web application Um, that is going to again deploy to our kubernetes cluster So I'm going to start this little python web server and you can see you got a sneak peek there That I already started earlier to make sure it works. Um, so it's starting a python web application And let me just refresh this to make sure it works So we have no active deployments, right? Um So I can specify a name Let's call it web app example And again, I'm going to deploy the docker Docker image of nginx latest if I click create and move back to my CLI you can see again, it's it's actually running polumi in the background like this python sdk Is actually provisioning things and again, we've got our five pods available here It's actually provisioning things into our kubernetes cluster Via the web application and you can actually see that and if you if you're a way more talented front-end engineer than I You could actually, you know, put perhaps stream this in your web application So that your non-technical users can get an example of what this looks like and if I go back to my web platform thing, I now have my web app example has been deployed And you know, I can if I had the networking set up for minicube correctly I could actually open this page and go directly to my nginx You know my nginx example So that these these are different ways that you can actually build these reusable libraries But then you can actually the due to the flexibility that we provide in the polumi cloud engineering platform This allows you to choose and decide What ways your users will be able to um, you know, what way your users be able to consume it And I'll also just have to caveat. I think I mentioned this before I don't particularly consider myself a talented software engineer. Um, I From an infrastructure background, right? I I learned htl. I wrote bash scripts. I wrote, um, you know, I wrote You know YAML configuration files for years and years and years and I threw this together last night in a couple of hours Um, so if you're an actual talented software engineer and you're actually capable of doing these things Imagine the kind of things that you could build that your users will be able to actually consume and use Um, you know, it's it's the the due to the flexibility the possibilities really are endless I'm glad you said that because I am a terrible programmer. I am Acknowledging that here in public I don't even know what i'm doing most of the time. Um, and this looks simple enough to me, right? I you know, I'm good at reviewing code and looking for things that don't make sense Because I try to like take and understand the logic and piece it out, right? So I love how simple this has gotten and this is this is amazing This is again is the we want to provide a platform to our users and we we can do it either via You know the web we can do it via a cli or a simple library, right? And everyone works on a different kind of plane and and wants the the flexibility so I love the flexibility I are these new is this new to plumey or is it just gotten easier? um, I think both uh the um the automation api has been around now for a year and honestly Like if I could tell you some of the incredible things that people have built with the automation api It just it blows me away all the time like what people like, you know One of the reasons I like to show this this web platform type example is because we have users that are building not just internal web platforms, but actual provisioning tools for external users that heavily leverage plumey's automation api To provision infrastructure. Um, you know, it's it's such a powerful mechanism. It's been around about a year now Um, you know and again, I've got to give shout outs to my colleague Kamal who has really put in lots of effort and another colleague of mine evan Who has really just kind of completely kind of seen what the potential and possibility of the automation api is and really created this incredible Flexible tool the multi language part that I've showed you where you can write a component that you can reuse in one language And it generates sdk's in all four available languages. That's a new feature that we announced earlier this year um And if you think about like the maintenance burden that people had that were creating these reusable components before this If they wanted to support all plumey users, they had to maintain languages and you know maintain libraries in four different languages And the maintenance burden was just crazy. Um, you know, we What we are planning on doing we're working on right now as we're actually working on creating I don't have an end date for this But it is on the it's in in progress right now It's we're building a registry that will allow you to share these components and build them and actually distribute them To all the users as well. So right now you can see this is all in a git repository Um that I um, you know that I kind of maintain and you can take a look at this Like I would encourage you to go and have a look. I'm just going to bring up the page if you um, I'm just going to bring it up here My fingers have just completely stopped typing But I'm going to just type it in here So this is the the repository is available if you want to take a look at it You can um, you know and you can see I was working on this an hour ago Um, and it should give you examples about to build and look at this thing But if you want to see what this looks like, um, it's all in here So please don't hesitate and you can also reach out to me on twitter at briggs l And i'm quite happy to kind of walk you through some of these examples as well But we are going to as I mentioned be creating a registry that will allow you to build these components Which we're looking at in here inside our Inside out this provider package. So this production app these components will be reusable and reshareable And so if you think if you're a helm chart maintainer if you're a Module maintainer, um, you know the possibility for you to be able to Write these kind of things and reach, you know, think about how large the javascript community is You're basically reaching every javascript engineer there is Um, and you can do that relatively easily with these kind of multi-language components This is uh, this is amazing. This is the next iteration of palumi And this is what makes it easier what makes it more composable repeatable shareable portable All of those fundamentals all of those principles that we are trying to build Modern platforms on I think right and I think this is amazing focus on services focus on developers It's so great to see this I really wish now that I would have been looking at plumi at least some point in the past few months And and playing around with it. I definitely will be maybe even this weekend This is this is exciting stuff Lee what you know, you mentioned the roadmap a little bit What is some of the the key things that you're seeing the teams that are using plumi right now What are they looking at and asking for in terms of like More maybe more power In control over what is possible more flexibility in dealing with model lists or enterprise applications I'm bringing those into the the mold of kubernetes land. What is kind of the the hot take there One thing that I think You know, we see quite a bit of we have a we have a kubernetes operator Which will actually kind of get get get involved in the reconcile loop that comes with kubernetes And the kubernetes operator actually uses the automation api inside It was one of the first things we built with the automation api One thing that we're really seeing is like that convergence right like that idea that your infrastructure converges like You know if you if you are using kubernetes You are used to this idea that it has this kind of self healing element to it And so we use our kubernetes We have multiple companies using our kubernetes operator that are really just kind of looking for more More of that convergence right like this if you imagine running plumi in a for a while loop or for a while loop That's one really kind of thing that we're kind of working on and looking at And I think that's again like marrying these two two kind of technologies together I think is is really You know such a really strong pattern That can allow you to not only feel comfortable in the way you deliver infrastructure and applications It also makes you feel like your users just understand a little bit more what is going on in their infrastructure and again you know This this has been an example of using plumi to kind of solve the problems that I talked about earlier But if you don't want to use plumi, I would just implore you When you make this tooling decisions and when you decide how to do things within your organization Think about what the end users want like I have personally been one of those people who has just tried to Shove this technology down people's um, you know down people's throats in in some respect and um, you know It's it's it's a much more invigorating and empowering way of working with your colleagues If you just think about what they want and like we are all here to help each other And that's really what I want to talk like this is why I love this slide this cloud engineering for everyone like All of the big cloud providers and kubernetes themselves have such a huge learning curve There's such powerful pieces of technology and all the other cloud native software There's such powerful pieces of technology But you have to be you have to remember that the You as a cloud native ambassador or you as a cloud native user You have time to kind of take these things in the people who are using them and consuming them don't always And if you think about how people want to consume these things, I think it gets a lot more human That's absolutely it. I remember talking to developers and trying to explain to them Pod anti-affinities and they were like, I don't I don't care. Yeah, like what like It worked for me like yeah, exactly exactly So simplifying getting to the the kind of brass tax if you will of what are we trying to do? I just need to ship this application. It needs to be somewhat redundant and reliable and providing that reliability Is you you know your job in a lot of cases if you're a necessary engineer a dev ops engineer platform Whatever whatever you want to call it plenty of overloaded terms I have so many more questions, but we have kind of come to an end here One thing I'll highlight really quick that happened while we were chatting is that the kubecon and cloud native con north america 2021 Schedule has just released. So please check out twitter Or the cncf.io website for more information on that that event is in person and virtual I will be there. I'm going early Lee any final any final thoughts? No, I just I really appreciate the the great questions that you asked. It's been a great experience If you are watching this on youtube Later on today and you have any other questions and just feel free to dm me at briggs ale Or you can talk directly to us at polumi at polumi call Absolutely love it. Thank you so much everybody for tuning in We really appreciate you coming to cloud native live And I think next week is going to be probably just as exciting as this week. So definitely tune in Subscribe and thank you so much for your time. Have a great rest of your day. Bye everybody. Thanks