 Wonderful being here. Thank you all for coming. Today we have a great session. We are going to, no, let me tell you actually what we are not going to do. We are not going to go deep into why crossplane is awesome because simply it is or why you should use it. Matthias will talk about it later but the main goal of today's session is to show you actually to acknowledge that world existed before crossplane that you probably have already your infrastructure and services and other stuff defined in other tools. And what we are going to try to do is to show how you can transition from whatever you're using today. Today we are focused on Terraform into control planes, specifically control planes with crossplane. I have great three people with me here that know much more about the subject than I do. So I will let them speak instead. And as it always starts, every single meeting, every single event, it always starts with a product manager. So Matthias, you want to kick it off? I don't know if you want to introduce yourself quickly and then tell us about what we're going to listen to today. Yeah, thanks Victor. I'm not sure if everything starts with a product manager but I guess this time it does. So Matthias, look at one of the PM's at Upbound and yeah, just very briefly, we're the company behind crossplane and we're helping folks or customers to introduce Upbound in whatever enterprise fashion that meets. And we're building different products, different services and different building blocks that are most wanted and ready to be used in production. So I guess something that I do want to set a context a little bit of what we're doing and why we think this is exciting today is that the way that we are approaching needs of today's world is that we think a good amount of people need to provide an internal cloud platform. And by that what we mean is something that sits inside of your organization and acts like your kind of internal cloud to you. So instead of using a specific cloud, you are basically our idea or the approach that we're taking or advocating for is that you have something that needs to be defined and can be customized, can be different, but we have this something that acts as a mediator in between. Now we call this a control plane or a cloud platform that's built upon a control plane. And it has a couple of properties and I think it's not going to go through this. Victor is right. It's basically just awesome. It's the way that we think it should be run. But one thing that is important is if we're coming from a different world, I think it's important to understand that the way this thing is built upon is built upon Kubernetes and the core mechanics of Kubernetes. So if you look a little bit at it, the little bit of the tech stack that we're using is that we're building upon Kubernetes and a little bit like separated here are the different parts of Kubernetes and Kubernetes runtime to run the workloads, the machinery for the CRDs and open persistence, the controller runtime for the reconciliation. Long story short, we're building on this really awesome foundation of building a control plane runtime. And Crossplane just sits on top of it and acts, makes external APIs available to manage your infrastructure out there. And to get this running, there's different type of providers that you need. There's a couple of providers that the community has. There's a couple of providers that we from upbound also open source we provide to the community. And then you build your custom APIs on top of it. And it's for some kind of internal cloud platform you can think of like, I want my Acme database and that Acme database has a special type of interface that you want to act on. And these are the custom APIs that you're defining in a custom composition. And the part that is like the general theme of how we're looking at the world and how our customers, the crossplane community is looking at the world. And what is exciting about like is that, as Victor has said, we have, you're coming with, you're most likely not starting on a green field. You're most likely have something already, right? And this is something where we're going to talk about today is part of this provider ecosystem is actually we have a special type of provider and it's called provider terraform. And there are other providers. There's a provider Ansible, for example, and there's other kind of like utility providers. But today we're going to focus on provider terraform. And what provider terraform allows us, and we're going to walk through this or Yuri and Nuno are actually going to talk about it, is like how to get the code in there and how to run it and how to actually transition from one to the other. But the important piece is like, you know, we, what we are enabling here is building these, you know, these cloud platforms, these internal cloud platforms, as we call them, with existing code, right? And I'm generally excited about this because what it allows us is to reuse code. And if you think about all the projects, all the transition projects that you are working with, right, there's always this, you know, long roads, right, of things that you need to do, right? And it's important to have like stepping stones in there, benches that you can rest on, because, you know, there's going to be some other initiative coming down the road, and you might pause a certain journey, right? So I'm, you know, really, really excited about it to provide terraform to reusing existing knowledge and code for, you know, using different ways of migrating, including existing knowledge and existing organizational units, which we're going to learn about later. And you know, take a rest on this beautiful bench that Dolly just created for me half an hour ago. So with that said, you know, I'm handing it over to Yuri, I guess, or back to Victor, and he's going to tell you a little bit about like what this provider terraform is actually about. Yeah, it goes straight to Yuri. He's the terraform provider master, knows everything about it. So Yuri, tell us what's what's going on? Why do we have that provider? Yeah. So hi, everyone. I'm Yuri. I'm principal solution architect in a bound and I'm also one of the maintainers of provider terraform. So I should be sharing my screen. Please interact me if I'm not. Yeah. So provider terraform, why we created it in the first place. So first goal is pretty straightforward to be able to run existing terraform code on top of Kubernetes as a workspace managed resource as a part of cross brain resource model. So but this ability to run terraform code is very useful by itself, but we also cannot utilize the cross playing power of putting stable consumable API in front of your terraform code and include this terraform workspace managed resource into a composition. Community and customers identified provided feedback by several main use case of provider terraform. So one is pretty frequent and quite obvious one is automated mitigation of a conversion drift. So basically you inherited by design a Kubernetes style reconciliation behind provider terraform is going to run your terraform code continuously and converge your infrastructure to a desired state. As Matias mentioned, you probably already have some terraform code base and it is frequently not easily transferable to cross plain native abstractions. So provider terraform allows you to hook into existing terraform code terraform code models and code base into cross plain work. And we have a nice segue to a GitOps process. So you can use the workspace with the remote source style point to your existing Git repo, which that has terraform code. And in this scenario, provider terraform will act as a GitOps controller on Kubernetes site and we'll pull a newest terraform configuration for you and apply it to the target environment. And there is some interesting use case for advanced cross plain users and who are actively waiting for observable resource coming in. But before they will be implemented in the core cross plain, you can hook in terraform workspace with the terraform data source and pooling data from existing infrastructure and in regional composition and mixing these cross plain native resources. So I want to demonstrate an actual transition demo of and to things that you can do with a provider terraform. So before I jump into the CLI, maybe like a small layout of what we are going to do, we're going to take existing sample terraform code. We will create an abstraction and API interfacing with it with the help of cross plain XRD compositor sort of definition. We will include the terraform code into the composition and we will gradually migrate to a fully cross plain native scenario. So let's do it like. I'm switching to my console and before I do so, I will show you a GitHub view of it. It's a part, this example is a part of official a bound provider terraform. It resides under example transition so it can clone at any time and write on your site later on and try it yourself. So everything is open source. So first thing first, we want to just run the existing terraform code with a cross plain. Let's do it right away and let's investigate what we actually instantiated, so it's a kind workspace of an official provider terraform, TFA bound IO API group and we have a source type in line and we just embedding the terraform code in line with YAML just for demonstration purposes. It's like a simplest mode of execution and running terraform code with workspace and we have a variable within our workspace and we parameterize it with the specific variables. So here we are just propagating from a vars array the VPC name and we instantiating the VPC and associated submit. That's pretty straightforward. So we can after instantiation get this workspace as any other Kubernetes resource and we can make a describe of it and get a standard event stream. So it's all ready and we can double check on an AWS UI console that we have VPC instantiated. We have submit instantiated associated with this VPC and everything is acting according to scenario. So our terraform is already running with a cross plain on top of Kubernetes. Let's actually emulate a horrible configuration drift, right? So let's change the name and see what happens. So we emulated it by manually changing the configuration in console and after some reconciliation it should mitigate it. While it runs in background I want to show you an alternative way of executing the workspace and it will be a remote source, right? So I will not instantiate it just to show you the configuration. So we have a source remote and we just point into existing Git repo and this Git repo contains the same terraform code maybe this is just a standard terraform layout, right? According to the terraform configuration files and in this case we will just pull it in and also parameterize the device exactly the same style. So it's more close to production scenario. But for the sake of this demo and to keep everything on the same page and changing the configuration in the same single set of YAMLs I will stick with inline example. So let's check if our configuration drift was mitigated and it was so we changed we did nothing and controller changed the configuration back to the desired state mitigating the drift and changing the name tag on the VPC to our desired scenario. So that's a bare bone manage resource of workspace which is capable to execute any arbitrary terraform code terraform model and it is already parameterizable. What we can do with this ability next so utilizing if you get back to our plan with the slides you'll see that we probably want to create a control plane out of our terraform code using the core cross-plane capabilities. So let's try to define interface first. Sorry Yuri let me just interrupt you for a second. I like to kind of pause for a second here and go through the reasons why would we do this in the first place. You mentioned it directly that just by moving your terraform manifest into cross-plane we are getting continuous drift detection and continuous reconciliation and also I'm not sure whether you can think of other benefits I can think of some like integration with the CNCF ecosystem this could already be managed by let's say github tools like Argosy the Flux right we start at this point we already have the benefits that we typically associate with applications running in Kubernetes right connection with the ecosystem drift detection reconciliation github send quite a few others right. So this alone is already providing certain level of benefits and justifying the reason for getting to this stage. Right totally great point Victor so what we want to achieve as the next stage so we already have like this abstraction right in the workspace we can parameterize it so it's some form of API but what we want to achieve most probably with the cross-plane power is to have a very special abstraction like in this case we use abstract in a way implementation completely we will create a special custom API and what our platform consumers will see is this example subnet right which is by the way it is our very own API group as well which we will create for our special infrastructure our our platform and we abstract in the whole implementation way we are providing as many minimalistic spec as possible and our customers our platform users will see only what is to the left instead of implementation to the right and the implementation of a associated composition which we will show in the next stages it will be only something that platform builders will be exposed to and they will configure it on their side and the consumers will be just consuming very minimalistic effective and efficient interface which is going to be consistent and we also will be able to evolve implementation of the logic behind this API on the platform builder builder side without unnecessary exposure of implementation details to our customers and on top of that we also can integrate the stuff like RBAC namespace based operation and all the goodness that we have with the standard Kubernetes objects by abstracting it these composite resources and composite resource definition does it make sense answer your question it pretty much does thank you so we actually thank you Victor we can actually transit to the implementation of this specific API right so this this is example of the claim that is going to be exposed to our customers so how we can implement it first thing first we need to extend the existing API with a thing called compositor search definition which is part of the core crossplane capability XRD for sure it is very close idea to standard Kubernetes here the customer source definitions same style open API history schema but it operates in a crossplane resource model and here we are defining a set of composite resource like X subnets and a claim names just subnet so X subnet is a cluster scoped resource and subnet its namespace proxy so we are able to separate it by the team's namespace etc so let's just apply this definition and crossplane controller will pick it up and it will create a set of CRDs for us dynamically so I just got a list of CRD standard CRDs and we see that it's already created a composite resource different composite resource and a claim resource for our consumption so the API is already defined but nothing yet implemented so we are done with stage first we created the custom API and now we can create a special composition that we will run our terraform so here's the composition I'll actually instantiate it quickly and we'll run the associated claim in background and we'll explain what is actually happening that's it so so we created a composition which actually defines the composibility of the resources and we created an implementation behind the defined API so here what we did so it's a composition it's another core capability of a crossplane what we did we just put the workspace inside the composition and we provided a set of patches to propagate the values from the our custom API to the underlying workspace resource so if we look under the left pane we have a spec vpc name and we are propagating it to the underlying terraform variable of workspace resource and this way we are controlling the vpc name exactly the same style as we did before but now it's totally abstracted and we're also dynamically propagating the status field of the XR with dynamic arrays so let's let's check the status of this subnet right so again we can interact with our claim our custom API as a as any standard Kubernetes Kubernetes object and we can also get a managed managed resources underlying that were created by this composition by instantiation of this claim associated composite resource and you look into composition logic so we can see that workspace was created so currently it's exactly the same as it was before it just abstracted and we are encapsulating all the abstracting all the logic these are simple API you can super quickly check if it's deep the job there for that authentication session need to be updated and we back to vpc and we see the provider terraform demo terraform is instantiated here now in a fully abstracted way so it's already good we created pretty much a control plane out of our terraform code what if we want to take a next step and move to the crossplane native resources and to slowly minimalize the terraform footprint in our infrastructure so what we can do is move to the next implementation I will apply it as well and the claim in background and while the instantiating I will explain what is happening so here we defined another composition for exactly the same API the API stays the same and we took out the subnet configuration out of terraform code leaving vpc only and we amended the composition with crossplane native provider edibles managed resource of subnet so by the way you can find it here in our amazing marketplace right so all the associated definitions and documentation so in this case we are running two resources one is still a workspace tf so partial terraform code and another part of the composition is driving the crossplane native so we can check what is happening there so it is not yet ready but we can already try to investigate what is happening underneath so we are asking for managed resources that are controlled by this specific claim and by the way this label is dynamically set by a controller so it's very convenient in and of separations so in this case as expected we are running workspace tf and a subnet and exactly the same scenario was deployed on a edibles side but now we have a pretty much partially migrated to a full crossplane native resources and we kept exactly the same API so if we come compare the initial one and a current one nothing changed for our customers for our custom consumers right so it is exactly the same spec vpc name and what we changed was only composition selector that's it so and in a real scenario you can switch like the full composition so even composition selector can be not exposed to the customers and the label links is set as a standard kubernetes standard kubernetes way so it's a very nice integration so currently yeah quick question what are the advantages of reasons for doing this why not stay with terraform fully wrapped in crossplane so why would somebody move to crossplane native resources yeah another great great question Victor so in in this case we are starting the transition to crossplane native meaning like we have a dedicated reconciliation per resource so they are pretty like reconciling asynchronous way so and you you're reducing the food terraform footprint which is for example we can see here we reduced it in double in this even in this simple demo scenario right so basically we are trying to reduce the maintenance of underline hcl code and move to the very straightforward declarative abstractions that are produced by crossplane and necessarily it is usually it is more performant and and more granular right because whenever we migrate i will show it in an as the next stage we will have a like a resource by resource granularity and as i say that uh dedicated recall reconciliation per resource instead of whole terraform model and it will make it make system uh much more resilient when we switch to this full crossplane native way among other things that means better visibility into the actual state right because now i can start asking questions like hey what are all the vpc running in my system yeah and things like that right or subnets in this case yeah yeah because what is happening is a subnet right as i mean something went wrong so yeah it brings multiple advantages over different layers yep very great one so and speaking of these advantages now as the next stage we can uh migrate to a full crossplane scenario reducing terraform footprint completely for this demo and i will instantiate yet another composition and another subnet clean in vocation and we will explain what is happening so here as you can see the switching to a fully crossplane native implementation uh using a standard provider edibles uh dedicated resources of vpc and subnet and we're using standard controller references so we don't need to use the status for id patching and basically reducing the the amount of things we need to care about so adjust the crossplane based implementation and again from a consumption perspective it is exactly the same api still if you see name your customers are happy they probably don't even know that you got rid of terraform uh behind the scenes right and to and just to emphasize the the mixed scenario is also totally valid right so you can run at run the mix mode for a while assuming you're underlying terraform models are complex and hard to migrate so the beauty of it is that each stage is already useful so uh we can get the plane again uh we can check our plane native it's all true and let's check the underlying resources right to support our case what what it did create right now yep so not to care from workspace anymore it's vpc and subnet and everything is successful deployed and as you noticed we didn't touch this definition at all the just transition or the different versions of implementation with the composition underlying implementing the api so that's probably for the live demo and again we transfer through all the stages from terraform code up to crossplane native we demonstrated a very useful cases in between especially mixed mode and just to recap the importance of stability of the api with xrd right so we went through all the stages and the some faceted api was was stable all the time it was just a subnet for our customers with a simple spec and we only changed the underlying composition the implementation and gradually migrated to a full crossplane native scenario and that concludes my demo thank you so much back to Victor thank you i was about to say shut up you're over your time but uh we did it somehow uh now that was a demo from Yuri uh what we're going to do next is listen to bruno because he's bruno didn't say bruno no no sorry for that anyways he's been using telephone provider in production in the company where he works for about now and it would be great to see and hear his experience in a real-world scenario thanks Victor thanks for having me so i'm no no from millennium bcp um i work mainly in cloud compute automation and observability and for those who don't know millennium bcp we are the largest private bank here in portugal started in 85 always focusing on innovation so for instance most of our customers are now digital customers using our mobile apps and so on despite having 1200 branches over three countries but being innovation focused we started this automation journey for infrastructure three years ago rounding it and we started with Terraform as many people and three years of work put into it meant that we now have a module registry with 70 modules around 114 000 lines of hcl codes custom providers multiple targets of public and private clouds providers multiple tools around Terraform and we thought this is cool but now we want to move on and moving on meant that we needed to find a way to move this pattern that we have used to build our automation which is basically focusing on abstracting our it services we're not we're not doing uh oh let's do uh s3 bucket in automation that's for that for us is a building block uh in the bottom of it and we want to and we want to compose those blocks into abstractions that take care of all of the concerns of some it service so for instance in storage this would abstract authorization backups connectivity and all of that stuff so typically somewhat complex implementations that we needed to move on from why because we feel the need to align our dependencies life cycle with the app so our goal here is we deploy an app an app manifest and the infrastructure dependencies just happen and if you decommission an app if you delete it from the environment dependencies should move along just as well so these typical topics about configuration drift continuous compliance and because it's Kubernetes using common Kubernetes tools for policy for security for observability all of these were things we wanted to get going on our infrastructure as well so of course now first selecting what we wanted to move first we focus on application dependencies as i was saying focus also on green fields to start with and then going into migration patterns and of course basic rules for this migration and so we said things like uh first thing we need to do is have that standardized contract that standardized API that Yuri was showing for this abstraction it's these four variables no matter where it's implemented and then making sure that from now on we are going to represent that in crossplane as well as support legacies implementations in Terraform with this then we followed the pattern that Yuri was describing so first thing we moved were custom providers so we needed to expose the same custom provider logic to crossplane so Terraform custom providers were also implemented as crossplane custom providers and then okay let's do the IT service abstraction first to get that composition in place let's do some nested compositions for what we have as common patterns that we reuse across multiple compositions and of course try to reach a pattern for each one of these IT service abstraction stacks where we have end-to-end visibility of control plane resources control plane loops and the right management patterns in place using crossplane but of course what this roadmap brought us to were in many many of these cases uh challenges for what for the patterns we had implemented before so typically we did not end up in the same pattern we had in Terraform of course some things were upgraded some things were broken up into two different things and so on and we talked a lot about a common set of topics one app dependency for instance network what is the the app the trigger to deploy a subnet for instance or is it the other way around all of the multiple ways we have to manage secrets now what's going to be deployed when and app dependency life cycles were really something that we at at a couple points we had to stop and think about them also despite our push into crossplane we'd still do things in Terraform and the AC API provider is an example of something that we still use because it's in an r&d environment we do stuff there so we need to get us sorry to put these two side-by-side in and not have clashes in terms of life cycles so one of the things is maturity guys we will not go into v1 beta one status in a resource type type on both on crossplane and Terraform without making sure that implementation is in place so even do we even though we have r&d we have tests we have labs we have all of that okay that's the first maturity that we have and of course because we have legacy ground fields then we certainly hit a set of migration challenges complexity is one as I was saying three-layer approach we have some Terraform modules that have over 1,000 lines of code in there there are a lot of dependencies expectations choreographies and that's always a challenge those multiple maturity levels need to be thought of and managed as well as the multiple development agencies that come from this so because imagine we have Terraform modules that are still alpha okay that's cool but how do we align these up not making making sure of the maturity curves that we want to support and how we're going to be doing what in Terraform and in crossplane writing it out getting some ground rules on that that that was important for us and of course Terraform has some specific things like data source the observ only pattern here in crossplane Terraform has functions we needed to see how to implement the same business outcome with crossplane without using Terraform functions and that's our thing and then we get into users because we may set up all of this and be technically sound but okay people will stop writing HCL or referencing Terraform modules they need to be comfortable with writing custom resources and instantiating those resources for crossplane so training was certainly a thing and then this thing between eventual consistency which is a community's typical expectation then going down to a common line and saying tf apply for instance that is a is something for people to think and adapt and of course now that we have configuration drift and we have configuration drift now people needed time to understand what was happening what was touching the resources but with all of this sets our goal and we're really pushing forward and we are getting there and it's really valuable for our IT business is now that we've coupled applications and dependencies we can spin up an application anywhere and go through all of the application lifecycle quickly but securely with the right automation the right place with right observability for all of that process because we just focus on the application and the rest just happens and because we're focusing on those patterns now we get abstractions now implement abstractions we really don't have to copy paste bits of Terraform codes and because it's Kubernetes our focus now is let's write over rules and start validating stuff validating business and for instance in our case being a bank that's really valuable so back to you Peter. Thank you okay that was four of us me Matthias, Yuri, Nuno we have a couple of minutes left for questions I see that Matthias and Yuri were hard at work answering some of your questions and before we move into questions the few minutes we have left I must warn everybody that we will not be able to answer all your questions we don't have enough time but if you go to the crossplane slack channel ask a question there or copy paste the same question if you don't answer it we'll make sure to answer it if you tag Matthias or Yuri or me then even bigger chance that it will be answered faster. Matthias now commits to next two hours to dedicate only to your questions. Anyways let's see what do we what do we have here there yet the link to the slack Matthias just pasted is here in the chat so let's go to the first couple of questions as much time as we have so let's see this one when you're using Terraform workspace do you mean the known Terraform workspace I'm going to redirect this to Yuri I would say yes but Yuri is better than me in Terraform provider. Yeah good question so it's actually both so it is workspace manager source like a crossplane Kubernetes abstraction that is running underlying standard Terraform workspace so and propagating all the fields and data there. So if you if you define it and say use this storage for the state if there is nothing in that storage then it will start from scratch if there is already existing state it will take it over and continue right? Yeah right I think there were one of the next questions in a Q&A session so by default we are starting with a Kubernetes state so it's ephemeral but if you have and most probably you already have some Terraform state you want to migrate in a I did it the configuration of an S3 for example in a provider config and Terraform a provider Terraform can pick up the remote state as well and run your Terraform on top of Kubernetes so reusing the existing state is totally valid scenario. Okay what tells do we have here? Okay here's one from Leo what are the effects of crossplane reconciliation clown the vendor cost for example vendor API calls done by reconciliation loop to detect drift is there the vendors charge for API calls? I see nobody dares to answer I'm not sure whether they charge or not but yes they do I mean it depends on how you'll configure it etc right so it depends on like how how you want to set it up but usually yeah it's a it's a combination of the number of resources that your reconciliation and the number type of API and the frequency but that these are all knobs that you can tweak if there's any any problem with it. Yeah and there is a recent addition in core crossplane you can put put a so-called pulse annotation on specific manage resource in this specific case it can be workspace and pose a reconciliation loop for a while if you like them. Okay from Neil question does it work with Terraform CDK like TypeScript? No I didn't try it and CDK is not very actively this integration just exists but I'm not aware of its status so I wouldn't bet on it let's say. Okay from Jakub, in provided Terraform is it possible to pass the credentials file to Azure RM provider block in provider config? Do you know me? Right I think Nuno correct me if I'm wrong we did it through environment variables in case of Azure. Yeah yeah you're working yeah yeah so in case of Azure is it like I think the limitations there like style configuration is dictated by a Azure RM provider of Terraform right and this specific provider respects environment variables and not a not a file that's pretty much it. Yeah we have time for only one more question sorry in advance to everybody again go to Slack please go to Slack we can continue conversation so last question for today from Andrew sorry if I'm butchering your name. Crossland project is older than cluster API copy project it is by copy has been implemented I don't think that anybody here can answer that question why it was implemented it's good to have different projects that are tackling different aspects of the same space so to me that it's perfectly valid to have it and it looks like cross-plane already covered the creation of Kubernetes clusters. Now there is no question there really but I would like to commend that there is a huge difference between copy and cross-plane copy is focused on Kubernetes and Kubernetes only right while cross-plane is trying to cover essentially everything right given enough time frame to do it so copy cluster API is great but it is focused only and exclusively on Kubernetes clusters while with cross-plane you can manage Kubernetes cluster and you should but I don't know RDS databases subnets separately of Kubernetes clusters uh lambdas anything really so our goal is much wider than than the goal of cluster cluster API if anybody else wants to turn in go ahead given once given twice now cool sorry everybody I think that we are at the top unless the organizer of this I forgot her name tells us that we can continue and we are at the top of the hour or the end of this session so unless I'm told otherwise I will thank you everybody for joining listening thank you thank you guys for explaining how all this works and see you in the select channel thanks a lot Nuno for participating for joining I always love real world scenarios I mean Yuri has made a great example thanks a lot Yuri but also Nuno like you know how this is applied in real life thanks a lot for sharing thank you all so much for your time today and thank you everyone for joining us as a reminder this recording will be on the Linux Foundation's YouTube page later today we hope you'll join us for future webinars and have a wonderful day thank you so much