GitOps for your infrastructure as code with Crossplane

Viktor (00:06):

We should not be concentrating on building the things that already work well. That is integral part of the design of Crossplane. We are not going to build specific logging mechanism, we are not going to build GitOps something, something. We are not going to build our own scheduler you know: we are going to extend Kubernetes’ scheduler, but we are not going to build it. Our approach is very different: Crossplane is a part of wider ecosystem while Terraform is the ecosystem by itself.

Marc (00:11):

Hello! And welcome to DevOps Sauna podcast. I’m Marc and I’ll be your host today.
The superpowers behind Kubernetes are declarative management by desired-state and automated controller logic. This enables companies to easily manage hundreds of compute nodes, thousands of containers, and to manage networking and autoscaling between all of them. To avoid cognitive overload in all of this is the declarative API that provides a useful abstraction level. Crossplane is one ways to achieve that. But when you strip it off of all buzz words, what is it, actually? We invited Viktor Farcic, Developer Advocate at Upbound, and Andy Allred, Lead DevOps Consultant at Eficode to help us make sense of all of this. Let’s tune in.

Marc (01:35):

Hello and welcome to DevOps Sauna. My name is Marc, I'll be your host today. Here we're going to talk about Crossplane.io. I've got two great panelists here first, I have Viktor Farcic. Would you like to introduce yourself, Viktor?

Viktor (00:27):

Yes, I would. So my name is Viktor, I work for Upbound, the company behind Crossplane open source enterprise. We'll talk about more later. I have a YouTube channel, write books, speak at conferences, destroy other people's systems.

Marc (00:46):

Very prolific and humble introduction. Thank you, Viktor. I also have an Eficodian here with me, Andy Allred.

Andy (00:55):

Hello. I started my career something unique in nuclear powered fast attack submarines doing electronic warfare, communications, and navigation; which often gives me a unique perspective on how to operate things and how to look at the operability of systems. And then I spent, I guess, decades in telecoms companies and recently moved into Eficode as a DevOps and Cloud consultant.

Marc (01:26):

Were those submarines turbocharged, Andy?

Andy (01:28):

Yes, we had a turbo on the diesel. <laughs>

Marc (01:32):

All right, let's talk about how to turbocharge our development environments. Viktor, would you like to tell us about Crossplane and Upbound?

Viktor (01:42):

Yes, so Crossplane is, if I would have to give a tagline, only a few words, that would be that it is a control plane of control planes, which might sound confusing to people. But think about Kubernetes, right: I've said Kubernetes now mostly because majority people are already familiar using Kubernetes, and Kubernetes itself is a control plane, it controls what is running and how it's running in a cluster. Now, what we want to do is bring that concept of a control plane on a higher level. Wouldn't it be great if you have a control plane that would control your Kubernetes clusters, but also your AWS resources, Azure, on-prem, GCP, GitHub accounts, doesn't really matter what that is. What does matter is that the idea is to have a control plane that controls everything. Just to clarify, control planes are everywhere. People might not be aware of it, but when you use AWS, you're actually interacting with the API. And there is a control plane behind it, and the same thing with Azure. Basically, behind almost every API, there is a control plane. But since everybody's multi-cloud now, which we can fight about later, but I stand by my claim that everybody uses more than one cloud, there is a strong need to have a control plane above all that; to have a single pane of glass, but not like CLI you know kind of fire execute this and then I want that, but a real control plane behind everything. And that's what we are trying to do with Crossplane. That's a short gist... There is much more to it, we extend Kubernetes, we are Kubernetes native, there are compositions, so on and so forth. A lot of things. But the short one kind of kickstarter is control plane of control planes.

Marc (03:55):

Great. Control planes on submarines as well, when Andy brought this to me, that's what I thought we were talking about dive planes or something. Viktor, could you tell us a little bit about the history?

Viktor (04:08):

So I'm assuming that you now mean the history of managing infrastructure, something like that,  it all started with shell. And then people realized that you cannot easily manage state in shell because you write shell scripts or Python or whatever. And then you need to have infinite number of if-else statements, "Hey, I want to do this, but if the state is like this, then I need to do something else." But we did something else... It's just complicated to manage all the permutations. So either you would need to have scripts that start always from scratch, or you die trying. Then we got CFEngine. There must have been things before CFEngine, but at least in my case CFEngine was the first contact with what later on became known actually at that time, I think that it was called configuration management, CM. And it was horrible, CFEngine was horrible. But t was seen 'how horrible' from today's perspective.

Andy (05:20):

It was fantastic at the time when I was trying to get all my bash scripts in line and trying to figure out where the if/else is failing. CFEngine was amazing at the time.

