FLOSS Weekly 738, Transcript

Please be advised this transcript is AI-generated and may not be word for word. Time codes refer to the approximate times in the ad-supported version of the show.

Doc Searls (00:00:00):
This is Floss Weekly. I'm Doc Searls. This week, Jonathan Bennett and I talked with Jared Watts and Nick Cope, who were founding engineers, both with a company called Upbound. And what they work on is cross plane and control planes are this really interesting category and it has to do here with Kubernetes. And they have a gigantic community involved in this thing. Over 9,000 members of a Slack channel. And they're there for a reason. And that reason is why you should be listening to this. And that's coming up next

Leo Laporte (00:00:35):
Podcasts you love from people you trust. This is Tweet is tweet.

Doc Searls (00:00:43):
This is Floss Weekly, episode 738, recorded Wednesday, June 28th, 2023. Cross Plaine your cockpit in the cloud. This episode of Floss Weekly is brought to you by Collide. Collide is a device trust solution that ensures that if a device isn't secure, it can't access your apps, it's zero trust for Okta, visit collide.com/floss and book a demo today.

Leo Laporte (00:01:14):
Listeners of this program, get an ad-free version if they're members of Club twit, $7 a month gives you ad-free versions of all of our shows Plus membership in the club. Twit Discord, a great clubhouse for twit listeners. And finally, the TWIT plus feed with shows like Stacey's Book Club, the Untitled Linux Show, the GIZ Fizz and more. Go to twit tv slash club twit and thanks for your support.

Doc Searls (00:01:41):
Hello again, everyone everywhere. I am Doc Searls, and this is Floss Weekly. This week, joined by Jonathan Bennett himself. Therein the

Jonathan Bennett (00:01:51):
Man, the man himself

Doc Searls (00:01:52):
<Laugh> the man himself who looks short in his tall chair, even though he's tall. So it must be a very tall chair. Big chair. Your high chair. You high chair. Oh,

Jonathan Bennett (00:02:04):
Oh goodness.

Doc Searls (00:02:07):
So how you doing,

Jonathan Bennett (00:02:07):
John? It's a blow blow doc. I'm good. I'm good, sir. It has been a, it has been a good week. It's good to be here again.

Doc Searls (00:02:15):
Yeah, it's, it's great to be here too. So, are, are you familiar with Cross Plane? Which is sort of our focus today.

Jonathan Bennett (00:02:22):
I was not until looking for, looking forward to the show, and I've done some reading and research about what they do, and it's, it's interesting. It's, it's kind of like they liked Kubernetes so much. They decided, why don't we run all the things using the Kubernetes api. And so you can connect to a Ws, it's kinda like a I think of it almost like a back plane on an old school server. And so you can connect to aws, you can connect to Azure, but then you can treat all of those things almost like they're just part of one big Kubernetes instance. And they kind of have the magic software that lets you do that. And it runs on Kubernetes too. So it's, it's kind of Kubernetes all the way down. It looks, it looks pretty cool. I'm looking forward to, you know, hearing their elevator pitch and learning more about the way it

Doc Searls (00:03:15):
Works. We'll take the elevator as high as we can. Yeah, I, I'm, I'm, I'm not familiar with it either, especially, but I'm familiar with the cloud native thing, which I've followed for a number of years, and I'm really curious to know where it applies, you know, where they're doing with it. So, with that out of the way, I wanna bring in Jared Watts and Nick Cope coming to us from Belgium and somewhere on the West Coast, respectively. They, they're both with with Upbound, which is a company working on this. And so I'm gonna leave it up to you guys. You can pick which one comes first. Tell us about yourselves and how, and what you're doing and, and all that.

Jared Watts (00:03:58):
Yeah. How about Nick? I start and then we'll kind of segue into you especially with the recent publication you authored about the project and what we're doing. That might be a good place to start, start after that. But yeah, so yeah, thanks a lot for having us today. Definitely grateful to be here. So my name is Jared Watts. Looks like I'm missing an s at the end of my name there, but, we'll we'll, we'll, we'll, you still know who I am here. I know who I am still at least. So the so I am one of the creators of the Crossway Project, so I've been working on it since the very, very beginning. You know, I've been, been a amazing ride on that, especially as we're growing the community and, you know, getting more adopters of the project and such. I started my career though, at Microsoft, working on Windows Server stuff. First startup I did was peer-to-peer storage network. That was, was pretty fun. I had a, a storage background for a while as well before getting into cloud native stuff, Kubernetes and, and all that. And then starting a couple different open source projects within that ecosystem.

(00:04:58):
And Nick,

Nic Cope (00:05:02):
Hey folks. I'm, I'm Nick. I've also been working on cross plane for a long time, by the way, somewhere in the west coast for, for me is Seattle. I've been in Seattle area. I haven't been working at cross plane for quite as long as Jared, but but almost, almost my background is SRE and platform engineering. So I'm pretty passionate about you know, what we do on cross plane. Cause we're building this tool largely for platform engineers and SRE folks outside of work. Massive pinball player, dog parent. And I think that that report that Jared was alluding to was, I recently wrote a an introduction to cross play for O'Reilly, which came out last month or thereabouts. So if folks want a a, a deeper dive into what cross play is, you can check that out later.

Doc Searls (00:05:49):
So. So this is a Riley book. Does it have a special animal in the cover?

Nic Cope (00:05:53):
It does not. It's it's not a, it's not a book. It's report. It's a mini book. It's something like 30 pages long or something like that. It's got some stripes on the cover. <Laugh>

Doc Searls (00:06:02):
<Laugh>, that's one, one kind of animal. So tell us about the relationship between cross plane and Upbound, where you're working and I assume there is one <laugh>. So,

Jared Watts (00:06:18):
Yeah, definitely. So Upbound is a startup that we formed in the Seattle area a little bit over five years ago. And so within Upbound is where we created the Crossman project. We were working on it internally there you know, amongst, amongst the team of engineers. And then we decided to you know, take, take it to the public and open source it. You know, probably about three or so months after we, after we started working on it, we thought it was a good idea. We wanted to build a community around it. So the relationship is that Upbound and the team of engineers there is the creators of the Cross Lane project. We're still very, very heavily involved in it as well. And building you know, we have a lot of our engineers are still focusing on it, and, you know, we're building a business around it, all that sort of stuff. So that is the relationship is that we're the creators and the stewards of the project still to this day.

Jonathan Bennett (00:07:07):
All right. Hey, Nick, you used a term there, an acronym. We're, we're gonna do a little bit of magic decoding here. What is an s r E and how does that relate to cross plan

Nic Cope (00:07:18):
SRE site Reliability Engineer one of the I dunno how controversial this will be one of the many terms that, you know, folks have had for systems administrators, DevOps people, what you might think of as a platform engineer, as the as the more modern terminology. My, I, I started my career at Google who coined the term sre. So my first jobs was was site reliability engineering at Google, I would say. And then similar Spotify and another company called Planet Labs. But I would say that what I've actually been doing has been more what we would think of as platform engineering today. Mm-Hmm. <affirmative>, so definitely focused on a lot of writing software to build a sort of a productivity platform for my peer engineers at, at these various companies sort of thing. SRE has become pretty broad, so I think it, it's you know, can, anything that involves keeping the lights on sort of can fall into that bucket. So I would say I was at the, the platform building of sre.

Jonathan Bennett (00:08:13):
So SRE is a fancy way of saying CIS admin, <laugh>,

Nic Cope (00:08:16):
Right, right. I went to college for being a CIS admin, but then all of my job titles have been SRE up until now.

