Listen to Episode

Read Episode Transcript

Crossplane is an innovative open source control plane framework that helps companies provide managed access to cloud native control planes. Upbound provides a single global platform to build deployed operate these internally managed control planes that are powered by crossplane. This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author and thought leader on cloud computing and application modernization. His most recent book, Architecting for Scale, is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, Modern Digital Business, and engaging an informative podcast produced for people looking to build and grow their digital business with the help of modern applications and processes developed for today's fast moving business environment. Subscribe at mdb.fm and follow Lee at Lee Atchison.com The song, Tabera, is the CEO for Upbound and he is my guest today. The song welcome to software engineering daily. Thank you for having me on again. It's always a me on to be on the show. Great. I'm glad you're here. So let's start out. Let's tell our listeners what exactly do you mean by a control plane foreign application? What are you talking about? Most people when they're exposed to control planes probably see them in another context. Let me see if there's two of the co-op quite a bit. If you've used a Kubernetes cluster in the past, then you know, you've typically as a container orchestrator, Kubernetes lets you run containers on machines, nodes. And when you requested a container runs on these nodes, you're talking to the control plane of Kubernetes. You're asking it to schedule, you know, one or more replicas of a container to run on a set of nodes. You do that by calling API on the control plane, you give it instructions to tell it, I want three copies of this container to run and from that point on, whereas it takes control. It's responsible for ensuring that these things are running, even despite node failures of a node goes down and it's responsible for reconciling, taking, you know, ensuring that it can start another container. So where else? Because you asked for three to run that entity is called a control plane, right? Another setting in other places you see this is in cloud computing platforms, like things like AWS or GCP or Azure, right? When you ask for an EC2 instance in AWS, you're talking to a control plane, you're asking it to provision and deploy an EC2 instance and it's responsible for ensuring that dots deployed and configured and managing the life of the system. And keeping records of what happens so that, you know, for accounting and billing purposes. So very central component of most platforms is a control plane, whether it's in the Kubernetes ecosystem or cloud, most platforms up built around. And in other places, I think a lot of people will see control planes is in like when they're building a SaaS service, they'll be an administrative panel and control for back end to create new users or to manage existing users or form customer support operations, all those sorts of things. That's often a control plane as sort of environment. So the term comes from, I think the term was coined in the networking space, you know, separating a data plane, the things that that's moving bits from control, configuring data paths and data routes, right? But it's carried it's carried on to like other things. Exactly. I think even in the networking space, they took a step further, they created a parallel network for just the back end. So that you can change the network settings without, you know, even if the network itself is down, you still have access to change the settings of the network and the diagnosis. That's the separation, you typically hear about data plane versus control plane. So one is about control configuration. And there's about the actual job that's being done, whether it's moving bits or, you know, running, running computer workloads, or other other domains. Right. Cool. Cool. Okay. So who are your customers? Who are you tailing this product for? So let me talk about crosswind and also talk about that. Crosswind is a cloud control plane. So it's using a control plane to manage cloud infrastructure and cloud services and cloud resources. Right. So I think if it is a control plane that sits on top of things like AWS and Google and Azure, maybe, you know, on premises and other services, you know, still like data bricks, etc. Right. It's designed to connect to all of them and provision resources, just like a controller would do and own the lifecycle of managing these resources across across the different vendors that that that is managing. Right. So that's a meta control plane essentially. Control plays do nest or you can create higher keys of control planes. So yes, it is a control plane on if you're on top of a cloud platform, it's probably, you know, layered on top of other control planes. Right. And the, the, you know, our primary customers, in fact, essentially platform engineering teams, you hear they have different titles. Right. But that are building what looks like an internal developer platform within enterprises, right. And they're responsible for managing the cloud infrastructure or level and one. They're responsible for ensuring that their policies and cost controls and governance and compliance are implemented. And they're also responsible for creating a self service experience for the internal customers, the developers that are building applications. So we, that's where we're seeing cross plane be quite popular. There are these teams are these platform teams are building these internal platforms around control planes and specifically around cross plane. Now cross plane is itself is a open source framework, right. It's an open source product is I correct. It's a CNC project. My company up there and donated it to the CNCF in May of 2020. It came in as an incubating project in the CNC and since as since, so it came as a sandbox project. And as since, you know, gone up the, so an incubating project. But yes, it is a CNCF project and it's open source. Are you a software engineer looking to make an impact with one of the world's pre eminent data and technology companies. Bloomberg is building the world's most trusted information network for financial professionals and they're looking for engineers to join them. Bloomberg engineers primarily build their software using C++, JavaScript or TypeScript and Python. Additionally, they actively participate in the open source community by contributing to and utilizing open source software in their products. At Bloomberg, you'll be part of a team that builds and delivers tools to help the world's leading business and finance decision makers, surface relevant information and an ever expanding ocean of data and quickly act on it. You will make an impact by building solutions that are relied on by more than 350,000 financial professionals around the globe to make critical business decisions. There are real-time market and enterprise data to sophisticated analytics, powerful trading tools, secure biometric access solutions, integrated communication platforms and more. They work with systems that operate at scale. The company's real-time market data feeds in just and process more than 300 billion, yes with the B, market data messages daily. Bloomberg is committed to building a diverse workforce full of fresh perspectives. Learn more about the opportunities that await you by visiting Bloomberg.com slash careers. That's Bloomberg.com slash careers. Cool. So how much activity do you see in the open source product itself? If it's moved up that quickly, it must get a lot of interest. There are lots of ways to measure that. We like to look at activity in terms of humans doing things with cross-line, like actually contributing. We're very happy with our amount of contributions that are coming from the community and from the ecosystem in general. We have a really healthy Slack community that is built around cross-line. I think we're almost 9,000 people now that are on the Slack channel and talking and contributing to things around cross-line. So I'd say it's a very, very popular project these days. Cool. You're talking about non-upbound contributors. There's your contributions that you're making to have, but these are external contributors who are contributing as well. Yeah. People contribute fall over whether it's changing a line in the documentation or actually adding major features. They come from all around. And yes, the contributors are from the community and non-upbound contributors are plenty these days. That's good to see. You hear so many presumed open source platforms, which are open source, but all of the contributions are coming from the company, the sole user of the company that contributed and built in the first place. They have open source contributions that are coming from them, but they haven't really created a community yet. But you actually do. There is a good solid community behind this. And I mean, by proof alone, just from where it sits within the cloud, it's a few foundations. It's a, it's a, it's got a great level of support. Is that correct? That is correct. Yes. So talk about the connection then between cross plane and upbound. Upbound is your company, is that correct? Yeah. So so upbound is the company that started cross plane. So we don't need it to the CNCF. We also are commercial entity around cross plane. So we sell a set of product and services that are built around cross plane. You know, our vision is to basically create this, you know, layer above cloud computing that we see our customers building the platforms, the journal platforms that they're building. And do so in a way that is, you know, has control plays at the heart of it, just like, you know, we were talking about layering here, but just like the largest platforms in the world are built. You know, the largest bottom of the world. So built around control planes and enterprise platform should also be built around control planes. And so in some ways, we're democratizing control planes. We're bringing it to the enterprise where you know, building a set of services and tooling and we help them. You know, we help them get to production on cross plane. We help them, being sure that they're building correctly on top of it. We offer them products and services that they could use to be successful with cross plane. You know, a lot of, you know, control planes can be both control as well as reporting, right? And and how much are you involved in the reporting aspect of of the can be the control plane sign. I think there's like control was a very central piece of piece of a platform. So there tends to be a lot of agencies around them, right? So monitoring reporting, building policy, cost controls, you know, all those things build benefit and build around control planes. The, you know, the beauty of how cross planes build and architected as it actually uses the leverage is the cloud native ecosystem. And so any tooling that works with a cloud native space specifically supports the Kubernetes style API will work out of the box with cross plane. So pick your favorite policy tool your favorite cost control tool favorite monitoring or observability tool. Those all work out of the box with cross plane. So what we tend to see is that and party why people choose cross plane when they're building platforms is that is already has a rich ecosystem around it. It's hard to find a vendor these days that in the infrastructure or DevOps space that doesn't support the Kubernetes API and the cloud native approach. And so, you know, but partly what we see customers doing is that they bring in cross plane, they bring in, you know, whether, whether, sorry, and then they build around it with things like open policy agents or give or know or things like backstage and cargo and flux and all these popular and rich projects that premieres, et cetera, that are built in the cloud native ecosystem work well around cross plane. In fact, they work better on cross plane because cross plane essentially provides a single point of control for all infrastructure. So you get to leverage these amazing tools that now are able to address all everything being managed by these platforms. So, you know, you talked about the enterprise space and one of the things that you see a lot and even even in modern enterprises is yes, there's the modern applications of the, you know, the cloud native application ecosystem that new applications are being created into and even some migration of older apps into this new. But there's also the old legacy applications that most enterprises still have to deal with and you know, there certainly is value in having a consistent way of managing controlling all of that. Do you do anything to help with those legacy applications as well to. Yeah, we see customers basically integrating their legacy systems or even internal systems that are not so legacy, but there are internal systems into the same control plan approach. Essentially anything that has an API could be brought into cross plane. So, you know, some of our largest customers are the ones that are very heavy compliance governance, you know, customers and they tend to have a lot of internal systems where, you know, to get a cloud credentials, you need to go talk to an internal system that they built right as a gatekeeper to cloud or cloud cost or they have strong, you know, and the second option, phytops type practices and they build a total systems to codify them. You can integrate these systems directly into cross plane. So, you can for example, automate the process of requesting cloud credentials or the process of asking for a new, you know, cost center that you could run infrastructure from a phytops standpoint. So, you can and have been automated as well. In extreme cases, you see folks that are trying to bring in even more legacy workloads. In one case, I can think of a mainframe being integrated into support as well. Yeah, and imagine I was going to say mostly, you know, in the legacy apps, but no, that's not necessarily just mostly the legacy apps. And then you can make a map that you can make of apps as well to comply and say compliance monitoring is important aspects for these control planes and imagine you play a big role in that. Yeah, part of, I mean, the beauty of a control plane is a don't sure that's you centralized and standardized. One way to manage everything. And so when you have, when you try to enforce policy, that, that gets a lot easier when you're. Yeah, I think that was linking cool. So I was actually when I was doing research, getting ready for this interview, I was intrigued by your. Hey, Glon, which is as I'm looking at right now, it says, let us scale your control planes so you can scale your business. So, you know, anyone who knows anything about me knows that I care a lot about scaling and I talk a lot about scaling and scale management. So I'm intrigued by that. That important use of the word scale in the control plane model and wondering why you think the word scale, why does the word scale imply to your control plane business and why isn't an important aspect of what you're doing. Yeah. So in some ways, I mean, you can think of control planes solve a ton of problems for enterprises. The ones we just talked about standardizing, getting everything to a single point of control building things around creating a self service experience. They solve all these problems, but they also introduced new problems. Right. And what we're seeing is the new problems they're introducing around scaling the control planes themselves. Right. Some of the things we look at here from a scale standpoint are, you know, how many resources can a control plane manage. How many control planes are you actually using in a given environment, right. And things are on security and tendency and multi tendency type models. Do you deploy a control plane per team? Do you deploy control plane per workload? Do you deploy a control plane for the entire organization? Right. So those are those are all some of the things that we see our customers struggling with. Right. When they, you know, have decided to use cross plane and they've decided to take into production. And they start running into these kind of scale deployment and hosting type type type issues. And that's kind of where up on can help. Right. We've, you know, not only created the cross plane project, but, but are really, you know, have scaled it for our own deployments. Right. I found itself runs on top of infrastructure to deploy to running using cross plane. We have a matter of SAS service that we built with cross plane and we scaled it. Right. And so part of what we just released in the last month was our own product that and at the heart of it is this feature called managed control planes. And you can think of managed control planes as, you know, the ability to deploy cross plane instances. At on demand and they can scale up and they can scale out arbitrarily. And, you know, so you can create one of these part team. You can create one of these per workload. You can create as many of them as you like, you can create higher keys of them. And the amount of resources that they can manage is essentially unlimited. They can grow, you can scale them. And that machinery, that logic to do all of that to scale out to scale up to create multiple system management lifecycle is all part of a feature we call managed control planes. That is part of the about product. So the the up on product is it mostly a, you know, a SAS enabled service or areas that also don't promise as well. The version we launched on on April 4 was a SAS embodiment of it. And but as you can imagine that our customers are asking for different deployment and hosting options. And we're working with them on, you know, essentially giving them managed control planes into their different kinds of. So it varies across the literally everybody wants to run these control planes everywhere is what we're seeing no joke everywhere. We've got folks don't want to do this under the ocean, which is. You know, you wouldn't think of as a, you know, as a place to run infrastructure, but it's fairly commonly states to put containers under the ocean shipping containers on like literally shipping containers under the ocean. Yeah, yeah, the touchless data centers and that what both got the Google and Amazon are dealing with it. They still have to be managed. So they need to start getting it's water guns. Exactly. Yeah. That's great. I will literally like you say we'll put a data center anywhere now. So let's see if any people are interested in learning more about either cross playing or up out where should they go. So you used to cross play this part of the CNCF foundation, but where should they go to find out more information about cross playing the where can they go to talk about to learn more about upbound. Honestly, the best starting point for both is upbound.io. So that I would start there. Upbound host this marketplace that has literally every resource and everything around crossman documented. It lets you it's kind of what the doctor registry was the doctor. Right. And really a good place to go get started with with cross time and also with upends. So they if you're looking to get you know it's easy to deploy a control plane using the upout product. It's easy to get you know deploy a set of services with it and play over there. It's probably the best place to start at this point. But some is the CEO of upbound and he's been my guest today. Awesome. Thank you so much for joining me today on software engineering daily. Thank you.