Viktor (05:30):

Exactly. It was horrible. Actually, I can say for almost everything that existed more than 10 years ago. But yes, I remember also, my first reaction to CFEngine was, "I cannot believe it. This is best thing ever." Then we got into Chef and Puppet. Later on, SaltStack. Chef and Puppet had interesting concepts and interesting ideas that died with those tools. And now we're reborn in ArgoCD and Flux. Some people are probably going to say, "Hey, what's the relation between Chef, Puppet and Flux?" They they serve different purposes. And that's true in a way partly. But they were based on very similar concepts. Hey, there is a code stored at that time. I'm not sure whether we already switched to SVN, or that was CVS, but there is a code store the so-called repository, there is a server running somewhere. It is monitoring that repository all the time; it's making sure that whatever is specified there is the desired state and that is converting to the actual state running somewhere. I'm not sure that even desired state, the actual state for use that term at that time. Maybe they were, maybe they were not.

Andy (06:58):

I think it was and the idea that they had was so applicable to exactly what we're trying to do today. They were on to the right idea but the technology was still holding them back. We didn't have the networking and things like that to enable their ideas to really come to fruition.

Viktor (07:16):

Exactly. But when people say, "Hey, this new thing, GitOps," I tell them, "Yeah, I use Puppet 30 years ago, don't tell me about new ideas GitOps." It's exactly the same. The only difference is that we didn't have Git at the time. That's the only difference.

Andy (07:30):

Yeah, SVNOPS! <laughs> 

Viktor (07:32):

Yeah, exactly. And now, at that time, I think that the problem, actually not the problem, but naturally, all those tools, I believe were designed with ideas around mutable everything because on-prem data centers, that was the norm. Cloud was just a word that was floating around, nobody really understanding.  We were still going to use virtual machines, I think at the time of CFEngine they were a new thing that's scary. I'm not sure, I don't know whether I can trust those things.

Andy (08:12):

Let's see if this really pans out in the end, or we can go back to the good old bare metal.

Viktor (08:18):

Exactly. That's a temporary thing. It's a hype. <laughs> Now, the problem with that is, if those tools were designed with physical hardware in mind, they had to be mutable. From today's perspective, you cannot go and whenever you change something, change a single line of configuration and say, "Okay, I'm going to create a new server for you and destroy the old one, I'm going to keep it immutable." That was not realistic at the time and that's why I think that we saw very rapid adoption, from CFEngine, Chef, Puppet, and later on Ansible into TerraForm. TerraForm championed, some people say championed Cloud, but actually what really made TerraForm different is that it was based on ideas that everything is immutable. Now, that does not mean that Ansible and Chef and Puppet cannot work in immutable way, they can, same as TerraForm can work in mutable but base design is different. Then we got TerraForm and TerraForm ruled, and still rules the industry in a way with later edition of Pulumi... Which is basically, from my perspective, the same thing as Terraform. Now I know that people are going to start yelling at me it's not the same. I know it's not the same, but conceptually, the difference is more in syntax than in the principles and what it does.

Andy (10:04):

Yeah, the idea of Pulumi is to solve the same problem TerraForm is solving. But the developers can do it in the language they're comfortable with instead of learning HCL and TerraForm model, and there's other subtle differences, but that's the main selling point, so to speak.

Viktor (10:19):

That's the short history, I think.

Andy (10:23):

I was just showing Marc a little bit earlier, one of my old TerraForm repositories and the hundreds and hundreds of files that we had there and hundreds of lines of configuration in one file and saying that this was so amazing because you only have to update this and this and make sure it's linked with that and make sure it's over here. And make sure you change this, so you don't overwrite the state file. And then it just works. It's so cool! And coming from the past, it was and it's still a very useful tool, but it has its pitfalls, mostly with how you're interacting with all these files that who's going to update which file and where do you store it? And how do you manage the state files and share them? And it's not solving everything, but it sure is amazing compared to the history we just described.

Viktor (11:18):

Yeah, definitely. I mean, Terraform really changed the game drastically. And that is so evident if you look at the adoption. There are very few tools in this industry that got such high adoption so fast. If you would name 10 tools that everybody knows about, TerraForm would be one of those.

Marc (11:48):

But we know that there's pitfalls with TerraForm. And we talked a little bit about the complication and requiring to learn HCL, what are some of the other pitfalls of TerraForm today. What are people facing?

Viktor (12:01):