Jonathan Bennett (00:08:23):
<Laugh>. That makes sense. All right. I think, I think I want to pitch this back over to Jared and kind of start getting at the basics here. What, what does cross plane do? Is it related to Kubernetes? How is it related to Kubernetes? Like, what problem are we solving with Cross Plaine?

Jared Watts (00:08:41):
Yeah, really good question. And, you know, it's a great place to start this conversation, go a little bit more deeply. So I think, you know, before we talk about the specifics of its, you know, relation to, to Kubernetes and how it runs in cluster and all that sort of stuff, I think it's really the high level you know, way to look at it here is that you know, think about a scenario where you've got application developers in your organization. They have, you know, some service that they're building and they need to deploy it to production. So in addition to, you know, whatever service and business log they're building oftentimes they're going to need some infrastructure and supporting resources. So that could be databases, message queues, buckets you know, you name it, right? Like Amazon has hundreds of services available in AWS and application developers may need access to, you know, any number of those, right?

(00:09:30):
So, you know, there's a couple ways you could solve that. You could give those developers direct access to, say the G C P console or the AWS console. But that's not a good idea at, at all, especially at scale for any number of reasons. You know, then there's some other, other approaches like one we call kind of refer to as ticket ops, where the application developers can open a, a ticket to the S r e DevOps, CIS admin, you know, platform team requesting infrastructure to be, to be made. Then it kind of slows things down while you're, you know, getting, you know, waiting for that to be solved. And, you know, and then that's kind of making the the developers that need their services to get to production, to, you know, just another part of the process, right?

(00:10:14):
And so there's, we found that there is potentially a better way to do that. And you know, it's not the only way to do it, but a better way to do it is to build a platform instead. And this is what Nick was referring to around platform engineers, right? Where you can have a standardized common way for your developers to get the services they need, get the infrastructure they need and be able to ship their code to production and have, you know, a common environment you know, and standardized you know, monitoring, alerting, observability you know, best practices, policy, all that sort of stuff, but be able to kind of give a little bit more power to the developers so that they can come to your platform, get everything they need, get to production, and you know, maintain velocity basically in a standardized way. So that's kinda the high level problem that we're, we were going after there. And then maybe I'll turn it over to Nick to kind of start talking about a little bit a layer below of, okay, so what is crosslane? Then I'm approaching that high level problem. Sure.

Nic Cope (00:11:12):
Yeah. Just to, to follow on from what Jared was saying. One one way that I like to think about it is that I, I, I think what the cloud providers have done is appealing to people, right? You've got this, this small risk board of infrastructure stuff. You could do databases, clusters, caches, all that kind of thing. And then you've got these various interfaces to work with them, to self-service. So you can hit an API directly, or you can use their C l I tools, or you could use their web console. But it's overwhelming. There's, there's so much of it. It's, it's a lot to ask for the average, you know, developer to go and learn all the things that they need to do there. And it's a lot to ask for our SRE or platform team to sort of trust those developers with the keys to the kingdom, to those, to those, you know, 900 services or something like that, that AWS has, for example.

(00:11:57):
So when I think of cross play as, as, you know, putting on my SRE hat, what I would've wanted back in the day is imagine if you could build that experience yourself and take away all the sharp edges and focus and frame it on your organization's concepts and your concerns. You know, everywhere I've worked, you, you build up a culture in the organization, terminology, ways of thinking about the world. Imagine if you could sort of build your own little lens into the cloud with maybe its own COIs and web portals and APIs and all that kind of thing that that framed everything in your orgs concepts. And we see cross play as kind of the control plane for that. It doesn't, it doesn't have those CLIs and web consoles and all that bake in, but it is, it is the heart of it.

(00:12:36):
It is sort of the backbone of building a system like that. And the way we've done that, we kind of saw that Kubernetes was an excellent framework for that. Kubernetes you know, everyone thinks of it as a way to orchestrate containers, but we really thought, thought that the the, the strong point of it was its architecture, its APIs, and the way that it reaches out and orchestrates things based on state put in the APIs. So we thought effectively, why don't we take those parts? Why don't we sort of put maybe the container stuff to one side, take the parts that we think are really strong, the API and the controller pattern, which we can get into a little bit later and kind just apply that to everything.

(00:13:19):
But I think the other thing that's kind of neat there is that there's layers of abstractions that can be built there. So I think one of the key things that we've landed on today in cross Plate is we don't really want to tell you here's what we think a database should look like. You'll said databases were too complicated. So we all sat down and we have the perfect database abstraction, trust us. Instead, we say, we think you should tell us what the perfect database abstraction is for your company, or the perfect cash abstraction, or the perfect VM abstraction or whatever you tell us, what should this API look like? And then you teach us what to do when someone calls api.

Jonathan Bennett (00:13:56):
So is cross plane primarily meant to be a development tool, or is it for deployments, or is it kinda have a lifetime that includes both?

Jared Watts (00:14:08):
Yeah, I, I think a good way to look at that is that you know, part of the design and the surface area and the experience that cross planes exposes is very much conscious of a separation to concerns and multiple different personas. So, you know, when you are as this core platform team that is, you know, servicing these application developers around, around them you know, that platform, CIS admin, DevOps type of persona it's definitely a tool for them to, you know, capture what is important in their platform, what resources do they want to expose what's the configuration and policy that they want to be enforced, you know, all of that sort of stuff. So that's one persona of, you know, the, the type of person and then the entirely different persona of the application developer that, you know, wants to use infrastructure, wants to access it and provision it in a self-service way.

(00:15:02):
But, you know, isn't, isn't necessarily going to be given the keys to the kingdom to do that on them, you know, all on their own. This platform team will define, Hey, here's the configuration knobs that you can turn for your databases. You know, here's what you're allowed to do for your queues and your buckets, et cetera. And so, you know, that strong separation of concerns where the platform people in charge of your infrastructure, the ones that are, you know, likely on call as well for making sure that it's up and running, et cetera. They've got a, you know, a different usage of cross plaine, and there's definitely one of the core personas. But then I guess at the end, it's mostly in service of that application developer persona that needs cloud resources and infrastructure, et cetera, for, you know, the purpose of getting their applications running and deployed.

Jonathan Bennett (00:15:45):
And then I'm assuming cross Plaine also has built into it a lot of monitoring tools, maybe even a, a fancy dashboard. So after an app is developed and deployed, it's out there, it's running on the cloud, then you can go back into cross play and say, you know, what's, what's the health of all of this? You know, how much, what, what sort of resource utilization am I pulling off of aws? Am I going to have a huge Azure bill at the end of the month?

Nic Cope (00:16:08):
Not so much because we think of cross plane as really we think that, that, that's absolutely something that I think a good platform should have. But we've got a pretty scoped charter for cross plane, so we're really focused on just being the backbone, just being the control plane. We are a component of a good platform rather than trying to probably the, the, I would, I would hope or argue the core component of a good platform, but we're not aiming to be the entire platform. We definitely see a lot of people mixing and matching cross claim with other cloud native tools. Backstage comes to mind, for example, to get that like web console experience. You know, we see people mixing and matching up with tools like Prometheus to get monitoring and whatnot. So we're not trying to be sort of the whole thing, but we are trying to be the control plane. The, the, you know, the, the, the core logic, the orchestration sort of tool that the powers all of this.

Jonathan Bennett (00:17:00):
Yeah. So I, I imagine then that you've gotta kind of get cross plane into the scenario while you're still on the whiteboard <laugh>, like you've, you've identified the problem you wanna solve and you're starting to think about how you're gonna architect it. That's the point where you go, Hey, we should use cross plane.

