Sveriges mest populära poddar

FLOSS Weekly

Episode 782 transcript

N/A • 8 maj 2024
FLOSS-782

Jonathan: This is Floss Weekly, episode 782, recorded Wednesday, May 8th. Nitric, in search of the right knob.

Hey, this week David Ruggles joins me. We talk with Rack and Steve, both from Nitric, a company that makes an infrastructure from code solution. It's all open source. It lets you write your applications in just about whatever language you want to, and then automatically provisions your cloud infrastructure.

It's really powerful. It's really neat. You're going to want to check it out. So stay tuned. Hey, it's time for floss weekly. That's the show about free Libre and open source software. I'm your host, Jonathan Bennett. And we are glad to have everybody here today. We've got an interesting show. Of course, it's not just me.

I've got David Ruggles in as the co pilot again. It's good to have you again, David. Thanks for stepping up and volunteering to co host. It's good to be here. So, We have today the company Nitric, and we've got Rak Siva, who is one of the founding team members and the vice president of engineering. And we've got Steve Demchuk, who is actually the CEO of Nitric.

And these guys do I want to say infrastructure as code, but I have been told that that's not exactly right. They do infrastructure from code, which makes all the difference. I'm told we will ask him about exactly what that means. Is this something that you're familiar with, David? Not yet.

David: But I'm excited to become familiar.

So I've. Some DevOps work. I've done some cloud hosting, nothing automated. I haven't even gotten into infrastructure from code or as code yet at all. So hopefully I have some questions that are above baseline, but they won't be very detailed.

Jonathan: Yeah, we were talking about this before the show, both David and I, we, we do, of course, sysops, we've done DevOps, but neither of us have done a whole lot of like cloud native work.

And as, as I, as I joked before we started, I built my own servers so that I didn't have to put things on the cloud. And so maybe part of this is going to be a rack and Steve trying to convince us that the cloud is the place to be. We'll see how that goes. All right. Let's not let's not waste any more time.

Let's bring them on. And Hey, rack and Steve, both of you, welcome to the show. Thank you.

Rak: Thanks, nice to meet you.

Jonathan: So, let's start with our patented and well known 30, 000 foot view. And maybe let's let Steve take this one as the CEO. Why, what's, what's the, what's the juice at Nitric? What's the what's the big tool there?

What's the reason that someone reaches for what you guys have?

Steve: Yeah, so thank you. Yeah, Nitric's open source multi language backend framework. And. It really truly is about letting teams scale DevOps without the complexity and maintenance burden of, of cloud development all by yourself. So kind of what you guys were talking about infrastructure as code and infrastructure from code, the, what we're doing is.

actually automated automatically provisioning your infrastructure directly from your app code. And then you can, the DevOps team can actually build customizable guardrails to actually help with that. So imagine a world where you're really focused on your app code. And you pick the cloud you want to to provision to, and it works.

Rak: Yeah, what's really cool about this is that Nitric lets developers actually focus on their application code. So it gives you a runtime that works locally, immediately. So from day one, you can start rapidly iterating your projects. But you're also ready to deploy that code directly to the cloud on day one as well.

So I'm not saying you're going to have your solution done in a day, but you're ready to run locally and in the cloud immediately.

Jonathan: So what kind of apps are we talking about? Are these like browser native applications? Are we talking mobile applications? You know, can you run an Android application and then use Nitric to set the backend up?

How deep, where do all the fingers of this stretch out to?

Rak: Yeah, it's typically the backend of any type of application. Could be a mobile application, could be a web application. As long as it's running on the backend side of things, that's where we play the most.

Jonathan: Okay. And, and then like what, what clouds, you know, what providers can we, can we plug into and how does that plug in work?

Rak: Yeah. So we have native support for AWS, GCP and Azure. That's, that's part of the framework today. But as you'll learn, like the, the idea behind nitric is that you can deploy to any cloud. It just, it's a, it's a pluggable sort of a framework. So you can additively extend to Oracle or to other clouds out there as well.

Jonathan: Is there anything built into it to to prevent the dreaded 10, 000 bill from your cloud company?

Rak: Yeah, definitely. So again, we'll talk about it a little bit more in detail later, but, but we do provision resources with the best practices and least privilege required to, to connect up resources to each other to avoid the dreaded 10, 000 bill.

So. Can't guarantee it. You can always, you can always find ways to work around it, but we do our very best to make sure that, that, you know, you can't accidentally get into that situation by deploying the nitric.

Steve: Sure. I think, I think one of the key things is as we work with, with users of the open source framework, and as we've worked with folks going into production, a lot of that, you know, it truly is architecting for the cloud, being knowledgeable about what infrastructure you are provisioning and why, and making sure.

You're only provisioning what you need versus maybe what you, what you wrote. So a couple of the teams we've worked with have told us they've saved up to 60 percent on their cloud build. And you know, a lot of that times it's, Hey, they, they, they decided to use the right compute based off of their, it's a long running service or it's a dynamic service.

But a lot of that too, is you're only spinning up what you need instead of leaving out there of what you've created from the past.

Jonathan: Yeah, that makes sense. So I'm curious about the kind of the open source angle on this, how much of the, how much of the tooling, how much of the, the offering is open source?

I'm like, what's the, what's the model? How do you guys pay your rent and buy your groceries? I

Steve: mean, as, as a, as a, Early startup. That's like every day, what you're thinking about obviously the open source piece came from, this is a new paradigm. It is something that's new. We ourselves are huge fans of open source.

We use open source in our projects with, with very large banks, with our own SAS companies that we've been entrepreneurs with. So number one, it was, it's the right thing to do to make this open source. And we knew if we're going to keep up with all the cloud providers, you know, big part of what we're adding here.

