2:42 Introduction

2:42 Hello, and welcome back to the Rawkode Academy. I am your host, David Flanagan, also known as Rawkode. Today, we're taking a look at an application called DevStand. We're gonna find out in just a moment what that is, but before we talk about it, we need to introduce its creator and maintainer. Welcome, Max. How's things? Hi, everyone. How are you, David? Yeah. You know what? I'm doing really well. I haven't streamed much in the last week because of speaking at an event in Oslo, and I had my own conference this week. So I'm really excited that I get to be back

3:01 Guest Introduction & DevStand Origin

3:17 in my office, have a stream with you, and, like, a really cool a really cool project. So thank you so much for taking the time to to join me this afternoon. Well, nice. Thank you for having me. Yep. My name is Max. I'm a full stack developer, and I've been a full stack developer for the recent like, around fifteen years. And it was just a couple of years ago when I started working on a project which is now called DevStand. But, originally, the project came when I was working for a client, and the client asked,

3:55 okay. Now your solution have to be deployed in Kubernetes. And nobody knew what was that, how to work on that, and I had lots of time figuring out and wrapping my head around it. And during working with the Kubernetes, I realized that it's quite difficult. I mean, if you need to create a Dockerfile, it's usually like a script a bash script for making a virtual machine, like, in the like, roughly. But Kubernetes brings a whole lot of it's very custom terminology, and you have to understand it first and then trace it back and realize, ah, in

4:42 order to do my thing, I have to do this and that in Kubernetes to make it work. And I had a strong belief that the whole technology is awesome, but it's quite difficult, and there must be a way to make it simpler for mere application developers. Because, you know, those developers who spend lots of their time working on business logic, database schema, interfaces, negotiating features with their clients, etcetera, and they have no time and no wish to dive deep into that modern Kubernetes cloud stack. So DevStand is a thing for mere application developer and which lowers the barrier towards cloud deployments.

5:40 Discussion: The Problem with Kubernetes Complexity

5:40 So this this is basically it. Awesome. Well, thank you for sharing a little bit about yourself and about the project too. It's it's always nice to get that extra context and history when we do these sessions. And I love what you're saying. You're 100% correct. Like, the lexicon that we need to understand what's happening in a Kubernetes cluster is not something that we have by default. It doesn't map to to the real world or even things in the past. You know, it could be that maybe we called it an application and people would understand Kubernetes a bit easier, but

6:10 we don't. We see pods, replicas, deployments, config maps. Like, these are not terms that people are familiar with by default. So I really love it. And I I I think it's a really powerful thing when we could take some of these things with Kubernetes and make them easier to understand through visualizations and other tools. So, yeah, I'm really excited for for today's demo. Okay. So now I'm going to share my screen and start my Let's do it. My presentation. Uh-huh. Your screen is now live with our audience. I can see your slides. Please feel free to take that away in your own

6:49 time. Well, that's great. So after several demos to fellow developers, I realized that some of them think of DevStand as a low code tool for cloud infrastructure. I personally believe that it's more about platform as a service atop any Kubernetes cluster, but you can see that both of these names can be applied to the solution. I wanna start with the most well known solution for branding developers' code and shifting it to the cloud, platform as a service. And every platform as a service has two basic promises. The first one is that it has to be easy for developers,

7:18 Comparing DevStand to PaaS & Kubernetes

7:40 and it's worth noting that popular platforms as a service is they usually deeply rooted, and they originate from developer community, not infrastructure communities. And they have to speak to developers in their lexicon, and they they didn't even sell support for a specific programming language. They usually sell support for a specific framework, and they gradually build trust between them and developers. So developers know they can rely on expertise of the platform as a service to to jump and to deploy their application. The second core promise is that infrastructure is managed by the provider. But in terms of platform as a services,

8:30 this infrastructure is not about networks, gigabits, gigahertz. It's about managed services, like a database or domain specific API or some kind of CICD automation. And you might think, what is the industry response to that PaaS weeds part? Many people think that Kubernetes is because bundle everything in a container image, throw it into Kubernetes, and Kubernetes is smart enough to realize how to how to run it. But well, actually, Kubernetes fails to fulfill both of these core promises, what I believe. The first of all, it's not easy for developers because, as I've just told, it forces you to