Nic Cope (00:17:15):
Potentially, potentially. I mean, we do see people sort of trying out other things and migrating to cross plane once they sort of realize maybe that we solve some of the pain points that they have. Often, often the pain point is sort of getting back to what we were talking about before. People might have some other way of, of managing their infrastructure, but they don't what they're using doesn't lead too much into self-service. They start to think, man, I don't really, they being a platform team, or SRE team or something like that. So start to think, man, I'd really love it if my developers didn't have to raise a ticket to me to ask to get some infrastructure. I think of this along to axes, right, safety and efficiency, sort of the things that Jared were getting at before is if you just give everyone straight on access to the a AWS Cloud console or Google Cloud console, it's somewhat efficient, right?

(00:18:03):
But it's probably not as safe. If everyone raises a ticket to you that's probably pretty safe. Cuz you could apply your best practices as someone who knows the cloud really well, but it's not very efficient. Whereas if you offer them a api, you offer them a control plane that you've designed so it doesn't have any sharp edges, well, hopefully if you've designed it well, it doesn't have any sharp edges, then they can go through that and they're getting, they're getting the efficiency, but they're also getting the safety as well. They're not having to go and, you know, you're not in the critical path as an SRE when a developer needs to say, Hey, I'm deploying an app and I need a database that's gonna support my app for its entire life cycle. Or a queue or cluster to run it on whatever you need when you're building apps.

Jared Watts (00:18:43):
Yeah, Nick, I I really like that that, you know, thinking about that on, on the two axes, that's, that's a really good way to look at it. And then something to kinda add on to, to what you're saying there is that you know, when you think about the way that cross plane is exposing all of its resources that you can, you know, go and provision, you know, all this cloud infrastructure and you have these abstractions you can define on top of it for your devs, et cetera, you know, at the end of the day, it's, they're all really APIs that you're exposing, right? So it does kind of facilitate a high level of integration or reuse, you know, whatever from other projects in other, you know, the tools in the ecosystem. It's not like there's one door, one front door into how you use cross plane, and that's the only way you can do it. It's, well, there's an API surface of surface area similar to Kubernetes in general, where you can use a whole, you know, ecosystem of tools or processes or methodologies or, you know, user interfaces or whatever. So it's nice to be kinda API first API driven, and then that opens up a lot of doors for how one could access and, and consume this, this platform that you're building with Cross Plan.

Jonathan Bennett (00:19:52):
So you're, hmm, if you're, if you're API driven, is there a, is there a graphical client that comes with cross plaine, or do does a developer kind of have to bootstrap and build his own little gooey to even be able to get started? It, it's, it's fascinating. It's kind of a, a different it's a different approach to things, I think, than most of us are used to.

Jared Watts (00:20:12):
Yeah. Nick, maybe you can, we can add on to this, but the simple answer there is that, you know, it is all of the entities within Cross Plaine that represent, you know, real world objects out there, such as databases and buckets and stuff all of those entities within the Cross Plains API are, are captured and represented in the same way that other objects within the Kubernetes API is so, you know, pods, config maps deployments, those typical primitives that you have in the Kubernetes api cross Bain extends all of that and adds, you know, cloud SQL or, you know, Amazon's Kubernetes service or, you know, all these sort of things like that. So that's the, the, however you are already accessing your Kubernetes you know objects in Kubernetes API surface area you know, you could use those exact same tools that, that to access Crosslane as well. Cause it's just an extension of the Kubernetes api,

Nic Cope (00:21:14):
Right? This is, this is definitely one reason we see folks coming to, to cross plane as well, is what I would think of as tooling consistency. If you're a shop that's already using Kubernetes, you might already have a web portal or a dashboard that's able to sort of work with anything of the Kubernetes api. And you've probably got a cli co cuddle being the, the one that sort of comes with Kubernetes that people use to interact with that particular api. So all of those things just work with cross play as well. So folks feel that that's kind of nice cause they can just add this capability into their existing platform without having to sort of buy into cross an entire sort of cross plate ecosystem.

Jonathan Bennett (00:21:49):
So when you go to, to use Cube Cube CTL to, to create and deploy an app, you can just define extra resources that Kubernetes normally has no clue what you're talking about. But because you've got cross plane in the mix, it just, it just works. Is that, is that how this is put together? Cause that's pretty cool,

Nic Cope (00:22:08):
Right? Right, exactly. And then it's interesting, like a lot of the time I actually, I actually found this while I was working in this report recently, people, kind of, people who've used Kubernetes a lot since an intuitive goodness to it. So a lot of the reason that we hear, while people, you know, a lot of, you know, a lot of people don't like the complexity and whatnot, but a lot of people are sort of are like, I like the way that Kubernetes work. And then when you go and look at why that is, I think a lot of it is you, you tell Kubernetes about your desired state and Kubernetes is a, a long, you know, the API server, Kubernetes is a long running process. It, you know, runs on a server somewhere, and it's sitting there constantly being like, okay, I remember that Nick told me I want this database to be 30 gig and every, I don't know, configurable interval, every, let's say 60 seconds, it's gonna go and double check, is that database still 60 gig?

(00:22:58):
And if someone goes around cross plane or around Kubernetes, it goes to the cloud and says, actually, I want this database to go be a hundred gig. Now cross plane's gonna notice and be like I was told the design stage should be this. I will make sure that I'll reset that change. I'll set it back to actually forget whenever I said originally, 20 gig or 30 gig or whatever it was. So I, I think this effectively what people want are, is they want a control plane for, for managing their infrastructure. And Kubernetes is just a really good control plane. So I think that's kind of what gets people excited about. I don't know if it's worth also like I don't have a whiteboard here, but I do want to kind of try and use my hands maybe though that won't work for anyone who's not watching the video.

(00:23:39):
There's kinda two layers to cross plane, right at the, at the, at the core layer, at the base layer, we have what we managed resources and a managed resource, I think of that as a high fidelity representation of something in the cloud. So AWS has a, has an RDS api that's their sort of SQL database api. We take all of those and we bring 'em into the Kubernetes API server. So at the base layer, you can say, Hey, cross played, I want an rds. And you make an API call to it that looks just like making an API call to aws. And then what Cross played is gonna do is make sure that AWS is always configured the way that you talk cross played. It should be configured, it's gonna sit there forever. Always making sure that your design state is what AWS is actually like.

(00:24:22):
If anyone changes in aws, leads it in aws, does anything cross plates sitting there and it'll go Uhuh, I'll correct that. So that's kinda the base foundation. So that gets you some of the benefits of sort of having a control plane that you control to, to keep your infrastructure in your desired state. But it doesn't help with complexity and it doesn't help with you know, cognitive challenges of like, you know, basically I think the RDS API has something like 50 configuration fields on it. That's a lot for a developer to remember. So then above that managed resource layer at the heart of Cross played, we have effectively abstractions. And that's where a platform team can come in and say, here's how I want frame a database. I work for Acme Co. So I think it should be an ACME database. And maybe for weird historical regions, my organization calls for AWS would call a region or a zone a location or a place or something like that. So I can just change that terminology in my api. It's called a place, and my developers can think about it the way that they've always thought about it. And when someone makes that API call, cross Plain's gonna resolve that to some concrete high fidelity managed resources, and then those are gonna go and get applied to the cloud. I dunno if that all made sense. It's kind of a lot to unpack. That's

Doc Searls (00:25:37):
Great. Well, <laugh> well, I, I, I have some questions about the actual users. You've got a, you've got a a, a Slack channel with 7,500 participants, and I'd really love to know what the conversation there is. But first, I have to let everybody know that this episode of Floss Weekly is brought to you by Collide. Collide is a device trust solution that ensures unsecured devices can't access your apps. Collide is the big news. If you're an Okta user, collide can get your entire fleet to 100% compliance. Collide patches, one of the major holes in zero trust architecture, device compliance. Think about it, your identity provider only lets known devices log into apps. But just because the device is known doesn't mean it's in a secure state. In fact, plenty of devices in your fleet probably shouldn't be trusted. Maybe they're running on an out of date versions, or maybe they've got LY credentials lying around.