Is really a, but comfort as things change that we can actually move fast and take care of those changes for you. That's going to take a community. The other part of that is we want people to extend it. The fact that we've chosen it to be cloud agnostic, we've chosen for it to be multi language.

It's kind of a huge principle of ours to meet people where they are in their preferences and not just say, we're all in on language X, so you must be too. So it really came from. I would say it was never even it was everybody saying yes as the founding team. From the how do we make money part I would say really modeling as people are going to, to production there, they usually ask us for architecture consulting, for licensing and support.

So it truly has been licensing and support of the framework is the monetization model that, that we've seen start to work really well. Yeah. So that's how we're doing it today. Right now it's a hundred percent open source. We don't have. Any features behind, behind any gates.

David: Awesome. So when you talk about licensing specifically, I assume it's where you've got customers that are concerned about open source licenses poisoning their code, so they want a non open source licensed version of this?

Steve: That has not happened yet, David. Actually, I, I do anticipate that happening maybe someday, but it's been more. Hey, we've gotten really far and we love what's happening. Will you support what, what we have? Can, will you do some custom development with us? And if we ever write something with them then that we are going to ensure that and make sure, you know, support it with them.

So we have not had a fork that's been proprietary in any way, shape or form. Yeah,

Rak: yeah. I think I'd add that it's a trust building exercise as well. So. We're taking responsibility of a very important piece of the cloud deployment story. And if you abstract that away and you, you make it opaque it's very difficult for people to trust you.

So this way, you know, we're saying this is what we do and you can inspect the code and have a look at what's happening under the covers if you want to.

David: So I've been digging through your docs as we kind of talked about at the beginning well, first, I wasn't aware of you at all until yesterday. So this is exciting. But I don't have a whole lot of experience with the infrastructure from or as code either side before now, but your integrations rely on Pulumi, if I'm pronouncing that correctly.

Yep. And so maybe I'm getting a little bit ahead, but hey, this is one of those open ended questions. Why would I use Nitrux instead of just writing it directly in Pulumi? Because as I dug down into it, it looked like it was also cross programming language.

Rak: Yeah, yeah, I'll fill this one. Basically, you need two things to deploy to the cloud.

You either need, I mean, you need your application code, which, you know, you're always going to need that, and then you need a runtime configuration. And the runtime configuration is what tells AWS or GCP what componentry you're going to be leveraging when your application runs, and how to have it configured so that they can interconnect and talk to each other.

So day one, let's say you're starting from scratch. You may go into the console, the AWS console or the GCP console, and you'll manually configure all of these resources. So you'll say, oh, I need a storage bucket. So I'll enable that service. I'll configure it. I'll set up the IAM policies, the permissions required for my Lambda to access that storage bucket.

Right? So that would be one way of doing it. And that's very manual, but it's not repetitive. So each server you go to, you're going to have to apply those same configurations. So enter IAC, which is a way of either programmatically or via configuration, applying the configuration that's required for you to provision your infrastructure.

ISE tools are like Pulumi, Terraform, CDK, that sort of thing. Ansible, yep. Exactly, yep. And so what that brings to the equation is repeatability. So now you've got a script or, or a piece of code that you can repeat across different environments or different projects. But, but what you end up with is you've got your, your application code and you've got your IAC project.

Two separate siloed pieces pieces of code or projects. And the link between them is actually manual. So let's say you, you, you, your first version of your code and you've got a bucket in it. But then you decide you're gonna, you're gonna use a third party bucket instead. So you don't need to provision that bucket with your IAC.

You're going to have to go into your other project and remove the IFC as well. So you're manually keeping both projects in sync. And that's quite, like, complicated when you start to scale. Right, so So what IFC does is it's an infrastructure from code. It creates a bridge between the two. So instead of manually saying, Hey, I changed my application code.

Now I have to change my IAC. What we do is we infer the requirements, the runtime requirements from the application code itself. So when you declare a bucket in your application code, we create a resource specification that kind of maps all of the, the resources to, to each other. And then we can use providers to fulfill that request and the providers in the IFC world.

are actually IAC, so we're complementing where we're using modules of IAC to implement your bucket each time you make a request for a resource. Does that make sense? I think so.

David: I'm following. Okay. You did mention Ansible. Ansible is something I've used and I'm familiar with, so I can actually ask a potentially more intelligent question around that.

Is Ansible something that you can run on top of? Is Ansible a backend that

Rak: So in, in our current versions, we don't provision with Ansible, but we could there's definitely the, the potential to, it really depends on the community and how, how involved they want to get in that space. We've chosen Pulumi as our provider of choice, just because it is language agnostic, as you pointed out, does support, you know node Python and, and a variety of languages go but we're also working on providers in Terraform as well, and we can also extend that to other tooling as well. So it really just depends, I guess, on how far we want to take the community support.

Steve: And I will say sorry, just to jump in real quick. Pulumi has been great partners of ours. If they have an automation API that really made this first version of kind of the proof of concept a couple of years ago, when we was, this is a really cool idea, can we actually make it work?

So I would say a huge to the Pulumi team because then providing that gave us a great way to get started and think about it from a developer's point of view of. I actually want to do this in Typescript, or I actually want to do this in Python. Versus yeah, Terraform really is the de facto. I mean, I would say it has, obviously, the largest market share.

But that you are learning a totally different skill set of learning HCL. Which, obviously, for certain roles, that's preferred. Just like, maybe for you, David, it's preferred to use Ansible. So, you're kind of hitting, you know, Why we like what we've done with nitric is if there's a community around that and there's people want to do that We actually built nitric to support that style in the future We've just chosen that proving it out that it's super valuable to kind of go where where our passions were and now we're spreading out To where our compute community passions are

David: makes complete sense.