9:22 utilize Kubernetes' own terminology. And it's weird, and it it doesn't speak familiar obstructions for developers. And one of the most beautiful features of Kubernetes, that declarative configuration, often ends up as a wall of YAML, which is huge, and it's blindly copy pasted from one repository to another. And this wall of YAML that they still do not speak in the language developers can understand. In to continue comparison with the past, there are no managed services in vanilla Kubernetes. Even so called managed Kubernetes offered by a variety of cloud providers are just bare bones. And you have to hire professional DevOps people

10:17 to get anything specific and usable from your cluster. But be besides the hiring need, which would better to avoid, every custom Kubernetes cluster is unique. There is no golden standard, like a packaged Kubernetes packed with add ons, and it means that there is no straightforward path from code to Kubernetes because every Kubernetes is a little bit different. And this is what DevStand is trying to achieve. I have three next slides in in steps explaining how to come from that wall of YAML to DevStand. So imagine a usual or decent application. Like, you have a web

10:54 How DevStand Works: Abstracting Configuration

11:10 application, maybe a background worker, a database, maybe file storage, or Redis cache, and all of that information of how that should be deployed in Kubernetes buried somewhere between the lines of these huge YAML files. But what if we can spot reusable templates, reusable portions within this huge YAML files, rub them in templates or functions, and call these functions in a way developers can understand. And each of these function has to have a set of parameters to actually produce this huge list of Kubernetes manifest. For example, in this code, we have web application, which accepts an image and port,

11:48 Using Functions & Managing Dependencies

12:07 an optional domain. And for image and port, by default, it creates deployment and service. And if a domain is provided, it also creates an ingress. What I want to pinpoint here is that just that one line of that code is actually what developers care, is that PaaS lexicon or that PaaS experience. Developers just want to know, okay. That cluster is capable of running web apps on a specific domain. Or think about a database. A developer who is not responsible for managing databases just wants a host name, a username, password, and the name of the database to use

12:57 it, and that's basically it. But if you think of a decent configuration in Kubernetes for a Postgres or a MySQL, it consists of lots of line of code, and they make no sense for a mere developer. So okay. First, the the output of that slide is we have these named functions. Then it can allow us to create a single file and with a compact syntax where you can list all of your microservices, your app, your background worker database, and reference these function calls within within that file. So for example, in that example, you have web application,

13:22 Building Blocks & Managed Services

13:50 background worker for email delivery, and Postgres database. For example, a worker, it's it's obvious that it has to work from the very same image, so it's referenced the very same image from my app component, and it shares all the environment configuration. What's also interesting is that in any programming language to reference values, we use variables, And that code is written in JSON. It's like JSON interpreter, JSON with macros. And we can observe dependencies between these components just by looking at which variables are referenced. And you can wrap anything within building block within the template. Think of it

14:51 as a managed service of a cloud provider. For example, when you run integration tests, you are fine to have a stateless Postgres container or in internal Kubernetes cluster, your custom corporate cluster, you have a a decent claim into a database operator. Or in public cloud, that Postgres can be a claim for Azure database or AWS managed database. So it's quite easy to swap things underneath. But for a developer, we have the very same interface. It's just a database. It within the template, it can be a microservice developed by other team, or it can be an off the shelf solution, like,

15:43 for example, a little WordPress install. You can give your content managers. They they use it to to write text, write code writing, and you just consume that as an API for your content. So there are plenty of ways to encapsulate your very specific things within these templates. But in the end of the day, you have a very short file, which is, by the way, backwards compatible with all that all of YAML, and all the syntax within the that file makes total sense for developers. Why do I talk a lot about these functions and interfaces? The idea is that strictly typed code could

16:24 The Visual Editor: DevStand's Core Feature