I would say rather than pitfalls, more that I think that there are missing things, or differences in concepts. One of those is that, I'm a strong believer that everything should be managed through an API: that CLIs, if you use them are just wrappers around the calls  to an API. That that should be able to instruct through API, hey, change the state of this, give me the list for all the resources of this type, and so on and so forth. Not only that TerraForm doesn't have an API, but it kind of tries to hide the fact that there are APIs on the other end of all that. And it makes perfect sense that TerraForm hides the API because if you don't have your own, then do you really want to be exposed to AWS and Azure, and Google and Datadog and all those APIs? That's just overwhelming. So I think that that's one of the missing pieces. I'm a Kubernetes fanboy and I think that Kubernetes API is probably the biggest advantage that we got with Kubernetes itself. It is the best candidate that we have today for something potentially to be called Universal API. From my perspective, it doesn't even matter whether there is Kubernetes engine behind that API scheduler or not, API is first. The most important thing about Kubernetes. I would even predict it. If we talk again, like 10 years from now and parts of Kubernetes do not survive, I would say that scheduler will disappear before Kubernetes API disappears from the scene, right? 

Andy (14:05):

Yeah, probably... 

Viktor (14:08):

That's what we are trying to leverage with Crossplane. Hey, there is already that widely accepted API that was designed to be extensible. That has a scheduler behind it and a few other things. Why don't we use that and create a higher-level API that would allow you to do some of the things that you might be doing today with TerraForm, but using the API itself. Simply kubectl or CURL, whatever you prefer, it doesn't really matter.

Andy (14:45):

But other than the API, the struggle I had with TerraForm was not so much the functionality. It was that in the big project I was doing TerraForm there were three of us who were managing all the infrastructure things and we all knew how that TerraForm worked, we knew which ones to update where, and it was fine, we were able to do it. Then we need to onboard a few more people and share it with some more teams. And once more than one team was trying to interact and manage and define infrastructure and request infrastructure, it didn't scale very well, when we're sharing state files and having the variables conflict between different files. It just got too complicated for more than a small team.

Viktor (15:32):

Yeah, but that's partially because TerraForm lives on your laptop, it was designed to live on your laptop, right?

Andy (15:41):

Yeah. 

Viktor (15: 42):

And by definition, something that was designed to live on your laptop is meant to be used by you, and not you and 57 other people at the same time.

Andy (15:52):

Yeah. We had Jenkins pipelines that would run and actually run the TerraForm for us. So it really wasn't running from our laptop, but the design of TerraForm is very much laptop centric. Yeah.

Viktor: (16:07):

Exactly. It's CLI-centric. Right, Rich? 

Andy (16:12):

Yeah. 

Viktor (16:13):

Yeah, ends up being laptop centric. Yeah, of course, you can use Jenkins or any other tool. And actually, you should be using Jenkins. It doesn't have to be Jenkins, but just pushing your manifests to GIT, you tried them locally, push them to GIT and let some other to do the stuff. But when you think about it, basically, in your example, the objective of using Jenkins is the same as the objective of first using Kubernetes, right?

Andy (16:53):

Yeah.

Viktor (16:54):

It's that central piece of mechanism that is orchestrating what will be executed and when and how. And then we can enter it too long. It wouldn't be a long discussion, but there are definitely benefits of Kubernetes orchestrate things over Jenkins, let's say.

Andy (17:15):

Yeah, but as amazing as TerraForm was, there were these pitfalls does sound strong, but these struggles that we had, and there has to be something better. And there has to be a better way to do this. And as you said, the Kubernetes API comes along, and has this Kubernetes control loop that goes through and just checks if everything's in state. And that's built-in and built to be extendable. So instead of reinventing your own control plane, you just tune a little bit and use a Kubernetes one, and then that unlocks so much potential.

Viktor (17:54):

Yeah, I think that that's one of the differences, which again, it's understandable given the time when TerraForm was born. But one of the huge challenges that TerraForm has is that TerraForm is the 'ecosystem in itself'. So TerraForm and TerraForm community in HashiCorp, and so on and so forth. Whatever is needed needs to be built specifically for the tool. But our route is more, I cannot say more open source because it's not more open source, but more in the spirit, let's say. There are already things that work and workwell. I mentioned a couple of times Kubernetes scheduler and what's or not, but there is Cloud native from the CNCF landscape, let's say our cloud native landscape, and we taught from day one that we should not be concentrating on building the things that already work well. And that is integral part of design of Crossplane. Hey, we are not going to build specific logging mechanism, we are not going to build get ups something. We are not going to build our own scheduler; we are going to extend Kubernetes scheduler but we are not going to build it and so on and so forth. So the approach is very different in terms of that Crossplane is a part of a wider ecosystem, while TerraForm is the ecosystem by itself with all the benefits and upsides and downsides of either of two approaches. 