I was just wondering like if if you've got somebody that's a startup, whether they're starting a new application or they're a complete startup, then it's a lot easier. But if you're trying to integrate it with a company that already exists, and they've got a large Ansible infrastructure already in place, instead of reworking all that, if there would be a way to tie those together, and I think that's the question that basically got answered there.

Yep, exactly. So I think Jonathan had some further questions about licenses and such. I do.

Jonathan: Actually, before we get to licenses, I'm, I'm real curious. You mentioned that Nitric actually looks at your application and kind of fills in the blanks for you. Is that like, is it just static code analysis or is there like a, is there a Nitric library?

I mean, I'm just kind of curious how the, like the actual nuts and bolts of this works.

Rak: Sure. Yeah. Now you've, you've noted it's a, it's a Nitric framework, so it's an SDK that you use. So basically you're declaring your resources. If you wanted to declare a bucket or a topic or a queue, you'd import those resources from the Nitric SDK.

You'd configure them. What we require is for you to give an intention. So let's say, let's say, let's keep on the bucket topic. Let's say you were declaring a bucket. Typical actions against the bucket would be read, write, delete, to, to delete objects from the, from the storage. You could also associate a non event handler.

So that when someone wrote to the bucket or read from the bucket or deleted from the bucket that a separate service would be triggered. Those things are the flexibility of the SDK that you'd be, you'd be using with nitric. So so you could write out those handlers and you could write your application logic to interact with that bucket as well, using the nitric SDK.

Jonathan: So you say, Hey, Hey, nitric library, I need a bucket. I don't care about the details of it. I just, I need a bucket somewhere. This is what I'm going to do with it. And then you have the, you have this object that you run around with and you do this stuff in your code and you don't know if it's going to be on Amazon or Azure.

It just, you guys make it work.

Rak: That's exactly right. Yeah. You're delaying the decision on where it's going to actually end up. So what we do is we build a resource spec from that saying this is what they want to do with that bucket. This is the level of permissions that we need to grant for that bucket because they want to read, but they don't want to write from it.

For example. And we create that specification and the second part of it at provision time is fulfilling that contract

Jonathan: Yeah, that's that's cool. I can see I can begin to see how that would actually work. I

David: I was digging into the docs around that because one of the things I noticed early on Was secret management because that is a challenge.

You know people commit secrets into their source repositories so often. And that's something that Nartrix did, where you could have a bucket that you keep your secrets in and you're specifying right to the process that stores the secrets, but then everybody else is only allowed to read. And that's that's from 15 minutes of doc reading there.

So that's the extent of my understanding. Yeah

Rak: You've got it. Yeah, we we basically picked foundational components Which we've recognized from projects that we've done in the past and deployed for for big fintech organizations So, you know, you typically need storage buckets. You need queues you need topic subscriptions You need scheduled tasks or delayed events.

These are the foundational building blocks that a lot of APIs and applications require, so they're available to you immediately with Nitric.

Jonathan: So Maybe a question, a series of questions for Steve. Let's start out with the easy one. What what License did you go with for this? You know, what open source license?

Steve: Apache 2. 0 for this one.

Jonathan: Okay, and then have you gotten Outside contributions? Are people out in the community excited enough to start pushing code?

Steve: Yeah. Yeah, what's exciting for us? I would say We want a lot more. So whoever's listening, we would love more help, but it's, you know, it's, it's been more around language development.

So we have we had to request earlier this year to actually start working with Dart. And which is really exciting for us. And you were talking about the mobile component and being able to work with that community. So it was really fun to say, yeah, that's exactly why we built this. We just put out our V1 release and we'll talk, we can talk about some of the features there, but just focusing on the contribution side with that we're actually co developing now with go so that we, you know, we really want people to be Okay.

So the first thing is, we're really proud to be working with the Go community to help us with the Go SDK as well. And you can imagine, our team has a lot of expertise in languages, so we're really comfortable when it was with JavaScript and Python, but when we're working with folks that are all in on Azure and also still use C Sharp, our philosophy on these things is We'll get it started.

We'll create like the structure, but we, we really want the developer experience to be fantastic to the language that you're, that you love. So we do rely on community feedback and and welcome the contribution side there. So yeah, so early days for us on contribution, but we've loved the, we've loved the, the contributions we've had.

Jonathan: Yeah, that's cool. So the, kind of the direction I want to go with this as do you have a, do you have a CLA or a copyright grant for contributors?

Steve: It's funny. We literally just put that on the board yesterday. So we are with, I was just talking about this go project that we're going to start we we will put that in place for that one.

So for, you know, for everything, but to get that going, and I'm curious from your perspective. Can you, I would say that's kind of a requirement for us to get going forth. What, what, what are your thoughts on that?

Jonathan: It's tricky. So, one of the friends of the show, Jeff Geerling, just put out a video the other day about, oh, I forget which project it was.

It was something Red Hat was doing, though, I think. And they, they had a CLA in place, and they used that CLA to make a licensing change. And can't remember what company it was. I don't think, maybe it wasn't Red Hat. Anyway, so he, he makes, he makes the comment that, you know, if you're gonna do business with a company and they have a CLA, maybe you should think twice about that.

And it's like, well, I, I don't know. Because I could see Let me put it this way. I'm in, I'm involved in a project where we have a CLA, and when you ask why, it is, it is essentially so that if a problem comes up with licensing, it gives the project the flexibility to be able to fix it. And some people have handled this by having, you know, GPLv2 where, you know, if, if the, Free Software Foundation comes out with another version of GPL, then kind of all of the code falls through to that automatically.