16:31 be visualized, and this is actually the primary and the core feature of DevStand. It's an editor built into Visual Studio Code to be as close to developers as possible, and it allows visually compose your solution architecture of these little building blocks and interconnect them to each other. And I have a demo for it. On our canvas, we have add component button, and we see a list of all the available components that a developer can utilize as a building block. Oh, sorry. Okay. So we select web application, give it a name. Come on. It happens all the time.

17:04 Adding a Web Application (Visual Demo)

17:30 So once we have a new square put on our canvas, we have to fill the these two parameters of that web app function, the image and port, and we have a web app. And at that exact step, after a few clicks, we're already capable of deploying that image running with a web server, running on that port to Kubernetes. But let's look what's more possible here. Let's create a database. We also give a short name for it and configure environment for our application with a drag and drop. That was it. So you just referenced and explicitly

18:15 Adding Ingress (Domain) (Visual Demo)

18:23 declared a dependency between your web application and the database. And since it's visual, it's really easy to wrap your head around all the solution infrastructure. Let's have a worker. It has to run the very same image as the primary application, but with a different command and also sharing the very same environment. So I think it's pretty simple and easy to understand. Like, what do you think? Very impressed. There's a few things here. It's like, I haven't seen, you know, JSON used in this way, but it's it's really it's really clever because you get a lot of composability

19:00 Discussion: Benefits of Visual Tools

19:16 and flexibility by adopting JSON over just regular YAML. Like you said, the ability to define types, to create functions, to have parameterization, like all of these things would have been cool on its own. But the fact that you have this extension that we can run and the tooling that we use every day to work with our code and give us drag and drop and visualization to connect all those dots. It's it's just too cool. That's that, like, it's very maybe we've got a wow for a from Redeemna in the chat there. So there we go.

19:51 You're impressing people. But, yeah, like, you know, I I know a lot of the time, you know, we say, oh, we love the command line and oh, yeah, we'll just break code all day. But these UI tools are very convenient. They speed up our development process. And you've always got the escape hatch if you need to go through something else, but there's a reason tools like from a networking policy point of view, like the Cilium editor and Hubble are so important because they allow us to take complex things. Like you said, the great wall of YAML and

20:22 that's not grokable, it's not understandable especially across disparate files, many files, thousands of lines. You have no idea what the output of that is until you have something like DevStand. So I can't wait to see more. Exactly. So we have just tried to move our Kubernetes closer to PaaS, but I think DevStand is also beneficial in comparison to PaaS. Let's compare them in in terms of easiness for developer and control. And I think DevStand is a good balance between low level and high level tooling because in Kubernetes, you can configure anything, but it usually requires lots of low level plumbing,

20:41 DevStand vs PaaS: Control & Flexibility

21:14 and it results in bad developer experience and difficulties to understand what you're actually doing. In comparison to PaaS, it has great developer experience, but you cannot usually escape that walled garden of your cloud provider. And once your solution receives a decent traffic, it can become really, really expensive to continue working on the same path. But what's most important that from time to time, any developer faces a situation when they have to deviate somehow from that golden path or so called paved road that the provider of the path had in mind while developing that platform. The sometimes you just have

22:10 to tweak something that it's not possible within a platform. But with DevStand, you still retain control of the underlying configuration. You can pipe the output of the DevStand to customize and do anything extra, or you can write your own transformation at in JSON at at top of that breadboard file. I think it it it there's something in it. Before I talked about the primarily about the private cloud, thinking of it's enterprise or inner inner source solution for developers working within a company brought by DevOps team also working in the very same company for their fellow developers, for

22:50 Cloud Use Cases & SaaS

23:11 their colleagues. And but I believe there has to be a cloud solution as well. Think of a SaaS service when you can just create an account, receive a freemium or trial, can give credentials to your AWS or Azure or DigitalOcean account, the credentials. And then that SaaS can create a new Kubernetes cluster and make it act as a path. And once you need, for example, a database, you can have a managed database from a cloud provider like this serious thing in the very same simple way as that just little square on your canvas. And what I see

24:05 Future Plans: Open Source & SaaS