Andy (19:40):

Right.

Marc (19:43):

So speaking of a better way to do things, how it's done with Crossplane, then.

Viktor (19:51):

Yeah, so we have a concept of providers, let's say AWS provider, Azure provider that have one to one mapping between a resource in a target provider, and Kubernetes custom resource. So if you have, let's say AWS as example is to instance, there is a custom resource definition Kubernetes for EC2, there is a custom resource definition for ELB, ALB, EKS, whatever. So there is that mapping. And then when you want to manage something, you basically create a custom resource from that custom resource definition, just as you would create a deployment in Kubernetes, or stateful set, or wingless, or whatever. So you're managing Kubernetes resources, which are describing the end resources living somewhere else. And Crossplane's job is to convert that Kubernetes definition of a resource into a real resource, whatever that resources. And now comes one more difference, I think huge difference actually between Crossplane and other tools: it is not doing that only when you say, "Hey, I would like an EC2 instance." It has that feedback loop that it is continuously monitoring that state of that instance. And whenever there is a difference between what you defined, and what it really is, it will converge those two states. So pretty much acts in a similar way as what you would use maybe Argo CD or Flux to synchronize what is in Git and what is in Kubernetes. Crossplane is fulfilling similar need or target between what is in Kubernetes and what is in AWS, for example, but it could theoretically be anything else. So if I would make that distinction, I would say that TerraForm is a tool that reacts only when you tell it to do something. Let's say, if I create an EKS cluster right now, TerraForm will do a wonderful job, it will create it. If something happened to that cluster and its actual state changes, that's something that will not be fixed until the next time I execute TerraForm which could be two minutes later, or seven months later. If you go back to the example of Jenkins, the next time I push to get it then it will be fixed.

Andy (22:40):

And then the Jenkins job will fail because something in TerraForm conflicts and it doesn't know how to resolve it. And you get an error and you're like this resource changed, "Man, when did this change? How long has this been this way? Why didn't we know? We have to redo this; we have to redo this? Man, I wish I would have known when that happened." 

Viktor (22:59):

Exactly. 

Andy (23:00):

But because Crossplane is now built on top of Kubernetes and using that control loop logic which Kubernetes is built on, it's always checking the status. So if something gets out of state, Crossplane notices it almost immediately, basically, and starts resolving it for you. So whenever you want to make a change, you know what state is that you're making a change to because Crossplane is always updating it and keeping it in sync. 

Viktor (23:29):

Exactly.

Marc (23:30):

Cool. And you had talked a little bit about the API. And I know that this is a big difference, but you'd like to open up a little bit more about the benefits of the API?

Viktor (23:43):

It's really about being able to communicate with some server somewhere and to that communication, do things right. Without an API, a simple operation, like give me all the virtual machines that have this label that belong to Team A cannot be done, at least not easily without an API, right?

Andy (24:17):

No, it is easy. I had a shell script that goes through all my TerraForm directories and then runs TerraForm apply against a TerraForm plan against them and the checks the output and then puts it all together and then formats it nicely with some awk and sed stuff. It's simple. I don't understand this problem you're solving.

Viktor (24:38):

Yeah, I'm exaggerating you see. You just need to write couple of 100, was it the hundreds or thousands <of lines of code>?

Andy (24:46):

Hundreds maybe.

Marc (24:50):

Yeah, I get the impression that there was a lot of 'bring your own' that now Crossplane provides.

Andy (24:57):

Yeah, it was really complicated to do but I had just been doing some experimenting and trialing was Crossplane and I didn't remember how many clusters I had deployed because I'm multitasking at the time. And I just went the Crossplane and list the clusters. I have four. Yeah, I wanted four, now I'm done. But with TerraForm, it would have been a little bit different because it's a CLI tool, not an API tool.

Viktor (25:23):

Yeah, in TerraForm, if you put all those four clusters and that's the only question you will ever ask, and you kept them in the same project, you would get that information, right?

Andy (25:32):

Yeah. 

Viktor (25:33):

Actually, no, you will still need to filter and say, "Yes, but all the node groups out." You'll need to start filtering out, actually. You will get too much information then.

Marc (25:46):

Cool. Sounds really good.

Marc (25:04):

It’s Marc again! Part of the reason why Kubernetes has become so popular is that it made containers extremely easy to run. Another reason for Kubernetes’ popularity and extensive adoption is that it didn’t change the model for running software too much. Michael Vittrup Larsen wrote a blog post named “The future of Kubernetes – and why developers should look beyond Kubernetes in 2022". I’ll leave a link in the show notes so you know what’s up and coming. Now, let’s carry on with our episode.