And that's one way to handle that. But then you kind of have a lot of trust in the Free Software Foundation to not do something really crazy for GPLv4, right? So I, I'm mixed. My feelings are mixed about CLAs. And, and so I understand, like, on the business side of it, It's, it's sort of something that needs to be there, particularly if you want to ever do dual licensing, you just, you just have to have control over that copyright to be able to do it.

At the same time, I know a lot of people are beginning to get a little gun shy about it. So it's a complicated issue. I, I do not have the answer on it.

Steve: I'm actually glad you brought it up because that gives me a little more of maybe that's something we need to talk with our community about a little further and see, see where people are at on that.

Jonathan: Yeah, I think, I think maybe the one thing that I would say is if you're, if you do a CLA, be Be absolutely upfront and honest about why. And so, you know, you want to, you want to assure people that you're not going to pull a Terraform and completely relicense to a source available license. Cause nobody wants that.

Nobody ever wants that except, you know, the, the guy's in suits making the financial decisions. That is the

Steve: opposite of what we want. Right, right.

Jonathan: But if you know, if you're, I would say from my, from my perspective, if a business is just upfront and say, look. We want to be able to dual license this code so that we can one day sell it to a big company and they do not get, you know, this poisoning problem.

I think the community is going to be reasonably okay with that. And I, I don't know, maybe there, maybe there could be a CLA designed that would actually prevent a like a gross relicensing of everything. Maybe we need to do with what we, do what we did with open source licensing in the GPL and kind of apply that same sort of sleight of hand to CLA's to make them fair to everybody.

I don't know, I think there could be some work to be done on that. Maybe you, maybe you guys will be the ones to do it.

Steve: I mean, I think, I think, I think you just gave me something to do. So

Jonathan: yeah, that'd be fun when, when you figure it out, come back on the show and give us all the answers to it.

Steve: I mean,

Jonathan: all right.

Fun. Okay. So I'm curious how hard is it to get started with nitric?

Steve: Yeah. I mean, you can tell I hope David had this experience, but we love documentation. So the fact that it's open source, please try it free to use. The big thing that we want to do is provide you with example apps that look familiar to things that people have built before or maybe are interested in building.

The other thing I'll tell you We do use discord with, for nitric and our, you know, the folks working for us as a as a company, but also the contributors are all very, very kind there. And yeah, I would say too, like that take the time just to learn a little bit about the concepts before you dig in is the only thing I would say is.

I think just reading the context, concept sections is, is helpful. So that you kind of get that, like, Hey, what, what is this actually doing? So then you can trust by verification once it does it.

Jonathan: I'm curious, this is kind of an aside, but you guys, as we've mentioned, your documentation is great. What's, what's the secret to having good documentation?

How have you managed that?

Rak: We have a, we have a pretty pedantic CEO. Co CEO and he, so he, this is one of our founders. So Steve shares the role with him and he he is very adamant that that documentation has to be understandable, you know, by everyone and simple and, and not, not just padded with unnecessary, you know content.

So basically he's, he's He's gotten us to revise it several times and to the point where we think it's it's quite clean but it could always use improvements and And so I think I think the key is key there is simplicity clarity and really solid examples.

Jonathan: Yeah, good documentation is such an art do you make the developers write their own documentation or do you have people in the project and in the company that are?

Just for documentation.

Rak: Yeah, it's the development team. That's self documenting right now we take a lot of community contributions as well and and that's, that's the great part about a community, right? Is that they're, that's the easiest way for them to get involved. And so we've had a fair few clarifications and fixes from them as well.

Steve: I'm going to make fun of Jai just for a second, just so that I have the opportunity. So, so our founders are, are Tim Holm and Jai Kush. And Jai, we, we were all at so Rak Jai, Tim and I were all at a previous meeting. Startup that was working, it was a FinTech and we were working with large banks.

And so part of the key value that we were adding was writing a lot of integrations and difficult integrations with core banking systems. And think about the documentation there. And I, I could see him pulling his hair out every day of the week for, for multiple years. And so when, when, when the team would find great documentation They would really talk about it.

And we bluntly as a business, when we were, Hey, what do you guys use for payments? What do you guys use for identity verification? We recommended what our developers recommended, which is the ones that have the, you know, the same business benefits, but by far the better developer documentation. So that I honestly think, why is our documentation good?

It's because our team knows what it's like when it's not. And they recommend tools that have great documentation. So it's certainly an ethos of. I'm very scared to write documentation personally but I'm going to get better. So,

Jonathan: yeah, it can, it could be a challenge. It is difficult, but there's, there's nothing, there's nothing worse than looking at the documentation and it not having the answer.

And so then you either have to, well, you know, you, you're, you're. Your options are like to Google about this thing and try to find the stack overflow threat where somebody else had this problem. And of course, when you go to stack overflow and you find the answer, it's, it's always, it is always a stack overflow question that has been closed for whatever reason, because it's not the kind of question that stack overflow wants.

But then in the comments, somebody has the answer. And I. Repeatedly, I've had that, that experience. So you either you Google and find a closed stack overflow thread, or you have to go on somebody's discord, which discord is great, but it should not be your documentation, or you have to go read the source for yourself and figure it out, which is a useful exercise, but it's also not good documentation.

Steve: Yeah. And I will say just watching the team. I mean, if we're just watching our threads of work and what we prioritize, like. You have to continually update it all the time. And like you said, like if you let other systems be Bob, but that's in discord, like you said, or, or, or I documented that in get hub on the issue.

You're going to lose it. You're going to get really far behind really quick. And that's where having, having someone that cares deeply about it, we definitely, you know, it'll be brought up. Like we've gotten too far away from, from where we were. Let's get back to it.

Jonathan: So we've talked about this a little bit, but give me the rundown on the difference between infrastructure as code versus infrastructure from code.