(00:26:41):
If a device isn't compliant or running the Collide agent, it can't access the organization's SaaS, apps or other resources. The device user can't log into your company's cloud apps until they've fixed the problem at their end. It's that simple. For example, a device will be blocked if an employee doesn't have an enough to-date browser. Using end user remediation helps drive your fleet to 100% compliance without overwhelming your IT team. Without Collide IT teams have no way to solve these compliance issues or stop insecure devices from logging in. With Collide, you can set and enforce compliance across your entire fleet. Mac, windows, and Linux Collide is unique in that it makes device compliance part of the authentication process. When a user logs in with Okta collide alerts them to compliance issues and prevents unsecured devices from logging in, it's security you can feel good about because Collide puts transparency and respect for users at the center of their product. To sum it up, collides method means fewer support tickets, less frustration, and most importantly, 100% fleet compliance. Visit collide.com/floss to learn more or book a demo. That's K O L I D e.com/floss.

(00:28:05):
So, so guys, I'm, I'm, I'm looking and on your homepage on the cross plain homepage, that is you scroll down and there is 7,500 Slack members, it says, and I, I'm there's, there's Intel, Travago, Accenture, Mercedes, ibm, Verizon, and, and they kind of this kind of acute hack there where they some disappear and others reappear this kind of beris. So I'm wondering what goes on there. I mean, I'm, IM curious to know what, even if you could pick one of them and walk us through what a typical issue might be or what some of the participants there are, you know, bringing up and where that goes. Does it go into code, for example? I'm just wondering.

Jared Watts (00:28:46):
Yeah, it's a really good question, doc, and that kind of gets to probably a number of aspects of the community that we're building up around this open source cross plan project. So, you know, slack is one of the channels that we have to engage and collaborate together as, as a community on the project. And I think actually that our cross plan.io website there for page there is, is a little bit outta data. I think it's over 9,000 folks on Slack now chatting and talking, et cetera. But you know, we have, it's pretty typical for folks to you know, think about adopting the cross plan project and kind of the phases they, they go through. It's pretty typical that folks will, you know, first they hear about crosslane in some way like, you know, a highly popular podcast such as, this is a good example of folks hearing about it, right?

(00:29:32):
For the first time they get interested, they come check out the, the website there, and maybe they get, dip their toes in the water with some getting started guides to get a initial feel of it's like to manage infrastructure manage their cloud resources from a control plane architecture like crosslane. And then often, you know, if they wanna start kind of understanding, okay, what else can I do here? Or, you know, Hey, I'm running into an issue here, or, well, Crosslane is, you know, seems like it's got a lot of power, but what are some more things I can do with it? Or how do I solve this scenario that I'm, you know, is important to my organization? And so folks often join our Slack channel, and that's where we have a lot of high fidelity, high bandwidth conversations of, you know, folks kind of sharing their ideas you know, kind of giving us good feedback you know, asking about new things that, you know, we as an engineering team that have been working on this, maybe haven't even thought of yet, right?

(00:30:21):
So it's, you know, a very good mechanism to connect to the community and, you know, collaborate on all this sort of stuff and, and really kinda make it you know, it takes a village, right? So kind of having a, a larger base of folks that are contributing in any number of ways to the project and discussing on Slack is, is, is just just one of those, right? Nick, is there any more you wanna add on that in terms of, you know, what people are using cross plan for? I think you had some, some good stuff that you kinda talked directly to people about that very recently on

Nic Cope (00:30:51):
Yeah, I could, I will say, I will say Jared <laugh> has worked on our customer community team more than me. So I I think you might have some better ideas, but the one that comes immediately to mind right now that we see a lot of folks setting up is this I think a term I've heard for it a lot is landing zones. So really big enterprises, a pattern that we're seeing you know you know, fortune 100 companies. A pattern that we're seeing is that there are probably multiple central platform teams, but one of those platform teams is kind of the, maybe the core platform team. And their job is to just set up an environment that a development team will work in. So let's say there's some new fairly large development team, fairly large project working on a wing of the business.

(00:31:39):
You know, maybe it's, maybe it's like a, a, a car configurator website or something like that. You've got like a, you know, let's say 20 plus people in that team working on that. Those, those folks will often these days get their own for that project, for that team, their own entire AWS account or Google account or Azure account. And that'll lead its own v VPC network set up in it. It probably maybe needs some subnets, some IM rules, just a lot of foundational infrastructure. And then, you know, this comes even before you ever start setting up databases and queues other things that actually power your app. This is just like the place to run your app in the first place. So a lot of what we see folks coming to us is they want people to be able to self-service and say, hi, I would like one of those landing zones.

(00:32:22):
I'd like you to send me up an AWS account. And vpc, it's subnet and science roles and all that kind stuff in the standard way that is compliant and approved by my platform team. But that's, that's a lot, you know, for the average developer that's, you know, without cross, that is gonna involve, you know maybe making 20 different API calls or going to the AWS console and booming ding into 20 different pages and setting up a lot of fairly complex you know, setups that make deep systems knowledge deep networking knowledge to make sure that you're doing well, as well as just deep knowledge and what cloud provider are doing. So with cross plane, what we'll see the platform team doing is saying, Hey, we've taught cross plane, we've taught our control plane about this concept called a landing zone. And when you ask cross plane for a landing zone, which maybe has 15, 20 configurable knobs on it, maybe what region should it be in?

(00:33:17):
Is it a big one or a small one or something like that? We'll just go and set up all those things for you on demand and why, when I say we, I, I'm saying cross plane's gonna do that. You use your coop cuddle or your web console or make an API call somehow to cross play and say, I'd like a landing zone cross plane says, cool, I know what that means. The platform team taught me that a landing zone means I need to go and create U native S account. I need to go and create you a V pc. I need to go and create you couple Im roles, some subnets, all that kind of stuff. And not only do I need to create them, but I need to make sure they stay this way forever. I need to monitor them for their entire lifecycle and make sure that they always look the way that the platform teams said they should look, if anyone changes them, I should change them back. And so this is, this is a pretty common thing, especially folks early in their cross plane adoption because after that, eventually now that you've got that landing zone, then you can start to, you know, kind of build a an infrastructure catalog almost of, you know, things that you could go and add to that landing zone to actually power your app, the databases, the queues, all those things that you think of as a, you know, modern cloud application being powered by,

Jared Watts (00:34:22):
You know, in that scenario that you're explaining there, Nick of, you know, offering a landing zone to, to developers and new teams and new parts of your org or business units or whatever that are, that are getting off the ground in your organization. I think a real awesome way that I continually hear from our adopters and people in the community, et cetera of, to like, to a way to really you know, like, see the value that provides is that we commonly hear from folks and their people that, you know you know, give talks about this you know, at events such as CubeCon, cloud Native Con, and, you know, other events like that, open source summit, whatever is that they often talk about the time for new projects to get spun up, or the time for services to get deployed, et cetera.

(00:35:06):
It gets drastically reduced. So that scenario Nick was talking about, about spitting up a new landing zone and all the complicated machinery, et cetera, there a lot of folks have given us that feedback that, hey, this list, this used to take weeks. Maybe we can measure it in months to get a new landing zone spun up in a new team up and running, and now we can measure it in hours as opposed to weeks and months. And so people are like drastically accelerating their, their, you know, journey into the cloud and, and getting things up and running much, much faster with this, this pattern here, the reusability and the, you know, the standard infrastructure catalog and all that sort of stuff. And every time I hear that, it's, it's, it's definitely something that speaks to the value of what we're building here,