Marc (25:38):

Are there any customer cases, either nameable or just that you can talk about in a generic way about the value that Crossplane has brought to an organization?

Viktor (26:00):

Yeah, so I cannot mention the names mostly because I was too lazy to check internally which ones I can mention and which ones I cannot. But we are in a relatively early stages of adoption. When I say relatively early stages, I think that from customer perspective, and this is different than user perspective because we can have any unknown number of users, it's open source. But from customer perspective, we are seeing huge interest among big customers. And I think that's normal or to be expected because the differences between doing things with Crossplane and doing it with other tools become more evident when you run at scale. Most of the examples that we were mentioning today, like hey, API server that can retrieve all the clusters, or the problems with working with state and so on and so forth are not really real issues when you have one cluster and then two load balancers. Right now, more customers, of course, we want everybody to be our customers, the things that everybody else wants, but the adoption comes mostly from big organizations.

Marc (27:04):

Can you name some sectors? 

Viktor (27:07):

Yes, quite a few in banking. There is interesting entertainment industry. And now you guess how many streaming companies you have right now in the world, right? <laughs>

Marc (27:21):

Yes. 

Viktor (27:48):

I won't say the name. So I'm seeing the financial industry, entertainment industry, medical industry as well, car manufacturers. Now, when I think about it, I don't think that it's limited to certain segments. And another interesting thing, actually, is that there is a huge interest and adoption, not only among end users like, "Hey, this bank uses this or this streaming service uses this, but also among vendors. It is very likely that vendors will use Crossplane to power their own solutions. You're a cloud vendor or you have a service for this or SaaS some solution or whatever it is that Crossplane has the potential to become the driver there as well. So it's also from that perspective, but quite a huge interest. But since we are relatively early in the process, at least from commercial side. Crossplane is officially project exists for for a while now, but commercial, I think that we started maybe half a year ago or three quarters ago. So we are mostly seeing interest from companies that say, "Hey, we want to be with you for a ride. We know that this is not the end game. We see a huge potential in Crossplane, we can imagine and we would like you to tell us where it's going. And we want to actually be in for a ride. We want to influence the roadmap. And we want to invest." So think of current customers more as investors in Crossplane than I simply buy this thing and this thing does whatever it does.

Marc (30:02):

I've heard a lot about the responsiveness of the community in terms of being able to help build enablers for some of these large companies. And plus it's open source, so they can all contribute back as well.

Viktor (30:14):

Exactly. And that's now the most important phase probably, to get a massively large coverage through contributions. Because we, as a company, we will never be able to create all the providers for everything that exists in our world. The goal is, "Hey, you're a company that you're AWS or you're Azure, or you're a small company like Sivo and so on and so forth. Why not join for a ride as well and contribute your provider to Crossplane. And I think there are a couple of ways you can do that easy and hard way, which I think we'll speak about later.

Andy (31:03):

But about this community helping each other, I just happen to have a very recent example. I like the Rancher tool for managing Kubernetes clusters, mostly for the centralized RBAC benefit, but I think it's a great tool overall, and it's getting better. But I always want to install Rancher. And when I started installing systems was Crossplane, I deploy the cloud resources, put in the Kubernetes cluster. And now I have to run something else to get Rancher. But now with the new Terrajet provider, which we'll probably talk about a bit more. The day that came out, I happen to be chatting in the Crossplane Slack where somebody said, "Yeah, we're working on the Rancher stuff now." Two days later, they said, "Here's your new Rancher provider, you can configure Rancher with Crossplane now as well." It's amazing. So it's a really great community to be part of.

Viktor (31:59):

Thank you. I probably shouldn't say this, but we are surprised. We did not expect. We always expected to be big adoption and stuff like that, but we did not expect anything at this scale that is happening right now, which is a good problem to have. Hey, actually, the adoption, and their contributions are pouring in faster than we thought.

Andy (32:29):

But I think that just speaks to how much it's solving problems that people have. So we were talking earlier, like AWS, everything you do is via an API, and it was Crossplane, companies can build their own API. So instead of going to Cloud, you go to the Eficode control plane and say, give me this, give me that whatever. And then because you can extend it, if I need a provider for Rancher, couple days later, I have a provider for Rancher, and then I can do it. And as an end user, it's so much simpler to use because my infra team or me when I have the infra team head on, I can define some some resources and then say here, and then a few lines of Yamo, anybody can deploy and get it. So the use case is just perfect.

Viktor (33:15):