24:07 for the future of DevStand is that a couple of products. The first one is the open source edition of DevStand for in house development. It can improve velocity of internal developers. And since it's open source and and no fees required, it can boost adoption, and we can receive a lot of valuable feedback from those early adopters. But it also has to have something living in the cloud that is just plain simple that a mere developer can stumble upon that. And once that developer lands in a company, he can just say, well, I know a thing

24:52 that helps save me lots of time, and you can usually utilize the very same thing within a company infrastructure. Like, for example, you know, GitLab is doing the same. You can create your account at GitLab, or you can have a self hosted GitLab. It and it spreads the GitLab across the world regardless if it's paid and cloud or it's unpaid and self hosted. What do you think is what would you like to see more? More of an open source thing? And do you believe that SaaS is really important, like, in in that product mix? Both.

25:42 I'll I'll be really partial. Like, you know, I always love to see open source software because, you know, the more it allows you to build a a sense of community and with and, you know, onboarding new contributors, helping them, allowing them to shift the direction of the project, having a a common voice that tries to push something forward and improve adoption, I think, is really important. But I also understand that, you know, open source isn't gonna pay our bills. We all know that. Exactly. You know, I I I think companies that go down this Azure,

26:17 you know, they can be wildly successful. You know, we see a lot of examples like this. Grafana is the most ubiquitous dashboarding tool in the world for observability and monitoring and platform engineering, but they have a hosted SaaS version because sometimes people just need convenience. Maybe they need enterprise features like, you know, SSO against SAML or whatever. So, yeah. And FoxDB do the same. They have their open source database and it's completely open source. But if you don't wanna roast host it yourself or you want this couple of extra features, then go with this as well.

26:48 I think as a model, we see it work well. The last example I'll give is Pulumi does this too. Everything Pulumi does is open source. But, you know, if you don't want to manage your state files, you give me a little bit of money and they do it for you. So, yeah, I think the strategy is is tried and proven to work. And I love that it allows us to keep things free, allow developers to experiment, and help shape the vision for the project. Mhmm. That's good. That makes total sense. And for the demo, it's basically it.

27:20 Audience Questions & Discussion

27:27 I have a video demo explaining and showing how that works a little bit deeper. But maybe before diving further, you can have some questions or we have some questions in the comments. Just people saying that things sound interesting. There's a comment there from Alina. With, oh, wow. That's interesting too. So and for them that also said at the start, but I forgot to show the comment is that, yeah, for new people, Kubernetes does sound scary. Although that is getting better. But it's also getting better through improvements to Kubernetes itself and new custom resources, but also

28:08 by tooling like this, which I think is really cool. You know, what I also noticed after several demos, there were no people saying meh about that solution. There were clearly two camps. The first camp were people quite enthusiastic about that solution. They told something like, yeah. That totally makes sense. It would save time. It's it's good. It's good. Can continue working on that. But there were completely opposite idea. Like, I don't know why you just developed that. Like, Kubernetes Kubernetes is sophisticated for a reason. Like, it it just has to be complicated because it's a serious thing.

29:00 And No. I don't agree with that whatsoever. I think Kubernetes being complicated is because the project is still young and we haven't found the right abstractions yet. And we still need to build these abstractions. And I see DevStand as a tool that can allow us to build these abstractions, you know, by leveraging JSON on it. You know, we allow we allow people to have repositories where they contain these abstractions like a web app or like a worker or like a queue or like a post grads database. Like, this is what Helm does, but Helm probably made a few mistakes. I don't know

29:35 many people that like Helm and the reason is why. Well, it uses Go template and syntax and not every consumer of Kubernetes even uses Go or writes and Go. So they have this barrier to entry where they're looking at something that just doesn't make sense. I mean, I remember still looking at helm templates for the first time and going at like, what is this range dot syntax? Why is dot context? What's a context? And it's like, have to understand scoping and this is like, what's what's wrong with mustache and handlebar syntax? Like And and don't forget the right amount of offsets