Nic Cope (00:35:45):
Right? It's, it's really all about that, you know, safety and efficiency overall what, what these platform teams want to do, they want be a force multiplier for what they're for the teams they support. They want to help them go faster and be blocked less in getting the things they need to be productive, but they want 'em to do it safely. They, they want 'em to do it. You know, with, with some guard rates.

Doc Searls (00:36:07):
I'm curious about, sorry,

Nic Cope (00:36:10):
Go ahead. I, I, while talking through that scenario, I completely I completely forgot about something. Earlier when we were talking about, you know, web consoles and CLOs and things like that. A really common pattern that we see for people wanting to to interact with Cross Plate is actually putting all of this configuration in a GID repository. You know, what people would call GI ops these days, I feel like we'd be doing it my entire career, but you know, the, the, the term these days is kiddos. So something that we commonly see is, you know, I, I love a good web console. I think that people learn really well from web consoles. I think that they'll always exist. But once you've learned those concepts, what we see from people is they wanna say, okay, my team has, my, my platform team as a developer has defined this concept of a landing zone when I, you know, my W accounts and all that kinda thing.

(00:36:57):
When I want one of those, what I'm actually gonna do is go to our central landing zone repository, and I'm just gonna commit a bit of YAML basically to that document, to that, to that get repo, rather a YAML document that just describes what my landing zone is. Is it on the west coast or the East coast is a, Europe is a big, small, et cetera, et cetera. Is it purple or green? And when they commit that to gi there's plenty of tools out there already that can seek that from GI to cross play. There's plenty of tools that could do that. Cause they all support the Kubernetes api. And then you get this nice sort of be all the benefits of revision control for your, for your infrastructure. Someone else, your team can go review it and say, yep, that looks good. That's exactly what we want from Atlantic Zone. And then you're unblock to crossway spring into action.

Doc Searls (00:37:37):
So, so I'm, I'm wondering about we haven't talked yet about Upbound, your, your company, both of you work for Upbound and so tell us about the company, how it relates to how it relates to cross playing, what your role in it is versus not, versus, or within the community. Seems like there's a lot of possibilities there.

Jared Watts (00:38:01):
Yeah, definitely. There, there is. And so, you know, we just briefly mentioned earlier, right, that you know, Upbound is the creators of the Crosslane project. We started it you know, for, so almost, almost five years ago internally at Upbound and then, then made it a public open source project to build like a big ecosystem and community around it, et cetera. But then, you know, beyond that like Upbound is, is building a business around Crosslane, right? We're building a product and experience around cross plaine. So, you know, one way to look at this is that what's good for Upbound as a company and as a business sorry, what is good for Cross as a project is going to also benefit Upbound as, as a business as well, right? And so this, this isn't our first open source project.

(00:38:42):
We have we are also some of us that created the cross plane project also created another popular cloud native project it's called Rook. And it's all about store storage orchestration in the Kubernetes and ecosystem. And so, you know, we understand the value of building a community, building a strong you know, strong project that, and technology and, and having a strong vision there and a charter that's well articulated and governance and all that sort of stuff, right? So, you know, we've got something I think that is well defined around cross plaine and the open source community and project and all that sort of stuff. And then Upbound as business you know, has a lot of opportunities to build on top of that and, you know, build a whole number of things that we can get into. But just a couple off the top, top of your heads are, you know, all sorts of enterprise integration and things that you need to run at scale.

(00:39:31):
Things that you need to, to you know, run across massive organizations you know, auditing and, you know, common logging, billing, metering you know, cost control, you know, compliance, all that sort of stuff. So, you know, there's a nice core of building a cloud native control plane and managing infrastructure and everything that's available in core cross plane. And then enterprise scale, you know, fleet management type of needs, et cetera. And a wonderful user experience and all that sort of stuff is something that you know, we believe is, is well solved with vendors within the Crossin ecosystem such as outbound,

Nic Cope (00:40:02):
Right? So Cross Plane actually is has its own lightweight package manager built into it. It's Kubernetes space package manager, but this actually allows you to do things like, say, I need AWS support, please cross play. And then you, you basically just tell it, you give it a couple of lines again, well, let's say or make an API call that's say, please create AWS support. And then the Cross Play package manager is gonna go download what we call a provider, which extends cross play with AWS support, or you know, it's not just Clouds. It might be GitHub support for managing GitHub, or it might be SQL database support for actually like going, creating rows in SQL tables and things like that. So Upbound has a marketplace, which you can loosely think of as like the docker hub for cross plate. It's a place that you can go not just to find Upbound providers and extensions to cross plate, but the whole communities, providers and extensions to cross plate.

(00:40:51):
It is a, is a cross plate or aware marketplace. So if you want to go and look at, you know, the awcc two provider it'll give you all the documentation for that. I'll teach you about all the things that that provider could do, which show you how to install it, all that kinda stuff. And then I would say abouts you know, other key product is, is Upbound itself, which as Jar said, is all about running cross played at scale fleets of cross plates. We definitely tend to find that, you know, these Fortune 100, these big companies they don't just need one cross plane. They tend to find that they need, you know, a bunch of different control planes. Maybe, maybe they have a control plane per team, or maybe they have a control plane per region, et cetera, et cetera.

(00:41:32):
And at that point, you know, we there's a lot of moving parts to a Kubernetes control plane. Cross plane uses a lot of parts of a Kubernetes control plane. I think a common complaint about Kubernetes is it is challenging to deploy and keep running. That becomes more challenging if you have 10 of them or a hundred of them or something like that. So this is where our outcomes in it's sort of a, you know, a we'll take care of that for you sort of thing, whether you're doing it you know, wherever you need to do it.

Doc Searls (00:41:57):
I, I have a a possibly trivial question, but and I were talking about this yesterday, we were wondering what your symbol there is that looks like a Popsicle with a Rainbow Popsicle. But that may be a technical thing. I don't, I don't know. What is that?

Jared Watts (00:42:12):
Yeah, with that that's, that's been the, the logo since the, you know, very, very first day of the project. And you know, something that's, that's nicely enabled with cross plan's approaches, you know, it's, it understands anything with an api. You can integrate with cross plan in some way and have cross plane provision resources there, management you know, manage them, all that sort of stuff, right? So multi-cloud is very much something that is a focus, or at least something that crosslane enables of, okay, I need to provision resources in aws, maybe Microsoft Azure, maybe Alibaba, you know, whatever it may be. So there's multiple flavors to the cloud. And then, you know, that Popsicle there is a, a, a huge representation of all the flavors of a multi-cloud that you can, you can have with Cross Plaine.

Jonathan Bennett (00:42:56):
All right. I wanna, I wanna pick this back up and go in a slightly different direction, although it's related, I promise it is. But first question, to start off with, what, what license is all of this under obviously we're talking about open source, which, which of the license did you guys choose for cross plane

Jared Watts (00:43:11):
Apache two? We tried to, you know, we picked a very permissive license and, you know, there's really, you know, PE be, so we donated the project to the Cloud Native Computing Foundation, which is, you know, a subset of the Linux Foundation. And so, you know, part of that, you know, donating the project to the C N C F is, you know, that it needs to have a permissive license. So Apache two is, is the license there that, you know, allows, allows folks to, to do a lot with it and, you know, build their own businesses around it and, you know, all, all that sort of stuff that, that permissive license like APACHE two allows you to do. Sure.

Jonathan Bennett (00:43:44):
So does CNCF actually provide the governance for the project?