Yeah, there is that also now that you mentioned other people and stuff like that. Probably the most important feature or capability of Crossplane is what we call compositions. We did not expect many people to use Crossplane resources that I was talking about like easy to and what's not correctly. At least going back to the customers question that you asked me before. One of the common themes among all the companies that I know of that use Rancher is usage of those compositions, which means, hey, I'm operations team or SRE team or something like that. And I do not want to respond to JIRA tickets, create a cluster for me, deploy this application. And I cannot also tell users, "Okay, why don't you manage AWS yourself because those users are going to freak out. Hey, how many years you need to spend to figure out subnets in VPCs, and ELBs and ALBs." And AWS itself has thousands of give or take resources that nobody understands, and so on and so forth. So with compositions, actually not for the compositions, but the the end goal, the end idea is that for Crossplane, to enable certain types of people, let's say, experts in security, in infrastructure, in Cloud and whatnot, to enable them to create a platform for everybody else. So if I go back to that Eficode API that you mentioned, you can create and say, "Hey, you want to create a cluster, you want to manage cluster?" "Yes." "What do you care about?" "I care about ABCD." Like for other nodes, is it big? Is it small? Is it running in Google? Is it running in Azure, you create a completely new resource for them, completely new custom resource definition, we call it Crossplane Resource Definition, and say, "Hey, there's that 10 lines of Yaml that you mentioned." Behind those 10 lines of Yaml, there are 5000 lines of Yaml. Because AWS is complex, it has many moving pieces, many things that needs to be done. But for you, I'm going to create something custom. And I think that's going back to why I see adoption among big companies because everybody, I believe, needs internal development platform or internal platform to do things because everybody has something that is different than somebody else. Maybe security rules, maybe which types of instances we use, and so on and so forth. Now, the approach that we as industry were having towards those types of platforms in the past was what I will call Heroku, but it applies to every to many other solutions, meaning, hey, I'm a vendor, I create an opinionated platform that will greatly simplify how you do something like Heroku, you say, "This is my code, run it." And the thing that Heroku is absolutely amazing. It's absolutely great. I love it, but it doesn't work in bigger companies. And it doesn't work because the result, it's enough to have one thing that is different between what you need and what opinionated platform gives you. One thing is enough to break completely, to say, "Hey, because of this one thing, and it's almost always never one thing, it's more than one thing. But because of this one thing, we can reduce this thing. And modifying how Heroku works is impossible. They're complicated.

Andy (37:04):

Yeah, so then was Crossplane. This example Eficode API, which I mentioned, now might be something on my to do list, by the way. So instead of saying this is Heroku's method, or this is Digital Ocean's method, I can say this is the Eficode outlook. And this is our opinionated way for deploying apps works. And then I can fine tune it for my requirements and say, "You have to have these security controls, you can only use these networks." And I build that in. And then expose a very simple API, just like these other providers have done, which is designed with my use case and my requirements in mind. And then the users get the same easy service of here's a few lines of Yaml give me my test system. But behind the scenes, all the complexity of complying with my requirements is done for them.

Viktor (37:58):

Exactly. It's a tailor made Heroku in a way. 

Andy (38:02):

Yep.

Marc (38:04):

And this way, like a small platform team can really show enterprise level value by hiding all of this complexity.

Andy (38:15):

Yeah. And the other benefit of that is also that when I'm building these, I can build in the AWS configuration, the Azure configuration, the GPC configuration, the OpenStack configuration, the whatever else, we want configuration, and those can be one line item inside the Yaml file. So when a development team says I needed a new environment, they don't need to care about which Cloud is it and how do you do things in that Cloud? They just change the one line, and the tool takes care of everything for them.

Marc (38:50):

Or even on-prem, we have some customers, especially in financial sector still running on-prem.

Andy (38:54):

Yep. 

Viktor (38:55):

Yeah, if there is an API on the other end, it can be made to work with Crossplane. Now, whether today there is a provider or as Andy mentioned the reason, but then it will be created two days later. That's a separate question. But if there is an API that Crossplane can be thought through with, then it can be added. Yes.

Marc (39:20):

Yeah. I've just been talking with the customer about implementing Crossplane in their systems. And we do have the use case that we have Azure HCI on-prem, we have Azure in the Cloud. And there's still a couple things in AWS that need to be taken care of. And with all of this, we can still hide them, so to speak, hide them behind the the Crossplane API. So the user experience is the same no matter what the target environment really is running on.

Viktor (39:55):

From that perspective, your users are treating you the same way as you're treating Azure. Meaning that you're not sending requests to Azure, "Azure, can you do this for me?" Azure's job is to provide the service that you consume. Your job is to provide the service that the others in your company consume. You're becoming a service provider, essentially, right? 

Andy (40:23):

Yes. 