Rak: Yeah. Yeah. So a slight rehash and it's, it's basically we're complimenting infrastructure as code with infrastructure from code. And it's, it's basically the principle of, of inferring the infrastructure from the application code and automating and streamlining that process rather than manually having to mitigate the differences between.

Your application and your infrastructure as code

Jonathan: So we're talking less less boilerplate to get started things just happen automatically.

Rak: That's that's right. Yeah. Yeah it happens automatically until you need to extend it and that you know That shouldn't be your number one concern when you're starting out your build

Jonathan: Yeah, so I think in the in the pre show I made a statement that it sounds like they have less boilerplate more sane defaults and Pretty much sounds like that's what it is.

Rak: Yeah, exactly.

Steve: I think it's interesting when when rack demos Nitric and you know just shows how it works from a console It is pretty cool to show like even a hello world example in AWS If you're going to use Terraform or Pulumi, you know, if you're going to build a production grade example that says hello world, that has all the things that you need, you're still going to see 80 to a hundred lines of, of infrastructure code there versus with this, you really are writing your seven lines of app code.

And it's going to infer that exact same infrastructure. And you can build guardrails around that. Use our, use our sane defaults, but then you could, if you have changes you want to make, you can make them.

Jonathan: Sure. Is there a, this brings to mind, this is kind of a nuts and bolts question, but is there a way that you can say, hey Nitric, I want you to do all these sane defaults, but I also want you to show me the code.

So can, can you ask Nitric to kind of build that builder plate for you?

Rak: Mm hmm. Yeah. Yeah. So because we export the resource specification from your application code, it's up to you actually how the providers spit out that information. So, you know, the, the default behavior is to use Pulumi to runtime deploy those resources, but we're also working on Terraform providers.

Which provides you with a Terraform script of of what you're going to be deploying to the cloud, which you can then init, plan, apply as necessary. But it doesn't even have to be those two. You could be, you know, It could just be a digest that you spit out for, you know, audit and tracking purposes. It's you're really in control of how you actually interpret the resource specification.

It's a completely flexible.

Jonathan: Yeah. Can. And so this, this is really what I'm getting at. And, and I've, I've not done the hello world example yet. So I'm, I'm speaking out of a little bit of ignorance here, but so nitric itself has a, A specification, essentially a config for your cloud, and it sounds like that could be extremely minimal or you can put a lot of detail in there.

Can you, can you give nitric that extremely minimal config and then get back out of it? Say, okay, I want you to fill the gaps in and give me. That, that the, the kind of config that nitric expects with all of these defaults filled in so that, you know, I don't have to go and figure out how to do, because one of the things that I've run into, it's like, okay, your program works.

Now you want to do this other thing that's a little bit obscure and there's so much documentation for, let's just say Android. I've done some Android development. It's like, okay, you want to do something different with Android. All right. They've got the knob to do that, but you have to go through pages and pages of documentation to find it.

find the right knob. And so if you could just get Android to tell you, okay, here's your manifest with all of the knobs that you're using and you don't realize. And so I'm just curious, is there a way to get nitric to kind of give you the nitric boiler plates that you can go in and make changes?

Rak: Yeah, I think you're talking about extension of, of our providers.

So, so basically we, we have a provider that's already prebuilt. But you can extend it. Right. So there's two ways of extension with Nitric and we've really focused on, on making this better by decoupling it as much as possible from the core Nitric framework. So you either take the Nitric provider and you add to it.

So let's say for example, Nitric does labeling one of your resources when you deploy to the cloud, you know, it applies some standard labels, but you may have a convention that you prefer, or you may want to add extra labels to it. You could take our provider and you could add to it. Without breaking the upgrade path.

And that's one way of extending our providers. But you could also just overhaul the provider and write your own provider instead. That's completely possible as well. Normally I'd recommend you kind of copy and paste from what we've started with. Because that's the easier path. But, you know, it really depends on how ambitious you want to be.

Jonathan: Yeah, yeah, makes sense.

Steve: And Jonathan, I just want to make it clear to the audience a provider is the combination of the cloud that you're provisioning to, deploying to plus the services that you've chosen to, so, hey, I've chosen this compute, this is how we're going to do buckets. This is how we're going to do messaging's queues.

Is that fair, Rack, that just a defined provider for people?

Rak: Yeah, that's exactly right.

Jonathan: Yeah, that's super useful. Alright, so we talked a little bit about a version 1 release. What did that look like? Yeah, so

Steve: Well, apparently

Jonathan: it was overwhelming.

Steve: Well, I think it's a, it's always a funny place for, I mean, I think for someone like us, of us basically saying we have, we've had a bunch of great design partners.

We have users now that are using it in production. What's all the feedback that we, that we want, we want to tell the world that we have a version. That we really want you to use and that's how we thought of the v1 advice And so the number one thing that we had to work on was when we show everybody what we're doing what nitric does They're like that looks powerful.

I love it what happened like the very first like worry is What exactly are you provisioning? What exactly are you creating? How, how can, if I need fine grain control, so in the V1 release, we, the thing we want to do is build the trust that you can see exactly what it's doing. So we built architecture for visualization.

So it's in real time as you're building your app code, you can actually see which resources will be created and the relationships between them. So that as soon as we started showing people that I literally saw attention. Tension out of the DevOps team, tension off of the security team. And. And honestly, I think it's pretty cool.

Like, you know, think about how many people want to build for the cloud, but that they're like, man, I don't know if I want to be an AWS expert or a Google expert, I kind of want to be a great developer expert. There's also this educational component of, Hey, I I'm writing this code. What would it create? So that was number one.

Number two was we did the CLI visualizations as part of this release. So as you're deploying to the cloud, you can see exactly what's being built for that cloud. So not just at the abstraction level, at that resource level, but now, This is the exact resource that's being created in just a nice CLI visualization table format.