Jared Watts (00:43:48):
CNCF provides a lot of things. They're, they're, you know, there's a lot of really mature projects in there. They provide a lot of services and you know, special interest groups and all that sort of stuff to help drive and define your governance and you know, contributor strategy and all that sort of stuff. So they, they help a lot with that, but they're also fairly hands off in the sense that the maintainers of the project can make the decisions about how they want to implement their governance and how they want to define, you know, how the project is run and releases and all that sort of stuff. So the, the C N C F has a lot of services in and you know facilitates a lot of that, but at the end of the day, the project gets to choose a lot about the specifics about how they run.

Jonathan Bennett (00:44:31):
And so how many of the <laugh> the, the people that make those decisions, your, your maintainers how many of them are part of the company versus from outside? Just curious.

Jared Watts (00:44:46):
Yeah, yeah, really good question. So I think on the core maintainer team of Cross plane, I think there are five total maintainers right now. And four of those are part, are part of Upbound that have been engineers there for, oh, sorry, no three are are Upbound engineers or folks that have, have, you know, been contributing to it for a while. One is a, a new, our newest maintainer that works for Nokia. And then another one is someone who is still a good friend of ours who, who worked at Upbound before, but now has is has gone on to work at a at you know, infrastructure IOT type of company. So it's like, I guess three outta the five are currently at Upbound right now.

Jonathan Bennett (00:45:23):
Okay. So is that right? That's

Nic Cope (00:45:24):
Right, Nick. I think so it's something like that. Definitely two of the maintainers are not up bounders. But it's also important to note that as Jar mentioned there, that's core cross plane, right? So cross plane as a overall ecosystem exists over a lot of repositories. So we have an entire GitHub org cross play country that has a lot of community driven providers, and those providers that add arguably kind of the, the core, the base functionality for cross play things like connecting to AWS or any particular cloud, any particular thing that crosslink can manage. A lot of those are managed by completely not upbound people sort of thing. The, the, within the broader ecosystem, it's quite a diverse set of maintainers.

Jonathan Bennett (00:46:07):
Sure. So something I'm curious about is, let's just say that hypothetically Ling there is a new cloud provider that announces a really nifty service. What does the process look like to, to making cross plane aware of that? Is that something that Upbound would do? Is that something that, you know, members of the community community could pay Upbound to do? Or do you normally just see those things come from somebody scratching their own edge?

Jared Watts (00:46:38):
Yeah. Dick, do you wanna take this one or, I'm happy to also

Nic Cope (00:46:42):
I, I'll take a shot and then maybe you could you can add your flavor to it. Specifically saying a new cloud provider popped up is interesting, right? Because it depends if a, if a new cloud provider just poofed into existence today at the scale of aws you know, that's, that's a, that's a pretty big hill to climb, right? If they, if they, if they showed up with like two or three services sort of thing, that is is fairly straightforward, right? So adding support for a new cloud provider basically means building one or more cross plane providers from a software engineering perspective for the folks who built these providers, which are, you know, maintainers of cross plane, kind of anything that the cloud could do. So I'll just stick with my RDS example. We provide a little interface at the software level that says, teach us how to create, read, update and delete this, teach us how to credit, and then we'll build everything else around that for you fairly automatically.

(00:47:37):
But even just teaching cross plane how to crunch things becomes quite a challenging problem if there's like 900 things to credit in AW s for example, right? So for what we've done so far when we've sort of come into this world, obviously after cloud providers, there's just a lot of surface area is we lean on a con combination of generation. So we basically look to other systems that, that sort of know how to orchestrate the clouds and generate code around them combination of that with community member contributions. But we have also found that it does help, it's not critical, but it does help with quality to have sort of a core team of people stewarding all those contributions. So Upbound has some, what we call official providers, which are basically providers that Upbound has put together, where we staff a team of people.

(00:48:25):
Those providers are open source. They're they belong to Upbound, they're in our GitHub org, but they are Apache too. That's, we have a team of engineers who work on those and they steward them and make sure they're high quality. But we get a ton of community contributions there. And we also leverage a lot of co-generation to make it faster to build those providers. We also have a bunch of what we would call community providers, and those are the ones that many of them just have no about involvement at all. A timber community, people are coming together and scratch their own niche. They tend to be maybe a little bit more the long tail rather than the behemoths like AWS or something So if a little new cloud showed up tomorrow that only a couple of folks want, probably a community provider would start from that if they would, you know, get the ball rolling there. And if that cloud provider became something that hundreds of thousands of people were beating down our door saying, we really want that, then it might sort of you know, become an efficient provider and get some more resources put on it.

Jared Watts (00:49:17):
Yeah, I think it's really nice that you know, this ecosystem and community we've built right definitely facilitates those, that type of engagement from contributors and from the community to scratch their own niche, right? And then like one good example that I've, I've saw kind of recently is you know, digital Ocean you know, the provider that's, that is now in the, the cross by ecosystem and, and helps you provision and manage resources in digital ocean that was driven by folks at Digital Ocean that, you know, saw some value in, you know, integrating into and having support for Digital Ocean from within cross plane. And you know, went and got it bootstrapped and got support for some of the critical resources there. And, you know, have it published and ready as well too. So this nice spectrum of community and code generation and cloud provider themselves involvement and Upbound involvement as a, you know, as a vendor and other vendors as well. It's, it's nice to have kind of a spectrum of ways to solve a fairly high, fairly large surface area of, you know, things you can do in the cloud and things with APIs, right? It's a big surface area, so it does take a village once again,

Nic Cope (00:50:20):
Right? And to be a little bit more concrete on the, on the code generation stuff a lot of the, the incumbent, you know, cross plane's relatively new compared to aws, compared to Google, et cetera. But there are other open source tools that know how to talk to Google that they've had years and years of, or talk to AWS tools like Terraform, for example. So cross plane you, we have tooling where you can just basically point the tooling at a Terraform provider and say, Hey, here's a Terraform provider. Please make a cross plane provider for that. And it'll automate a lot of that. Not all of it, but a lot of it.

Jonathan Bennett (00:50:48):
Very cool. So one of the things that AWS spends a lot of time on is security and permissions. Like I, I've watched over the, over the years, when I first started with aws, it was very simple. You created an Amazon account, and then you, I think you generated a token and you used the token, and that was it. You were done <laugh>, it's now a bit more, a bit more complex than that with, with IAM and all of those things. Now, when we talk about cross plane, I imagine that there's kind of two sides to this, because you've got your cross plane configuration where you set up some permissions inside of that. But then I assume there also has to be kind of an outward facing security component where not just anyone can talk to your deployed cross plane, and you probably have roles set up there too. What, how does, how does that work? What is the security aspect of cross

Jared Watts (00:51:39):
That? You pretty much got it right there, Jonathan, right? Where there are gonna be multiple layers of it. So, you know, that first layer is okay, how does, you know, whoever the, the cross plane provider, let's say, that is going to be making the API call, you know, over the wire to the cloud providers you know, surface area of, of API and, and their control plane you know, it needs some credentials to do that. It needs to act on behalf of somebody, right? And so typically within the providers, we try to support all the majority of the, the important authentication schemes and authentication mechanisms that are available for that. So for aws, you know, you can use, you know, long term Im user credentials. You there, there's support for what's called I R S A, which is, you know, IM roles for service accounts that integrates directly into Kubernetes.

(00:52:26):
You can use a, you know, assume identity and web identity, that sort of stuff too. But then you get above that next layer, right? Where you've got cross plaine, it's got certain credentials in a certain way you know, in that to be stored in a number of ways as well. Maybe it's in, you know, HashiCorp Vault or something like that too. But you know, it's gonna be using those creds to make the actual calls. But then above that access to cross plaine is, is the next layer, right? And so there we typically rely on the r a scheme in, in functionality that is built into Kubernetes. So, you know, you can provide you know, various entities and subjects that have access to the Kubernetes cluster. You can provide them you know, role-based access to, you know, with certain verbs to certain resources.