30:06 in the beginning of line. Oh, yeah. And having to end on things and and and and how those work and new lines breaking and empty object. It's really tough. Right? And I'm not saying JSON it is better, but it but it is. It's more familiar at least because it's JSON with some extra tweaks on top of it. So yeah. So long way to say, I I disagree with the people that made that comment. Kubernetes does not need to be complex. That's what people say that wanna protect their smarts. But really, we need to make Kubernetes available to to

30:39 everyone. We we need to make it simpler to the right abstractions. And it's only over time we can actually understand what those abstractions should be. Yep. We got a couple more comments there. So, Pradumna's Oh, sure. In love the product. We've got Kumaraju saying no image files and YAML's. Great. And we've got one from Russell's in I assume most business devs that have been responsible for supporting and for dependencies, DB's, Kubernetes, etcetera. Probably want to have it managed as a service ops can be hard. So plus one for SaaS. I know the comments are a

31:14 little bit off the screen there, but I need to fix that later. Well, that's great to hear such feedback. I encourage the listeners to go to the website DevStand.app. And at the very bottom of the main page, there is a little form when when you where you can leave your email address and receive updates. I haven't posted anything yet, but I believe I would have some big updates in the fourth in the forthcoming months. So stay tuned. And even if you want to have a a deeper talk about the the technology or you have an idea of how

31:20 Get Involved / Contact Info

31:58 to fit DevStand into your very specific case, also just leave your email. I would reply you back and we can talk. Or you can directly send me an email at max@DevStand.app. Alright. Awesome. I guess I've got a question then before we dive straight in to the demo. Mhmm. So for anyone who's currently using JSON to deploy their application, will that work by default with DevStand? Will I be able to visualize that? Or to is there something slightly different to the way that things work? I'm not sure on on the studio question. Right? But we'll see.

32:21 Question: Visualizing Existing Configuration

32:45 I have a a micro service just now that has a conflict map and a deployment. And I I I I deploy it with JSON. So I'm using JSON as a compiler, and I'm typing it through to KubeControl apply, but I don't have any DevStand. Is there a way for me to visualize that with DevStand? Not. No. Okay. Because, yep, you have to have these functions quite strictly structured. You have to provide JSON JSON schema for your configuration parameters. And so your so the plugin can understand or read your code and extract that information from your code.

33:30 Because as I told, nothing is hardwired to the plugin itself. Plugin is just a visual visualization of a very specific way of coding this JSON and functions. Okay. Alright. Let's see it in action then. Let's have some fun. Good. In order to avoid any hiccups and to save time, this is a recorded video. So let's so we have a very specific directory. It doesn't have to, but for the demo purposes, I have the directory dot DevStand. And right clicking on that directory in Visual Studio Code and selecting Scaffold breadboard directory will create a new breadboard file

33:44 Detailed Recorded Demo Start

34:22 and immediately open it. Nice. I got add component, web application. Just set the image, the port. And, yep, before piping into Kubernetes, we can just select view manifests, and a new editor opens in a separate tab. When you have all the output of that breadboard file, you have all your ports for the for the deployment and specification for the service itself. We can add ingress over here. And just checking that the local host domain just properly is traced to the local host. It's good because the demo was recorded on the local computer. And among the manifests, we now have our

35:51 new ingress, which references the host name to our service and port. Okay. So and once we are ready to deploy, just click pipe to kubectl, and a terminal opens up with just that pipe command. Okay. We have created deployment ingress and service, and this is this is a very a few words about that demo application. This is file manager that just uploads files. That's a a very basic feature to to show. So what if we can update our domain right there within our breadboard? And once we apply to Kubernetes that breadboard again, we see that

36:38 Updating Deployed Configuration (Demo)

36:52 nothing is unchanged except the ingress, And the previous link doesn't work now. But once we visit a new address, it works. Alright. So You happy to take questions as we go? Sure. So I'm curious now. Like, is there the means with DevStand? Like, okay. Let me try and set some context first. You know, I don't just deploy to one cluster. It's likely I'll have some sort of dev cluster at a production cluster. So for the ingress, it may be that I wanna pull that value externally or change it based on where I'm deploying to. Is there any way of pulling external