Marc (40:24):

Yep. So development teams can configure what they need with a small amount of Yaml. And it hides a lot of complexity and NFR, (non functional requirements) behind that. And compliance, I would assume, as well, and some other things

Andy (40:39):

Compliance and security. And you can put limits on how many how many pods they are, how many nodes, they can spin up, what type of nodes they can spin up, which of course, affects the cost. So all controls can be built in. And best practices can be there, that the developers or the end users, let's say that way, don't even need to know about, of course, it's good if they do and it's good if they're aware of everything, but they don't have to stress about 'am I remembering all this stuff'? They just say, give me an environment, and they get it?

Viktor (41:14):

Yeah, and those compositions can be made depending on the level of experience of those end users. Hey, what do you know, you know those three things, those three things is what I'm going to expose to you. You want to be a power user, I'm going to create the composition with 25 knobs that you can change. It's treating them as customers, hey, what do you need? You need this? What is the level of control? You you need that? Excellent. Here's the service.

Marc (41:44):

This sounds so amazing to have this level of configuration management and even an internal customer focus instead of we get sometimes the tools teams are like, "This is how you're going to do it." But being able to provide that level of flexibility, I think is really fantastic. But Viktor, speaking of all of this versatility on the on the different cloud providers and whatnot, I think you had a big announcement this week, which is the end of January 2022, or, as we say in podcast speak at the time of our recording. So what was the big announcement you just had?

Viktor (42:21):

Yeah, a while ago, a few weeks ago, it was live in public, but we announced a few days ago from the time of this recording, the project called Terrajet. And in a short explanation of the project would be it takes TerraForm modules, it passes them through code generation and creates Crossplane providers. I would say it's not the end game, but it gives us 100% coverage for whichever pro modules we put through the code generation. And that was the most important milestone because quite a few of users’ customers, whatnot of crossplane had that complaint, hey, this is amazing, but you have 375 resources in AWS and AWS itself has 800 something and I happen to need this one. You need to add it to the list of resources in a provider and it takes a lot of time to develop the equivalent of a resource in a provider. And this is especially true if any of people listening never work directly with let's say AWS API, but the same applies to almost every other big provider: the APIs are messy, they are inconsistent, they are complicated, and so on and so forth. So Terrajet through the code generation, based on TerraForm module gives us like coverage of some provider in a matter of hours or maybe days if it's something extremely complicated. So now with Terrajet we have all the coverage we need. And then that means that now we removed to the biggest blocker for adoption, hey, this is missing because now it's not missing anymore. And if it is, as Andy said before, it will stop being missing in a day or two. And then we can go back to the original idea of building what we call Crossplane Native Providers, which are tailor made defined from scratch written in Go for all those providers, but now we're not in a rush. Hey, will we have native coverage for AWS next month or two years from now? It's not anymore that important because through Terrajen and code generation became that coverage almost instantly.

Andy (45:16):

So do I remember right that at least as of this week, AWS announces new stuff all the time, but at least as of this week, there's 100% coverage of all the AWS Azure and GCP components?

Viktor (45:30):

Correct. Those are the three modules that bulk of the work was done by 'us'. And in this context, I wear two hats, 'us' can be community and 'us' can be Upbound. In this case, I'm in Upbound. I might be wrong. I think that by this time, we already have additional seven or eight providers, Rancher being one of them, with rumors of many more in the works. And this is also going back to what I mentioned before about involving other vendors into Crossplane. This gives them a very easy way to translate their stuff into Crossplane within a day, and then they can also work on native providers slowly without having so much pressure. See instant coverage, let's say.

Marc (46:32):

Sounds fantastic. What's on the roadmap? What's coming next Viktor?

Viktor (46:39):

Yeah, so let's say three types of projects or platforms, I'm not sure how to call it. There is Crossplane, completely open source. That's the majority of stuff going on. We are very, very open source type of company. And then there is a Universal Crossplane platform, UXP, which is completely free, but it is distribution of Crossplane. That's the distribution that we validated with providers that we validated. That works with some additional tools that we are building like, VS code extension, and so on and so forth. So there is a free distribution. I'm trying now to think about another example of something like that, my brains stop now. Anyways, pre distribution of curated distribution of Crossplane, for which we are building additional tooling, apart from it being stable testing and whatnot. And the first one that we are releasing, I think in a week or something like that is VS code plugins. So that's when you write your compositions and manifest and whatnot, you get down to completion and things like that. And there is Upbound itself, which can be enterprise or Cloud, for which we are working on a lot of things. For example, there is already but there will be improved the registry, where you can see all the details of all the resources, and that feels soon include other people's compositions. So for example, when you want to create, let's say, an EKS cluster and EKS cluster needs subnets and VPC, there are a lot of things. And then you can go to registry and see all the different people who already implemented that composition and steal it from them, it's not stealing, it's contributions, but see different examples of how people implemented and solve certain problems and then build it from there to fine-tune it for your specific use cases. We are working now in case of commercial version for external secret storage. First one is vault, much more to come. XRM, which is a way for UI to evaluate either provide the resources for your custom compositions and present you with the UI. In the example that Andy was mentioning before, or I was talking with him, you create your own composition it has whichever schema that you define it to have, that's completely up to you. But then your users will be able to see the fields and all the drop downs and whatnot off your own compositions. And then we are getting having internal development platform with custom made UI or console. 