(00:53:09):
So, hey, you know, this, this entity can only do create or updates but maybe not delete on this particular type. You know, so our back access, that's pretty standard in Kubernetes is the, the major way to do that. But then a really important point here is that there is that next layer once again where, you know, in cross plan you can directly create an Amazon RDS database or a Google Cloud sql, but you can also define your own abstraction that composes together multiple resources and offers that as a simple, a simplified API to your developers too. And there's r a at that level also. So at the end of the day, your developers only get one specific you know, access through R a C to a high level ACME company database type, and they don't get any of that access to the lower level primitives of like RDS or Cloud sql. And they certainly don't get access even lower than that to, you know, the cloud account, cloud provider account cred credentials and things like that too. So it's, I I look at it as in three layers, and that's kind of the scheme that we use there.

Nic Cope (00:54:13):
Do wanna point out really quick

Nic Cope (00:54:18):
This was a big part of cross play and choosing to build on Kubernetes, right? We talk about Kubernetes being a great control play and having to be bought for containers, but great for everything else. All of this role-based access control everything in cross plane is fully encrypted, authenticated, or authentication authorization. We just got all of that for free by picking the Kubernetes sort of infrastructure to build on. So that also means a lot of interoperability with other tools, like Jared mentioned, I R S A as a way to authentic AWS that just came cross because roughly Kubernetes,

Doc Searls (00:54:55):
I wanna get back again, getting a little bit on time here, but I wanna get back to the the, the C N C F because it's interesting to me like the, the, the C N C F has this wonderful gigantic graphic I think most my laptop certainly can embrace it all. The, the cloud native interactive landscape and has changed a lot over the years. I I went to their conference Linux Foundation conference in San Jose in 2018. I just checked my calendar to see what it was. I just, I just located time as before the pandemic, when I still went out. It was that kind of thing, right? And they still had conferences. But it's changed a lot and it has so many variables you can add. You can say which ones are open source and which ones aren't. They have one here, the cards from China that's relatively new. And two things. One is where you fit in here and also how, how the cloud native landscape, which you're part of in a big way, I think has changed over the last last few years. And what changes can we expect? Because it looks to me like it's getting, it has more categories getting more complex. It's almost becoming three dimensional

Jared Watts (00:56:06):
<Laugh>. Nick, do you wanna answer how we fit into that? And then I'll talk about how it's changed over time.

Nic Cope (00:56:12):
You know, I actually I think that you are the best one to handle this. I remember that in the literal box that we're in, they put us in one of the fairly central, was it like orchestration or something like that? Boxes on that diagram up there next to Kubernetes, if I recall correctly. Yeah, <laugh>.

Jared Watts (00:56:26):
Yeah. Yes. That's where it is. Yeah. Yeah. That, and that's not, that's it, it's kind of hard to place cross plane into, its a, a, a existing category cuz in some sense it's, it's doing some new things and, and, you know, bringing control plane to the masses and, and kind of defining a new category of its own a little bit, but it's not, you know, it's not grossly incorrect to have it at the, or, you know, as an orchestrator in next to Kubernetes as well. Sort of like where, you know, if you think about, Hey, I have a control plane and I need it to manage certain things. Kubernetes manages your containers and your container workloads, et cetera, and things that it needs for that. And then Crossman extends that enables you to manage the world. <Laugh>, you know, a lot of things there.

(00:57:06):
So it orchestrates and deploy and all that sort of stuff. So it does, it's hard to fit it into this particular box there, but, you know, there's definitely reasons why, why it landed in, in that particular box that, that it, that it landed in. And then, you know, the, the cloud native landscape is, is actually really interesting doc to me because you know, we've been a part of the cloud native computing foundation for quite a while and especially with our earlier open source project that was one of the first few projects to graduate from the C N C F, so very, very early on. But, you know, it's, I think it speaks to that there we're onto something that's, you know, this, this cloud native way of, of running our applications and you know, getting things deployed and, you know, everything that comes along with it is very interesting.

(00:57:50):
And there's a lot of, of ability and a lot of problems to solve, and a lot of, you know, interesting capabilities and functionality that exists there. And so that landscape does keep exploding. And that something that I think that remains important to me. Two things. One is that you know, the landscape as a whole, there's a lot of things out there, but one thing I do like about the C N C F is that, you know, in order to join the foundation and donate the project to the foundation, you go through a fairly rigorous process of technical vetting and due diligence. And, you know, a technical oversight committee of the C N C F you know, examines it pretty heavily. And you really kind make sure that the project has momentum that's solving a real problem, that it has a nice niche, that it's filling in the landscape and all that sort of stuff.

(00:58:36):
So there's good vetting of projects that join the C ncf. And so, you know, those projects that have gone to that vetting, you've got some, some confidence, some assurances around those that they've, they've got a certain level of maturity. So that can be one way at least to identify projects within the, the greater ecosystem and landscape as a whole. That or maybe, you know, maybe things that you can focus on. But then the other point I wanted to make is that within that landscape, like seeing all those boxes and, you know, how do you make sense of it? It's, it's kind of challenging. That kind of makes a point for it's, we need more solutions from the cloud native landscape there. So instead of individual tools and individual projects, knowing how, how do we pull some of those together to solve higher level problems? What are solutions that we can, we can make out of all these projects in there? And so we see that, I think we'll see that more over time as well, is, you know, a more solutions focused point of view for the cloud landscape as opposed to just individual tools that just keep adding boxes onto, onto a map.

Jonathan Bennett (00:59:35):
Hey, I wanna jump in real quick. We are almost outta time, but there's a question I love to ask, and I'll ask both of you guys. What is the weirdest or most surprising thing you've seen somebody do with Cross Plaine?

Jared Watts (00:59:47):
Well,

Nic Cope (00:59:47):
That is really good question, really comes to mind. The first thing that comes to mind to me, this is a, this is maybe almost a troop now in the infrastructure management space, but one of our one of our product managers who worked it up for a while, I think grant, was it Grant? I think it was Grant made a Domino's pizza provider for Cross Plain. So basically you can order a pizza declaratively through the Cross Plain api. I'm not sure exactly what the, I didn't look at the code, but as I mentioned before, an interesting thing about Cross Plain is it, you know, make sure that things are always in your design state. So I'm not sure if that means I design pizza, so it's just always gonna be ordering me pizza or whether it just gives me the one and says, so that was your design state <laugh>. It's definitely one of the more unusual things. That's great.

Jonathan Bennett (01:00:30):
Jared, anything from you?

Jared Watts (01:00:32):
You know, that's, that's probably one of the first ones that came to my mind as well. But then, you know, I think that there's maybe not as, as interesting or zany as that, but you know, there's, there's a lot of use cases that we find for running the, the sites and infrastructure that you know, we, we use to power other projects as well. And, you know, making sure, like we, we started down a path as well of that, that somebody, somebody in the community created a GitHub provider. So you can manage objects and, you know, repositories and users and teams and organizations inside of GitHub and, and GitLab as well. And so using Cross plane to manage the GitHub organization that hosts the cross plane project. And so you're having a little bit of like, inception there. It was kind of one that comes to mind as well of, Hey, it's got an api, let's use Cross plan to manage it declaratively, and then a, you know, active reconciliation and avoiding configuration drift and all that sort of stuff as well. So that one's interesting too.

Jonathan Bennett (01:01:28):
Very cool.

Doc Searls (01:01:29):
Well, guys, this has been a fast hour. Sometimes. I sometimes think it go slow, but sometimes this is, this makes it a record for, for feeling like it's the fastest. Anyway, <laugh>. And, and I like, I also like how you guys hand off that's really good to each other. So we always end with two questions, which in this case is gonna be four <laugh>, which is what, what are your favorite text editor and scripting language?