37:41 configuration? Sure. Well, I mean, at the very moment, that's not developed yet. But, sure, as you can see later, you can use variables Right. Okay. Within your JSON, and you can have, like, a top level configuration. Like, this is my production domain top level domain. This is my development top level domain. And, sure, it's possible to use that suffixes within your JSON files. Alright. Well, I'll I'll keep watching. So just to have a look at it, yep, we have our application deployed, and, well, we even can see that the the container is actually running. Let's

38:39 Adding Storage (Minio) (Demo)

38:40 create more components and add a storage. For s three compatible storage, let's use Minio. And in the very same fashion, we create extra configuration for that storage. And the the application, oh, while it's being deployed, the that file manager application, that that demo application is written in in PHP with Laravel framework. And Laravel framework has a built in feature, the so called file system drivers. So access when your application wants to access a file system, it can be either local file system or s three file system or FTP file system. In order to configure our Laravel to use

39:47 that s three storage, we have to set a file system driver equals to s three. And now we have to I can I can just yep? And, again, since the the software is very early, it should like, in in the way it it is now, it it's not ready for production because in ideal world, it would be something like there is a secret associated with that storage component. So you can just drop the whole secret into your application, and it will be mounted as a file or end file or put inside your environment variables. But for that demo purposes,

40:41 I think it's quite clear to to understand how it works and where is the value of of that solution. So once we have that the whole configuration and deploying. So storage wasn't changed because nothing has changed and just the configuration of the web application was updated. And now for the demo time, uploading real files to that file manager. Yep. And our files appear in s three. Nice. So in the very same fashion, it will work with databases and any other microservices or domain specific APIs or any other thing that works with standard protocols. I have the

41:51 Visual Editor and Underlying Code Relationship

41:52 last piece of demo trying to show what are the relations between the presentation and the file itself. So right now, I'm going to open in Visual Studio Code the same file two times. So on the upper side of the Visual Studio Code, you have the breadboard editor, that visual editor, and underneath it, you can see that plain text file, which is actually the source for the visual visualization. Here you see that you have my app, which extends that web app function and configuration. You can update either for example, in your company, you do not call web apps like web

42:52 apps. You develop APIs, and you call them web service. You can do that. And you as you can see, once you update your text file, the visual designer reflects all the changes immediately. Nice. You can update your exact values, for example, tag or report. You can even rename it right into the code editor, or you can rename it in visual editor. And since this is just Visual Studio Code, you just can hit your keyboard shortcut for undoing or redoing actions. It it will automatically redraw both plain text file and the visual editor. But what's inside this

43:53 web app function? This is actually a code in JSON. I won't say it's, like, very straightforward, but this is the way how JSON and code is written. And the very last thing oh, yeah. You do not have to use Visual Studio Code to actually utilize DevStand, for example, within your CICD pipeline. You can have the just binary and DevStand manifests and pass through that breadboard file, and you receive your YAML. And you can process that YAML further within your pipeline, for example, with a customize at something at top, like your custom domain or annotations, labels.

44:54 Git Integration & Version Control

44:54 And the last thing, and I think it's really, really important, since the underlying file is just a plain text file, it's ready for Git. And within Visual Studio Code, you can easily spot what has been changed. Yep. We just added ingress. It just feels natural that it's so straightforward. And that's what that was it. Nice. Awesome. It's a cool project. Let me pop this back over to there we go. Yeah. If anyone watching has any questions about DevStand, now is a good time to drop them into the comments, and we'll ask them before we wrap up for today. So if

45:33 Post-Demo Discussion

45:47 you wanna know more, you've got ideas for new features, feel free. Speak now. Alright. So, yeah, we've got to thank you for the demo. There we go. Yeah. So I I like this. So we can take the JSON on it. We build our own abstractions. We commit them to get That is what losing my words today completely. What I like here is that we can have people that want to write JSON and bother with abstractions go and do that. But you've created this other area for just consumers. Like you said, the Latterfield Developers out there, the people working