Andy (50:09):

Sign me up for the beta! <laughs>

Viktor (50:12):

Yeah. There is a disabled feature that is that is already doing that, but we are thinking about how we can make it better and fixing some rough edges, but it's getting there. We're getting there.

Marc (50:30):

Sounds like feature flag developments going on, which I'm also very happy to hear.

Viktor (50:34):

Yeah. <laughs> What else? And then also there will be custom compositions, its a working title, probably it sounds silly, custom compositions, but anyways, you will be able to use your engine of choice to render the final compositions. So whether that would be Helm or to pass it through some Go code or any other engine, so that you have more flexibility on how those compositions are created. Because that will solve, I'm not sure whether to say problems, but we are intentionally do not want to put templating engine into Crossplane. We don't want to convert it into helm type of stuff. But there is a need to do something like that. So we want to create a mechanism that will enable you to plug it in into whichever templating or code generation engine you want. Those are the few that come out from top of my head.

Marc (51:39):

Just from the top of your head to name a few. <laughs> Viktor, this has been really amazing. I know there's a great tutorial on on Crossplane.io and you have a tremendous presence online on your channels. I've listened to some podcasts you've done with some other people. What would you like to tell people about how to get involved and start using Crossplane?

Viktor (52:03):

Come to Slack, that's the first step!

Andy (52:06):

Awesome. 

Viktor (52:10):

I don't recall the last time any question or any request for help was left unanswered. It's a company mandate. It's not demanded, we want to do that. We're all in Slack all the time. We are all all the time monitoring for anything happening there. So the first step, join Slack, ask your questions. If you have an issue, anything, just be there and talk to us. That's on a company level. Of course, open issue for anything you found doesn't matter how silly or not silly it sounds contribute with your own Terrajet providers. If there is a provider that is missing, if there is something that you want to do, there is a tutorial, intelligent tutorial, and it will probably take you 15 minutes to go through the tutorial. You create your own provider, be nice, contributed back to the community. And finally, I have now outside of Upbound, I have a personal mandate that whomever contacts me directly, I sent them a Calenday link. Yeah, let's talk! Personally, I'm available to anybody for anything.

Marc (53:32):

This is really amazing. The enthusiasm that I see you bring, the openness, come to Slack is your first answer. That's really cool. I think Crossplane brings together a lot of amazing things. You've got community, you've got contributions from the community, you've got enterprise and contributions from enterprise. You are reducing complexity. I like the word configuration management. So I think that you're doing the world of service with the level of configuration management you're providing. This reaches all parts of the enterprise because you're able to have small platform teams that are able to take care of a large number of environments, developers still are able to configure the things they need. You're even reducing ticketing and handovers of information in enterprises, and you're not only doing all of the Cloud providers but also providing stuff for those who are still having to support on-prem so I applaud the work that you're doing here, Viktor with Upbound and Crossplane. And I'd like to really sincerely thank Viktor for joining and Andy for bringing you to us and being enthusiastic Eficode cheerleader for this. I'm not going to imagine you in a cheerleader outfit, Andy, but that's a different thought.

Viktor (54:52):

<laughs> I cannot take that thought out of my head now!

Marc (54:56):

Fortunately, this is a podcast. <laughs>

Hey, I'd like to thank our panelists very sincerely once again and this is Marc with the Eficode DevOps Sauna and we'll be signing off for today. Thank you.

Andy (55:12):

Thank you very much.

Viktor (55:14):

Thank you Andy and Marc.

Marc (52:04)
Thank you for listening. You can find Andy’s social media profile from the show notes, as well as related content we referred in the episode. If you haven’t already, please subscribe to our podcast, and give us a rating on your platform. It means the world to us. Also, check out our other episodes for interesting and exciting talks. Finally, before we sign off, I leave you with this. Take care of yourselves, and remember to make overall systems decisions instead of those only affecting your own work.