Jared Watts (01:01:57):
Nick, you wanna get Go ahead on that one first.

Nic Cope (01:01:59):
Hmm. You know, that is a, that is a really challenging one. I think probably text editor in spirit. I'm more in the Vim camp, although sadly, maybe, sadly, I I use Visual Studio Code these days in Vim Modes. It feels like I'm using Vim <laugh> scripting language. Well, I was a Python developer for most of my

Jonathan Bennett (01:02:18):
Career, so probably Python, if you would consider that a scripting language.

Jared Watts (01:02:23):
And then nice <laugh>, I like the bell. And then, so for, so for me, I I, I, I have a little bit of shame about it now but I do kind of go back to my deep Microsoft roots that I started my career, you know, working on Windows Server and working as a, as an in, you know, an intern there, <laugh>, where I, I, I do find you know, that I still have a lot of muscle memory for an editor that, that, you know, comes along with Visual Studio, visual Studio Code. I, I definitely did that. And then also, like, I don't use it anymore these days, but I have had some fun with with PowerShell. I, it is, it is weird. I don't think this group, this group is, this camp here is going to like it, but PowerShell is definitely interesting for scripting. Thank two things for Nick and Two by Eyes for Jared <laugh>.

Jonathan Bennett (01:03:08):
Powershell is a vast improvement over anything that came before it. Oh my goodness.

Jared Watts (01:03:12):
Thank you, Jonathan. We'll go, we'll group that.

Jonathan Bennett (01:03:14):
It's, it's not my favorite, but it is so much better.

Jared Watts (01:03:17):
<Laugh>.

Doc Searls (01:03:19):
Well, guys, this has been great. It's clear this thing has, has moved along far and fast, and so it'll be great to have you back on one of these months or years. It's been a great show. Really appreciate it.

Jared Watts (01:03:32):
I thank you so much for having

Doc Searls (01:03:33):
Us, us. Yeah, so Jonathan <laugh>,

Jonathan Bennett (01:03:37):
It, it took us a while, I think, to kind of wrap our heads around exactly what they do exactly how Cross Plaine works. You know, I, I, I sort of expected more of a dashboard and it's, that's, that's not what this is. It's not a dashboard. But it's, it's neat. It's, yeah, for, for being able to put all of these things together essentially inside Kubernetes, that's, that's a really cool idea. And I, I like to hear that they're kind of eating their own dog food doing a lot of things. For example, they mentioned their, their GitHub account, they apparently control with the GitHub integration inside Cross Plan, and that's neat. Didn't get to ask them quite, you know, we, there's a lot of questions that I would like to be able to have time to ask 'em. We do need to have 'em back. Like there at the very end, we pulled up their their card on the, the Cloud Native Computing Foundation's website, and it said 99% written and go. And it's like, oh, I wanna ask 'em about go, but we're outta time. So it's, it's a, it's a neat project. And if I ever dive into Kubernetes, like if I ever do block out those couple of days I think I will definitely have to spend some of that time looking at cross plane. Cause it looks pretty cool.

Doc Searls (01:04:52):
Well, I have no idea if this applies or not, but the idea of a control plane, which I had not thought much about, and just in a general way would be relevant to a big topic that came up at this distributed web camp under the Redwoods that I was at for half of last week. This put on by the by the internet archive where conversation went to how do, how do we control our own lives when we get our own personal ais, the ones that know all our property, all our mm-hmm <affirmative>, all our health, all our finances, all our everything else, but don't leak out into the world. And how do we control how they leak out into the world? But the conversation went around to, oh wow, if I can do all this stuff, how do I control it? <Laugh>? And, and so, I don't know, just listening to these guys made me think a lot about that. It's not relevant necessarily what they're doing. Good, Jonathan,

Jonathan Bennett (01:05:51):
I was just, I was just thinking next time we have 'em back, or maybe in the after show, we can ask, is there a, is there a plugin? Can you control control something like chat G P T or any of the other machine learning platforms via cross Plaine? And I bet the answer is yes, somebody has already made that happen. <Laugh>.

Doc Searls (01:06:07):
Yeah, well, there, there's that. There's, I mean, if you think of it, so there are open source versions of GPTs and right large and, and the rest of it. And somebody demonstrated, they took everything I wrote for Linux Journal, which I gave them put, and, and had the, the, the model trained on that, and then asked it questions. And this is all offline, right? And right. And, but if you want the big back, the big back plan as it were of, of, of the latest G P T itself and the intelligence that comes from that, and downloading that parts of that model, you have to know where what you've got that's trained on you ends in where this, this stuff that, that you're getting from the world begins there. It's just a, yeah, it's so early in where that's going, but it just really felt pretentious. So, yeah. That's interesting. Yeah. So what do you got to plug? I see Hack a day behind you.

Jonathan Bennett (01:07:06):
Yeah, I, I like pulling this up as part of my background. So there's hackday.com, you can follow my work there. I, I had the trifecta of original content articles. That's our, that's Hack Day's, A long form articles. I had three of them queued up at the same time. There's the one about Mesh Astic, which has a plug back to this show one about, of course, the Red Hat debacle. And then of course there's the security column that goes live every Friday. And yeah, there you go. You've got 'em all right there. And make sure to check those out. Really proud of all three of those articles. They, they both went pretty well, had a lot of community feedback, and some people thought I was nuts and thought some people thought it was great, which, you know, that's, that's always a good place to be where not everybody agrees with you, but some people do <laugh>.

(01:07:47):
Oh yeah. And don't forget the Untitled Linux Show. Thank you Ant don't forget that. If you're not on Club Twit, you really should be, it's only seven bucks a month. Goodness. That's, that is one cup of Starbucks coffee a month. It will get you into Club Twit. And we have some, not only can you get the ad free versions of shows, but you also have some dedicated shows like the Untitled Linux show that is mine, where we talk about Linux news and how-tos. And it's a lot of fun. You should be there too.

Doc Searls (01:08:11):
And you don't, you don't have to wait in line <laugh> like you do at Starbucks, which

Jonathan Bennett (01:08:16):
Is, it's a much better experience. Nobody, nobody's gonna misspell your name on your coffee cup. Nobody's gonna call you out. Something weird. You know, Mary with an e, your coffees or none of that

Doc Searls (01:08:27):
<Laugh>. Well, it's also I just read that the only 25% or something like that of Starbucks action is actually in the store anymore. So, so you, you could drive to the Starbucks store and there's lots of room in the parking lot, but the, but the car, the line of cars goes out to the street. It's weird. People don't wanna leave their cars. So, so next week, I'm actually prepared with this, this time is Golds she's a, she's a friend. And she was at the thing I just talked about where we were, where we were talking about at, at the De Webb camp under the Redwoods in far northern California, where I got a flat tire driving out, by the way. Which I have not had experience changing a tire in a long time, but there it was. But gold is great. She's really smart. Very original. She's doing a lot of on the ground work with all kinds of stuff. So she's gonna be up next week. And until then, I'm Doc Searls. This is Floss Weekly. We'll see you then.

Jason Howell (01:09:25):
It's midweek and you really wanna know even more about the world of technology.

Mikah Sargent (01:09:29):
So you should check out Tech News Weekly, the show where we talk to and about the people making and breaking the tech news.

Jason Howell (01:09:35):
It's the biggest news. We talk with the people writing the stories that you're probably reading. We also talk between ourselves about the stories that are getting us even more excited about Tech News this week. So

Mikah Sargent (01:09:45):
If you are excited, well then join us. Head to twit tv slash tnw to subscribe.