Then yeah, our founders took that, that, that moment to say all those little DX things that, that, that was bothering them as we were helping people with projects, we fixed those and really improve, improve that. And then rack did a great job just talking about it, but this custom providers is kind of the key for us.

People love, like we, we believe that 90 percent of, you know. Applications that are going to be building for AWS, Google, or Azure could start with our default provider. But everybody asks us, how do I add this? How do I add that? And we get it because we like to do that too. So just making custom providers actually be easier to build was a big focus of this.

Brack, what did I forget?

Rak: You didn't forget anything actually, but, but I'll just add that the reason why the visualizations has really helped so far is that I'll give you an example. For you know, you. The same example as before, you've you built your application, you've got a bucket in it, you decide to use a third party library, but you forget to delete the bucket from your application code.

The visualizations actually lets people inspect and just kind of spot check their application and be, and see that there are rogue resources connected, or disconnected from the rest of their architecture. And it's kind of a nice way to spot check your application for little errors like that.

Additionally you know, you could be working with non to non non coders as part of your team, you know, project managers or the architecture team who don't really want to dig into the code, but want oversight of what's going on. And so the visualization becomes really useful there because they can spot check it and they can just be like, that's great.

You know, you're, you have an over, you have an overused a resource that's really expensive for our organization or your, you know, you are perfectly using resource as well. So. It's it's been quite useful and that's the feedback we've been getting so far

David: So i've got a couple of questions around that.

So first continuing down the version one discussion I was looking at the languages supported Node. js and python have full support Go c sharp jvm have v0 support. So that means that they're in version zero, but not in version one so far That's correct And then DART's experimental, which you mentioned that you're, you're actively developing that.

So, are you, so do you, well, let me think how to ask the question. Are you, working towards bringing Go, C Sharp and JVM into version one?

Rak: We are. Yeah, it's based on supply and demand. So we have a finite team of resources and we do our very best to keep things in sync. You know, the reason why Python and TypeScript have the support they have is because a lot of our early adopters were those were, were primarily targeting those languages.

So as we see more and more people get familiar with infrastructure from code and with nitric We do think that, that Go and and C Sharp will take a little bit more will get a little bit more attention.

David: A related language question, or maybe not related but what language is it actually written in itself?

Rak: Mm hmm. Yeah, the underlying, the underlying NYTCH framework, sometimes referred to as the membrane, is in Go for performance reasons. And, and maybe our CTO's preference as well.

Steve: Yeah. That's it. Enjoyment of coding. It probably had something to do with it too. Yeah.

David: I'm a Python developer myself, so I feel I have full support.

So I'm happy, but I just wanted to ask about the other ones as well. Yeah.

Rak: Makes sense. The, the, the, the providers and the extension. So the, the application code can all be written code agnostically. So where. You know, we're very happy for anyone to, to bring their language to the to the table.

Jonathan: I, I want to jump in actually and just say, I'll give it back to David here in a second, but it really fascinates me this, this approach.

I don't know if I've ever seen somebody do this before, that we have a partial V1 release based on which language you're using. And so, because the, the, the problem some projects run into is You, we have to bring everything along. And so there's this huge monolithic V1 release or, you know, your, your, your V dot next, whatever it is.

And sometimes that just drags out for months and months and years and years. And suddenly you've got five years of code built up to have to try to massage into a release. And this idea of it's a V1 release if you're using these three languages, and if not use the previous, that's, that's fascinating. Has that worked out pretty well?

Rak: Yeah, I'll be honest. The first time we've released nitric, we. So the, the V zero, I guess, if you could call it that, we, we did have every language in there and it's hard to maintain all of that without constant feedback. And you know, some languages got neglected because they weren't, they weren't used very much.

And so we just made a conscious decision. Let's, let's target, what people actually care about and want to use. And let's talk to our community members and use what they want to use. And a lot of our, you know in production use cases steer the direction of the language choices.

Jonathan: Is the, is the, the nitric code base kind of parallelized in such a way that you can do that easily?

Like there's, there's the module for this language, like maybe there's a shared backend, there's a module for this language, a module for this language, and so it makes it easy to make that?

Rak: Yeah, yeah, it's all, it's all based on gRPC contracts and protos, so we can generate a language SDK and then we fine tune it for the requirements of that language.

To make it the developer experience that the Python X the Python developer expects and the TypeScript developer expects.

David: So a lot of cloud deployments now you're seeing more companies start looking at hybrid cloud. Or even retracting from the cloud where they went and jumped 100 percent cloud.

Now they're like, Whoa, that's too expensive. And they start pulling back. And I know that we already talked about how we can code our own providers and, and do that sort of stuff. But is that on your roadmap of something that you're looking at more of a hybrid deployment functionality?

Rak: Yeah, definitely.

I think it's all within the realms of possibility that that's for sure. The way that we've architected Nitric is so that. Your, your provider doesn't have to be one of them. So your, your cloud provider doesn't have to be one of the major cloud providers. It's, it could be, it's within your control. So we'd be happy to co, co develop and partner with people to do those sorts of those engagements.

I think, I think that's going to be a space that we, we grow into as the requirements kind of flow in.

Steve: Yeah, it's interesting that, you know, when we talk to, you know, innovation centers of larger companies, like, given that we've, we've, we've really delivered for large financial institutions and insurance companies and regulated companies and previous, previous startups, right?

People reach out to people they know, so we've talked to them and it's, I've been fascinated by the interest of, you know, it always starts with multicloud of like, hey, is it possible that I could give my developers a similar experience with it with Google and Azure and AWS? And then the third that that next question is kind of where you're going up if we pulled some of the stuff in house.