46:26 with Ruby on Rails, the people that are building databases. Whatever. Like they have the option though to just consume the abstractions made by other people and a very visual way to connect the dots with the variables that they need. And the JSON is is there. They can commit it to get they could push it somewhere. CI can take over. But it's a tool that enables people to do things that they couldn't previously do. And I think that's really important. We need to make this easier for people to deploy to Kubernetes. And it's just a cherry on the top

47:01 that it runs in Versus Code. Like, I love that. Like, it's not another tool. It's not an electron application. It's not a web application. I'm already in my editor, and I just think that was a great decision that you made there. I mean, don't get me wrong. Have no idea how you write Versus Code extension, and I have no idea how you make it actually, like, a drag and drop of a board with little dots and connectors. But yeah. Very cool. You must like, I wanna know just how like, were you a Versus code or

47:29 Node. Js developer before? Had you done graphics? Like, I I I'd love to know more. Well, a Visual Studio Code has a notion of editors. And one of a way to create a new editor within Visual Studio Code is to make a WebView, and the WebView has to follow certain protocol for intercommunicating between Visual Studio Code and your JavaScript running within your web view. So the whole editor is basically a web page. Code is written in Svelte framework. I picked that one because because it's has the the least amount of RAM to be used for

47:35 VS Code Extension Architecture & Features

48:30 drawing dynamic HTML. So and there are two parts of the extension. The first one is that web view thing, and another part is the actual code, which written in in TypeScript, which scans file system, find files, update a specific file. If an interesting thing is that I can show you. Is that the code the extension actually treats the JSON file as code. And when you update something, it actually update that very specific line and that very specific portion of code that you reference. For example, if I have this as my comment. For example, a DevOps person or a developer left a

49:45 comment for for their colleague. Once you update something, like, We have your comment preserved. The I mean, it would be much easier to just dump the whole configuration and override the whole file. Yeah. Yeah. Or something like that. Although, do I have a feature request? Like, can we get those comments as little yellow posters on the the breadboard? I haven't thought of that. That that's a that's quite a smart thing. It would be even even simpler. Yeah. And if we look at a comment on, let's say, 17 for the image, then that could be, like, a little annotation on

50:42 that property on the in the UI as well. Like, you could take you could take comments of first class citizen here. That would be very, very cool. Yeah. Something like just this cute the other one. Yeah. Yeah. And then we get a That's a great idea. Alright. We do have a question for Russell in the chat. Russell is asking, are there any plans on providing best practice templates? So like, are you gonna release a obstruction library with like API or web app or I don't know, Kafka deployment. Like, you know what we see with Artifact

51:03 Discussion: Template Libraries & Distribution

51:25 Hub and Helm? Do you see DevStand having a space on Artifact Hub where people push these obstructions for reuse and sharing? Sure. Right now, when you when you scaffold and you breadboard, it automatically fetches the default templates. Think of them as provided by the the the creator of DevStand. You can throw them away and replace them with yours, but there should be something, a default to start with. I think of having templates for usual stuff like web app or databases, but it should also be integrated with a popular Kubernetes operator. For example, there is a Kubernetes operator for

52:25 Postgres, or you have a Rook for many databases or Redis operator. And they have their very specific CRDs, which you can you you you have to follow that notation, that syntax for claiming a new Redis instance, for example. And I think that has to be provided out of the box for newcomers as well. I see that that open source version of DevStand will come with something like a wizard step by step. For example, the first step, hi, your DevOps person. DevStand provides out of the box integrations with these 20 popular Kubernetes operators, a menu operator,

53:16 Postgres, Redis. You just click them, selecting those operators that existing DevOps team already implemented within their Kubernetes cluster, and then just return, okay. You just have to have these several functions to utilize. A good question about distribution. I had NPM as a source of inspiration for it. So, basically, it fetches from GitHub, either GitLab or Bitbucket or just any Git repository. It just fetch these repositories and store them in this JSON or PKG directory. It means that you can also for example, I'll just open. So that's code for the for the functions. Mhmm. And that's the schema for the properties that

