 My name is Lauren Johnson. Hello, and I'm Nick Cope. And we will be talking about outgrowing tear-borne. I am a software engineer at GuideWire, and I work on cloud infrastructure specifically in persistence type resources. GuideWire is a platform and a service company that caters to the property and has the insurance industry. And we're currently beginning our migration into cross-plane. So speaking of cross-plane, again, I'm Nick. I'm a software architect, software engineer working at Upbound on cross-plane. I'm on the cross-plane steering committee, and I've been working on cross-plane since shortly enough after it was open source. The founder's open source did about two years ago before working on cross-plane. I did a lot of work with tear-borne, so I'm a big fan of both. Okay, so GuideWire, prior to becoming a platform as a service company, we provided on-premise solutions to our cross-plane. Our development process used to involve developing complex software installations at our customers' offices. So the constant effort of doing so, of installing these snowflake onsite installations, is not very cost effective. It doesn't scale very well. And it takes a long time to upgrade because the installation will take a two-year process to get any features in there. So we decided to make a shift towards the cloud. So given GuideWire's long extensive history in property and casualty, we were set in a better position to try to unify, try to put our current customers on a platform where the ecosystem can better serve our customers. But to that point, we used Terraform to build our platform. It was, it aided us in our shift by being, you know, basically kind of, you know, just a good intermediate step into managing cloud resources. The implementation itself is similar to JSON, which a lot of developers are already used to. And so we were able to leverage that type of language to manage AWS resources. But as time went by, our platform is, you know, growing and getting large. And now we're maintaining, you know, about 73,000 lines of HCL. So now we're starting to, we're starting to, to fill some of the limitations of Terraform. We've, we really used the heck out of it. So one limitation that we've come to encounter is that one thing I didn't forgot to mention was the fact that our infrastructure is basically consisting of three layers. We have our account level configuration, which is one module. We have our infrastructure layer, which is another module that is built on the resources that the account level model provisions. And then we have our more customer facing module, our tenant module that uses those two previous layers to provisioned resources that the user did our customers can use to develop and customize our products. So having said that, one limit, limitation is drift. So Terraform defines our resources in a, you know, pretty much in a file. A, you know, you have one your Terraform file and you have your Terraform state. So, and they're stored either, well, the Terraform state is stored in a remote bucket. And the Terraform source of truth, what defines our actual, what defines what resources we need for a given module is stored in Git. So unfortunately, there's no way for these two pieces of information to be constantly and up to date with what is, you know, actually out there. So unfortunately, there, things happen like auto minor up, auto minor version upgrades or somebody in the state that goes in and into the console into the actual provider console and changes something. There's no way for Terraform to know until, you know, somebody comes along and tries to introduce another change. So you have to actively go in and manage and make sure and be aware when you introduce a change, you have to be aware of the plan. And as I mentioned earlier, our whole infrastructure is based on three Terraform modules that consist of hundreds of resources and several modules. So let's say you want to change a tag on one resource, if you were to do a Terraform plan or an apply, you have to be, you have to take into account that there might be drift. And your plan, if to make sure that your plan is not either, it's not basically worst case destroying another resource that you don't need to do. So if your plan says, hey, this resource is going to be destroyed or replaced because somehow this one, you know, field, it has an update to something that will basically, you know, it will force Terraform to destroy and replace it because it doesn't match the state. So anyways. So crossplane approaches. Managing infrastructure similarly to Terraform in that they both use declarative configuration. But a big difference that crossplane has is that it is a always on control plane. So whereas the open source version of Terraform at least is a is a command line tool that's invoked on demand. I know your guide wire uses it via CICD a lot. But you know, you can away that you can also invoke it from develop laptops and I like to learn we're saying part of the problem is Terraform doesn't know to go check the world unless you ask it to whether something has changed. So this can lead to surprises, you know, you go and run Terraform to go and update your caches and it's actually saying yeah, I'm gonna update your caches but also I notice your databases need updating as well and you weren't expecting that crossplane kind of approaches this by by leaning in to to constant reconciliation. So instead of checking the world whenever someone tells crossplayed hey, you know, I want to change something. There's sort of two levels with crossplayed first you tell you crossplayed I want to change something that crossplane saves that as its desired state and then it just sits there forever applying that desired state. So you need to be a little bit brave because it takes away the kind of the check that you get with Terraform where Terraform is like hey I'm going to go change this here's what I would change is this okay. Crossplane you say here go change this and then crossplane will just always be running every 30 to 60 seconds correcting any any problems and finds in the world. So if, for example, someone goes into AWS console and changes a database from 20 gig to 30 gig of storage crossplane will just change it back to 20 gig if that's what the source of truth is if you've trusted crossplane to manage that infrastructure. So kind of forces you to buy into crossplane you can't really fight crossplane. A nice thing about crossplane as well is that it doesn't have this big graph of of the world that Terraform computes to do sort of audit applications and things like that because crossplane is always running. It can be a little bit less tightly coupled it can be eventually consistent. So this means if you say hey crossplane go update this database. Hey, it is possible to just update that database regardless of what your caches are doing you just be like just update this one thing don't touch the others. Be if multiple things do need to change, they can all just kind of change when they're ready sort of thing. So crossplane can effectively go and apply changes to your database and if that changes block to a change to your cash or something like that. When your cash is ready crossplane just becomes ready. Another limitation that we have experienced is versioning. So again, I'm going back to that to the beginning our whole infrastructure revolves around basically three terrible modules. So, within those different modules. There are hundreds of resources again, several modules, and they pretty much all have to be within the same range of Terraform version, and a US provider version, in our case, a US provider version. So, if, again, if one layer needs to basically be applied they all every resource every module, which is controlled by different teams, especially in the tenant level. They, you know, we have to, they all have to basically be on the same version. So there was actually a case recently where my team wanted to introduce new Terraform feature. It was a new feature in Terraform 13 was you were not 13 would allow account on Terraform modules. So, because we're part of a single module from the perspective of our platform. In order to introduce that module we had to basically go through every module talk to pretty much every team that manages any resource and change their repo to get this one change out there for for us. So that was, it was an experience and the bright side is we got to talk to a lot of people, but the downside it took a month to introduce this to our platform. So, like, like Terraform crossplain users providers we have a core of crossplain that effectively has a package manager that delivers providers that manages what providers are installed, as well as managing configuration for providers. So the, you know, the, the declarative configuration of what you want to be running in the world. So providers are versioned in crossplain as well and honestly you can hit some some problems with with version you do need to be careful you could say for instance some providers can declare what version of crossplain they're compatible with it could be that you hit you want to install a new version and provide a SQL to manage your SQL databases but that needs a particular crossplain version and you've got provider AWS that needs a different incompatible version so it's possible to have version inconsistency in crossplain to incompatibilities. The other thing that makes the problem a lot simpler in crossplain is that because it is a service because it's a control plane that's just off running somewhere that doesn't, you know, need to have providers installed on different people's laptops and different providers configured for different, you know, modules of, of Terraform code in that example, you have a centralized place that you can go and upgrade your Terraform. Sorry, you're a crossplain providers. So you could just go to the crossplain control plane and say okay I'd like to install provide AWS and as long as it doesn't make breaking API changes. Everyone is now just running the new version of provider AWS. So it sort of takes some takes the problem of like what version of software is running and where it boils it down to like does a new version make breaking API changes and crossplain takes pretty seriously following the Kubernetes strict policies. So in Kubernetes resource versions everything V1 beta one or above has a pretty strict no breaking changes policy. So theoretically, in DeLorean's case where one team wanted a new feature, you should be able to upgrade to the new version of your crossplain provider AWS is just one place in your crossplain control plane. And then everyone should get access to that new feature, and everyone who doesn't want to use that new feature, everything should just have same defaults for them. That's how we sort of design their upgrade story. The one exception to this is alpha APIs we do have a API that rated V1 alpha 1234 etc. And those kind of all bets are off because we're still experimenting with the features there so we think we might actually put those behind a feature flag or something soon so that you know just really shows people. These are the ones that we don't provide that contract for there if you want to try them, but be aware that if you upgrade that might break. But for everything else all about V1 beta one and our core V1 APIs. It's a really safe upgrade path. One, another excuse me another access control, another limitation is access control again going back to our, you know at the beginning when I said that we are infrastructure is three different modules, lots of resources a lot, lots of sub modules in those layers. We actually provision I am roles for the next layer. So, for one layer we have for the account level where we have the provision the admin I am roles that will be used in the infrastructure layer, where we provision the resources, and then the next layer provides the I am roles for the tenant level, and whatever they, whatever that level needs to provision whatever resources they have. So it is essentially I am role food. We have eight areas to, to configure resources within our cluster, therefore has no concept of access control so we have to basically rely on the cloud provider to, and cloud provider in combination with, you know, clever naming conventions to get what we want down, you know, our walled garden. And as one of my colleagues put it for our developers. So, so yeah, so it kind of just undermine self service. It's not a lot of people so our admins have to be aware of a lot of different things so the user wants to do something. They have to go back and refer to us to or to ask us for access, instead of having it more of a more national configuration so there's a lot of I guess tribal knowledge amongst and it's a bunch of a bunch of a few teams to get this going so it's so instead of working on new features to expand the platform we're having to, to worry about a lot of special configuration that accomplish access control. So I think the fundamental nice thing about access control in crossplane. There's some technical details and sort of touch on but but sort of from a fundamentally the nice thing is that in crossplane access access control is framed around your business's concepts not necessarily your cloud providers not a US concepts. So I think I touched on briefly before that you can deliver these configurations to crossplane. And what these configurations include what we call compositions and composite resources, which are effectively your own custom API is so it guide wise case instead of saying a team has access to a US concepts like S3 buckets and maybe I think website policies or all the various things you can do with a bucket that API level. You can just come up with an opinionated guide why abstraction that might be like you know, a guide why storage or guide why bucket or guide why database it's actually made up of like multiple different things in the back end multiple different things. And because this is all done in the Kubernetes API, you can use Kubernetes are back to restrict this. As users credentials to talk to AWS obviously you need to give it credentials somehow, and it can load those from coup d'etre or it can like look from IRSA. Can you just give it a conflict file with sorry a secret I should say rather with your your AWS account keys. And you can even have multiple of those providers so you can say some of these resources you know this team are going to use this account this team is going to use that account etc etc. But it's kind of layered your grant cross playing access to act on your behalf on AWS or any cloud and any API that you call it. And then you use our back to restrict what people can ask cross playing to do on their behalf. So it allows you to frame access control along the lines of sort of can this person create a guide why bucket in this name space. You can rely on managing a ton of hyper granular AWS access controls behind the scenes something if you trust cross playing. You can limit the rights the cross playing has if you only ever want to use do buckets you can just give cross playing access to only do buckets so you can be as restrictive as you want. But you sort of shifts the access control up a layer into the Kubernetes API, where you're modeling your businesses needs not AWS API. Again, going to keep recapping our structure. So, basically, our infrastructure, the layers are very well one, the bottom layer is the okay so the top layer depends on the next one and then there's the next one depends on the bottom layer so tenant relies on the infrastructure which provides on the account level. So, there's no way within to perform itself for one for the tenant level to access what we've already provisioned for the infrastructure. So, they're just configured in isolation so even though the infrastructure level is necessary for the tenant to sit on top of. There's no way to actually access these resources or kind of right configuration where we can dynamically. I guess, use it to refer to that lower level. So we have to either rely on, you know, already knowledge that somebody knows to name this certain resources way like our, like, for example, our back end state file or state bucket that stores or tear from state file for the tenant has been provisioned by the infrastructure level so we already we follow in any convention and we just hard code the whole name it'd be nice. If there was a way that somehow the layer could just discover it and we don't have to worry about any configuration, but right now we have to do that. So, there is ways that tear from allows you to discover resources that exist like we do have, we do have to basically check to see if the cluster is there but it's again, it's something that's hitting Kubernetes directly, or there's a tear from just give you the ability to run a script that, you know, make an API call but again, you're, it's still directly hitting AWS, but you know we provisioned our resources be a tear form. Why would there should be a way to kind of query in that within the tool to get this get these resources. So I think the advantage that the cross plane has here is sort of the interoperability that comes from being a control plane with a rest API. So you know in terraform you could theoretically, you know you can run terraform and maybe write some output sort of thing but you end up having to sort of wrap terraform in a script sort of thing or start using complex shared state relationships and things like that to refer to other modules if that's if that's even a news case. Whereas with crossplane, everything is just an object in a rest API. So at the crossplane layer itself, we have, we have sort of ways of referring to things. So when you're composing infrastructure together sort of thing you can you can basically refer to. So when you have the infrastructure that you compose can potentially like reference other bits of infrastructure and say hey you should go be in this BBC I just tell you to go point to that BBC that's also model with crossplane and it'll kind of figure it out we built that at the manager resource layer. We also support basically many, maybe maybe most of our crossplane resources are able to write some or all of their interesting connection details to a secret to make it extra easy to compose to consume. I mean, again, everything's just a rest API so if you can write like a Python client of a rest API so you can pull out whatever you need to get from from crossplane. But if you're a pod or something like that and you want to make it like really easy to get like the connection details for a database, either because you want to consume it from an application because you're going to like build other infrastructure on top of it. Then you could say hey we're going to write this data to a secret and then something else you know pods can have built in machine or retail load up environment variables coffee files and that kind of thing from from secrets. One limitation that we that we need to figure out and crossplane in the moment that's on our sort of backlog is crossplane does not yet have anything like a terraform data source. So crossplanes really good at giving you information about stuff that crossplane manages but it's as yet doesn't have great functionality for giving you information about arbitrary other stuff. Let's say you know there's a there's a database running over there or a cluster running over there or VPC running over there that crossplate is not in charge of it's not the source of truth for its state. It's, it doesn't currently have any functionality to go and grab details about that thing. There's an escape hatch here at least which again is just that we exist within the Kubernetes API so while it's not the easiest thing in the world to write a Kubernetes controller it is possible to write your own code to interact with our API is and glue this together at the moment something so it's possible today with a bit of elbow grease and code and we aim to make it just a native part of the crossplane ecosystem suit. One last limitation I know earlier I said that ACL has allowed us to scale very quickly, and well, to allow us to get our platform implemented in a very, you know, in a relatively short amount of time. So where we're getting to we're starting to get a little bit more sophisticated with how we manage and we need and it's, it's, we're starting to understand that we need to work closer with the cluster so it's just turning into another thing to maintain our file isn't get our state is in this three, and then we also currently right now we're, you know, we run our QCTL clients so wouldn't it be nice if we could just you know kind of work a little bit more closely with the cluster have our Kubernetes resources and be closer to Kubernetes. So, yeah, so we can be more productive so we don't have to worry about again, you know where things are and in somewhere else that is not, you know, just lobby in the terminal and just messing around at that part. Just using just one one interface. So I think the, the advantage of the cross plane has here is pretty much the door and just touched on its tool and consistency effectively I think if you're a hypothetical organization that does not either use Terraform or Kubernetes and you're thinking hey I'd like to go manage my cloud infrastructure declaratively, probably about the same level of maintenance and burden and learning to go using the cross plane or Terraform. But increasingly we're seeing that a lot of people are just using Kubernetes already, you know they've already bought into Kubernetes for maybe managing their apps, you know so that developers are getting used to writing deployments for containerized apps or using something like you know just you know operating down to the coop CTL layer. So if they are doing that and they've you know the people have already invested invested in learning and maintaining Kubernetes. It's a smaller shift to sort of add a cross plane as a Kubernetes add on the users similar patterns basically run that off of that as a platform team to your users that it is to learn a different DSL for Terraform sort of thing and keep all the tooling running to get Terraform going you know CICD system or all that kind of thing and you know even further than just necessarily saying that if you know Kubernetes cross plane is easy to pick up we can sort of lean on the fact that again that it's hard Kubernetes is sort of like a really good rest API. So, even if you have developers who are to move with with Kubernetes, you could always position it as hey you can make these rest API calls to manage your infrastructure, you know if you're a Python developer or something like that, you can say hey there's a really well documented rest API for managing infrastructure if you don't want to go learn the intricacies of Kubernetes. So I think just again the wonders of APIs goes a long way here and just tooling consists to see the fact that everyone's kind of using Kubernetes but many people want people at this conference are using Kubernetes already. Okay, so right now, we are taking our first steps to integrating cross plane into our ecosystem, or I guess migrating on to cross plane. So right now we're working with my team in particular we're working with managing S3 via cross plane and another one of our teams is working with ECR or working with composing both of these resources and cross plane. So, yeah, so anyways, we, we are hitting the, we are experiencing the freshness of, you know, this bleeding edge technology, but the cross plane community has been very responsive and very helpful. Because again, you know, I'm, I'm very new to, you know, to Kubernetes and to all this stuff myself. But so maybe sometimes our questions are going to be a little bit obvious to folks that are a little bit more seasoned in the technology, but you know, again, everybody's been nice and helpful and, and maybe one day once you know our, you know, our team gets a little bit more familiar with Go and everything else which can contribute back to the community. Yeah, I'll say that speaking as sort of a cross plane steering committee, a person maintainer. One thing I really like about working with the folks at Guidewire as part of the cross plane community is that they really get the vision of the project and I think see a lot of the same value that we see in the project. You know, some people come to cross plane and they really, they really just want what we think of as like the core drivers they just, they just want to have raw APIs model in Kubernetes. And there's value in and of itself there that you know it's valuable by itself, but cross plane really sweats the separation of concern we really think of cross plane as a tool to build your own API is as a platform team that you can offer to your to your personal customers to the developers you support and guide wire from the get go just sort of saw that and has been looking at it that way. It's really, really nice, you know, we, not the only folks in the in the cross plane community to see that value by a long shot but definitely I've been very impressed seeing like guide wise internal presentations and things like that that really like get what we're doing. It's been a lovely to work with folks at Guidewire. Okay, and shout out to you, Janet Hill and James Dox and for helping us put together this presentation. And thank you for watching. Thanks folks.