And so it is yeah, again, what we've, we've put out with the default providers. No, they're, they're based off of the, the major three cloud providers, but that is where we see this going. A combo of those things of being able to meet people where they want to work.

David: And kind of a follow up question on that that sort of hybrid support, is that something that would make more sense to people?

For, for just like me, if I wanted to try to start contributing, is that makes, is that something that makes sense to do in nitric or would it be better to go like, look at Pulumi and do it there?

Rak: Yeah, I guess that's, that's an, that's an interesting thought. I'm not sure. I think you'd have to have an understanding of Pulumi as well.

So you might be using both together to solve that problem. Again, bringing us back to the infrastructure from code piece that we're bringing to the equation. That's gonna, that's gonna fast track and streamline some of your, your deployment processes. I would, I would say you'd probably end up using both to solve that problem.

Yeah.

David: And to clarify, I wasn't saying not use Nitrate, but I was saying implementing that layer. Would it make more sense to try to implement that later in Pulumi and then use that new API or

Jonathan: When you go to build this out in the source code, are you writing Pulumi source, or are you writing Nitric source, or are you writing both?

Yeah,

Rak: it's gonna be both, but yeah, you would use Pulumi to fulfill some of that contracting, so, yeah.

Jonathan: All right, I am, I'm actually fairly curious. We've talked about this term DX. And I have, I have a feeling that we're talking about the developer experience. You know, kind of going along with this, you know, UX and UI and DX. It seems that, but what, what exactly, like, what does this look like? What are we talking about?

We talk about DX and why does it matter?

Rak: Yeah. Developer experiences, you know, how you interact with the tooling that you're working with to, Bye. To build out your applications. And we've we're really tech, we've really taken a lot of inspiration from tools like super base or oversell. And it's kind of like you know, tools that, that help developers not, not restrict them.

So when I think about super base, you can get a database set up really quickly. It's almost like turnkey so that you're up and running and you're, you're developing as quickly as possible without really. You know, being, being blocked by anything. And that's kind of one of the philosophies that we've tried to take into Nitric.

It's that idea that you're running from day one without too many blockers in your way. Just everything available to help you build your application.

Jonathan: Yeah, that seems like that's important And this is just this is just because i'm not a very good developer But one of the most important things for me and my tooling is to be able to iterate quickly because I make dumb mistakes and if I have to spend an hour waiting for something to compile to discover that I made a dumb mistake It just makes everything so, so much terrible, so much worse.

And you know, if I can discover 15 seconds after I hit the compile button, then, oh, I made a dumb mistake there. Well, I can fix it a lot faster. Not have to spend all day on one single line of code. So it makes sense. It's important.

Rak: Yeah, exactly. That's the idea behind the Nitric CLI and dashboard. So our dashboard experience, aside from the visualizations, what you can also do is you can trigger your application offline.

So the buckets and the queues and the events and the scheduled jobs are all available to you locally. So even before you've hit the cloud, you can experiment with your APIs. And that's that rapid iteration that we're talking about where, you know, normally if you've got a delayed task or a scheduled event, you'd have to wait the duration to test it out.

But with our dashboard, you can trigger it immediately. You can fire off events and topics immediately. To get, to get testing.

Jonathan: Does Nitric, does Nitric have a simulated cloud then to be able to run local tests against?

Rak: Yeah, exactly.

Jonathan: Oh, that's, that's good stuff. I like that. That's, that is particularly clever.

Yeah.

Rak: Yeah. So you're actually running your local code. Let's say you wrote it in node, right? You're just running a node application locally, but it'll register against the Nitric server, which spins up all of the necessary resources locally. And allows you to talk to them and work with them. So, This is all done, you know, we're not containerizing to run this locally.

So you can still test your application with Jest or whatever you're using. Your every, every tool that you use locally, you still use it locally. You're just using the nitric SDK and the nitric server offline to. to help you with your, your DX and your, your app building experience.

Jonathan: Yeah, that's cool. So the, the nitric server, I assume it also has to run as part of the, the, the real world deployment.

Rak: We have a tiny little add on that. We, that we apply to your container that fulfills the runtime aspects of nitric. So. You know, when you're using the SDK and you want to write to a bucket, we have a runtime component that we deploy alongside of your your container, which takes care of those requests.

Jonathan: So there's not, there's not yet another virtual machine or yet another Docker container that has to run that just, that just gives you nitric. Correct. Not

Rak: required. Yep.

Jonathan: That's, that's also very nice. That's cool. You guys have really thought through this. Apparently, it's like you're, it's like you're developers that know what you're doing.

Rak: Well, we've gone through a few iterations to get here, but we're pretty happy with where we're at right now.

Jonathan: Yeah. Yeah. So we've talked about some of this, but what what's on the roadmap? What are you guys looking forward to? And particularly if there's anything that you know is coming that we haven't chatted about yet.

Rak: Yeah. We've briefly mentioned that we're working on Terraform providers. Yeah. And this is because, you know, a lot of ISE a lot of, a lot of people who work in the ISE space anyway, like Terraform and enjoy using it. So we want to, we want to bring IFC to Terraform developers as well. We're working on bringing database support into nitric.

So right now that's a separate piece of work that you'd have to take care of, but we're going to bring some functionality in house. We've mentioned that, you know, we've been working a lot on our documentation for customization. And, and so we're looking to get some community contributions for custom resources as well.

And co, co build support for, for other cloud foundational components that we haven't built so far. You know, like things like AWS recognition or something like that. We'd want to build support for that if, if the community requires it. Yeah, that's I think that's those are the big ticket items anyway.

Jonathan: Yeah, very neat All right. We are we are getting close to the end of the show and I want to ask you guys this and this is a Difficult question because you have to do some set math and that is of all the things we've talked about and that's one set And then the things that you wanted to talk about.