54:46 you can configure within within your within the designer. And if you have that, I mean, that specific repository is public, so once you fetch it, it's fetched as a tar or a zip file and extracted. But if it's a private repository, it would be just git cloned with your SSH key, so it's safe to distribute these libsonnet these JSON functions or these DevStand templates within your private Git repository. Okay. We have a question kind of related there from who was asking, can we provide custom keys and values? So I'm assuming he's asking how do we

55:26 Discussion: Custom Configuration & Overrides

55:35 extend that schema. So maybe we could take a look at one of those functions and just show a little bit of the JSON that makes that work. Okay. For example, this is for the web app. Yeah. What if we wanted to maybe it's already done, but what about requests for CPU and memory? Is that part of your spec? Well, right now, well, it is not. I I still have that on my on my list. Yeah. But, yeah, right right right now, it's you either have to create your own function, or since this is just this is just JSON, you

56:23 can and I honestly, I can't remember how I did that while prototyping, but either you have to be able to write something over here. It's like cube deployment. You know, somewhere over here, you have this Yeah. Well, I don't know how this works in JSON. Are these structures closed? Like, can you just add a b c and the value of one underneath line 14? What would happen if you do that to the UI? If you just do a b c pull on one. That's that's for, for example, how low Yeah. It is possible. Hello, world. Alright. Nice. Yeah. So those structures are

57:31 open. So you can start to you could start to add your own. But you you you yep. But it wouldn't be compiled to anything. Right? That Well, you can you can still edit them. Yeah. Okay. Nice. Very cool. Alright. Let me pop this back over. Alright. Well, I don't think we have I I remember how to do that. Oh, yeah. Sure. It has to be plus. And here you have all your overrides over here. And for a developer, it can be easy as okay. That portion of code, this is what I'm responsible for, and the rest of the gibberish is that

58:17 what my DevOps people do. Have often classified the work that I do as as gibberish, so I appreciate that. Yep. That that that should definitely work, that plus thing, because this is a native feature of JSON. Nice. It's a good question. Alright. Well, I don't think we have any more questions. So I'll just say thank you for taking some time today to to sit down with me and to show everybody DevStand. I'll finish with the the easiest question. But, like, what's coming next then? What are you working on right now? Well, right now, I'm working

58:42 Conclusion & Future Outlook

59:06 mostly on the commercial side of the project. I'm trying to rise some investments so I can continue working on that project full time because it requires a a significant amount of time to make it work to fix box and to to push it forward because I already have lots of features in my wish list, but I just didn't have enough time to implement them. So and as for the very first iteration, I see it something like works with, for example, DigitalOcean. Like, every like, most of developers, they have their account in DigitalOcean, so it would be quite straightforward

1:00:02 to just integrate that solution with DigitalOcean managed Kubernetes to to and to see how it works there. And maybe something that SaaS version can be obvious first step when you have just restrictions for, okay, you can host either web apps or background workers and manage databases from DigitalOcean and just these three options. And to I did and just go through all the obstacles required to to release that first working versions. And then once I can make it slick with just one single provider, then I can bring all the features back to the open source version.

1:00:56 But I definitely will continue working on the open source version because I truly believe that Kubernetes has to be simple. Awesome. Thank you again for your time. I'll finish with, you know if you had asked me six months ago what I thought of JSON, I would have said it was dead. And I I I genuinely believe that DevStand may be the project that brings it back to life. So I'm gonna wish you the best of luck. I can't wait to see what's next. So please get in touch with the new version, and I'll see you again next time. Have

1:01:30 your last words? The well, thank you very much for having me. I really appreciate your feedback, and kudos to our listeners for being engaged and asking for questions. There are still a lot on the tape on the table, and thank you very much for your time. And thank you for an opportunity to share what I've been working on for the recent, like, year and a half. That that project is really important for me, and I really wish it finally takes off. Alright. Well, we're all rooting for you. We'll all contribute at help, and we'll see you

1:02:14 again soon. So thank you again. Have a great day. Thank very much. Have a good time. Bye all. Thank you for watching Rawkode Live.