That's another set. Is there a place where they didn't overlap? So the question put a little bit, a little bit easier to understand. Is there anything that we didn't talk about that you wanted to make sure and let folks know about?

Rak: Oh, I think we covered, we covered most of what we wanted to talk about. Yeah, good questions and good session.

Jonathan: Yeah. Steve, anything, anything you want to let folks know about?

Steve: No, I mean really, it's just thanks for the time, please check us out, keep supporting these guys because they're awesome, and yeah, look, look forward to have another conversation about licensing next time, Jonathan.

Yeah, that'll, that'll be, that'll

Jonathan: be real interesting, I do look forward to that. Okay, couple, a couple of wrapping questions I want to ask you then What's the thing that somebody has done with nitric that surprised you the most? Like what's the most oddball or off the wall solution of product that somebody has built with nitric?

Steve: I'll tell you a favorite one. I, I just, I, I, we have a, a, a a user that we've love working with that wanted to build, try all, try out AI one code base, but multiple clouds ai, right? So imagine one code base, but now you can. See what Azure is doing. See what AWS is doing. See what Google's doing and try that same application code with all three.

So that was one.

Jonathan: Oh yeah, that's, that's actually a real interesting use. So that's something we didn't talk about and, and I, I don't know, is that something you guys are doing? Is there any, are, are you doing anything with cryptocurrency or artificial intelligence? You know, our two big buzzwords of, of the year.

I, I,

Steve: I would say we've made a lot of great demos with Copilot. Obviously the GitHub team's really interested in what we're doing. So it's more, it's more about Using nitric to help, you know, imagine using a copilot to help you with your application code using nitric than to be your guardrails for the infrastructure side.

Obviously, those two spaces drive a ton of interest, so we are interested in the type of provider support we can do there. But I wouldn't say there's something there yet, but it's certainly things that we are playing with in the background.

David: Related question then. So does GitHub copilot? Understand Ry?

Rak: Yeah, I mean that a lot of that depends on how much example code we put out into the into the ecosystem. And we're doing as much as we can to, to get code snippets out there that allow the mod, the the, the models to learn from us. So the more we put out there, the better. The more we get from the community, the better.

But. Initial trials with it have been really promising and we think it'll only get better.

Steve: I would just say like giving it a project structure like made a huge difference, right? This is like six months ago when we first started it. It was Hey, if we just give it a little bit of a little bit of a way to go, it does really well.

Jonathan: Yep. Yep. Makes sense All right. So final two questions and I will ask Rack first. What is your favorite scripting language and text editor?

Rak: I use VS code for the most part just, just, I just like it. I don't know if this is any other reason really. And scripting language? Getting more into Python again lately.

So but, but Node as well.

Jonathan: Okay. And Steve, same two questions, scripting language, favorite scripting language and the text editor you spend all day in.

Steve: I mean I'm not doing this as much as I used to VS code, but can I just tell you the one I miss and you're going to judge me? I miss CoffeeScript.

Yeah, that's fine. I was good in it and and I miss it.

Jonathan: Understandable. All right. It has been a blast. Thank you guys for being here and a really interesting project. I'm really excited to learn about it and hear about what happens in the future.

Rak: Awesome.

Jonathan: Thank you. Cheers. Yeah. All right, David what do you think?

Any thoughts on it?

David: That's very exciting so now I'm going to go download it and at least kick the wheels. There may be a role for that. I may not be able to leverage it immediately because a lot of the DevOps that I've been involved in is not cloud based. But it's exciting. It's something that's very interesting, and I really like the ability to run the nitric server locally and test it out and be able to see what's happening, you know, just so that you get that rapid development cycle.

Jonathan: Yeah, I think I don't know how many other frameworks and companies do this. Maybe it's common, and I just don't know. But being able to have a simulated cloud where you test all your code and you fix all your bugs without actually having to talk to Amazon. I think that's brilliant. If, if other companies aren't doing that, they really should.

And I also love that, you know, their, their hello world example is apparently only like seven lines. I, I need to actually go look that up because that, that is impressive. I remember my first Android application and it's like pages and pages and like 15 different files of boilerplate just to be able to get, you know, a side by side window so that you could put stuff in it.

And. So, I like, I like, I like getting rid of boilerplate. It's, it's definitely the way to go. Alright, David, do you have anything you want to plug before we before we go?

Steve: Well,

David: I always like to plug Twit, the Twit Club and ULS. I get to show up there. Actually, I've been there the last two weeks and I'll be there this Friday.

So I might have to remove my guest cohost label and just become a cohost. I think you

Jonathan: can do that. I think that would be fair. And in fact, you know, over, over on ULS, I've thought for a while about making it more of a rotating panel of cohosts rather than primary and secondary. So we'll see what happens with that.

All right. So next week we have a couple of guys talking about the UnPhone, which is a sort of a hobby slash educational device, which I've actually got one somewhere around here. I can't put my hands on it at the moment, but they sent me one to take a look at. It runs. It has been ported to run Nescaster.

Yeah, well, I know, I know where it's at. It's just not here within, within arm's reach. It will run Meshtastic, but I think they're also using it for teaching a a university level course on doing embedded programming. And so, some pretty, pretty cool stuff there. Get to talk to those guys next week. You already mentioned Twit.

The only other thing I will mention is Hackaday. We sure appreciate Hackaday being the new home for the for Floss Weekly. And, of course, I've got the security column that goes live on Friday mornings. Make sure to check that out and all of the other good stuff on Hackaday. And, hey, thank you to everyone for being here.

Those that caught it live and those that are on the download. We sure appreciate it. And we will see you next time on Floss Weekly.

Kategorier
Förekommer på
00:00 -00:00