Guides and Tutorials

Opinions and Insights

News and Announcements

Customer and Partner Stories

Featured

Press Releases

Subscribe to our Newsletter

Upbound

Crossplane

Kubernetes

Marketplace

Terraform

Solutions

<h4>Upbound, creator of Crossplane, is now a certified VMware Tanzu Application Platform partner</h4><p>The developer experience can mean a lot of things. To level-set and simplify, let's go with the notion that it is all of the feelings software developers have while producing and publishing their code. Mostly, it measures their level of aggravation during the process. In other words, how many interruptions in their work flow they have to endure. In today's environment, where there is the desire to move fast and securely, the developer experience is usually disappointing.</p><p>Today, Upbound and VMware are working together for the better and celebrating a new partnership for the benefit of the Crossplane community and enterprise users. Let's see how Upbound and VMware are teaming up to build a completely satisfying developer experience.</p><h2>About Upbound &amp; UXP</h2><p><a href="https://www.upbound.io/" target="_blank">Upbound</a> is the company behind open-source CNCF <a href="https://www.crossplane.io/" target="_blank">Crossplane</a>. Crossplane utilizes the Kubernetes resource model to expose reusable APIs to build cloud services. Essentially, it is a framework to create control planes to deliver a standardized experience to consume cloud services. <a href="https://www.upbound.io/product/universal-crossplane" target="_blank">Universal Crossplane (UXP)</a>, is Upbound's fully tested and supported version of OSS Crossplane.</p><h2>About VMware Tanzu Application Platform</h2><p>VMware <a href="https://tanzu.vmware.com/application-platform" target="_blank">Tanzu Application Platform</a> is an end-to-end integrated platform solution that enables companies to build and deploy more software, more quickly and securely, through a rich set of developer tooling and a pre-paved path to production. Teams can build golden paths to production from the first lines of code, to delivery, to production. VMware Tanzu Application Platform is modular and flexible, with the ability to plug in multiple solutions into your organization’s custom golden paths.</p><h2>Before Tanzu Application Platform Met UXP</h2><p>Individually, UXP and Tanzu Application Platform help improve the developer experience. UXP provides APIs to build standardized cloud services and Tanzu Application Platform enables all the appropriate tools to build and ship software to be plugged in. However, until now, there was still aggravation when a developer needed to build a supporting service to test or deliver their code. Not only did they need to know how to build their services, they also needed to know the approved ways and how to connect the services to their application. Unfortunately, this aggravation was what caused a lot of ad-hoc creation of services leading to cloud sprawl—an increase in potential security holes and a decrease in overall quality.</p><h2>The Integrated Experience</h2><p>Today VMware has added Upbound as a Tanzu Application Platform partner. With UXP and the <a href="https://tanzu.vmware.com/content/blog/tanzu-application-platform-1-5-ga" target="_blank">release of Tanzu Application Platform 1.5</a>, developers can now utilize the UXP powered APIs within their existing workflow with no additional headaches. Cloud services can be automatically provisioned and connected to their code in a platform-team approved way automatically! Current UXP or Crossplane users will be able to utilize any CompositeResourceDefinition (XRD) created by UXP in Tanzu Application Platform workflows.</p><blockquote><p>“We’re excited to be partnering with Upbound and build on the innovation provided by Crossplane as we continue to meet customers where they are in their platform journey. VMware Tanzu Application Platform and Upbound can support Platform Engineering and Application Development teams with a seamless experience to provision and connect to the data services they need. Together, we’re able to help customers embrace the OSS tools and cloud services of their choice, while providing enterprise support and security best practices," Samuel des Baux, Director Tanzu Application Platform – Cloud and Services, VMware.</p></blockquote><p>Currently, in order to use both UXP and Tanzu Application Platform together, they must be installed and managed on the same Kubernetes cluster. However, with the release of <a href="https://blog.upbound.io/upbound-general-availability">Upbound and managed control planes</a>, Tanzu Application Platform will be able to consume APIs available on Upbound.</p><h2>What’s Next?</h2><p>To find out more about the UXP integration with Tanzu Application Platform check out this joint webinar, <a href="https://resources.upbound.io/all-content/achieve-a-fully-automated-devops-experience-with-universal-crossplane-and-vmware-tanzu-application-platform" target="_blank">"Achieve a Fully Automated DevOps Experience with Universal Crossplane and VMware Tanzu Application Platform"</a> or learn more in the <a href="https://docs.vmware.com/en/VMware-Tanzu-Application-Platform/1.5/tap/crossplane-about.html" target="_blank">tech docs</a>.</p><p>If you’re curious about Upbound and what we can offer, try our latest product offering, Upbound, for free. Enable SRE teams with a more efficient workflow and the building blocks of platform engineering by setting up your first cloud platform powered by Upbound’s managed control planes. <a href="https://upbound.io/register?ref=blog.upbound.io" target="_blank">Sign up for your 30 day free trial here</a>!</p>

Upbound and VMware Tanzu Application Platform Partner to Deliver a Completely Satisfying Developer Experience

<p>Welcome to the latest Upbound Resource Roundup! Last month, we delved into a spectrum of tailored solutions. This month, we’re going to dive into a few more that will help you streamline platform team operations with Upbound's versatile capabilities powered by Crossplane. Here are some resources that can help you stay ahead in the ever-changing cloud-native landscape and achieve cloud native excellence.</p><h2>New Resources From Upbound</h2><p><a href="https://blog.upbound.io/upbound-announces-new-crossplane-reference-implementation-for-cnoe">Upbound Announces New Crossplane Reference Implementation for CNOE</a> – Upbound announced a practical application of Crossplane's capabilities through a new reference implementation for Cloud Native Operational Excellence (CNOE)! Now, you can start spinning up more resources within this powerful stack, customizing it to fit your specific needs.</p><p><a href="https://blog.upbound.io/k8s-is-not-the-platform-or-is-it-and-we-all-misunderstood">K8s Is Not the Platform – Or Is It and We All Misunderstood?</a> – Stefan Schimanski, a long-time Kubernetes expert, takes a look at Kubernetes and Crossplane as the core of a developer platform beyond container orchestration.</p><p><a href="https://blog.upbound.io/ai-ml?utm_medium=email&amp;utm_source=email-newsletter&amp;utm_term=blog">AI Made Easy: Your Guide to Fast and Reliable AI/ML Workload Deployment</a> – The AI and ML landscape of software, tools, and techniques is growing larger by the hour. Let’s take a look at how you can build a platform to get ahead in the AI/ML race.</p><p><a href="https://blog.upbound.io/2023-11-07-product-updates?utm_medium=email&amp;utm_source=email-newsletter&amp;utm_term=blog">New from Upbound: Dashboard Filtering &amp; Control Plane Explorer Flow Enhancements</a> – See new enhancements in the Upbound Console to share – from improvements to the user flow in the control plane explorer, to new filtering functionality in the control plane dashboard, to linked references in the resource details view to support debugging.</p><h2>Crossplane Highlights</h2><p><a href="https://blog.crossplane.io/crossplane-v1-14/" target="_blank" rel="noopener noreferrer">Crossplane 1.14 is here</a> – This month, the latest version of the Crossplane open source control plane framework was released. It is packed full of big features that will make Platform Engineers more productive and effective in building control planes to power their infrastructure.</p><p><a href="https://blog.crossplane.io/design-compositions-for-your-organizational-needs-with-crossplane/" target="_blank" rel="noopener noreferrer">Design Compositions For Your Organizational Needs With Crossplane</a> – This article is for curious individuals with specific requirements for building and operating cloud infrastructure efficiently along corporate guidelines, governance, security, and the breadth of systems that can be configured and resource lifecycle managed with Crossplane.</p><p><a href="https://blog.crossplane.io/platform-building-with-crossplane-your-questions-answered-at-control-plane-day-with-crossplane/" target="_blank" rel="noopener noreferrer">Platform Building with Crossplane: Your Questions Answered at Control Plane Day with Crossplane</a> – A few months ago Crossplane hosted Control Plane Day with Crossplane event. The event was a smashing success with hundreds of attendees and some outstanding talks from both maintainers and users. Here are some answers to all of the most-asked questions from the event.</p><h2>What’s Next?</h2><p>Interested in seeing these updates in action? Our team is on standby to walk you through it! <a href="https://www.upbound.io/request-a-demo">Request to have a live demo with them now</a>.</p>

Upbound Resource Roundup: November 2023

<p>Provisioning infrastructure should never be seen as a barrier to developer velocity. In fact, platform teams often seek to deploy Kubernetes Clusters-as-a-Service to provide developers with a streamlined and efficient environment for deploying and managing their applications. One significant advantage of offering Cluster-as-a-Service is the abstraction of complex infrastructure management.&nbsp;<strong>Upbound makes</strong>&nbsp;<a href="https://www.upbound.io/solutions/cluster-as-a-service"><strong><u>Cluster-as-a-Service</u></strong></a>–and many other self-service deployments of cloud-native infrastructure and applications–<strong>easy for developers</strong>&nbsp;and manageable for the platform team. Let’s explore why it’s essential for any platform team and how it’s done!</p><h2>Complexity is the enemy of developer velocity</h2><p>When dealing with complexity,&nbsp;<strong>abstractions are super important</strong>. A good abstraction will allow ease-of-use while still providing control over the complexity that lies underneath the surface. In the case of Cluster-as-a-Service, developers can focus on writing code and building applications without the need to worry about the underlying cluster setup, scaling, or maintenance. This abstraction reduces the learning curve for developers, allowing them to quickly leverage the power of Kubernetes for container orchestration without becoming Kubernetes experts.</p><p>Furthermore, enabling Clusters-as-a-Service offers scalability and resource optimization. Platform teams can configure and manage the clusters to suit the specific needs of different applications and services, ensuring optimal resource utilization. Developers can request and provision Kubernetes clusters on-demand, which leads to more efficient resource allocation, reducing costs, and minimizing infrastructure waste. By standardizing the deployment process with Upbound, platform teams can also enforce best practices, security policies, and compliance standards across all applications, enhancing the overall stability and security of the platform. In short, Clusters-as-a-Service, when done correctly, means&nbsp;<strong>faster development cycles and more reliable applications</strong>.</p><h2>Control planes offer the best of both worlds</h2><p>Upbound started the&nbsp;<a href="https://www.crossplane.io/"><u>Crossplane project</u></a>&nbsp;and now also offers the&nbsp;<a href="https://www.upbound.io/product/upbound"><u>Upbound platform</u></a>&nbsp;to solve this very problem. By using control planes, developers get a simple API to interact with based on the configurations and definitions that the platform team specify and maintain. Since these configurations can be reconciled when changes are made, the platform team can obfuscate all the gory details while&nbsp;<strong>reducing</strong>&nbsp;<a href="https://blog.upbound.io/true-cost-of-configuration-drift"><strong><u>configuration drift</u></strong></a><strong>&nbsp;and tickets for failed deployments</strong>.</p><h2>Let's try it!</h2><p>Let’s say you are a member of a platform team. One of your goals is to improve the speed and reliability of infrastructure deployments by offering a self-service option for your developers. Perhaps you have the following requirements:</p><ul><li>Create an API for fast, easy deployment</li><li>Multiple deployment options (different cloud providers, regions, business units, etc.)</li><li>Changes must be easily reconciled</li><li>Control of every aspect behind the scenes</li><li>No scripts since they cause configuration drift!</li></ul><p>We will use the Upbound platform to get everything set up in just a few minutes. If you are following along, you will first need to&nbsp;<a href="https://upbound.io/register"><u>sign up for a free trial</u></a>&nbsp;or use an existing Upbound account. If you are signing up for a free trial, you can follow this&nbsp;<a href="https://docs.upbound.io/quickstart/multicloud-deploy/"><u>detailed Quickstart Guide</u></a>&nbsp;if needed. You’ll need to create an organization and add your GitHub credentials at some point. If you’re a returning user, you can get started by heading over to the Configurations section of Console and hit "create new control plane".</p>

<p>You can fill out a few details to clone the example configuration into your Upbound account so you can use it. As part of this process, Upbound automatically creates a Git repository in GitHub on your behalf. After Upbound creates your repository, it watches for new commits to the main branch. For every commit, Upbound automatically attempts to build the Configuration package for you. If it’s successful, you can then upgrade the definition on your managed control planes.</p>

<p>After a few seconds the configuration will be cloned and a window will appear prompting you to create a new control plane to install this configuration onto.</p>

<p>That’s it! Sit back and watch as your new control plane and APIs are configured. You can review the information about the control plane that you just created.</p>

<p>The control plane will take only 5–10 minutes to provision. While you are waiting, be sure to check out the documentation to learn more about control planes and how to interact with them.</p>

<p>After a few minutes, your control plane with the example configuration will be ready to use&nbsp;<strong>without writing a single script</strong>. As you can see,&nbsp;<strong>we now have Cluster-as-a-Service APIs</strong>&nbsp;created for AWS, Azure, and GCP.</p>

<p>Of course, before you can start rolling out infrastructure you need to configure access to whichever cloud provider you will be using. To do that, click on the Providers tab, choose one of the cloud providers and create a ProviderConfig. This will be different for each cloud service so we have put together&nbsp;<a href="https://docs.upbound.io/quickstart/multicloud-deploy/#authenticate-with-providers"><u>some documentation</u></a>&nbsp;that covers the process.</p>

<p>The next step would be to enable these APIs to be used in whatever developer frontend you are using. This could be Backstage, Port, or anything else. Just as an example, you could click on “Self Service” and choose Control Plane Portal.</p>

<p>Click on one of the APIs on the left of the screen and then click the “Create New” button. This will bring up all the required fields that were defined in this example that are necessary to deploy a new cluster. However, outside of this demonstration, this could be whatever you require. For example: namespace, region, number of required nodes, instance size, etc. The beauty of a control plane is that it can be defined however you need it to be. You are not locked into someone else's vision for how things should work.</p>

<p>We will stop here as we have met all the objectives so far:</p><ul><li>Setup an API for fast, easy deployment</li><li>Multiple deployment options (different cloud providers, regions, business units, etc.)</li><li>Changes must be easily reconciled</li><li>Control of every aspect behind the scenes</li><li>No scripts since they cause configuration drift!</li></ul><p>However, there is so much more you can do with Upbound and control planes. For a more complete look at setting up an internal developer platform in your organization be sure to check out&nbsp;<a href="https://blog.upbound.io/7-core-elements-of-an-internal-developer-platform" target="_blank">this blog</a>. Don’t forget that you can&nbsp;<a href="https://www.upbound.io/register/a" target="_blank">try this for free right now for 30 days</a>&nbsp;and be sure to contact us with any questions you might have.</p>

Using Upbound to Roll Out Cluster-as-a-Service to Your Developers

<p>Upbound’s cloud-native infrastructure management platform is now available in the <a href="https://aws.amazon.com/marketplace/pp/prodview-ksv3yjcqod3kg?sr=0-3&amp;ref_=beagle&amp;applicationId=AWSMPContessa" target="_blank">AWS Marketplace</a>, empowering AWS customers to build, deploy and manage cloud services from a single point of control using Crossplane control planes. AWS customers use Upbound for multi-cluster management, cloud service provisioning, and building complete internal developer platforms.</p><p>Customers can now access the Upbound platform directly from the cloud provider using the new integration with AWS Marketplace. Like other products available on the AWS Marketplace, Upbound meets AWS’s security and solution design requirements.</p>

<h2>Key customer benefits of purchasing Upbound through AWS Marketplace</h2><ul><li>Use existing AWS accounts and budgets to purchase Upbound software, accelerating planned projects and strategic cloud migration objectives</li><li>Flexible purchasing and consumption program options</li><li>Negotiate Upbound software procurement pricing using AWS Marketplace Private Offers, where the customer negotiates pricing and terms directly with Upbound to transact through marketplace</li><li>Cost-effective, faster procurement: AWS Marketplace purchases count towards customer commitments under the terms of their Enterprise Agreements. Purchasing Upbound through AWS Marketplace simplifies approvals by enabling “Click to Buy” through your Master Payer Account with AWS</li><li>Simplified billing: Customers get a single consolidated AWS invoice for all the purchases made through the AWS Marketplace with complete visibility over their spending in a single location</li></ul>

<h2>Upbound features</h2><ul><li>Creates a platform for deploying clusters, databases, networks, AI/ML, and other workloads that can be used as part of a internal developer platform to increase velocity, meet compliance, and reduce risk</li><li>Deploy and manage Crossplane control planes at scale, with Upbound managing the underlying infrastructure and auto-scaling control plane resources</li><li>Manage major and minor upgrades of core components on behalf of the user, including automatic snapshotting of platform state for disaster recovery</li><li>Command and Control Center for Day 2 Crossplane operations</li><li>Console enabling users to view control plane usage, manage operations, debug API calls passing through users control planes, and integrate with logging and monitoring solutions</li><li>Available for consumption as both SaaS and self-managed deployments</li></ul>

<h2>Resources</h2><ul><li>Upbound is available as a <a href="https://www.upbound.io/register/a" target="_blank">free trial</a></li><li>Upbound is available as an <a href="https://aws.amazon.com/blogs/awsmarketplace/deploy-third-party-software-add-ons-aws-marketplace-amazon-eks-clusters/#:~:text=The%20following%20third-party%20software%20products%20are%20ready%20to,Agent%204%20Factorhouse%20%28KPOW%29%205%20Tetrate%206%20Teleport" target="_blank">EKS add-on</a> from the EKS management console</li><li>AWS’s blueprints for deploying &amp; using <a href="https://aws.amazon.com/blogs/opensource/introducing-aws-blueprints-for-crossplane/" target="_blank">EKS</a> and <a href="https://docs.aws.amazon.com/lambda/latest/dg/with-kubernetes.html" target="_blank">Lambda</a> with Crossplane</li><li><a href="https://youtu.be/0U51OeJJHQ0?feature=shared" target="_blank">Best practices</a> for architecting an internal developer platform with AWS and Crossplane</li><li>Upbound’s Open Source Marketplace, with <a href="https://marketplace.upbound.io/configurations/upbound/platform-ref-aws/v0.8.0" target="_blank">AWS reference architectures</a> to get started</li><li>Read about the new OSS standard<a href="https://cnoe.io/" target="_blank"> CNOE approach</a> to building internal developer platforms, and try the <a href="https://marketplace.upbound.io/configurations/upbound/platform-ref-aws-cnoe/v0.1.0" target="_blank">Upbound CNOE reference platform</a></li></ul><h2>What’s Next</h2><p>Check out the <a href="https://aws.amazon.com/marketplace/pp/prodview-ksv3yjcqod3kg?sr=0-3&amp;ref_=beagle&amp;applicationId=AWSMPContessa" target="_blank">Upbound listing</a> on the AWS Marketplace, sign up for an <a href="https://www.upbound.io/register/a" target="_blank">Upbound free trial</a> and learn more about deployment and purchasing options in the AWS marketplace. If you are interested in talking with Upbound please <a href="https://www.upbound.io/contact" target="_blank">contact us here</a>.</p>

Upbound is Now Available in AWS Marketplace

<p>Upbound announces a practical application of Crossplane's capabilities through a new reference implementation for <a href="https://cnoe.io/" target="_blank">Cloud Native Operational Excellence (CNOE)</a>. This example demonstrates how <a href="https://www.crossplane.io/" target="_blank">Crossplane</a>, a powerful open source control plane, serves as a valuable starting point for organizations navigating the complexities of cloud-native development.</p><h2>CNOE + Crossplane</h2><p>CNOE, supported by industry leaders such as Adobe, AWS, Autodesk, Salesforce, and Twilio, aims to simplify developer tooling and guide informed technology choices. However, current tools for building Internal Developer Platforms (IDPs) lack practicality, leaving organizations with the challenge of assembling components for effective cloud-native operational excellence.</p><p>Enter Crossplane, a robust open-source control plane created by Upbound and governed under the Cloud Native Computing Foundation (CNCF). This tailored example provides a seamless entry point for platform teams eager to initiate their <a href="https://www.upbound.io/solutions/internal-developer-platform" target="_blank">IDP</a> journey, showcasing Crossplane's potential in simplifying cloud-native operations.</p>

<p>Crossplane is a key component of CNOE, and with today’s announcement, engineers have an easy way to get started with best practices in building a control plane as the foundation of their IDPs.</p><h2>Benefits Simplified</h2><p>By highlighting this Crossplane configuration, organizations can explore the potential of Crossplane and the Upbound platform in a straightforward manner. Standardizing on Crossplane can help build a robust foundation for your cloud-native stack and accelerate the creation of IDPs. This is a practical illustration, inviting organizations to delve into the unique benefits and ease of use that Crossplane brings to the cloud-native operational landscape.</p>

<p>While this example is demonstrated with AWS, it's essential to note that it's designed as a starting point. Modifying basic configurations for Azure or Google Cloud is a small task with predefined configuration packages.</p><h2>Hands-On Overview in 3 Steps</h2><p>Ready to get started with Crossplane and CNOE? Follow these simple steps:</p><ol><li>Go to the <a href="https://marketplace.upbound.io/" target="_blank">Upbound Marketplace</a> and search for <a href="https://marketplace.upbound.io/configurations/upbound/platform-ref-aws-cnoe" target="_blank">platform-ref-aws-cnoe</a></li><li>Install this configuration to your cluster with "Install Manifest"</li><li>In just minutes, you'll have your first IDP up and running. This includes a Kubernetes Cluster with Network, ArgoCD, Backstage, and Keycloak as SSO.</li></ol><p>Now, you can start spinning up more resources within this powerful stack, customizing it to fit your specific needs.</p><p>If you want to contribute to the project you can head over to <a href="https://github.com/upbound/platform-ref-aws-cnoe/" target="_blank">platform-ref-aws-cnoe in GitHub</a>.</p><p>Unlock the potential of Crossplane and kickstart your cloud-native journey today with Upbound!</p>

Upbound Announces New Crossplane Reference Implementation for CNOE

<h4>Bringing structure and security to the Kubernetes type system with Crossplane packages.</h4><p>Organizations running on Kubernetes have been steadily moving to a multi-cluster approach. The life-cycle of any individual cluster is relatively short and provisioning new clusters is a common occurrence. There are a variety of factors leading to this shift, including:</p><ol style="list-style-type:decimal;"><li><strong>Availability</strong>: more clusters means that losing any one cluster is not catastrophic.</li><li><strong>Isolation</strong>: while RBAC and Namespaces provide isolation within a single cluster, utilizing multiple clusters allows for cluster-scoped isolation, and physical isolation when necessary.</li><li><strong>Scalability</strong>: depending on the nature of your workloads, the various components that make up a Kubernetes cluster may not scale to accommodate your use case. One such example is the API server struggling to handle a large number of Custom Resource Definitions (CRDs), as detailed in a <a href="https://blog.upbound.io/__GHOST_URL__/scaling-kubernetes-to-thousands-of-crds/">recent post</a> by my colleague <a href="https://twitter.com/internegz" target="_blank" rel="noopener noreferrer">Nic Cope</a>.</li></ol><p>This is not a comprehensive list, but the reasons listed are broadly applicable to many organizations. Mitigating these issues has been compelling enough to drive them to adopt a more complex architecture.</p><p>As organizations have moved into this new world, there has simultaneously been an explosion in the number of CRDs and controllers that are installed in a given cluster. This greatly enhances the capabilities of Kubernetes, but also increases the management burden of replicating the same custom API across many clusters. As a result, interacting with a Kubernetes cluster has become more like writing a program, but without any of the safety or guarantees offered by a modern programming language. In this post, we’ll explore why a lack of API compatibility can lead to dangerous and unpredictable behavior, and how Crossplane packages make it possible to present a verifiably consistent programming interface across multiple clusters.</p><h2>The Perils of an Unknown API</h2><p>What can actually go wrong when API’s diverge across clusters? There are multiple possible outcomes, listed below in order of increasing severity.</p><ol style="list-style-type:decimal;"><li><strong>The “Early Conflict”</strong>: an object being created violates the type definition (CRD) in one cluster, but not the other. This is the best case scenario, but still presents a poor user experience to the developer.</li><li><strong>The “Hope I’m Not On-Call”</strong>: The object is successfully created in each cluster, but only reaches a healthy status in one due to divergence in reconciliation logic, which is decoupled from the definition of the type.</li><li><strong>The “Sleeper Agent”</strong>: The object is successfully created in each cluster, and both reach a healthy status, but reconciliation logic has performed different operations in response.</li></ol><p>In each of these scenarios, a stronger type system could surface these issues prior to creating the object. We are specifically looking for the following attributes:</p><ul><li>Verification that type definitions are equivalent across clusters.</li><li>Verification that reconciliation logic is equivalent across clusters.</li></ul><p><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">Crossplane packages can offer these guarantees, but before exploring how, let’s examine how the Kubernetes type system compares to that of popular programming languages.</span></p><h2>What’s a type?</h2><p>Despite the ever-growing API surface area and the movement to a multi-cluster world, we have not seen a fundamental change in Kubernetes architecture. This is mostly a good thing; the stability and predictability of Kubernetes is a major factor in its widespread adoption. However, when we drastically change how we consume Kubernetes, we must also consider the impact that has on how we configure it. One of the most pronounced differences in configuring a Kubernetes cluster in a multi-cluster world is the scoping of types.</p><p>Kubernetes comes with some built-in types - <code>Pods</code>, <code>Deployments</code>, etc. - and allows you to define your own with CRDs. This is not dissimilar from most programming languages: there are built-in primitive types, such as <code>boolean</code>, <code>integer</code>, etc., but there are also user-defined types, which may be defined via a built-in type, such as a <code>struct</code>.</p><blockquote><p>I <a href="https://danielmangum.com/posts/the-missing-kubernetes-type-system/" target="_blank" rel="noopener noreferrer">have argued</a> that types defined by CRDs directly are, or should be, considered built-in types, but that’s a conversation for another day.</p></blockquote><p>User-defined types are typically scoped - they are identified relative to where they are defined. For example, in the Go programming language I can define a <code>MyType</code> in the <code>cooltypes</code> package. I can also define a <code>MyType</code> in the <code>okaytypes</code> package. The identifiers for these types internally are <code>cooltypes.MyType</code> and <code>okaytypes.MyType</code>, allowing them to be distinguished when consumed.</p>

<p>Zooming out even further, the packages are hosted somewhere on the internet, or at a location on my local machine. This adds further specificity to their scope, guarding against any collisions with another <code>cooltypes</code> package that may be hosted elsewhere. However, with these two types having identical definitions, do we really need to distinguish one from the other? As with many topics in computing: it depends.</p><h2>Defining Equivalence</h2><p>There are two popular mechanisms for defining equality in a type system: <strong>nominal equivalence</strong> and <strong>structural equivalence</strong>. Nominal equivalence defines two types as being the same if they have the same name. For example, in the following example, the types of variables <code>a</code> and <code>b</code> are considered equivalent, but the type of <code>c</code> is not considered equivalent to <code>a</code> or <code>b</code>.</p>

<p>This is because Go, like many languages, uses <strong>nominal equivalence</strong> when evaluating equality of types. Importantly, the <i>name</i> of the type in this context is referring to the fully qualified name. If we compile this program and look at the symbol table, we can see each of the two unique type names defined:</p>

<p>In a language that uses <strong>structural equivalence</strong>, such as TypeScript, OCaml, Haskell, and more, <code>cooltypes.MyType</code> and <code>okaytypes.MyType</code> would be considered equivalent because their members (i.e. <code>Message </code>and <code>ID</code>) are equivalent. In fact, Go uses structural equivalence when evaluating whether a given type implements an <code>interface</code> (i.e. the <i>structure</i> of the methods are equivalent).</p><p>In Go, dependencies are pinned at the <a href="https://pkg.go.dev/cmd/go#hdr-Modules__module_versions__and_more" target="_blank" rel="noopener noreferrer">module level</a> (we are going to skip over the new <a href="https://go.dev/blog/get-familiar-with-workspaces" target="_blank" rel="noopener noreferrer">workspaces</a> flow added in 1.18 for this post). When a new dependency is added, the go.mod file is updated with a reference to the location of the module, and the <a href="https://go.dev/ref/mod#go-sum-files" target="_blank" rel="noopener noreferrer">digest of the content of the package</a> (and any transitive dependencies) is added to the <code>go.sum</code> file. This makes it such that you, or anyone else who is adding code to the module, are able to verify that the type you are creating an instance of is exactly the same as it was last time, barring any change in the <code>go.mod</code> or <code>go.sum</code> files. It also means that we can easily verify whether two types in separate modules are equivalent by ensuring that they are nominally equivalent, then comparing the checksums of their source modules. This is not something that is typically required when writing programs because creating instances of types is typically scoped to a single code base (i.e. module).</p><p>Kubernetes also uses nominal equivalence in its type system, with each type having a name consisting of its Group, Version, and Kind (GVK). However, unlike a statically compiled binary, Kubernetes has types dynamically added and removed at runtime. This means when you are programming against a cluster’s API, the name of the type you are creating an instance of does not fully reflect the type’s identity—the API may have been modified since the last time you interacted with the cluster, and changing the source or content of the type is decoupled from creating new instances of the type. Furthermore, unlike writing a program, there are typically multiple personas involved when configuring and consuming a Kubernetes cluster.</p>

<p>This becomes an even larger problem when multiple clusters are involved, as the constraint of only one type existing for a single GVK is no longer upheld. When we are treating clusters as ephemeral, the inability to verify whether two types with the same name are equivalent becomes an issue, as the semantics of the “language” we are using is changing beneath our feet. A multi-cluster environment is akin to programming across multiple Go modules, where someone else may be changing types, and the only way to ensure consistency is by a literal byte-to-byte comparison.</p><p>In fact, the situation is even more complex than described thus far. While we have primarily been discussing their structure (i.e. definition), types also have associated behavior. In programming languages this is frequently represented as methods that may be invoked imperatively on an instance of the type. In a Kubernetes cluster, associated behavior takes the form of one or more controllers that are invoked based on the declarative life-cycle of the type. Despite these controllers being dependent upon the existence of the types they reconcile. Kubernetes does not natively create a strong association between types and their controllers. Because of this, even comparing the content of a CRD with another with the same GVK does not necessarily indicate equivalence in both structure and behavior.</p><p>In an ideal world, we could verify whether creating an instance of a type in one cluster would result in the same operations being performed as in another cluster.</p><h2>Crossplane Packages and OCI Images</h2><p><a href="https://crossplane.io/docs/v1.9/concepts/packages.html" target="_blank" rel="noopener noreferrer">Crossplane packages</a> (xpkgs) are how new types are added to Kubernetes clusters where Crossplane is installed. Their <a href="https://crossplane.io/docs/v1.9/reference/xpkg.html" target="_blank" rel="noopener noreferrer">specification</a> is a subset of the <a href="https://github.com/opencontainers/image-spec/blob/main/spec.md" target="_blank" rel="noopener noreferrer">OCI image specification</a> (i.e. xpkgs impose additional requirements), which allows for users to take advantage of the vast ecosystem of tooling and distribution.</p><p>OCI images are made up of content and manifests. Traditionally, the content includes filesystem changeset layers (i.e. <i>blobs</i>), which can be extracted to form a complete filesystem for a container at runtime. Manifests tie these layers together, specifying how to obtain the content, as well as the order in which the changesets should be applied. Crossplane takes advantage of this flexible model by assigning significance to content in the blobs, specifically a <code>package.yaml</code> file that exists in the root of the final filesystem. This file is a <a href="https://yaml.org/spec/1.2.2/#92-streams" target="_blank" rel="noopener noreferrer">YAML stream</a> containing package metadata, and all the types that Crossplane should install. Crossplane is indifferent as to the content of the rest of the image.</p>

<p>A Provider or Configuration package can be installed by creating an instance of the <code>Provider</code> or <code>Configuration</code> type in the cluster with a reference to the package image.</p>

<p>When installing, Crossplane first fetches the digest of the package image manifest, and creates either a <code>ProviderRevision</code> or <code>ConfigurationRevision</code>, depending on the package type, with a name constructed from the manifest digest. Next, the JSON content of the manifest is fetched. As mentioned previously, the manifest contains a list of content blobs in the form of descriptors. A descriptor contains the media type, size, and digest of the layer. It may also include annotations, among other fields, with additional information.</p><blockquote><p>Note that both the manifest, and descriptors in the manifest, may include annotations. In this case we are talking about annotations on descriptors in the manifest.</p></blockquote>

<p>If the one of the layer descriptors in the package image manifest has a <code>io.crossplane.xpkg</code>: base annotation, Crossplane only fetches that layer, then extracts the <code>package.yaml</code> file from it. If none of the layer descriptors in the manifest have the annotation, all layers in the manifest are fetched, the full filesystem is constructed, then the <code>package.yaml</code> is extracted from the root directory.</p>

<blockquote><p>Note that this manifest also includes an <code>io.crossplane.xpkg: upbound</code> annotation, which is an xpkg extension. We’ll cover extensions in a future post, but you can read about how to implement your own in the <a href="https://crossplane.io/docs/v1.9/reference/xpkg.html#manifests" target="_blank" rel="noopener noreferrer">specification</a>.</p></blockquote><p>Crossplane parses the contents of the <code>package.yaml</code> file, caches it, then begins installing the package. If the package is a Provider, the <code>package.yaml</code> contains metadata and a stream of CRDs, <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook" target="_blank" rel="noopener noreferrer">Validating Webhook Configuration</a>, and <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook" target="_blank" rel="noopener noreferrer">Mutating Webhook Configurations</a>. If the package is a Configuration, it contains metadata and a stream of Composite Resource Definitions (XRDs) and Compositions. Before applying the objects to the cluster, Crossplane first adds the package revision to a singleton cluster-scoped object of kind <code>Lock</code>. <strong>This object plays a similar role to </strong><code><strong>go.mod</strong></code><strong> and </strong><code><strong>go.sum</strong></code><strong>, defining the packages that are installed in the cluster, the dependency relationships between them, and information about their content.</strong></p>

<p>For example, installing <code>xpkg.upbound.io/upbound/provider-aws:v0.11.0</code> would result in the following entry in the singleton <code>Lock</code>, where the package revision reference, type, and name are defined. The name includes the resolved short digest of the referenced image (<code>e1dde2d0d249</code>).</p>

<p>Installing objects from a package into the cluster consists of first verifying that the given revision can obtain sole control of each object, and, if so, applying them to the cluster with a <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications" target="_blank" rel="noopener noreferrer">controller owner reference</a> to the package revision. This ensures that in a cluster where the Kubernetes API surface is <i>only expanded via Crossplane packages</i>, we can ensure the <i>only one package</i> can ever act on a given type.</p><p>This is especially important with Providers, as installing a Provider not only adds new types to the cluster, but also implements each type’s corresponding functionality in the form of a <code>Deployment</code> that runs controllers to watch and take action based on the lifecycle of instances of the installed types. Unless overridden, Crossplane and the controller image from the same package are the only system components that are given permission on any installed type.</p><h2>(Content) Addressing the Issue</h2><p>A more subtle advantage of being built on top of OCI is the usage of a content-addressable API. Just like any OCI image, Crossplane packages can be installed by digest rather than by tag (e.g. <code>v0.11.0</code>) to ensure that the content that is installed matches what was expected.</p><blockquote><p>If you don’t think pulling by digest is important, I encourage you to <a href="https://www.youtube.com/watch?v=Ve_CFyVYo3M&amp;t=1066s" target="_blank" rel="noopener noreferrer">listen to Jon Johnson</a> describe all of the reasons why you can’t trust a registry when pulling by tag.</p></blockquote>

<p>As seen below, the package revision still uses the short digest in the name (e.g. <code>e1dde2d0d249</code>), but the version corresponds to the full digest of the package image.</p>

<p>Pulling by digest guards against a number of potential issues and vulnerabilities, including tags being updated to point at a different manifest, or a malicious party intercepting requests. However, it does make utilizing semantic versioning for upgrades and dependency resolution more difficult. It would be nice if we could have the convenience of using versions when referencing packages, but ensure that the content is still what we expect, similar to the guarantees we get with a programming language like Go. Fortunately, C<strong>rossplane does not force you to choose between convenience and security</strong>. When installing a Provider or Configuration, users can choose a <code>revisionActivationPolicy</code> of either <code>Automatic</code> or <code>Manual</code>.</p>

<p>If set to <code>Manual</code>, Crossplane resolves the image tag to its digest, but waits until the revision is manually updated from <code>Inactive</code> to <code>Active</code> before continuing with installation. This allows the human to interact with human-readable identifiers (tags), while still relying on the machine to verify the content.</p>

<p>Using this strategy is particularly useful when installing or updating packages across clusters where a consistent API is desired. It also means that if package contents are lost from the cache and the package source has updated the tag to point at a different manifest, Crossplane will wait for approval before rolling to a new revision of the package.</p><blockquote><p>Combining <code>Manual</code> revision activation with <code>packagePullPolicy</code>: Always can be used in interesting ways, such as pinning to a channel tag (e.g. <code>latest</code>) and letting Crossplane create new <code>Inactive</code> revisions any time the tag is updated to point at a new manifest. It is highly recommended that users consult the <code>packagePullPolicy</code> <a href="https://crossplane.io/docs/v1.9/concepts/packages.html#specpackagepullpolicy" target="_blank" rel="noopener noreferrer">documentation</a> before enabling this functionality.</p></blockquote><p><strong>Most importantly, using a content-addressable API and a unit of installation (a package) that contains both type definitions and their corresponding reconciliation logic enables the verifiable equivalence of types across clusters we are seeking.</strong> However, though we do want to couple definition and behavior, sometimes it is advantageous to be able to verify them independently. Let’s take a look at a scenario where this would be useful.</p><h2>Case Study: Multi-Arch Bundled Provider Packages</h2><p>In the <a href="https://github.com/crossplane/crossplane/releases/tag/v1.6.0" target="_blank" rel="noopener noreferrer">v1.6.0 release</a>, Crossplane added support for <a href="https://github.com/crossplane/crossplane/pull/2758" target="_blank" rel="noopener noreferrer">bundled Provider packages</a>. Prior to this change, Provider package metadata was required to include a reference to the controller image for the types included in the package image. Bundled packages allow for omitting this reference, and instead building the package content and controller machinery into a single image. The previous system of decoupling the images had a number of advantages:</p><ol style="list-style-type:decimal;"><li>Crossplane only needed to download and cache the package contents from the package image, while the often larger controller image was only pulled by the node that the <code>Deployment</code> was scheduled to.</li><li>If <i>only</i> the content of the package changed, or only the content of the controllers changed, the digest of the other would remain the same, making it simple to determine if changes occurred to the API surface, the controller logic, or both. This is especially useful when evaluating whether an upgrade includes breaking changes.</li></ol><blockquote><p>Actually performing the verification in (2) proved to be cumbersome, as the digest of the package image would change if its controller image reference changed. The ability to c<a href="https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/ControllerConfig/v1alpha1@v1.9.0#spec-image" target="_blank" rel="noopener noreferrer">hange the controller image reference at runtime</a> via a <code>ControllerConfig</code> somewhat mitigated this issue, but is not a recommended pattern in production settings.</p></blockquote><p>However, the flexibility of the OCI image specification, as well as the formalization of the xpkg specification in the subsequent <a href="https://github.com/crossplane/crossplane/releases/tag/v1.7.0" target="_blank" rel="noopener noreferrer">v1.7.0 release</a>, made it possible to achieve the above benefits while also reducing the complexity of managing multiple images. As previously described, Crossplane packages may annotate a descriptor with the <code>io.crossplane.xpkg</code>: base annotation to indicate that the package manager should only consider that single layer when extracting package contents. In doing so, Crossplane does not increase the amount of data it maintains in its package cache, and, importantly, can easily verify if two packages install an equivalent set of type definitions.</p><p>This functionality is useful in a number of scenarios, such as verifying whether a patch release of a Provider presents the same API as previous patches for the same minor version. One area where this is especially useful is multi-architecture Provider images. Prior to supporting bundled Provider images, there was no need to publish variants of package images for multiple platforms as they only contained YAML content. However, when the controller and package images are bundled into a single image, ensuring that the package content layer is consistent across variants for each platform is critical. It would be highly confusing if installing a package on a <code>linux/arm64</code> host resulted in different types being installed than when installed on a <code>linux/amd64</code> host.</p><p>Multi-architecture OCI images are supported by <a href="https://github.com/opencontainers/image-spec/blob/main/image-index.md" target="_blank" rel="noopener noreferrer">image indexes</a> (sometimes referred to as manifest lists). When you pull a multi-architecture image, your client is first hitting an image index, then resolving to the manifest for your host platform, before finally downloading the layers specified in that platform-specific manifest. The image index for the <code>xpkg.upbound.io/upbound/provider-aws:v0.11.0</code> image we have been using throughout this post looks like this:</p>

<p>As expected, the <code>digest</code> for the <code>linux/amd64</code> image manifest does not match the <code>linux/arm64</code> image manifest <code>digest</code>. However, if we were to examine the layers for each of these manifests, we would see the final two layers are identical:</p>

<p>The ability to both couple the definition and behavior of types (image digest), as well as decouple the verification of the definitions (<code>base</code> layer digest) is critical in ensuring the integrity of multi-architecture images. When pushing multi-architecture packages to Upbound’s registry (<code>xpkg.upbound.io</code>), different digests between the <code>base</code> layers in each variant cause packages to be rejected during verification.</p><h2>Where We’re Going</h2><p>This post outlines ways in which Crossplane enables a more robust Kubernetes type system, but the current functionality only serves as a foundation for future tooling and machinery, similar to how OCI images have helped enable more secure distribution of containerized applications, and as we’ve seen today, any content. A small sample of improvements that can be made to this system includes:</p><ul><li>Supporting installing by type, rather than by package.</li><li>Verifying controller logic on a per-type basis.</li><li>Verifying which types are not equivalent across packages, rather than just that some types are not.</li><li>Supplementing the <code>apiVersion</code> and <code>kind</code> of objects with the digest of the type and its corresponding controller logic.</li><li>Supporting <a href="https://github.com/crossplane/crossplane/issues/3048" target="_blank" rel="noopener noreferrer">package image signature verification</a>.</li></ul><p>If you are interested in joining <a href="https://www.upbound.io/">Upbound</a> in doing our part to enable this future, check out our <a href="https://upbound-www.vercel.app/blog">open roles</a>.</p><p>—</p><p>Upbound is the company that invented the open source Crossplane project. Our mission is to help customers build Internal Cloud Platforms using control planes. Every Upbound customer gets access to Upbound Universal Crossplane (UXP) and Official Providers so they can build their Internal Cloud Platforms with Crossplane confidently. UXP is Upbound’s downstream distribution of Crossplane, and Official Providers are production ready versions of Providers available exclusively to Upbound customers. Both are maintained, tested, and supported by Upbound on behalf of our customers, and are included with an Upbound subscription.</p>

Verifiable Kubernetes API Compatibility

<p>When organizations start to scale, getting the correct infrastructure-as-code workflow right can be a daunting task. Thankfully, when teams think about the next step in their cloud-native journey after Terraform, Crossplane is there to help. In this blog post, we'll take a look at an example company going through some growing pains and how the Crossplane provider-terraform can help. For an in-depth how-to guide, check out the <a href="https://docs.upbound.io/providers/provider-terraform/migrate-provider-tf/" target="_blank" rel="noopener noreferrer">Upbound docs</a> migration tutorials.</p><h2>Introduction</h2><p>It's 2024, and your startup JNCOmatic isn't just hot; it's Unicorn-in-a-Ferrari hot! Your groundbreaking app, which can slap a pair of hyper-realistic, backwards JNCO jeans onto anyone (or any dog on its hind legs), is running on all cylinders.</p><h2>The Terraform Tango</h2><p>Back in the day, when Viv was the lone Op of the Ops team, things were simpler. Deployments were a breeze, the scale was low, and AWS bills were…manageable. Viv started out on the team of one by implementing a Terraform workflow to easily deploy all the necessary infrastructure to the cloud. She mapped out the resources, accounted for spot instance scaling, and ensured user data was encrypted from a few files. Here’s an example of a Terraform resource configuration she might have used:</p>

<h2>Scaling up</h2><p>But that was before, CourtJortster, a TikTok influencer with a flair for the '90s, happened. Livestreaming the entire 1993 Chicago Bulls roster in NBA2K – all decked out in JNCOmatic gear – turned your world upside down.</p><p>The Terraform approach worked well when the team was a single person responsible for serving a small number of users. The first step of the cloud-native journey was just laying a foundation, but as JNCOMatic scales by orders of magnitude, Viv knows the workflow needs an update.</p><p>Four people on an Ops team can’t collaborate as they would like on the Terraform configuration files. You’ve got a growing number of developers who need to spin up environments to test new methods of generating realistic jean texture with AI. And managing state files? "As if!"</p><h2>Shifting Gears: `provider-terraform` and Crossplane</h2><p>Viv decides the Ops team needs to shift to PlatformOps. PlatformOps is how companies ensure their software, infrastructure, and security experts can get the tools and environments they need to get their jobs done. The developer platform the company needs is <a href="https://www.crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a>.</p><p>Crossplane is an open source Kubernetes extension that transforms your Kubernetes cluster into a *universal control plane*. The control plane allows you to connect Kubernetes clusters to external resources and enables platform teams to build custom Kubernetes APIs to build and manage resources. The platform team already uses Kubernetes for application deployment so there is not a significant learning curve - in fact, Viv is removing tool sprawl from the organization by consolidating infrastructure deployment in the same workflow as application deployment.</p><p>By using control planes instead of Terraform, the team doesn't need to worry about configuration drift or use a custom language for their deployments. Painful rollbacks or errored apply operations that stop deployments in their tracks left the team with half-applied configurations with little choice but to start from scratch. In addition to complex module management, multi-cloud or hybrid deployments in Terraform require a lot of patchwork to make sure your resources work together.</p><p>The big problem: The team has amassed so many Terraform configurations that it’s difficult to easily start over on Crossplane.</p><p>The big solution: Crossplane has a <a href="https://marketplace.upbound.io/providers/upbound/provider-terraform/v0.14.1" target="_blank" rel="noopener noreferrer">`provider-terraform`</a> that executes HashiCorp Configuration Language (HCL) within Crossplane.</p><p>The same Terraform configuration above is easily slotted into a Crossplane spec:</p>

<p>The team can easily move from HCL to Crossplane with the `provider-terraform` option and reduces the learning curve a little more. After creating a few more Crossplane specs for their resources, the team gets more comfortable with the workflow.</p><p>The <a href="https://www.techtarget.com/searchitoperations/definition/GitOps" target="_blank" rel="noopener noreferrer">GitOps</a> philosophy baked into Crossplane makes it easy for the team to collaborate. The Crossplane configurations live in a team repository and there are no locks or state files to contend with. This workflow also minimizes resource drift. If a team member edits a resource in AWS through CloudFormation or in the GUI, Crossplane uses continuous reconciliation through Kubernetes to keep resources aligned with the source of truth in the Crossplane specs. In other words, your desired state in the spec is exactly what Crossplane will deploy and will prevent drift through Kubernetes' reconciliation loop.</p><h2>All-in on Crossplane</h2><p>Eventually, the team fully embraces Crossplane, opting to use its native Kubernetes spec for infrastructure management.</p>

<p>In this example, the team employs a consistent configuration language throughout the deployment spec. Crossplane's AWS provider supplants the Terraform provider, directly orchestrating the desired infrastructure.</p><p>This process takes time and it can’t be completed overnight. Meticulous planning is essential for critical infrastructure. Thankfully, you don't have to do it alone. As a Cloud Native Computing (<a href="https://www.cncf.io/" target="_blank" rel="noopener noreferrer">CNCF</a>) project, Crossplane's open-source, community-driven nature offers support through an open source <a href="https://github.com/crossplane" target="_blank" rel="noopener noreferrer">GitHub repository</a>, <a href="https://crossplane.slack.com/join/shared_invite/zt-2dimsong0-VwekA~pVM8OW~Mpg0JtawA#/shared-invite/email" target="_blank" rel="noopener noreferrer">Slack channel</a> and bi-weekly <a href="https://github.com/crossplane/crossplane#get-involved" target="_blank" rel="noopener noreferrer">community meetings</a>.</p><p>Once the team maps out their existing configuration in Terraform, the next step is to match the resources in Crossplane. This is where the <a href="https://marketplace.upbound.io/" target="_blank" rel="noopener noreferrer">Upbound Marketplace</a> comes in. The Marketplace is the central hub for finding Crossplane providers. Upbound, the company behind Crossplane, offers a selection of official, actively maintained, and tested providers. In the Marketplace, the team has access to Providers (external APIs you consume from cloud providers) and Configurations (out of the box solutions for deploying the building blocks of your architecture).</p><h2>The Next Level</h2><p>If your team is ready to level up your infrastructure, <a href="https://docs.upbound.io/providers/provider-terraform/migrate-provider-tf/" target="_blank" rel="noopener noreferrer">check out the Crossplane Get Started guide for a step-by-step tutorial to get familiar with Crossplane</a>. If you're looking for top-tier <a href="https://docs.upbound.io/concepts/mcp/" target="_blank" rel="noopener noreferrer">Managed Control Plane</a> environments for hosted, scalable infrastructure, check out <a href="/">Upbound</a> and sign up for a <a href="/register/a">free trial</a> now.</p><p>Looking for a real world example? <a href="webinars/kubernetes-called-and-it-wants-your-iac-back-using-control-planes-to-modernize-your-iac-tech-stack" target="_blank" rel="noopener noreferrer">Millennium BCP modernized its tech stack with Upbound</a> and has a few pointers for you.</p><p>For more information on migrating from Terraform or the `provider-terraform`, <a href="https://docs.upbound.io/providers/provider-terraform/migrate-provider-tf/" target="_blank" rel="noopener noreferrer">check out the Migration Guide and the Marketplace documentation</a>.</p>

Time to Cross Over: Migrating from Terraform to Crossplane

<p>Organizations are increasingly tasking a central team to build self-service developer platforms. These platforms are built above AWS, Azure, or GCP with the goal to accelerate app teams’ velocity by enabling them to select from a list of templates that have already baked together a set cloud infrastructure, preconfigured and compliant to an organization’s internal policies and requirements.</p><p>Creating a resource in the cloud can seem simple at first, but quickly the complexity compounds: what VPC, IAM roles, and security groups need to be set up? What does the security team think about opening an API gateway ingress point? What policy concerns are there from naming to access? Suddenly that need for a cloud resource has become many steps across several teams with multi-week approval cycles. Crossplane allows you to define a new abstraction—your own custom API—that provides a simple interface. A central platform team can define and implement those concerns, alleviating app teams from needing to think about these things and cutting down on cross-team approvals in the process.</p><p>Many organizations, such as&nbsp;<a href="https://www.upbound.io/why-upbound/customers/millennium-bcp"><u>Millennium Bank</u></a>, are choosing&nbsp;<a href="https://blog.upbound.io/what-is-crossplane"><u>Crossplane</u></a>&nbsp;to power their self-service platforms. Crossplane is a flexible, Kubernetes-native framework that allows users to build their own abstractions above the cloud. In this post, we will demonstrate how you can get started building a self-service platform above GCP&nbsp;<a href="https://www.upbound.io/register/a"><u>using Upbound</u></a>, which allows you to offload the job of operating Crossplane to Upbound so you can focus on what matters—building your platform!</p><h2>Create your first control plane</h2><p>Get started by&nbsp;<a href="https://www.upbound.io/register/a"><u>creating an account</u></a>&nbsp;on Upbound (which offers a free 30 day trial). Upbound will prompt you to create a new organization and then start your free trial. After you start your free trial, Upbound offers you a few control plane configurations as a starting point. Select the GCP-based configuration.</p>

<p>Complete the remainder of the flow:</p><ul><li>Connect your Upbound account to GitHub so it can clone a repo that holds the source definition of your control plane’s configuration.</li><li>Create your first control plane, which will be configured with the package you selected earlier.</li><li>Connect your control plane to your GCP cloud account via&nbsp;<a href="https://docs.upbound.io/knowledge-base/oidc/"><u>Upbound Identity</u></a>, an OIDC-based auth mechanism. For a step-by-step guide on how to do this, see the&nbsp;<a href="https://docs.upbound.io/quickstart/gcp-deploy/#connect-to-gcp-with-oidc"><u>GCP quickstart</u></a>.</li></ul><p>Once you have finished setup, launch into the Upbound Console.</p>

<h2>Taking inventory</h2><p>At this point, you have:</p><ul><li>Created and configured your first control plane, with a definition that is sourced directly from git.</li><li>It is connected to your GCP account.</li><li>In your git repo, you will find a “starter” API already defined and which has been already installed on your control plane. You can use this API to create and manage PostgreSQL instances on GCP CloudSQL.</li></ul><p>The Upbound Console is currently intended as a first-class experience for platform teams. Since our objective is to build a “self-service” platform, we need app teams to be able to use the API(s) offered by our control plane to provision resources on their own. The next two questions we will tackle are: “What if I want to offer APIs besides databases?” and “How can I enable my app teams to use these APIs?”</p><h2>Expand your control plane’s capabilities</h2><p>We will begin by answering the first question. Our control plane can provision PostgreSQL instances in GCP; what if you want to do more? You can add as many APIs and abstractions as you want to a given control plane. The configuration you picked in the “Get Started with Upbound” flow is meant to be a starting point. You are expected and encouraged to customize your control plane’s configuration by modifying what was scaffolded in your git repo. You can navigate to the git repo which sources your control plane’s configuration by going to the Dashboard &gt; “Configurations” pane in the lower half of the screen &gt; click the git repo hyperlink.</p>

<p>Clone your git repo to your machine. Go to the root of the cloned repo, where you will find a folder called APIs. This is where you can define new APIs with Crossplane–new <a href="https://docs.crossplane.io/v1.12/concepts/#composite-resources" target="_blank">CompositeResourceDefinitions</a> (XRDs) and compositions (implementations for those XRDs). For this blog, we’ll define new APIs to create new Compute Engine instances and the associated network resource required. For brevity, you can copy the <a href="https://github.com/upbound/gcp-example-platform/commit/d4ab9a2955c33d6da765ebf018d22503617396a2" target="_blank">same changes</a> made in <a href="https://github.com/upbound/gcp-example-platform" target="_blank">this repo</a>. The repo contains the following:</p><ul><li>Addition of two XRDs defining new virtual machine and network resources</li><li>Two compositions that implement those resources, respectively</li><li>Moved the postgres resource into its own folder for consistency</li></ul><p>Once those changes have been committed to your synced repository, Upbound will automatically detect the commit and build a new package so you can update the definition installed on your control plane. Go back to your <a href="https://docs.upbound.io/concepts/console/#control-plane-explorer" target="_blank">control plane explorer</a> by clicking the control plane tile on the dashboard. Click the “Update available” button and confirm the update of your control plane’s configuration.</p>

<p><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">Once your control plane’s configuration has been updated, refresh the page to see the new resource card offered by your control plane.</span></p>

<p><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">⚠️ </span><strong>Very important next step:</strong><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;"> the quickstart had you create a GCP Service Account configured with role access to CloudSQL (which your control plane assumes when making requests to GCP). You need to make sure to enable role access so the Service Account can create Compute Engine resources, too. After you’ve updated your Service Account’s role access, it's helpful to confirm auth is working by using your </span><a href="https://docs.upbound.io/concepts/ctp-portal/" target="_blank">control plane’s portal</a><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;"> to directly CRUD resources.</span></p><h2>Self-service</h2><p>Now that you have a control plane configured to offer and manage the resources you need for your organization, the next step is to build out how you want to enable self-service with it. There are a few ways you could do this.</p><h3>Use a CLI</h3><p>For organizations who are comfortable providing direct access of the control plane directly to their app teams, you can use a CLI directly (such as with kubectl). You can configure a kubeconfig for <a href="https://docs.upbound.io/concepts/managed-control-planes/#connect-directly-to-your-mcp" target="_blank">connecting directly</a> to a control plane and afterwards run `kubectl apply -f claim.yaml` to create resources directly.</p><h3>Use the MCP Connector</h3><p>Upbound ships with a feature called the <a href="https://docs.upbound.io/concepts/control-plane-connector/" target="_blank">managed control plane (MCP) connector</a>. This allows you to connect one or more Kubernetes app clusters (running somewhere in your own cloud environment) to your control plane (running in Upbound’s cloud environment). This feature was built for organizations that have app teams deploy to Kubernetes. It allows teams to bundle resource claims alongside their app deployment configurations and use GitOps to drive communication with your control plane. You can find instructions for how to set this up in this <a href="https://docs.upbound.io/concepts/control-plane-connector/#connecting-to-managed-control-planes" target="_blank">section</a> of the Upbound docs.</p><h3>BYO frontend</h3><p>The MCP Connector approach involves setting up external Kubernetes clusters with supporting tooling to have a functional self-service flow. Another common approach that many organizations are adopting is building their own frontend, either custom-built in-house or by starting from a project such as <a href="https://github.com/backstage/backstage" target="_blank">Backstage</a>. The control planes in Upbound are not opinionated; each control plane <a href="https://docs.upbound.io/concepts/managed-control-planes/#connect-directly-to-your-mcp" target="_blank">offers a Kubernetes API server</a> endpoint that you can communicate with. You will need to connect the frontend for your self-service platform to the API endpoint of your control plane.</p><p>In a future blog post, we will explore the steps for how to implement these methods.</p>

How to Build a Self-Service Platform on Upbound: Day 0

<p>In this sprint’s product update, we cover improvements to the Marketplace that will make it much easier to find the Crossplane content you need, the arrival of support for the managed control plane connector in a Spaces-managed control plane, and some additional features now in the <code>up</code> cli to make interacting with control planes easier.</p><h2>Navigating the Upbound Marketplace faster</h2><p>Browsing available providers, configurations, and API definitions just got a lot faster. Users should expect to see up to 50x faster page load times in the <a href="https://marketplace.upbound.io/" target="_blank">Upbound Marketplace</a>, thanks to some recent changes we pushed. Whether you’re browsing the list of <a href="https://marketplace.upbound.io/providers" target="_blank">Crossplane providers</a> or exploring the spec of a managed resource, it should be considerably faster to get where you need to go in the Marketplace.</p><p>We’ve also updated how search results in Marketplace to allow for more content to be shown on screen, depending on the size of device viewing the Marketplace.</p>

<h2>Managed control plane connector now supported in an Upbound Spaces</h2><p>Spaces is a recent feature of Upbound that allows customers to operate self-hosted environments for Upbound’s managed Crossplane control planes. When a managed control plane runs in a Space, you can now use the same MCP connector that we support in our SaaS environment.</p><p>The MCP connector is one of many interfaces you can use to interact with a Spaces control plane. It’s specifically designed to help you connect a Kubernetes app cluster to a managed control plane, so your dev team can bundle their app helm chart (destined for their app cluster) alongside Crossplane claims (destined for a managed control plane) and deploy it to their single app cluster context.</p><p>Learn more about how to set up the MCP connector in a Spaces-managed control plane by reading <a href="https://docs.upbound.io/mcp/ctp-connector/" target="_blank">the documentation</a>.</p>

<h2>New capabilities in up CLI</h2><p>We’ve made it simpler to connect and disconnect from a control plane’s API server. <code>up ctp connect</code> was re-introduced, with different experience. Invoking the command will now connect your kubectl directly to the target control plane. Any kubectl commands run in that terminal will be executed against the target control plane. To return to the previous context stored in your kubeconfig, simply run <code>up ctp disconnect</code>. Learn about this more in the latest up CLI <a href="https://docs.upbound.io/reference/cli/rel-notes/#v0210" target="_blank">release notes</a>.</p>

<h2>Improvements &amp; Fixes</h2><ul><li>Improved the control plane dashboard and configuration list by making the table headers sticky, allowing you to scroll through longer lists without losing context</li><li>Resolved an issue affecting Configurations with dependencies on the latest releases of family providers that prevented users from creating new ProviderConfigs via the UI</li><li>The console now shows UI create hints on the control plane and configuration list screens for organizations with no control planes or configurations created.</li><li>We fixed the background color of the main navigation tabs to match the page.</li><li>The UI tabs in a managed control plane dashboard now link via url hash. For example, the settings tab renders as&nbsp;<code>console.upbound.io/org/controlPlanes/org:ctp-name#resources</code>)</li></ul><p>If you have feedback, a feature you’d like to see, or want to chat with the Product team, you can find us in the <a href="https://crossplane.slack.com/archives/C01TRKD4623" target="_blank">#Upbound channel</a> of the Crossplane community slack.</p><h2>Want to Learn More?</h2><p>To understand the full picture of Spaces, check out this webinar, "<a href="https://resources.upbound.io/all-content/managed-crossplane-in-your-own-environment-with-upbound-spaces" target="_blank">Managed Crossplane in your own environment with Upbound Spaces</a>" that I put together to give a great overview and detailed rundown.</p>

<p>On behalf of the Upbound team,<br>Craig D Wilhite</p>

New from Upbound: Finding Content Faster in the Marketplace, MCP Connector Comes to Spaces

<p>This article was originally&nbsp;<a href="https://thenewstack.io/7-core-elements-of-an-internal-developer-platform/"><u>posted on the New Stack</u></a>&nbsp;by Viktor Farcic and&nbsp;<a href="https://www.getport.io/?utm_content=sponsormodule&amp;utm_source=thenewstack&amp;utm_medium=website&amp;utm_campaign=platform"><u>Port</u></a>.</p><p>What does it take to build an internal developer platform? What are the tools and platforms that can make it work? This post will discuss the architecture and tools required to stand up a fully operational internal developer platform. To see the actual steps of setting up the platform, watch&nbsp;<a href="https://www.youtube.com/watch?v=Rg98GoEHBd4"><u>this video</u></a>.</p><h2>Why Do We Want an Internal Developer Platform?</h2><p>Platform engineering’s overarching goal is to drive developer autonomy. If a developer needs a database, there should be a mechanism to get it, no matter if that person is a database administrator or a&nbsp;<a href="https://roadmap.sh/nodejs"><u>Node.js developer</u></a>. If a developer needs to manage an application in Kubernetes, that person doesn’t need to spend years trying to understand how&nbsp;<a href="https://thenewstack.io/kubernetes/"><u>Kubernetes works</u></a>. All these actions should be simple to accomplish.</p><p>A developer should be able to accomplish what they need by defining a simple manifest or using a web UI. We want to enable all developers to consume services that will help them get what they need. Experts (<a href="https://thenewstack.io/platform-engineering/"><u>platform engineers</u></a>) will create those services in the internal developer portal, and users will consume them in its graphical user interface or by writing manifests directly and pushing them to git.</p><h2>The High-Level Design of an Internal Developer Platform — 7 Core Elements</h2><p>An internal developer platform needs several parts to become fully operational. For each part we will recommend a tool, but they can be exchanged with similar tools. The core idea is to map out the functionalities needed to build the platform:</p><ul style="list-style-type:disc;"><li>A control plane: The platform needs a control plane that will be in charge of managing all the resources, no matter if they are applications running in a Kubernetes cluster or elsewhere, or if the infrastructure or services are in&nbsp;<a href="https://aws.amazon.com/?utm_content=inline-mention"><u>Amazon Web Services (AWS)</u></a>&nbsp;, Azure, Google Cloud or anywhere else. Our recommended tool here is Crossplane.</li><li>A control plane interface: This will enable everyone to interact with the control plane and manage resources at the right level of abstraction. Our recommended tool here is Crossplane Compositions.</li><li>Git: The desired states will be stored in git, so we’ll have to add a GitOps tool into the mix. Its job will be to synchronize whatever we put in git with the control plane cluster. Our recommended tool here is Argo CD.</li><li>Database and schema management: Given that state is inevitable, we will need to have databases as well. Those databases will be managed by the control plane but to work well, we will also need a way to manage schemas inside those databases. Our recommended tool here is SchemaHero.</li><li>Secrets manager: For any confidential information that we cannot store in git, we’ll need a way to manage secrets in a secrets manager. Those secrets can be in any secrets manager. Our recommended tool to pull secrets from there is External Secrets Operator (ESO).</li><li>An internal developer portal/ graphical user interface: In case users don’t want to push manifests directly to git, we should provide them with a user interface that will enable them to see what’s running as well as to execute processes that will create new resources and store them in git. Our recommended tool here is&nbsp;<a href="https://getport.io/"><u>Port.</u></a></li><li>CI/CD pipelines: Finally we will need pipelines to execute one-shot actions like the creation of new repositories based on templates, building images with new release changes to manifests and so on. Our recommended tool here is GitHub Actions.</li></ul><p>The setup will require a few additional tools, but the list above is a must.</p><p>The diagram below shows how each of the elements interacts with each other. You can use it as a reference as you read through this article.</p>

<p>Let’s examine the role of each layer in the setup:</p><h3>Control Plane</h3><p>Let’s talk about control planes: We need a single API acting as an entry point. This is the main point of interaction for the internal developer platform. In turn, it will manage resources no matter where they are. We can use Crossplane with providers, which enables us to manage not only Kubernetes but also AWS, Google Cloud, Azure or other types of resources. We will use Kubectl to get custom resource definitions (CRDs) that will create deployments, services and manage databases in hyperscaler clusters, etc.</p><p>However, this alone isn’t enough for a full-fledged internal developer platform. An application can easily consist of dozens of resources. Infrastructure can be much more complicated than that. Most importantly, all those low-level resources are not at the right levels of abstraction for people who are not&nbsp;<a href="https://roadmap.sh/kubernetes"><u>Kubernetes</u></a>&nbsp;or AWS or Google Cloud specialists. We need something that is more user-friendly.</p><h3>A User-Friendly Interface for the Control Plane</h3><p>The control plane interface can act as the platform API when you’re 100% GitOps. It shouldn’t be confused with the internal developer portal, which acts as the graphical user interface. We can use Crossplane Compositions for that.</p><p>What is the right level of abstraction for the users of the platform we’re building? The rule is that we should hide, or abstract, anything that people don’t really care about when they use the internal developer platform. For instance, they probably don’t care about subnets or database storage. The right level of abstraction depends on the actual use of the platform and will differ from one organization to another. It’s up to you to discover how to best serve your customers and everyone else in your organization.</p><p>Crossplane Compositions enables us to create abstractions that can simplify the management of different kinds of applications. Next, we probably do not want anyone to interact directly with the cluster or the control plane. Instead of people sending requests directly to the control plane, they should be storing their desired states in git.</p><h3>Synchronize from Git with GitOps</h3><p>Changing the state of resources by directly communicating with the control plane should not be allowed, since no one will know who changed what and when. Instead, we should push the desired state into git and, optionally, do reviews through pull requests. If we plug GitOps tools into the platform, the desired state will be synchronized with the control plane, which in turn will convert it into the actual state.</p><p>This is a safer approach as it doesn’t allow direct access to the control plane and also keeps track of the desired state. I recommend doing this with Argo CD, but Flux and other solutions are just as good.</p><h3>Schema Management</h3><p>Databases need schemas. They differ from one application to another. To complete our internal developer platform, we need to figure out how to manage schemas, preferably as part of application definitions stored in git. There are many ways to manage schemas, but only a few enable us to specify them in a way that fits into the git model. The complication is that GitOps tools work only with Kubernetes resources, and that means that schemas should be defined as Kubernetes resources as well. This requires us to extend the Kubernetes API with CRDs that will enable us to define schemas as Kubernetes resources. I recommend using SchemaHero for that.</p><h3>Secret Management</h3><p>Some information shouldn’t be stored in git. Having confidential information such as passwords in git could easily result in a breach. Instead, we might want to store those in a secret manager like HashiCorp Vault or a solution provided by whichever hyperscaler you’re using. Still, those secrets need to reach the control plane so that processes inside it can authenticate with external APIs or access services, for example, databases. I recommend using External Secrets Operator (ESO) for that.</p><h2>Internal Developer Portal — Graphical User Interface</h2><p>The internal developer platform needs a user interface to sit on top of everything we’ve built so far. This is the internal developer portal. It both provides a catalog of services people can</p><p>use as well as an interface for developers to perform the actions we want them to use autonomously. Specifically, we need a way to initialize a process that will create new repositories for applications, add sample code, provide manifests for the databases and other dependencies, create CICD pipelines, and so on and so forth.</p><p>For this setup we began with the&nbsp;<a href="https://www.getport.io/blog/software-catalog-templates"><u>Kubernetes catalog template</u></a>&nbsp;from Port.</p>

<p>We will then add two additional&nbsp;<a href="https://docs.getport.io/build-your-software-catalog/define-your-data-model/"><u>blueprints</u></a>&nbsp;that will be related to the cluster blueprint, Backend App and Environment:</p>

<h2>CI/CD Pipelines</h2><p>Finally, we need pipelines. They are the last piece of the puzzle.</p><p>Even though we are using GitOps to synchronize the actual state into the desired state, we need pipelines for one-shot actions that should be executed only once for each commit. These could be steps to build binaries, run tests, build and push container images and so on.</p><h2>The Internal Developer Platform in Action</h2><p>From the user (developer) perspective, a new application can be created with a simple click on a button in a Web UI or by defining a very simple manifest and pushing it to git. After that, the same interface can be used to observe all the relevant information about that application and corresponding dependencies.</p><p>Behind the scenes, however, the flow would be as follows.</p><ol style="list-style-type:decimal;"><li>The user interacts with a Web UI (Port) or directly with git. The job of the internal developer portal in this case is to trigger an action that will create all the necessary resources.</li><li>Creating all the relevant resources is a job done by the pipeline such as GitHub Actions. In turn, it creates a new repository with all the relevant files, such as source code, pipelines, application manifests, etc.</li><li>As a result of pushing changes to the application repository (either as a result of the previous action or, later on, by making changes to the code), an application-specific pipeline is triggered (GitHub Actions) which, as a minimum, builds a container image, pushes it to the image registry and updates the manifests in the management repo, which is monitored by GitOps tools like Argo CD or Flux.</li><li>GitOps tools detect changes to the management repo and synchronize them with the resources in the control plane cluster.</li><li>The resources in the control plane cluster are picked up by corresponding controllers (Crossplane), which in turn create application resources (in other Kubernetes clusters or as hyperscaler services like AWS Lambda, Azure Container Apps or Google Cloud Run) as well as dependent resources like databases (self-managed or as services in a hyperscaler).</li></ol>

<p>This article was originally&nbsp;<a href="https://thenewstack.io/7-core-elements-of-an-internal-developer-platform/"><u>posted on the New Stack</u></a>&nbsp;by Viktor Farcic and&nbsp;<a href="https://www.getport.io/?utm_content=sponsormodule&amp;utm_source=thenewstack&amp;utm_medium=website&amp;utm_campaign=platform"><u>Port</u></a>.</p>

7 Core Elements of an Internal Developer Platform

<p>The previous<a href="https://blog.upbound.io/upbound-day-0"><u>&nbsp;blog post</u></a>&nbsp;in this series showcased how Upbound makes it easy for organizations to get up and running with their first instance of Crossplane in minutes. Today’s entry in the series covers a typical Day 1 operation for users of Upbound: configuring your control planes for&nbsp;<a href="https://docs.upbound.io/xp-arch-framework/interface-integrations/git-and-gitops/"><u>GitOps flows</u></a>.</p><p>GitOps is an approach for managing a system by declaratively describing desired resources’ configurations in Git and using controllers to realize the desired state. Crossplane is compatible with this pattern and it’s strongly recommended you integrate GitOps in your platforms built on Crossplane–<strong>and you can do this with&nbsp;</strong><a href="https://www.upbound.io/product/upbound"><strong><u>Upbound managed control planes</u></strong></a>!</p><p><i>Want to learn more? Here are the links to other blog posts showcasing new features for platform operators:</i></p><ul style="list-style-type:disc;"><li><a href="https://blog.upbound.io/2023-06-09-product-updates"><i><u>New Changes in Upbound: ProviderConfigs, Control Plane Explorer</u></i></a></li><li><a href="https://blog.upbound.io/2023-06-30-product-updates"><i><u>Upbound Identity with Azure, search in the Marketplace, and expanding the Configuration catalog</u></i></a></li><li><a href="https://blog.upbound.io/2023-07-28-product-updates"><i><u>New from Upbound: Configuration &amp; Provider Events in the Console, Crossplane Architecture Framework</u></i></a></li></ul><h2>GitOps and Crossplane</h2><p>Every managed control plane in Upbound comes with a&nbsp;<a href="https://docs.upbound.io/concepts/ctp-portal/"><u>control plane portal</u></a>&nbsp;by default. This portal is a convenient CRUD (create, read, update, and delete) graphical interface to interact with the APIs on your control plane. Think of using the control plane portal as talking&nbsp;<i>directly&nbsp;</i>to your control plane. The GitOps flows we will describe in this post are yet another flow you can use to interact with your control plane, and likely one you will want to use for production scenarios.</p><p>Integrating GitOps flows with Crossplane is useful in three ways:</p><ol style="list-style-type:decimal;"><li><strong>You can use git to store the definition of your control plane configuration.&nbsp;</strong>This is something users of Upbound get as a built-in feature of Upbound, since the platform supports automatically syncing the definition of your control plane’s configuration from GitHub. Read about&nbsp;<a href="https://docs.upbound.io/concepts/control-plane-configurations/#how-configurations-work-on-upbound"><u>how control plane configurations work</u></a>&nbsp;on Upbound.</li><li><strong>You can use Git as an interface to invoking your control plane’s APIs</strong>. Whenever a user needs a resource from your control plane, a claim must get created. Claims themselves are resources with a configuration (a spec), and as such can and should be declaratively stored in Git. This is the one we’ll demonstrate in today’s blog.</li><li><strong>Use Git to store the infrastructure definition that backs your control plane.&nbsp;</strong>In Upbound’s&nbsp;<a href="https://docs.upbound.io/xp-arch-framework/"><u>Crossplane Architecture Framework</u></a>, we call this out as a third way you can integrate with git. In the case of Upbound, this is not relevant because managed control planes by nature shift this responsibility away from you and over to Upbound.</li></ol><p><br>By the end of this blog, our goal is to have:</p><ol style="list-style-type:decimal;"><li>A managed control plane with a custom API running in Upbound.</li><li>A GitHub repository that is the source of all the claims I want to have against my control plane’s APIs.</li><li>An engine that observes when new claims get committed to my Git repository and syncs them over to my control plane. Conversely, when a claim is removed from the Git repository, it will get cleaned up from my control plane.</li><li>Once a claim is on the control plane, the control plane will fulfill its API contract and create all the resources that need composing.</li></ol><h2>Prerequisites</h2><p>If you want to follow along with this blog post, it requires that you have an account on&nbsp;<a href="https://www.upbound.io/register/a"><u>Upbound</u></a>&nbsp;and have already created a managed control plane. The configuration you choose for your control plane doesn’t matter; pick whichever one you like. You should also make sure you have installed the&nbsp;<a href="https://docs.upbound.io/cli/"><u>up CLI</u></a>&nbsp;on your machine.</p><h2>Set up a GitOps engine</h2><p>If you are already familiar with Kubernetes, it's likely you’ve heard of the GitOps pattern. There is already popular tooling available in the Kubernetes ecosystem to solve these problems.&nbsp;<a href="https://argo-cd.readthedocs.io/en/stable/"><u>Argo CD</u></a>&nbsp;and&nbsp;<a href="https://fluxcd.io/"><u>Flux</u></a>&nbsp;are two examples of projects in the Kubernetes ecosystem commonly used for GitOps. You can use them in tandem with Upbound managed control planes to achieve GitOps flows.</p><p>Today, we demonstrate how to integrate Flux. Check back to our blog or documentation for an update when Argo CD integration becomes available.</p><p>In order to integrate Flux with a managed control plane, you first need an instance of Flux installed into a Kubernetes cluster. Flux is not installable inside of Upbound, so you need to provision it on your own cloud infrastructure. For production scenarios, it’s recommended you designate a cluster for running Flux. For the purpose of this blog, we installed Flux into a local&nbsp;<a href="https://kind.sigs.k8s.io/"><u>kind</u></a>&nbsp;cluster.</p><p>You install Flux into a cluster by&nbsp;<a href="https://fluxcd.io/flux/installation/#github-and-github-enterprise"><u>bootstrapping</u></a>&nbsp;it and pointing it at the repo it should monitor. You would run something like this (assuming you are connecting to GitHub):</p>

<p>Once Flux is installed, you should see pods deployed in the flux-system namespace.</p>

<h2>Connect Flux to your managed control plane</h2><p>When Flux observes a change in a Git repository, it syncs those changes to a target. In a traditional installation of Flux on Kubernetes, the assumption is that Flux is installed as an add-on in the same cluster you wish to sync changes to. That’s not the case for a managed control plane on Upbound, so you need to tell Flux about the managed control plane. You do this by providing the managed control plane’s API server endpoint.</p><p>All managed control planes have a deterministic Kubernetes API server endpoint in the following form:</p><blockquote><p>https://proxy.upbound.io/v1/controlPlanes/&lt;account&gt;/&lt;control-plane-name&gt;/k8s</p></blockquote><p>Fetch your managed control plane’s API server endpoint so you can provide it to Flux. In the step below, use the&nbsp;<a href="https://docs.upbound.io/concepts/managed-control-planes/#connect-directly-to-your-mcp"><u>up CLI</u></a>&nbsp;to fetch the kubeconfig of your managed control plane and write it to a file. The up CLI uses personal access tokens to authenticate to Upbound. You can&nbsp;<a href="https://docs.upbound.io/concepts/console/#create-a-personal-access-token"><u>generate a personal access token</u></a>&nbsp;from the Upbound Console. This is the token passed in the following command:</p>

<p>Next, create a secret on the external Kubernetes cluster where you installed Flux. This secret should contain the kubeconfig from the previous step.</p>

<p>Then, define a new Flux Kustomization resource representing your managed control plane and apply to your Flux cluster. The example manifest below assumes you store claims in your Git repository under a claims folder.</p>

<p>Finally, apply a Kustomization to the cluster where Flux is running to tell Flux about this resource.</p>

<h2>Use Git to drive control plane interactions</h2><p>You can now commit claims in the Git repository that Flux is monitoring. When you do, Flux will sync them to your managed control plane running in Upbound. Your control plane will create and compose resources accordingly.</p>

<h2>What’s Next?</h2><p>To get the full rundown on the end-to-end flow of building an internal developer platform using control planes, I explain it in depth in this webinar with the Linux Foundation, “<a href="https://resources.upbound.io/all-content/todo-enable-developer-self-service-using-kubernetes-and-control-planes-powered-by-crossplane" target="_blank">//TODO Enable Developer Self-Service Using Kubernetes and Control Planes Powered by Crossplane</a>”.</p>

<p>To follow along with this blog series as well as the webinar above, be sure to&nbsp;<a href="https://www.upbound.io/register/a"><u>sign up for a free trial of Upbound</u></a>&nbsp;today. You will be able to create and configure your first managed control plane in minutes!</p>

How to Build a Self-Service Platform on Upbound: Day 1

<p>Remote work exploded during the pandemic, with 35% of US workers having the option of working fully remotely in 2022 according to <a href="https://www.mckinsey.com/industries/real-estate/our-insights/americans-are-embracing-flexible-work-and-they-want-more-of-it" target="_blank" rel="noopener noreferrer">McKinsey</a>. Formerly office-based companies have had to shift their ways of collaborating and working to deal with this new normal, with varying degrees of success and hand-wringing. Some companies have given up on this whole remote work thing and are demanding a return to the office… and many of the product managers I know are celebrating this.</p><p>Product people have had a particularly hard time making the adjustment to being suddenly remote.</p><blockquote><p>Product management is about leading through influence, making it a communication-heavy role where building relationships and driving alignment is key.</p></blockquote><p>We spend our time understanding our users, translating the company’s vision into actionable strategies, and representing the customer in the decisions our teams make while building the product. For the typical PM, that responsibility has historically resulted in meetings—meetings with their devs, design, the field, other PMs, customers and users… all day, every day.</p><p>Defaulting to meetings as your primary communication method is a PM antipattern that has been laid bare thanks to the rise of remote work. Trying to replicate the all-day-wall-of-meetings approach in an office-free company is like playing product management on hard mode. Besides being a recipe for the dreaded <a href="https://hbr.org/2020/04/how-to-combat-zoom-fatigue" target="_blank" rel="noopener noreferrer">Zoom fatigue</a> and eventual burnout, it’s a missed opportunity to unlock the full potential and flexibility of being on a remote dev team. Add in any kind of geographic complexity, like a team spread across multiple time zones, and your insistence on getting everyone onto a video call will result in bottlenecks, irritated engineers, and someone—perhaps the same someone, repeatedly—having to join meetings outside of their working hours if they want to be included in the process. <strong>But what if I told you that there are product managers out there working on fully remote teams </strong><i><strong>and loving it?</strong></i></p><p>As a PM at Upbound, I’m helping platform teams around the world to <a href="https://www.upbound.io/whitepaper/platform-teams-solution?utm_campaign=rise-above-the-clouds&amp;utm_medium=linkedin&amp;utm_source=organic-social&amp;utm_term=whitepaper&amp;utm_content=platform-for-platform-teams">build internal cloud platforms</a> that help them deliver amazing experiences to their own end users. We’re a global remote-first company—as of the writing of this post, Upbounders <a href="https://www.upbound.io/about">work fully remotely</a> from 10 countries on five continents.</p><p><strong>A huge advantage to working in a fully remote company is that you can form the best team around the problems you’re trying to solve and the value you’re going to deliver to your customers.</strong> For my squad, optimizing for skills and experience rather than location has resulted in a team spanning 4 countries from the Pacific (UTC-8) to Central Europe (UTC+1) time zones. Collaborating successfully with such a wide geographic spread is impossible if you’re a PM with a meeting addiction. If you’re stuck in the PM meeting trap, read on!</p><h2>Tips for getting out of the remote PM meeting trap</h2><p>Getting out of the meeting trap as a PM means rethinking the role that meetings play in your communication. It requires you to do the up-front work of establishing trust and working relationships remotely, being empathetic to ensure flexibility is distributed fairly within the team, and determining the right balance between asynchronous and synchronous collaboration for your context.</p><h3>Establish your foundation of trust</h3><p>Building up relationships based on trust and mutual respect is essential in any PM role, but requires a more intentional approach in a fully remote setting than you might have taken as an office worker.</p><h4>My tips for building trust with your team as a remote PM:</h4><ol style="list-style-type:decimal;"><li>Be sure you can fulfill your role as the “voice of the customer” on-demand and asynchronously through documentation</li><li>Create clear and transparent records of the decisions you make and rationale behind them</li><li>Dedicate time for casual one-on-one conversations with your teammates and peers</li></ol><p>Trust as a PM is earned by being a reliable subject matter expert on your customers and their problems as well as the data surrounding usage of your products. The classic approach for sharing that knowledge might involve throwing together some slides and spreadsheets that you walk people through (perhaps more than once) to make the customer problem and priority understandable. In a fully remote setting, it’s essential that you document that customer knowledge in a way that is more digestible and discoverable so that your squad can self-service access to the insights and understanding that you’ve developed by talking to users and researching the market. One lo-fi way to accomplish this is to put together a “cheat sheet” before kicking off feature work that lays out who you’re building for, what problem they’re trying to solve, why solving that problem is important to users and the business, and your supporting evidence (i.e. hard data and research snippets).</p><p>Related to this is being explicit and clear with the criteria you’re using to make product decisions—and getting that documented in a way that’s visible to the team async. This can be as simple as commenting on a Github issue with the rationale for a decision that was made live during daily standup, or as complex as building out a scorecard for prioritizing feature work. If product decisions are a black box for your team, async collaboration falls apart.</p><p>For me, building up trust is also rooted in dedicating time to get to know my teammates as whole people. Developing camaraderie in a fully remote setting can be tricky if your schedule as a PM is 100% dedicated to “official” meetings—the office apologists are onto something when they mourn the loss of hallway chats and coffee machine banter. I make a habit of throwing 20-minute casual coffee chats on people’s calendars once a month or so, being clear in the invitation that the goal is to get to know one another better rather than discuss a specific agenda. I’m lucky at Upbound to have regular opportunities to meet up IRL with others from the company—be it by traveling to a conference like KubeCon or a company event. If you have similar travel opportunities in your remote PM role, be sure to take full advantage of them!</p><h3>Strive for fairly-distributed flexibility and an economy of meetings</h3><p><strong>Flexibility</strong> is one of the biggest reasons I choose to work in a fully remote organization—from the flexibility to choose where I live, to avoiding time wasted on commutes, to setting custom work hours based on my needs. As a PM on a global remote team, it’s especially important to me that the decisions I make do not result in my teammates being unable to enjoy that same flexibility. In other words, if I am scheduling a meeting, I stop to consider how it will impact the people I am inviting and their own work-life balance. This might seem obvious, but in other companies, I’ve had colleagues consistently have to decide whether to join meetings outside of their working hours or risk being excluded from important discussions and decisions (especially when someone’s time zone or schedule made them the “odd one out”).</p><p>Our squad’s budget for synchronous communication with the full team hovers around 10 hours per 2-week sprint due to time zone differences. Having such an explicit limit on the amount of time we can all sit together on a call is a healthy mechanism for preventing meeting sprawl. Just like we prioritize our backlog of issues, we prioritize our backlog of conversations and collaboration points to try to ensure meeting time is spent wisely. Rather than defaulting to a meeting, communication and alignment might happen around a document, a Github issue, or an online whiteboard.</p><p>In a typical sprint, we spend 5 hours on squad rituals – daily standups, story writing/tech breakdowns, retros, and sprint planning. These timeboxed touchpoints form the heart of our squad operations and keep the tactical day-to-day work flowing when combined with all of the async communication happening within Github or Slack. The remaining budget, if we decide to spend it, is available for group discussions to brainstorm and share ideas for the future, align design and engineering approaches in a dynamic way, and so on. Our meetings are intentional, with a specific agenda and outcome expected, and we record them to share with others whenever possible.</p><h3>In the end, working remotely will make you a better, more empowered product manager</h3><p>Succeeding as a product manager in a fully remote company means breaking free of the PM meeting trap. Working on a remote team opens up new possibilities to build amazing software together with teammates and users from around the world, but it requires a different mindset than the one that served you well back in your office days. From recording product walkthroughs to creating self-serve knowledge bases of customer insights, remote product people are forever finding ways to serve as the voice of the customer even when they can’t be present for every discussion. Whether your foray into remote product management is temporary or permanent, reducing your meeting footprint creates new opportunities to build up your communication muscles while freeing up valuable time for strategic thinking and learning from your users.</p>

Succeeding as a Fully Remote Product Manager Means Breaking Your Meeting Dependence

<h2>Overview</h2><p>Today, we're announcing the Azure Reference Platform for Kubernetes + Data Services configuration package release in <a href="https://cloud.upbound.io/registry/upbound/platform-ref-azure">Upbound Registry</a>. The Upbound Platform Reference Architectures (<a href="https://github.com/upbound/platform-ref-aws" target="_blank" rel="noopener noreferrer">AWS</a>, <a href="https://github.com/upbound/platform-ref-gcp" target="_blank" rel="noopener noreferrer">GCP</a>, <a href="https://github.com/upbound/platform-ref-azure" target="_blank" rel="noopener noreferrer">Azure</a>, <a href="https://github.com/upbound/platform-ref-cloud-native" target="_blank" rel="noopener noreferrer">Cloud-Native</a>, and <a href="https://github.com/upbound/platform-ref-multi-k8s" target="_blank" rel="noopener noreferrer">Multi-K8s</a>) are foundations, intended to help accelerate understanding and application of Crossplane within your organization. We love to see how people build on these references, and encourage you to customize and publish your own configuration packages to the Upbound Registry.</p><p>Crossplane enables platform teams to offer simple and flexible self-service interfaces (via the Kubernetes API server) to provision any combination of API fronted resources, without sacrificing governance or control. The Azure Reference Platform for Kubernetes + Data Services is a great example of this. With this configuration, your platform team can offer a pair of resource kinds called "Cluster" and "PostgreSQLInstance" that allow your developers to provision the infrastructure they need in a self-service manner, while only having access to a limited set of configuration values.</p><p>With those limited values, we enable the requestor to provision a fully functional AKS cluster, with supporting infrastructure (e.g. Resource Group, Virtual Network, Subnet, and Azure DB) while the platform team maintains control of finer-grained attributes like Region, Network CIDR, and VM shapes. We also enforce Service Endpoint configuration to ensure the Azure DB instances are securely connected to the AKS nodes. As a bonus, we're using the Helm provider to include Prometheus in the provisioned cluster.</p><blockquote><p>Note: Because Crossplane providers operate as Kubernetes controllers, the deployed infrastructure is continuously reconciled. If someone changes a value in the cloud provider portal, Crossplane will automatically revert it to our intended state.</p></blockquote><p>The following manifests represent all that is required from a requestor. For Cluster, we allow node count, node size (This is transformed via a Composition from small/medium/large to predefined Azure VM types, the requestor cannot override those mappings), and Prometheus Helm chart version.</p>

<p>For PostgreSQLInstance, we expose only provisioned storage size. We additionally require a reference to the AKS cluster ID to correlate the secure networking configuration. Notice there are no inputs required for network provisioning. Those details are abstracted from the requestor and entirely controlled by the platform team.</p>

<blockquote><p>Note: In the two sample manifests, you'll notice the 'writeConnectionSecretToRef' block. For resources that generate sensitive connection details, Crossplane will automatically write these to Kubernetes secrets. This block enables the requestor to specify a predictable name for future reference.</p></blockquote><p>Using this Configuration, platform teams (and the application teams they support) can easily deploy Kubernetes clusters with securely connected database services to Azure Cloud, unlocking a lot of velocity and flexibility to deliver their software to multiple environments.</p><h2>Summary</h2><p>In the Kubernetes + Data Services Deployments on Azure platform reference architecture, we are offering requestors a semi-flexible self-service API (via the Kubernetes kubeapi). The platform team maintains control over the node sizes/mappings, regions, networking, and other supporting infrastructure configuration, while developers get a self-service experience that increases their deployment velocity. We encourage you to create an Upbound Cloud account and try it out for yourself with this <a href="https://github.com/upbound/platform-ref-azure" target="_blank" rel="noopener noreferrer">quick start</a>.</p>

Kubernetes + Data Services Deployments on Azure with Upbound Cloud

<p>This article was <a href="https://vmblog.com/archive/2024/01/25/upbound-2024-predictions-the-standardization-of-ai-tooling-and-platforms.aspx" target="_blank">previously published on VMblog here</a>.</p><p>With the rise of hot artificial intelligence (AI) tools, every company and person seemed to be experimenting with AI in 2023. There is no going back: AI will continue to play an evolving role.</p><h2>AI and platforms</h2><p>I predict that 2024 will be more about standardization on AI tooling and platforms. It's still the Wild Wild West with AI, but with more maturity will come more standardization and out of the box solutions.&nbsp;</p><p>There will be a great reckoning. We're going to see a lot of the "garbage" that exists today-like low-value UX/UI on top of other platforms (like on top of ChatGPT)-will basically go away. This will happen since it'll get much easier for any platform engineer to run these AI stacks themselves.</p><p>Here's what other members of the Upbound team contemplated regarding the potential impact of AI on businesses this year.</p><h2>AI and candidate-driven job matching</h2><p>Lem Diaz, head of people at Upbound, says:</p><blockquote><p>"I predict that AI will become more prevalent in conversational job matching. Job seekers will begin to see more interactive tools to help them navigate the front end of their job-seeking journeys. This may include things like asking questions about the company's culture, strategy, competitive landscape, tech stack, funding, and other factors and getting a list of matches. These interactive models will enrich a job seeker's understanding of their potential fit and whether or not to pursue a position at a company. This will begin the shift from employer-driven job matching to candidate-driven job matching. It'll still be nascent in 2024, but I believe it will mark the beginning of this shift powered by AI."</p></blockquote><h2>AI makes marketing less tedious</h2><p>Kelsey Havens, head of marketing at Upbound, notes:</p><blockquote><p>"AI will become less of a buzzword in marketing and more of an integrated feature in existing marketing tools and technology. Tedious and repetitive tasks like ad sizing, sequence writing, tagging and task management will be offloaded to AI, giving marketers more mental space and time to be creative and strategic."</p></blockquote><h2>Cloud-native, multi-cloud infrastructure powers AI and ML</h2><p>Tom Anthony, vice president of global sales and customer success at Upbound, adds:&nbsp;</p><blockquote><p>"In 2024, AI will make its way deeper into enterprises. I see this evolving in two ways. Cloud-native, multi-cloud infrastructure will be the fabric that enterprises standardize on to power their AI/ML initiatives. And, "AI-as-a-Service"- the ability for businesses to access AI tools and capabilities without having to invest in their own AI infrastructure or develop expertise-will become the way to drive faster innovation, productivity and cost savings within the enterprise."</p></blockquote><p>It is clear the teams building the underlying infrastructure powering platforms, including AI and ML, have played an increasingly important role in companies. Here at Upbound, we're about making the lives of platform teams easier while helping them meet security, compliance, and policy standards. I'm convinced that creating platforms powered by control planes is a crucial step towards enhanced efficiency-a need that becomes more pressing as AI permeates all facets of the business. I talk more about this in a video on how to <a href="https://resources.upbound.io/community/unleash-the-potential-of-your-aiml-platform-with-a-crossplane-control-plane" target="_blank">unleash the potential of your AI/ML platform with a Crossplane control plane</a>.</p><p>To learn more about how Upbound can enable you to standardize AI/ML infrastructure with reference architectures that are easily deployed and meet security, compliance, and policy requirements, <a href="https://blog.upbound.io/ai-ml/">view this blog here</a>.</p>

The Standardization of AI Tooling and Platforms

<p>What better way to kick off the new year than to reflect on the last one? Last year, we had some huge milestones that propelled Upbound and Crossplane forward in the cloud native space. From major product releases to important community contributions, there is much to recap. Looking forward, 2024 brings a new light on innovation as we build upon the foundation of our past achievements. It's in this retrospective moment that we find the essence of inspiration, knowledge, and strength to chart our course ahead.</p><h2>2023’s Big Wins</h2><h3>Upbound Becomes Generally Available, Helping Platform Teams Scale And Simplify Crossplane</h3>

<p>Though Crossplane can help any company streamline their cloud infrastructure, customers have told us how they don’t want to spend their bandwidth managing Crossplane, especially at scale.</p><p>In April of last year, <a href="https://blog.upbound.io/upbound-general-availability">we launched Upbound</a> to let customers offload the management of their control planes to Upbound. Our Managed Control Planes (MCPs) were built from the ground up for performance, scalability, and full lifecycle management. You can depend on MCPs to scale to thousands of CRDs, allowing you to use control planes to manage resources across as many cloud services as they desire. We even released a 30-day trial with the product, which you can <a href="https://www.upbound.io/register/a">sign up for at no cost here</a>.</p><h3>New Provider Families are Released, Offering a Better Cloud Native Integration Experience for Crossplane</h3>

<p>Since we released the official providers in 2022, our coverage of the most used resources for cloud-native deployments has quickly grown to 75%. As the number of resources in each official provider has increased, it is clear that no organization needs ALL those resources in one single provider.</p><p>With that in mind, <a href="https://blog.upbound.io/new-provider-families">we split up and organized the official providers into Provider Families or groups of smaller providers</a> that more closely align to how platform teams actually use them in June. This reduced bloat, improved performance, and provided a path for future growth as the number of cloud resources grows on a seemingly daily basis. Check out the <a href="http://docs.upbound.io/knowledge-base/migrate-to-provider-families/">migration documentation</a> and read <a href="https://blog.upbound.io/new-provider-families">the full update here</a> to leverage the streamlined providers.</p><h3>Upbound Achieves SOC 2 Type II Compliance, Strengthening Trust and Security</h3>

<p>In July, we successfully <a href="https://blog.upbound.io/soc2-type2-and-trust-center">achieved SOC 2 Type II compliance</a> to showcase our unwavering commitment to ensuring the highest level of security, privacy, and data protection for our valued customers.</p><p>We also launched the <a href="https://www.upbound.io/trust-center">Upbound Trust Center</a> where companies can find a consolidated view of everything we are doing to validate our adherence to industry-recognized standards and best practices, providing peace of mind to businesses and organizations that entrust us with their critical data.</p><h3>Leading the Partner Ecosystem for Crossplane, Upbound Establishes a New Partner Program</h3>

<p>Also in July, we launched our <a href="https://www.upbound.io/why-upbound/partners">Global Upbound Partner Program</a> to support the rapidly growing ecosystem around <a href="https://www.crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a>. The new program enabled partners to access Upbound’s products and services along with resources, technical expertise and go-to-market opportunities.</p><p>Some notable partners are Accenture, Akuity, Aviatrix, AWS, Azure, Datadog, Google Cloud, and more. <a href="https://blog.upbound.io/upbound-partner-program">Learn more about the partner program here</a>.</p><h3>Upbound Releases Spaces, Allowing You to Bring Managed Control Planes into Your Own Environment</h3>

<p><a href="https://blog.upbound.io/announcing-spaces">We released a new feature of Upbound in September: Spaces</a>. Upbound Spaces allows teams to run their own Upbound managed control planes in any hyperscale cloud provider or data center where compliance or data sovereignty is a concern.</p><p>With Spaces, users can self-host many managed control planes in a single Kubernetes cluster running in their own environment in addition to the Upbound managed environment that we offer today. <a href="https://www.upbound.io/request-a-demo">You can get a demo of how it works here. Just say want to try out Spaces in the comment box</a>!</p><h3>Upbound Contributes Control Plane Provider Technology to Crossplane</h3>

<p>At Upbound, we are committed to supporting the open-source landscape, particularly through the contributions we make to Crossplane. As such, <a href="https://blog.upbound.io/donate-upjet-provider-project-to-cncf">we donated Upbound’s control plane provider technology</a>, <a href="https://github.com/upbound/upjet" target="_blank" rel="noopener noreferrer">Upjet</a>, to the open source Crossplane project so that it can be officially governed under the Cloud Native Computing Foundation (CNCF).</p><p>With this, we are moving the providers for AWS, Google Cloud, and Microsoft Azure to the Crossplane project. Our goal is to accelerate the growth of the ecosystem around Crossplane and remove any doubt about the viability of the project especially in light of recent licensing changes in the industry.</p><h3>Crossplane’s Biggest Release to Date, v1.14</h3>

<p>With over <a href="https://github.com/crossplane/crossplane/compare/release-1.13...release-1.14">700 commits</a>, <a href="https://github.com/crossplane/crossplane/releases/tag/v1.14.0" target="_blank" rel="noopener noreferrer">Crossplane v1.14</a> is packed full of big features that will make Platform Engineers more productive and effective in building control planes to power their infrastructure. In particular, the beta release of <a href="https://blog.crossplane.io/composition-functions-in-production/" target="_blank" rel="noopener noreferrer">Composition Functions</a> is a game changer that allows teams to programmatically configure their infrastructure with familiar languages.</p><p>The velocity has only continued to increase as the project matures. Additionally, the community has recently reached an exciting milestone by surpassing over <a href="https://twitter.com/crossplane_io/status/1717194303846641755" target="_blank" rel="noopener noreferrer">10,000 members on Slack</a>, so everything about the project continues to grow. <a href="https://blog.crossplane.io/crossplane-v1-14/" target="_blank" rel="noopener noreferrer">See all the exciting progress in v1.14 here</a>!</p><h2>Other Highlights from 2023</h2><p>As you might have seen in our numerous product update blogs, we’ve come out with a number of features to improve the Upbound and Crossplane experience. You’ll find that in only a year, we have released about 30 new product features in addition to what you’ve already read above. Here are some of the highlights:</p><h4><a href="https://blog.upbound.io/2023-11-07-product-updates">November</a>:</h4><ul><li>Improved User Flow in the <a href="https://blog.upbound.io/2023-11-07-product-updates">Control Plane Explorer</a></li><li>Filterable Control Plane list in the dashboard</li><li>New “Referenced By” section in the Resource Details drawer</li></ul><h4><a href="https://blog.upbound.io/2023-10-24-product-updates">October</a>:</h4><ul><li><a href="https://blog.upbound.io/2023-10-24-product-updates">Navigating the Upbound Marketplace faster</a></li><li>Managed control plane connector now supported in an Upbound Spaces</li><li>New capabilities in up CLI</li><li>Release of <a href="https://blog.upbound.io/2023-10-10-product-updates">Upbound Spaces v1.1</a><ul><li>Auto-scaling control planes</li><li><i>up</i> CLI compatibility with Spaces</li><li>External Secret Store support comes to Spaces</li></ul></li><li>Improved resource details drawer and events stream</li></ul><h4><a href="https://blog.upbound.io/2023-09-26-product-updates">September</a>:</h4><ul><li><a href="https://blog.upbound.io/2023-09-26-product-updates">A control plane explorer for fleet scale use</a></li><li>Use Argo CD to target managed control planes in Upbound</li><li>Offer <a href="https://blog.upbound.io/2023-09-12-product-updates">Cluster-as-a-Service to your organization with configuration-caas</a></li></ul><h4><a href="https://blog.upbound.io/2023-08-25-product-updates">August</a><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">:</span></h4><ul><li>New <a href="https://blog.upbound.io/2023-08-25-product-updates">provider management experience</a></li><li><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">Streamlined configuration creation flow</span></li><li>Declaratively create managed control planes</li><li><a href="https://blog.upbound.io/2023-08-11-product-updates">Control Plane Dashboard Expanded View</a> (up to 100 Control Planes)</li><li>Single Table to View and Install Configurations</li><li>Events Tab enhancements to View Crossplane Events</li></ul><h4><a href="https://blog.upbound.io/2023-07-28-product-updates">July</a>:</h4><ul><li>Viewing <a href="https://blog.upbound.io/2023-07-28-product-updates">Crossplane Events in the Upbound Console</a></li><li>Surfacing Configuration Installation Errors in Context</li><li><a href="https://blog.upbound.io/crossplane-architecture-framework">Upbound Crossplane Architecture Framework Released</a></li></ul><h4><a href="https://blog.upbound.io/2023-06-30-product-updates">June</a>:</h4><ul><li>Upbound as an <a href="https://blog.upbound.io/2023-06-30-product-updates">identity source with Azure</a></li><li>ProviderConfig CRUD (Azure)</li><li>New Azure-based configuration starters</li><li>Skippable First Run Experience</li><li>Global CRD searching in the Upbound Marketplace</li><li><a href="https://blog.upbound.io/2023-06-09-product-updates">CRUDable ProviderConfigs</a></li><li>Improved Control Plane Explorer</li></ul><p>If you’d like to read more about any of them, you can <a href="https://resources.upbound.io/product-news">see them all here</a>.</p><h3>Looking Forward to 2024</h3><p>2023 was a busy year for us and we are sure 2024 will see more huge improvements led by feedback from our Upbound customers and the Crossplane community. It is increasingly clear that teams don’t want infrastructure to stand in the way of innovation while at the same time they need to meet security, compliance, and policy requirements. We believe that Upbound and Crossplane are the best way to meet these needs and the features that will come out in 2024 will help make companies' lives easier when deploying applications in cloud-native environments.</p><h2>See It In Action</h2><p>To see all of these wins in action, try out the product for yourself! We have a free 30-day trial you can <a href="https://www.upbound.io/register/a">sign up for here</a>.</p>

Elevating Platforms: Celebrating Upbound and Crossplane Milestones of 2023

<h2>Introduction</h2><p>Crossplane Compositions are a powerful abstraction layer that enables platform teams to create a custom API for their internal customers to simplify and standardize the infrastructure management process. The Composition authors wrestle with the complexity of cloud infrastructure and at the same time need to ensure a stable and user-friendly API surface for the platform consumers.</p><p>Historically, Compositions were intended to support only very simple resources’ manipulation to allow the API calls to patch and transform the information passed from a Claim or Composite Resource (XR) to the Composition engine. The lack of touring complete language supporting the required transformations resulted in a very verbose YAML files with lots of repetitions, increasing the toil of authoring Compositions.</p><p>With the addition of <a href="https://github.com/crossplane/crossplane/releases/tag/v1.11.0" target="_blank" rel="noopener noreferrer">Compositions Functions</a> in the Crossplane v.1.11 it is possible to use a programming language, like Go or Python (more to come) or in our case a capability of Go called <a href="https://pkg.go.dev/text/template" target="_blank" rel="noopener noreferrer">Go-templating</a> to enrich and transform the authoring of Compositions.</p><p>This blog will guide you through the process of rewriting a simple internal platform Composition in the Go templating style using the <a href="https://marketplace.upbound.io/functions/crossplane-contrib/function-go-templating" target="_blank" rel="noopener noreferrer">go-templating-function</a>.</p><h2>Use Case: Collapsing two Compositions into one</h2><p>Since traditional Composition's engine does not allow using conditionals, there is no way to render one Composition or another using a parameter from a Claim. To illustrate this example, let’s look at the two Compositions that render a GCP Bucket:</p><h3>Standard bucket</h3><p>This very simple composition renders a single GCP bucket</p>

<h3>Versioned Bucket</h3><p>Another Composition needs to be created to accommodate for a versioning setting.</p>

<p>In this case, we have to have two Compositions and need to use a Composition selector in a claim just for this one field.</p><h3>Using go-templating-function</h3><p>The two Compositions can be transformed into just one using the go-templating-function. Follow these steps</p><p>1. Install <a href="https://marketplace.upbound.io/functions/crossplane-contrib/function-go-templating" target="_blank" rel="noopener noreferrer">go-templating-function</a> and <a href="https://marketplace.upbound.io/functions/crossplane-contrib/function-auto-ready" target="_blank" rel="noopener noreferrer">function-auto-ready</a> from the marketplace.</p>

<p>2. Convert the Composition to use the go templating. The initial conversion gives us one to one translation between the standard “Patch and Transform” style Composition and the go-templating style. We are going to improve this design.</p>

<p>Using Composition Functions is very well documented in the <a href="https://docs.crossplane.io/v1.14/concepts/composition-functions/" target="_blank" rel="noopener noreferrer">Crossplane docs</a>. Read the details to learn more about it.</p><p>The current implementation of our Composition renders the <i>non-versioned</i> Bucket. Next steps are to change the XRD and template to accommodate for the versioning field.</p><p>Using the new Crossplane beta trace command is helpful in checking the latest events on the composed resources from the Claim/XR:</p>

<h3>Adding the versioning field</h3><p>1. Modify the XRD to set the versioning field with a boolean flag:</p>

<p>2. Now let’s modify the Composition template to add the conditional for the versioning field.</p>

<p>3. Now we are ready to apply the Claim of the versioning enabled Bucket to the preconfigured GCP project.</p>

<h3>Default values</h3><p>Not all the schema fields are required, and for those the Composition provides default values. location and storageClass are not required in the schema, and the Composition provides default values for those fields when omitted. Let’s add them to the template. Now supplying a Claim without the location and storageClass fields will result in the default values being rendered like so.</p>

<h3>Bringing back PatchSets</h3><p>This specific Composition is very simple, but there are multiple others where the same patch needs to be applied to multiple resources. In the original Composition we have the ownerAndServiceLabels that are applied to all resources that support labels.</p>

<p>With the go-templating-function, it’s easy to define the <i>patchSet-like</i> behavior</p><p>Here is the modified Composition template part with the labels:</p>

<h3>Template Variables</h3><p>One small quality of life improvement is to define variables in the template so there is no need to type .observed.composite.resource.spec.parameters all the time. Here is the final version of the Composition:</p>

<h2>Conclusion</h2><p>In conclusion, the use of the go-templating-function in Compositions authoring significantly simplifies the process of creating and managing resources with varying configurations and makes it easier to manage complex Compositions.</p><p>It allows for the creation of Compositions with conditional fields, reducing the need for multiple compositions for each variation of a resource. The re-introduction of PatchSets-like behavior makes the portability from “Patch and Transform” style Compositions easier. Adding variables scoped to Composite Resource paths makes it easier to reason about the template.</p><p>Additionally, using the new Crossplane CLI functionality to render the resources based on the Claim, Composition and functions and also trace the state of resources is a very helpful development tool. Here’s a tip: running the commands with watch makes the development loop even better.</p>

<p>If you are interested in technical details and design of the go-templating-function, check out the <a href="https://github.com/crossplane/crossplane/pull/4935" target="_blank" rel="noopener noreferrer">go-templating-function one-pager</a>. Big thanks to <a href="https://github.com/ezgidemirel" target="_blank" rel="noopener noreferrer">@ezgidemirel</a> for creating the function! It significantly improves the Compositions authoring process.</p><p>You can find various functions in our <a href="https://marketplace.upbound.io/functions" target="_blank" rel="noopener noreferrer">Marketplace</a> and <a href="https://docs.crossplane.io/knowledge-base/guides/write-a-composition-function-in-go/" target="_blank" rel="noopener noreferrer">create your own</a> to take the Crossplane Compositions to the next level.</p>

Improve Crossplane Compositions Authoring with go-templating-function

<p>Today, we are announcing a new feature of <a href="https://www.upbound.io/product/upbound" target="_blank">Upbound</a>: Spaces. Upbound Spaces allows teams to run their own Upbound managed control planes in any hyperscale cloud provider or data center where compliance or data sovereignty is a concern.</p><p>Previously, when users wanted to run Crossplane, they had to spin up an entire Kubernetes cluster per instance of Crossplane and manage its lifecycle. With managed control planes, users can offload that management to Upbound’s software. Now, with Spaces, <strong>users can self-host</strong> many managed control planes in a single Kubernetes cluster running <strong>in their own environment</strong> in addition to the Upbound managed environment that we offer today.</p><p>It’s been incredible to see the ways customers are building platforms powered by managed control planes on Upbound. Variphy is an analytics platform for Unified Communications who’ve found a lot of value building on Upbound. Dylan Moore, a Principal Engineer at Variphy shared, “By using Upbound, we are able to shift complex cloud-native management and deployment to a highly scalable service rather than trying to manage it all ourselves. Upbound's new self-hosted feature gives us more options for where we deploy managed control planes. This helps us be more efficient while allowing flexibility for future deployment requirements.”</p><p>For other users, they want to offload the toil of managing Crossplane at scale to Upbound, but <strong>requirements such as compliance and data sovereignty</strong> mean they need to run control planes in their own environments instead of as SaaS. Spaces let you extend the Upbound platform into your own environment–whether that’s a cloud account in AWS, Azure, or Google Cloud or an on-prem data center–which provides the data separation needed for certain environments.</p><p>Nuno Guedes, cloud compute lead at <a href="https://www.upbound.io/why-upbound/customers/millennium-bcp" target="_blank">Millennium bcp</a> shared, “As Portugal’s largest private bank, we invest in the best technologies to provide us with business value while enabling us to adhere to our compliance standards. Upbound helped us to modernize and standardize our workflow backed by control planes, leading our platform team to save thousands of hours yearly, reducing human error and improving compliance and visibility. Upbound Spaces enables us to reach new scale and service continuity targets, while providing a tailored control plane experience to our internal customers.”</p><p>Business critical customers can begin using the Spaces feature today. Interested users can get trial access to the feature by <a href="https://www.upbound.io/contact" target="_blank">contacting Upbound</a>.</p><h2>The power of managed control planes</h2><p>At the heart of the Upbound platform is managed control planes. Our managed control planes were built from the ground up for performance, scalability, and full lifecycle management:</p><ul><li><strong>Lower operational complexity:</strong> You no longer have to manage individual Kubernetes clusters to use Crossplane, making it practical for organizations to successfully operate tens–or even hundreds–of control planes. Organize your control planes by team, business unit, or application. You choose.</li><li><strong>Highly scalable:</strong> each managed control plane runs a hyper-optimized Crossplane instance, dynamically scaling resource consumption. Scale to arbitrary sizes with your organization by running many of them.</li><li><strong>Git integration out of the box:</strong> Drive the configuration of your control planes from Git without needing to set up additional tools.</li></ul><p>Managed control planes commoditize creating new instances of Crossplane and unlock new ways to build multi-tenant solutions that are highly secure.</p><h2>Fully managed control planes in your own environment</h2><p>Think of an Upbound Space as a self-managed slice of the Upbound platform in your own environment, whether that’s a hyperscale cloud provider or on-prem. Spaces supplement our SaaS service by enabling a new deployment option: to have control planes that run in your preferred hosting environment <i>and</i> Upbound’s own SaaS. Spaces let you:</p><ul><li>Increase scale and cost efficiency by running 50 or more control planes per Kubernetes Cluster instead of just 1.</li><li>Each control plane configuration is fully managed from git</li><li>Integrate with Kubernetes ecosystem tooling to manage the full lifecycle of the control planes.</li></ul><p>All that’s required to bootstrap a Space is a Kubernetes cluster. Popular managed Kubernetes services including Amazon EKS, Google GKE, and Microsoft AKS are fully supported.</p>

<p>After you bootstrap an Upbound Space into a Kubernetes Cluster, you can use the <i>up</i> CLI or interact with its API directly to create managed control planes in your Space. The control planes’ lifecycles are automatically managed by Upbound software running in the Kubernetes cluster.</p><p>Today at launch, we have full support for interacting with a Space using the <i>up</i> CLI. It’s on our roadmap to add the ability to optionally connect a Space back to Upbound’s global SaaS service and Console. This will give you a unified point of control across all your managed control planes. You’ll be able to use the same great control plane explorer views and debugging tools on a managed control plane running in a Space.</p><h2>Declarative Interfaces</h2><p>We’re also introducing new declarative interfaces for interacting with resources in Upbound. Customers can use the new Controlplane API to declaratively create new managed control planes. Users can use popular GitOps tools combined with Git to declaratively create new managed control planes. This capability will first be available for control planes running in a Space and make its way back to the broader Upbound platform soon.</p>

<h2>Enhanced Git integration</h2><p>All managed control planes have a single source of truth for their configuration stored in a Git repository. In Upbound, GitHub integration is available out-of-the-box. This enables platform teams to define their control plane’s API definitions and compositions in Git. Upbound handles packaging and deploying the configuration to the managed control plane.</p><p>We’re expanding the capabilities of Upbound’s built-in Git integration to support deploying all Crossplane resource types. In addition to deploying XRDs and compositions, you can now deploy “runtime” configurations like ProviderConfigs, EnvironmentConfigs, and more. Control planes also now have a ControlplaneSource property that allows them to source configuration from <i>any</i> Git repository–not just GitHub–provided the version control service offers <i>SSH</i>, <i>BearerToken</i>, <i>Basic</i>, or <i>None</i> as auth methods. This enhancement is available for managed control planes when running in a Space today and will make its way back into the broader Upbound platform soon.</p>

<h2>Bring managed control planes into your own Space today</h2><p>You can get started building with Spaces today. Spaces is a feature of Upbound and available in our business critical tier. A trial is available if you contact Upbound. Head over to <a href="https://docs.upbound.io/" target="_blank">Upbound's docs</a> to find the quickstart guides. For pricing and other commercial information, <a href="https://www.upbound.io/contact" target="_blank">contact Upbound sales</a>.</p><p>What to learn more? <a href="https://www.addevent.com/event/dg18380407" target="_blank">Watch the livestream</a> on Thursday, September 7 at 8 AM PT, Unveiling Upbound Spaces: Unlock the Power of Managed Control Planes in Your Own Hosted Environment. Register for <a href="https://www.upbound.io/resources/events/webinars/upbound-spaces-webinar-sep28?utm_campaign=2023_Q3_9.6_GBL_CT_EM_Spaces-Announcement-Email&amp;utm_medium=email&amp;utm_source=webinar&amp;utm_term=webinar" target="_blank">this webinar</a> September 28 @ 8 AM PT to hear more about why running Upbound Spaces might be right for you, especially if you have rigorous compliance and data sovereignty requirements for your internal developer platforms (IDPs) and cloud-native Infrastructure-as-Code (IaC)!</p>

Introducing Spaces: Bring Upbound Managed Control Planes into your own environment

<p>Since the release of <a href="https://aws.amazon.com/lambda/" target="_blank">AWS Lambda</a> in 2014, serverless applications have gained wide adoption. But it can be a challenge to configure and manage the mix of events, code, backends, permissions, and other dependencies that make up a serverless application.</p><p>With powerful <a href="https://www.crossplane.io/" target="_blank">Crossplane</a> primitives like <a href="https://docs.crossplane.io/v1.12/concepts/#managed-resources" target="_blank">Managed Resources and Composition</a> we can manage these serverless deployments and provide internal development teams with custom Kubernetes-based API.</p><p>This blog will cover two topics: Using Crossplane to provision AWS Lambda functions, and invoking those functions in order to return data to Crossplane so that we can use it to provision other Resources.</p><h2>The Challenge</h2><p>The platform engineering team supports developers in many global regions. Each team has a primary and a backup region for their cloud infrastructure.</p><p>The proposed solution is to have an <a href="https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html" target="_blank">AWS Parameter Store</a> (SSM) to store common parameters and have Crossplane provision infrastructure based on each team’s Primary and Backup regions.</p>

<h2>Our Lambda Architecture</h2><p>To start, we’ll review the infrastructure architecture. Our application is made up of several Crossplane <a href="https://docs.crossplane.io/v1.12/concepts/composition/" target="_blank">Composite Resources</a>. To make Composite Resource available and functional in your custom API need to configure two components:</p><ul><li>An API defined by the platform team called the CompositeResourceDefinition or XRD.</li><li>One or more Compositions that implements the API defined by the XRD by provisioning Managed Resources like S3 Buckets or GKE Clusters. For the platform we are building, we have defined a number of XRDs and Compositions.<br><br>One of the ways to deploy AWS Lambda functions is by storing them in an S3 Bucket as a .zip file, so the <strong>XBucket</strong> Composition creates an S3 bucket and associated configuration settings like Encryption and BucketVersioning. This bucket will be used to store the packaged Lambda functions.<br><br>The <strong>XParameter</strong> Composition provides an API for storing values into AWS SSM, and the <strong>XFunction</strong> composition takes care of provisioning the Lambda function and associated IAM roles (for example, we have to allow our Lambda function to fetch parameters from the SSM Parameter store.</li></ul>

<h2>Storing Parameters in AWS SSM</h2><p>First, let’s look at the <strong>XParameter</strong> Composition. As part of the Composition, the platform team can define a namespace-scoped <a href="https://docs.crossplane.io/v1.12/getting-started/introduction/#claims" target="_blank">Claim</a> called <strong>Parameter</strong>, which allows teams to request Crossplane infrastructure into a Kubernetes namespace.</p><p>Our Lambda function will use the value stored in these Parameters to tell Crossplane where to install the user’s infrastructure.</p><p>In our example team-1 and team-2 use parameters to store their Primary and Backup cloud regions.</p><p>To create a new SSM Parameter, a team submits a standard Kubernetes YAML manifest to the Cluster to deploy using our <strong>Parameter</strong> Kind. In this example, team-1 configures their backupRegion to be us-west-1</p>

<p>On the cluster each team has their Parameters scoped to their namespace:</p>

<h2>Creating our Lambda Function</h2><p>We’ll use Crossplane to provision and manage our Lambda function, using a Composition called <strong>XFunctionDeploy</strong>. This Composition creates an S3 bucket and uploads our Lambda function’s python code into an Object in the created bucket. BucketVersioning is set so that any new code uploaded to the S3 bucket triggers an update of the Lambda function.</p><p>Since compositions can be nested, we use our existing <strong>XBucke</strong>t and <strong>XFunction</strong> Compositions. In this way we’re creating a reusable library of components.</p>

<h2>Giving Our Lambda Function the Right Permissions</h2><p>Our Lambda function needs to be able to connect to the SSM parameter store in order to query it. In our <strong>XFunction</strong> Composition create a Role with the following Policy and also attach the AWSLambdaBasicExecutionRole managed policy to this Role.</p>

<h2>The Lambda Function</h2><p>To make things easy to understand, we’ve created a simple Lambda function in Python that uses the <a href="https://aws.amazon.com/sdk-for-python/" target="_blank">boto library</a> to fetch SSM parameters. This function is packaged into a Zip archive and uploaded to the S3 bucket using a <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/v0.33.0/resources/s3.aws.upbound.io/BucketObject/v1beta1" target="_blank">BucketObject</a>.</p>

<h2>Invoking Our Lambda Function</h2><p>To trigger our Lambda function, we need to send it a JSON payload with the parameter we are interested in fetching:</p>

<p>In Crossplane we can use an&nbsp;<a href="https://marketplace.upbound.io/providers/upbound/provider-aws/v0.33.0/resources/lambda.aws.upbound.io/Invocation/v1beta1"><u>Invocation</u></a>&nbsp;to trigger the function to run and collect the output. How does the Invocation know which Lambda function to call? One method is to use a Selector to match the Lambda function’s Kubernetes Object on the cluster:</p>

<p>When provisioned by Crossplane, the Invocation will return the output of the Lambda in its status:</p>

<p>Now that we have results, we can use the outputs in other Compositions.</p><h2>Putting It All Together</h2><p>Finally we can define a sample Application that will be created in a Composition called <strong>XApplication</strong>. The Composition consists of two Invocations that call the lambda function and store the output in the compositions status field. Those values are then passed to a VPC Managed resource to create VPCs in both the primary and backup regions.</p>

<p>The results of each function invocation is applied to the XApplication’s status field:</p>

<p>Now that Crossplane has created our VPCs, we can use kubectl’s support of&nbsp;<a href="https://kubernetes.io/docs/reference/kubectl/jsonpath/"><u>JSONpath</u></a>&nbsp;to extract the region for each VPC:</p>

<h2>Deploying the Platform</h2><p>This is the first in a series of blog posts highlighting how Crossplane and AWS Lambda work together. This next section will describe how you can install and deploy this configuration into your Kubernetes and AWS environments.</p><p>The code and examples can be cloned from <a href="https://github.com/upbound/platform-ref-lambda" target="_blank">https://github.com/upbound/platform-ref-lambda</a>, with installation instructions located in the <a href="https://github.com/upbound/platform-ref-lambda/blob/main/README.md" target="_blank">README</a> file. You’ll need a Kubernetes cluster and AWS credentials to deploy the platform</p><h2>Final Thoughts</h2><p>We hope this is a starting point for integrating AWS Lambda with Crossplane. If you’re interested in learning more or have questions, <a href="http://slack.crossplane.io/" target="_blank">join the Crossplane Slack</a> and ask us there or open an issue on the <a href="https://github.com/upbound/platform-ref-lambda" target="_blank">https://github.com/upbound/platform-ref-lambda</a> repository.</p>

Using Crossplane to Provision and Invoke AWS Lambda functions

<p>Upbound&nbsp;<a href="https://blog.upbound.io/blog/upbound-general-availability/"><u>launched&nbsp;</u></a>this week and we’re excited to see how platform teams begin building above the clouds with&nbsp;<a href="https://www.upbound.io/product/upbound"><u>Upbound</u></a>. Users beginning their journey in the product will notice the Get Started experience only offers launching managed control planes from Crossplane configurations built on AWS or GCP.</p>

<p>Does this mean users who want to build above Azure are out of luck? Not at all! While we work on building a configuration for Azure (coming soon!), this blog demonstrates how you can use the features &amp; capabilities of Upbound to build a platform above Azure.</p><h2>Complete the Get Started experience</h2><p>Upbound’s Get Started experience must be completed before you can gain access to the Upbound Console. Once you reach the Console, you will be able to provision another managed control plane and create a GitHub-synced configuration where you will define your APIs for Azure. If you have not already completed the Get Started experience, “speed run” through it by selecting any of the configurations above, connect Upbound to your GitHub account, and give your first managed control plane a name.</p><p>Finally, when Upbound asks for parameters to connect Upbound to GCP or AWS, provide fake strings. Upbound uses these inputs to concoct a ProviderConfig for your managed control plane to connect to GCP or AWS. But we don’t care about this – we’re creating our own managed control plane for Azure!</p>

<h2>Use the Upbound Console</h2><p>Let’s get to work building a platform above Azure driven by an Upbound managed control plane. From Upbound Console start by creating a new configuration. Hover over the `Create Configuration` button and select `Start from Scratch`.</p>

<p>To create a new configuration from scratch, give your configuration a name (for example, “my-azure-platform-apis”), set the GitHub repo visibility to whichever you prefer, and click `Clone configuration to GitHub`. After the configuration is created, Upbound will take you to the overview screen for your new configuration. Confirm that Upbound created a repo for you (it should look something like “https://github.com/&lt;your-gh-account&gt;/my-azure-platform-apis.git</p><p>Navigate back to the dashboard of the Console by clicking the icon in the top navigation bar. Now, create a managed control plane by clicking `Create Control Plane`.</p>

<p>Select the configuration you created previously to install it on your new managed control plane. In the next screen, give your control plane a name (for example, “azure-control-plane”), and click `Create`.</p>

<p>You should now have a new managed control plane created and configured to install from a new “scratch” Crossplane configuration. The remaining steps you need to do are:</p><ul><li>Author a new API for Azure resources in your git repo based on <a href="https://marketplace.upbound.io/providers/upbound/provider-azure/v0.30.0" target="_blank">provider-azure</a></li><li>Deploy the new configuration with API to your managed control plane</li><li>Create a ProviderConfig for Azure on your managed control plane</li></ul><h2>Author your API</h2><p>Go to the GitHub repository Upbound created for you in the previous step. Open the `crossplane.yaml` file and replace the contents with the following (<a href="https://gist.github.com/cwilhit/9316f435b75fcf564633928cb1b823fc" target="_blank">gist reference</a>):</p>

<p>The important thing we have done above is take a dependency on provider-azure for this configuration. Next, create a folder called “apis” in the root of your repo. In the “apis” folder, create a folder called “blob”. In the blob folder, create a “definition.yaml” and “composition.yaml”. Your directory structure should look like this:</p>

<p>We are going to build an API for Azure Blob storage. To start, let’s define the shape of the API. Open the `definition.yaml` file and paste in the following (<a href="https://gist.github.com/cwilhit/046b4eec3bd9070c07444e6bb25fbf26"><u>gist reference</u></a>):</p>

<p>Close and save the file. Next, open the `composition.yaml` file and paste in the following (<a href="https://gist.github.com/cwilhit/7e132e8115b34226ead4acfc7669f3e1"><u>gist reference</u></a>):</p>

<p>Save and close the file. Commit and push the changes to your repo on GitHub.</p><h2>Deploy new configuration definition</h2><p>Back on Upbound Console, click into your managed control plane for Azure. You should see an update is available to be installed on your control plane. Initiate the update by clicking the `Update Available` text and confirm by clicking `Update Configuration`.</p>

<p>It will take about a minute or so to apply the latest configuration. You can click over to the Settings tab, scroll down to Providers, and see that provider-azure gets installed. Once the configuration has been updated, there should now be a “Blob” type card in the explorer view (you may need to refresh the page once the update is completed).</p>

<h2>Create a ProviderConfig</h2><p>The last thing you need to do is create a ProviderConfig on your managed control plane for provider-azure, so your control plane can communicate with Azure and process resource requests. Provider-azure does not support Upbound’s <a href="https://docs.upbound.io/knowledge-base/oidc/" target="_blank">OIDC integration</a> yet, so you will need to provide credentials for a service account. You can find instructions for how to do this in the <a href="https://marketplace.upbound.io/providers/upbound/provider-azure/v0.30.0/docs/quickstart" target="_blank">quickstart documentation</a> for provider-azure under “Create a Kubernetes secret”.</p><p>In order to push your ProviderConfig to your managed control plane, you can use the up CLI’s <a href="https://docs.upbound.io/cli/command-reference/#controlplane-kubeconfig-get" target="_blank">ctp kubeconfig get</a> command to set your kubeconfig. For that command, you need</p><h2>Make a claim against your API</h2><p>Now that you’ve configured your managed control plane to communicate with Azure, it’s time to create a claim for the Blob API. You can use your control plane’s <a href="https://docs.upbound.io/concepts/ctp-portal/" target="_blank">portal</a> to do this or you can submit the claim directly via CLI (<a href="https://gist.github.com/cwilhit/1352e81b2a982ff30a79772f70585e11" target="_blank">gist reference</a>).</p>

<p>After you’ve submitted the claim, you can return to the control plane explorer view and observe the resources get created. It can take a few minutes, but you should eventually see green status icons for each of the resources created.</p>

<p>Congratulations: you now have a managed control plane in Upbound configured to talk to Azure &amp; the definition of your APIs is now syncing from GitHub.</p><p>&nbsp;</p><hr><p>&nbsp;</p><p>Want to try out Upbound for yourself? Enable SRE teams with a more efficient workflow and the building blocks of platform engineering by setting up your first cloud platform powered by Upbound’s managed control planes. &nbsp;<a href="https://upbound.io/register?ref=blog.upbound.io"><u>Sign up for your 30 day free trial here</u></a>!</p>

Using Upbound to Build a Platform Above Azure

<h2>What if onboarding a new software vendor was as easy as adding a dependency?</h2><p>The process of onboarding a new vendor in a large enterprise is long and arduous. While organizations frequently have a uniform set of checks that any software must undergo before it can be adopted, the process inevitably leads to special cases being identified as unique to each vendor. This creates an inefficient iteration cycle that can last months — time in which the vendor could have been providing value to the customer.</p><p>If vendors were able to package their product in a way that allowed them to easily integrate into existing customer platforms, adoption could be drastically more efficient.</p><h2>Crossplane Packages and API Dependencies</h2><p><a href="https://www.crossplane.io/" target="_blank">Crossplane</a> is a framework for building control planes. Large cloud providers offer a suite of services that provide varying levels of abstraction over physical compute. To build the platform that can offer these services to thousands of customers, cloud providers have an underlying control plane that ensures the desired state of infrastructure that a customer has requested is aligned with the actual state.</p><p>If they are not already, the control plane will work to drive the two states to alignment. In simplest terms, the control plane is what translates from the interface exposed to users to actions required to satisfy their requests. A platform is the API that the control plane exposes.</p>

<p>In Crossplane, the interface, or APIs, as well as the translation logic is grouped into&nbsp;<a href="https://docs.crossplane.io/v1.10/concepts/packages/"><u>packages</u></a>. Packages that include both APIs and logic are referred to as&nbsp;<a href="https://marketplace.upbound.io/providers"><u>Providers</u></a>, while those that strictly translate from an abstract interface to a more granular one are referred to as&nbsp;<a href="https://marketplace.upbound.io/configurations"><u>Configurations</u></a>.</p><p>Much like libraries in a programming language, packages may&nbsp;<a href="https://docs.crossplane.io/v1.10/concepts/packages/#configuration-packages"><u>declare dependencies</u></a>&nbsp;on other packages and build upon their APIs. When a package is installed in a Kubernetes cluster where Crossplane is running, the package manager will evaluate its dependencies and install compatible versions of any that are not already present.</p>

<p>For example, if a user wanted to build a Configuration package that presented a developer-friendly interface to requesting MySQL databases, they may define a translation from that interface to the <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/latest/resources/rds.aws.upbound.io/Instance/v1beta1" target="_blank">RDS API</a> offered by <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/latest" target="_blank">provider-aws</a>, then declare a dependency on provider-aws, with optional version constraints. When their Configuration package is installed, Crossplane will ensure that provider-aws is also present.</p><p>If another user then wanted to include the MySQL API alongside other APIs in their control plane, they could either install the MySQL Configuration package directly or declare a dependency on it from another package that is installed. Either way, Crossplane will traverse the dependency tree, ensuring that a control plane with healthy packages will respond to the creation of the instance of any API with the desired behavior.</p><h2><strong>Defining a Platform with a Root Package</strong></h2><p>While Crossplane allows users to install many packages alongside one another, a common pattern has emerged of defining a single “root” package, which is an ancestor node of every other package that gets installed in a control plane. Doing so makes the entire API surface area reproducible by installing that one package. As an organization grows and evolves over time, that package can be expanded by defining new APIs or establishing new dependencies.</p>

<p>Furthermore, because using a root package is a convention rather than a technical constraint, the property of composability is not violated. Taking the previously mentioned MySQL Configuration package for example, a user may install it as the root package of their MySQL database control plane, while another user may depend on it as only one component of a much larger API surface for use cases like internal cloud platforms.</p><h2>Declaring a Vendor Dependency</h2><p>While the attributes of Crossplane packages enable platform builders to quickly add functionality to their control planes, they also present a unique distribution mechanism for vendors. When your customers all build on a common substrate, you need only target that substrate. Furthermore, the APIs you offer to your customers do not have to be “one size fits all” — there is room for customization both in front and behind the interface.</p>

<p>As an example, a developer tools vendor may offer a product to enterprise customers that manages hosted development environments. The service needs to be distributed in a manner that it can be run on the customer’s cloud provider of choice, and the interface to deploy a development environment needs to support all configuration options that a customer could need. Typically, this would require a combination of scripts, deployment manifests and documentation.</p><p>However, when bundling as a Crossplane package, a vendor can specify dependencies on external infrastructure, such as a relational database or in-memory cache and rely on the customer’s control plane to provide them.</p>

<p>To make it concrete, a Configuration package to deploy the aforementioned hosted development environment product on AWS could establish a dependency on provider-aws, and include a Composition that created an RDS instance. When the customer adds the Configuration package as a dependency in their root package, Crossplane will verify the presence of a compatible version of provider-aws in their control plane.</p><p>When the customer interacts with the API offered by the vendor package, the creation of an RDS instance object in the cluster will result in the provisioning of an RDS instance in the customer’s AWS account, subject to all of the policies and constraints they already have in place. Because the vendor’s deployment ultimately depends upon the APIs that the customer’s control plane already offers, a successful deployment implies compliance.</p><p>Similarly, the customer is not required to interface with the vendor’s product via the interface that the vendor offers. A common pattern in the Crossplane community is to take an API and wrap it in a higher-level abstraction, optionally including additional resources that are to be provisioned alongside the original.</p><p>For example, if a customer wanted to create monitoring and alerting policies that are custom to their organization every time they deployed a developer environment, they could wrap the vendor’s developer environment API and their monitoring APIs in a higher-level abstraction, and only give developers access to interact with the abstract API.</p><h2>Discovering Your Next Platform Component</h2><p>To build platforms like the ones described in this post, customers need a place to discover packages and vendors need a means of distribution. The Crossplane community takes advantage of the automatic API documentation and robust discoverability features of the <a href="https://marketplace.upbound.io/" target="_blank">Upbound Marketplace</a>. Search for your next platform component or publish your own, and feel free to reach out in <a href="https://slack.crossplane.io/" target="_blank">Crossplane Slack</a> if you have any questions!</p><p>This article was originally posted on <a href="https://thenewstack.io/crossplane-a-package-based-approach-to-platform-building/" target="_blank">The New Stack here.</a></p>

Crossplane: A Package-Based Approach to Platform Building

<p>We’re at the cusp of a special moment in Cloud Computing. Cloud services that cover the spectrum of “-as-a-service”—ranging from the foundational “infrastructure-as-a-service” and building on up to “5G networks-as-a-service” and beyond—have cropped up and promised customers faster time-to-market and lower overhead to operate their businesses on the global stage. Now, more than ever, organizations have a wealth of options to choose from.</p><p>But with these options comes inevitable sprawl and the challenges associated with stitching services from many vendors together. While it might feel easier to go all-in on one cloud vendor, customers risk closing themselves off from innovation happening across the rest of the industry. And even within the scope of a single cloud vendor—golmany of which offer ten’s of their own services—sprawl&nbsp;<i>still&nbsp;</i>must be contended with.</p><p>Crossplane is a technology that will unlock a “Golden Age” for organizations: it is a framework for building control planes; it gives organizations the tools and knowledge required to create solutions that can consolidate teams onto a single platform (bye bye sprawl) while enabling them to stitch across whichever cloud services are desired. However, Crossplane is not a silver bullet and there is work involved. After all, the Golden Ages of antiquity did not just “happen” upon them. It took work to achieve that prosperity, and more importantly it was the discovery of certain learnings that set them down the path towards prosperity.</p>

<h2>Building in the Cloud</h2><p>The Cloud is massive and growing: In addition to large public cloud providers such as AWS, Azure, and GCP, other providers such as Cloudflare, Snowflake, Okta, Datadog, DigitalOcean, and more offer cloud services that help organizations accomplish their business goals.</p><p>The goal of the Cloud is to allow an organization to focus on building what matters most for their business. Whether that means offloading management of underlying hardware (because they’re running in virtual machines), or managing the underlying virtual machines (because their solution is built atop of “serverless” containers), organizations should move up the stack and focus on building the unique value that makes their business tick.</p><p>However, the promises of the Cloud carry challenges in complexity as usage scales upward. Organizations may find:</p><ul><li>Teams build “their own way of doing things”. The more teams in an organization, the more “bespoke” platforms crop up, which impedes knowledge sharing from one team to the next and limits engineers’ lateral mobility within an organization.</li><li>It’s hard to know whether their infrastructure is <i>really </i>up and running or whether it’s actually on fire. How can they be certain their infrastructure hasn’t drifted from their desired state?</li><li>There may be a temptation to burn it all down and start over – building a platform from scratch <i>again</i>, until the cycle repeats itself down the road.</li></ul><p>To be a bit tongue in cheek, whereas organizations were promised the rich benefits of The Cloud, they may find it takes an overwhelming amount of work to keep their bet on the Cloud from descending into the state depicted below:</p>

<h2>You need a control plane</h2><p>Control planes are a key ingredient to combatting what is described above. You need something that will:</p><ul><li>Configure</li><li>Control</li><li>Monitor</li><li>Reconcile changes</li><li>Be resilient</li><li>Offers a stable interface</li></ul><p>A control plane-based architecture gives you a declarative approach to defining and managing resources, continuous reconciliation of resources to eliminate configuration drift, and a pattern for achieving self-service.</p><p>The requirements list above may sound familiar because the industry recently similarly solved these challenges for container orchestration by consolidating around <a href="https://kubernetes.io/" target="_blank">Kubernetes</a>. But set aside containers for a moment. Kubernetes fundamentally offers some capabilities that make it ripe for being a control plane <i>in general</i>: it offers a declarative model, is self healing, offers role-based access control, has a strong ecosystem, is extensible, and offers capabilities around secrets &amp; config management.</p><p><a href="https://crossplane.io/" target="_blank">Crossplane</a> is the open-source framework for building control planes, built on the foundations of Kubernetes and extending it to allow for orchestration of <i>anything</i>. Upbound built Crossplane and contributed back to the CNCF for this purpose: to help organizations build their platforms like the cloud vendors build theirs—with control planes. It encapsulates policies, permissions, and other guardrails behind a user-defined API line that enables users to self-service without needing to become an infrastructure expert, all while eliminating configuration drift.</p><h2>Getting started with Crossplane</h2><p>Crossplane extends a Kubernetes cluster, so it must be installed into one; it can be a local cluster (like <a href="https://kind.sigs.k8s.io/" target="_blank">kind</a>) or pick your favorite managed K8s offering. Once you have Crossplane installed, <i>Crossplane Providers </i>are the first building blocks you will come across; they are bundles for a cloud service and they are the glue that allows your Crossplane control plane to talk to its associated cloud service’s API. To find what providers are available in the community today, go to the <a href="https://marketplace.upbound.io/providers" target="_blank">Upbound Marketplace</a>, which is the discovery hub for Crossplane.</p>

<p>Suppose a user wanted their control plane to have the ability to provision a pre-configured EC2 instance along with a composite monitor in Datadog for that EC2 instance. To do this, their control plane needs to talk to AWS and Datadog, so it needs the respective Crossplane providers installed into their control plane.</p>

<p>If one were to peek under the covers of a Crossplane provider, they will find pairs of Kubernetes controllers and Crossplane “Managed Resources”—think of these as Crossplane representations of resources in an external system:</p>

<p>Going back to the AWS EC2 instance + Datadog monitor scenario above, the last key piece is that Crossplane would allow this user to expose this ability as its own API–callable, repeatable, stable, and well-defined. A single API call that:</p><ol><li>abstracts away the inner-working to go set up an appropriate EC2 instance (setting its size, storage backing, whether it has an enclave, etc) and Datadog monitor (trigger window, monitor thresholds, etc)</li><li>Stitches together these two services running in different cloud environments</li></ol><p>This powerful capability of Crossplane is called <a href="https://crossplane.io/docs/v1.9/concepts/terminology.html#composition" target="_blank">Compositions</a>, and it’s what is going to really unlock the Cloud Golden Age. Compositions are your custom API. Compositions sit on top of those Managed Resources and “compose” them into higher-level abstractions. Not only are Compositions functionally powerful, they naturally enforce a great software development practice of “separation of concerns”. That is, “Platform teams” can be responsible for the API (its definition and implementation) and consumer/app teams can self-service consume the API without needing to understand its inner workings.</p>

<p>In this model with Crossplane, organizations can get started building their own internal cloud platforms on top of the growing public cloud. This is Kubernetes, after all, so standardizing on Crossplane means organizations can converge on a single platform that is flexible enough to meet the varied needs of the teams that compose their organization.</p><p><i>Note: If these topics interest you &amp; you would like to help build upon them, </i><a href="https://grnh.se/54d95d844us" target="_blank">we are hiring for various roles regarding Kubernetes and more</a><i>.</i></p><h2>Welcome to the Golden Age (Thanks Crossplane!)</h2><p>Exciting times are ahead for the Crossplane community. If you are wondering where to get started, check out Upbound’s quickstart documentation. These quickstarts use <a href="https://www.upbound.io/products/universal-crossplane" target="_blank">Upbound’s Universal Crossplane</a> (<a href="https://docs.upbound.io/uxp/" target="_blank">UXP</a>), an open-source, downstream distro of Crossplane that is commercially supported by Upbound, and is focused on Crossplane <a href="https://marketplace.upbound.io/providers?tier=official" target="_blank">Official Providers</a>, also open-source and fully supported by Upbound:</p><ul><li><a href="https://marketplace.upbound.io/providers/upbound/provider-aws/latest/docs/quickstart" target="_blank"><u>AWS quickstart</u></a></li><li><a href="https://marketplace.upbound.io/providers/upbound/provider-azure/latest/docs/quickstart" target="_blank"><u>Azure quickstart</u></a></li><li><a href="https://marketplace.upbound.io/providers/upbound/provider-gcp/latest/docs/quickstart" target="_blank"><u>GCP quickstart</u></a></li></ul><p>If you want to spend more time learning about Crossplane, I have explained the rise to the Golden Age even further in my webinar,<a href="https://resources.upbound.io/webinars/kubernetes-powered-control-planes-with-universal-crossplane" target="_blank"> “Kubernetes Powered Control Planes With Universal Crossplane”</a>. It’s a great watch if you are looking to learn more about everything you’ve read today. You can also visit the Crossplane <a href="http://crossplane.slack.com/" target="_blank">slack community</a>.</p><p>If you are interested in leveraging the power of control planes and interested to learn more about what Upbound is doing in this space, try out Upbound for yourself. Enable SRE teams with a more efficient workflow and the building blocks of platform engineering by setting up your first cloud platform powered by Upbound’s managed control planes. &nbsp;<a href="https://upbound.io/register?ref=blog.upbound.io" target="_blank">Sign up for your 30 day free trial here</a>!</p>

Unlocking the Golden Age of Cloud Computing

<p>At <a href="https://akuity.io/" target="_blank">Akuity</a>, we are <a href="https://www.upbound.io/why-upbound/partners" target="_blank">collaborating with Upbound</a> to streamline our infrastructure using <a href="https://akuity.io/what-is-argo/" target="_blank">Argo CD</a> and <a href="https://www.crossplane.io/" target="_blank">Crossplane</a>. This blog post will explore how Argo CD users can implement Crossplane to manage infrastructure resources beyond Kubernetes to simplify infrastructure management and create a clear sense of the dependencies for an application.</p><h2>Introduction</h2><p>Argo CD is a prevalent tool for implementing GitOps, the practice of declaratively storing the desired state with immutable versions and using tooling to reconcile the live state, in Kubernetes. Argo CD enables GitOps by implementing the Application resource, which provides a declarative approach to managing config management tooling for Kubernetes resources (e.g., Helm, Kustomize) and a controller for handling the reconciliation loop for syncing the resources into the cluster (i.e., updating the live state to match the desired state).</p><p>A basic example of an Application looks like this:</p>

<p>This 'guestbook' Application will create a Deployment and a Service in Kubernetes based on the manifests in the `guestbook` folder of the `akuity/argo-cd-crossplane` repository.</p>

<p>What is not represented by the manifests in the repository is that the fictitious guestbook application relies on a bucket for storing images uploaded by guests. But since the bucket isn’t a Kubernetes resource, Argo CD can’t manage it without the help of another tool.</p><h2>Before a Universal Control Plane</h2><p>The existing process to create the storage bucket is to log in to the GCP console and create a new bucket, specifying its name, location, storage class, access controls, configure versioning, and the lifecycle rules. Once the bucket is created, you need to configure the application to use it.</p>

<p>This whole process is done once, with none of it represented declaratively. So the next time the application is deployed to a new environment, another bucket must be created manually. Hopefully, the same person is creating it, or the documentation is good. Otherwise, you will waste time figuring out what settings are needed for the bucket (probably by comparing it to the existing one).</p><p>The downside of this approach is that it requires the application developers to have direct access to GCP or rely on an operator to create it, and it’s a manual imperative process prone to human error. For example, the bucket access could be easily misconfigured, compromising the bucket's contents. Additionally, if the bucket configuration needs to be updated, the change must be made manually, potentially leading to inconsistencies between the desired and actual state.</p><h2>Introducing Crossplane</h2><p>Crossplane is an open-source Kubernetes-native framework for building cloud-native control planes using a consistent API without writing code. Crossplane facilitates creating resources on various providers, including GCP, AWS, and Azure, using configurations defined as Kubernetes resources, making it easier to manage infrastructure using familiar Kubernetes tooling.</p><p><a href="https://www.upbound.io/" target="_blank">Upbound</a> created Crossplane to democratize control plane technology for all and continues to drive it forward as maintainers and contributors. Upbound also offers <a href="https://www.upbound.io/product/upbound" target="_blank">commercial products</a> and <a href="https://www.upbound.io/product/universal-crossplane" target="_blank">support</a> for those organizations that want to take Crossplane even further.</p><h3>Using Crossplane to Manage the Storage Bucket</h3><p>To use Crossplane to manage the storage bucket, you must install <a href="https://marketplace.upbound.io/providers/upbound/provider-gcp/latest" target="_blank">the GCP provider</a> (`provider-gcp`), which requires authentication to a service account with permission to manage the resources on the provider. This can be done with a JSON key from a service account in GCP or using Workload Identity to authenticate based on a service account in Kubernetes.</p><p>Creating the Crossplane GCP provider in Kubernetes will also introduce all of the Custom Resource Definitions (CRDs) representing resources on GCP. Including one for managing storage buckets, `Bucket`. <a href="https://marketplace.upbound.io/providers/upbound/provider-gcp/latest/resources/storage.gcp.upbound.io/Bucket" target="_blank">The CRD</a> defines the structure of the resource and the parameters that can be configured, such as the bucket name, location, and access credentials.</p><p>A basic example looks like this:</p>

<h3>Adding the Storage Bucket to the Application</h3><p>To add the storage bucket to the Kubernetes resources managed by the Application, you need to add the `Bucket` manifest to the `guestbook` folder of the `akuity/argo-cd-crossplane` repository. Argo CD will then deploy the new `Bucket` custom resource (CR) alongside the existing Kubernetes resources, ensuring that the live state of the cluster matches the state described in the Git repository. Once Argo CD creates the CR in the cluster, Crossplane will use the provider to create the corresponding resource on GCP using all of the configurations from the `Bucket` CR.</p>

<p>This approach provides several benefits, including:</p><ul><li>creating visibility into how the bucket is configured,</li><li>reducing the likelihood of human error, and</li><li>making it easier to manage infrastructure alongside application resources using Kubernetes tooling.</li></ul><h2>Conclusion</h2><p>Using Argo CD and Crossplane together provides a powerful toolset for managing infrastructure and application dependencies in Kubernetes environments. Defining infrastructure as Kubernetes resources makes it easier to manage the entire stack using GitOps practices and Kubernetes tooling.</p><p>Resources that were once a distant and implied dependency of the application can now be managed declaratively alongside the Kubernetes-native resources. The complete configuration for the Bucket is transparent and easily reproducible. Creating a simple mechanism for deploying new instances of the application in any Kubernetes environment with Crossplane and Argo CD set up.</p>

Argo CD and Crossplane for Managing the Whole Application Stack

<h2>“Sumbry’s Philosophy on building a great engineering team.”</h2><p>“We’re hiring a team of rockstars!”</p><p>Every time I hear that quote, I cringe. Now while that phrase normally compares hiring at a startup to starting a band I’m going to adjust this analogy to a sports one, specifically American Football since I’m a huge College Football fan. Anytime I hear that a company wants to hire a team of rockstars, I immediately translate that to:</p><p>“We’re hiring a team of quarterbacks.”</p><p>… which sounds absolutely ludicrous! Let’s just look at what a typical football team, specifically its offense, actually looks like and all the different positions it entails:</p>

<p>These are highly specialized positions. You only have one quarterback on an offense and they are charged with controlling the ball and calling the plays. Guards protect the quarterback. If the quarterback decides to run the ball he will hand the ball off to a running back who is protected by tackles. If the quarterback decides to throw the ball he will pass it to a wide receiver. There are only eleven people on an offensive team. Each has distinct roles that allow them to develop and execute an effective strategy and score points against the opponent's defense.</p><p>Now imagine if you will, for one second, that the team consisted of all quarterbacks:</p>

<p>This would be an absolute unmitigated disaster. You’d have a team of folks where everyone was trying to call the shots, they’d all be fighting for control of the ball, no one would be available to run or catch the ball — and who the heck is going to defend you from the rather large individuals playing defense for the opposing team and barreling down towards you?</p><p>So the reality is that you’re not trying to hire rockstars but are building a team — a team with room for folks with different skills and experience that collaborate, develop, a strategy, and work together as a unit to execute and ultimately score points and win the game!</p><p>In the example above, and a failure mode that I’ve seen when you hire too many rockstars onto a team, is that it actually causes a lot of churn on the team. The team finds itself unable to make decisions, often finds the most senior folks jockeying for projects and positions, leaves no room for less experienced folks to take on tasks or find space to grow, and usually results in a bunch of unnecessary projects and an over-complicated solution to problems to satisfy the egos of all the rockstars — and all rockstars have Rock Star Sized Egos.</p><p>When I <a href="https://blog.upbound.io/__GHOST_URL__/why-i-joined-upbound/"><u>joined Upbound as the VP of Engineering</u></a>, developing a strategy and building out a great team were the first things I immediately set out to do. We had a wonderful team of people that helped get the company to where it was, but my focus was now on how to scale the engineering organization and do it in a thoughtful way. We have huge product ambitions, have a popular open source project and great technology and have many paying customers that want the best from us and need us to meet all of their needs while continuing to deliver value for the company.</p><p>So I set out with my own strategy for how I think about team building. I’m not trying to find a bunch of quarterbacks, but rather folks I think can fit in the various positions required on the team and how we can make that entire team an effective unit.</p>

<p>One of the things I really want to outline about this strategy is that a team should be able to operate on multiple fronts at once, and should usually be around seven to ten people. You can think of a team as having smaller sub-units, that are capable of driving projects on their own and are usually a triad or quad that maintains a healthy ratio of staff engineers to everyone else. &nbsp;This allows the team a bit of autonomy and flexibility to execute independently without having to always collaborate with everyone across the entire team directly all the time. It allows space for individuals on the triad opportunities and space to grow and execute technically, while not bogging down the entire team in all the minutiae.</p>

<p>So as I set out to execute against this strategy and start hiring, I wanted to make sure that I avoided the mistake that I see many new hiring managers make — trying to find a person that fits too specific requirements for the role. You really want to look for good people, and mold roles and opportunities around them. In reality, you’ll probably only get an exact match to what you’re looking for about 30% of the time. So you need to allow room for what I call growers and pivoters to round that out. &nbsp;</p><p>Growers are folks that tend to be earlier in their careers and are hungry and looking for opportunities to join a company and quickly iterate on their technical learnings while also getting the opportunity to grow in their careers.</p><p>Pivoters on the other hand tend to be more seasoned folks that may have been working in a related industry, usually have a solid background, and are looking to pivot their career towards yours. Pivoters tend to bring a unique perspective and viewpoint, so all teams should definitely have them.</p>

<p>This strategy does not build teams of quarterbacks, but recognizes that a high-functioning team is also a diverse team that includes folks with different levels of experience, different ambitions, different skillsets, specific roles for individuals with a certain amount of flexibility, and an operating model that allows growth and autonomy.</p><p>It’s how we’re doing things at <a href="https://www.upbound.io/about" target="_blank">Upbound</a>, and I’m proud of &nbsp;all the progress that we’ve made to date. We’ve got some awesome folks here.</p><p>&nbsp;</p><hr><p>&nbsp;</p><p>Upbound is the creator and maintainer of the popular open source project <a href="https://www.crossplane.io/" target="_blank">Crossplane</a>. We are democratizing the best kept secret in cloud computing — the control plane — giving platform engineers centralized control and developers the freedom of self service.</p><p>We have two offerings — <a href="https://www.upbound.io/product/universal-crossplane" target="_blank">Upbound Universal Crossplane (UXP)</a> and <a href="https://www.upbound.io/product/upbound" target="_blank">Upbound</a>.</p><p>UXP is Upbound’s downstream distribution of Crossplane, and Official Providers are production ready versions of Providers available exclusively to Upbound customers. Both are maintained, tested, and supported by Upbound on behalf of our customers, and are included with an Upbound subscription.</p><p>Upbound is a single, global platform to build, deploy, and operate your own internal developer platforms using managed control planes powered by Crossplane. Want to try Upbound for yourself? <a href="https://upbound.io/register?ref=blog.upbound.io" target="_blank">Sign up for your 30 day free trial here</a>!</p>

We’re Not Hiring A Bunch of Quarterbacks!

<p>Imagine if you could create, for people in your company, a platform that would provide them with the same experience they have when working with AWS, Google Cloud, Azure, or any other public cloud provider. Imagine if there would be a service for everything they do.</p><p>Do you need a database that works exactly as we expect it to work in this company with all the security, backup, compliance, and other policies we have?</p><p>Well...There is a service for that. Do you need to run a backend application in Kubernetes? There is a service for that as well. Do you need a Kubernetes cluster itself? There is yet another service for that.</p><p>All you have to do is define a simple manifest that contains only the things you care about and abstracts all the unavoidable complexity. From there on, all you have to do is submit that manifest, the desired state, to the control plane API and observe the actual state. Even better, you can forget about the API and just push it to Git.</p><p>Wouldn’t that be awesome?</p><p>Wouldn’t it be great if we could replicate the experience of using a public cloud provider but made specifically for our needs? Wouldn’t it be great if there were a clearly defined API and a clear separation between the tasks end-users need to perform and the tasks that are the responsibility of the platform itself?</p><h2>Crossplane: The Cloud Native Control Plane</h2><p>If that sounds like something you might need, Crossplane is the project that will get you there. It enables you with capabilities of creating control planes based on the same principles public cloud providers have. It democratizes technology that was previously reserved mostly for big cloud providers like AWS, Azure, and Google Cloud. It enables you to create internal developer platforms.</p><h2>Crossplane Implementation</h2><p>How can we get started with implementing it? You’ll need to understand these topics:</p><ol><li>Crossplane Providers</li><li>Managed resources</li><li>Composite Resource Definitions</li><li>Compositions</li><li>Configuration Packages</li><li>Composition Functions</li><li>And more…</li></ol><p>While these topics above may seem daunting, I’ve written it all out in my book, <a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane" target="_blank">Crossplane: The Cloud Native Control Plane</a>, in an incredibly hands-on way.</p><p>To make things easy, instead of providing step-by-step setup instructions for this, I created scripts that will do that for you. You can run them and follow the instructions they present through questions, or you can choose to inspect the scripts if you prefer setting up everything manually.</p><p>This is a book that reflects the way I learn. I learn by doing. I learn by having my hands on the keyboard at all times. I learn by making mistakes and fixing them. I learn by experimenting. That’s the approach I’ll take with this book. I’ll explain theory and concepts, and I’ll show diagrams, but only through hands-on exercises. I’ll explain what we did rather than do what I explained. You can grab <a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane" target="_blank">Crossplane: The Cloud Native Control Plane</a> for <a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane" target="_blank">free from Upbound</a>.</p>

Why Choose Crossplane?

<p>For many Crossplane users just beginning their journey, users must eventually venture off the beaten path of reference docs and Crossplane tutorials and begin crafting APIs of their own. Users may find themselves in situations where they try to submit a claim for a new, custom API they just defined to their control plane and find, “...wait, is the control plane doing <i>anything</i>?” Knowing how to debug issues with Crossplane is a crucial tool to have on your Crossplane journey. Here are three tips for Crossplane users who want to understand how to begin debugging their control planes.</p><h2>Anatomy of Crossplane resources</h2><p>It’s helpful to familiarize yourself with the moving parts that are involved in making your APIs work. If we assume users are creating claim objects as desired end state for consuming your control plane’s API, there are several objects that get created in response to the claim:</p><ul><li>Claims generate a <strong>Composite Resource (XR)</strong></li><li>The Composite Resource generates <i>at a minimum</i> either <strong>Managed Resources</strong> (one or more), <strong>nested Composite Resources</strong>, or a combination of <strong>both </strong>(both Managed Resources <i>and </i>nested Composite Resources</li><li>The Managed Resources are ultimately backed by <strong>Controllers </strong>provided by the Crossplane <strong>Provider </strong>they originate from, which must be correctly configured with a <strong>ProviderConfig </strong>object to talk to whichever external service’s API that you’re building on top of</li></ul><p>It’s worth highlighting that Composite Resources can themselves be composed of nested Composite Resources, which recurses the diagram until there are no more nested Composite Resources to unpack. Here is a diagram to illustrate:</p>

<p>Walking the tree of the diagram, we see that a Crossplane Claim generates a Composite Resource (XR). That Composite Resource will generate Managed Resources (minimum of one to many) OR it will generate nested Composite Resources OR it could do both. The faded boxes are meant to illustrate the optionality here–it ultimately depends on how a given Composite Resource is defined. When you finally unwind a Composite Resource to its foundations–that is, unwind it plus its nested XRs (if any) and you will eventually end up with only Managed Resources–each of the resulting Managed Resources are defined and implemented by a Crossplane Provider.</p><p>Having a grasp of this anatomy will pay dividends when it comes to debugging complex Crossplane resources (which Composite Resources are). For now, let’s stick to surface level troubleshooting and look at some tips for debugging simpler Crossplane resources–ProviderConfigs and Managed Resources.</p><h3>Tip #1: Verify you have a valid ProviderConfig</h3><p>The first problem area users might encounter when submitting a claim and finding that they do not deploy: make sure the ProviderConfig is correctly configured. If the ProviderConfig is misconfigured, the control plane will never be able to successfully call the external cloud service. Here are some ways ProviderConfigs can end up in a faulty state:</p><ul><li>If you are using a Service Account, it may have insufficient permissions.</li><li>The secret associated with the ProviderConfig has the wrong name or is in the wrong namespace</li><li>The secret may be misconfigured our formatted incorrectly</li></ul><p>In this blog post, I demonstrate debugging a ProviderConfig on a control plane that has <a href="https://marketplace.upbound.io/configurations/upbound/platform-ref-gcp/v0.3.0" target="_blank">platform-ref-gcp</a> installed on it. The first thing to note: Configurations and Providers can report a “healthy” and “installed” status of “true” even if the ProviderConfig is absent or misconfigured.</p>

<p>For now, the best approach to knowing whether or not you have your Provider configured correctly is to try creating a simple Managed Resource (MR) from that Provider and see if it succeeds. We’ll use Tips #2 and #3 to help us accomplish Tip #1.</p><h3>Tip #2: Use Kubernetes events to debug</h3><p>To demonstrate the first troubleshooting tip, I purposefully misconfigured my ProviderConfig and tried creating a GCP Bucket below. Notice in the screenshot below, my bucket does not show a “ready” status. Now I can demonstrate the second tip: when in doubt, grab the Kubernetes events for the Crossplane object you need to debug! I can use the following kubectl command to grab events associated with that bucket:</p><p><i>kubectl get events --field-selector involvedObject.name=upbound-bucket-9269b6d08</i></p>

<p>This command returns a helpful hint: it is reporting that my secret (which is referenced by my ProviderConfig) is not found. I am using UXP, Upbound’s distro of Crossplane, so I look for which secrets exist in the&nbsp;<i>upbound-system&nbsp;</i>namespace because Upbound’s documentation references this namespace in Get Started docs:</p>

<p>We have confirmed the secret exists.</p><h3>Tip #3: Use kubectl describe to see rendered configs</h3><p>The next thing to do is describe my ProviderConfig and see if that reveals anything. Here is another powerful troubleshooting tip: you can use “kubectl describe” on Crossplane objects to get events <i>and </i>a rendering of the submitted .yaml config. In the screenshot below, we use this command (and trim out the middle of the output for brevity):</p><p><i>kubectl describe ProviderConfig default</i></p>

<p>The culprit has been found: the ProviderConfig thinks the Secret exists in&nbsp;<i>crossplane-system</i>, but we know this is not the case (UXP is installed into&nbsp;<i>upbound-system</i>). We can fix this by updating our ProviderConfig. After doing that and getting the events of the Bucket now, we see this:</p>

<p>I purposefully misconfigured the private key for the Secret associated with my ProviderConfig. This error complains about an issue with the private key, which matches our expectation. If I fix the Secret associated with the ProviderConfig and check the status of the bucket afterwards, I will now see this:</p>

<p>Success! The resource is now showing a ready status and the event log shows the resource creation was requested successfully. If we wait a few seconds, the Bucket will be provisioned and will show up in the GCP console. This test using a simple MR revealed two separate errors, we successfully troubleshot them, and have now confirmed the Provider is correctly configured.</p><h2>Closing</h2><p>These three tips will set you down the path to troubleshooting Crossplane and squashing those pesky bugs. In a future post, we’ll explore how to use these same tips to debug more complex objects like Composite Resources. For &nbsp;now, check out the Crossplane troubleshooting resources on the <a href="https://docs.crossplane.io/v1.10/reference/troubleshoot/" target="_blank">Crossplane docs</a>. Stay tuned!</p><p>Cheers,<br>Craig D Wilhite</p>

Learning to Troubleshoot Crossplane

<p>Update: As of June 13, 2023, Upbound has updated its Official Providers with Provider Families. Go to the announcement to learn more:&nbsp;<a href="https://blog.upbound.io/new-provider-families"><u>https://blog.upbound.io/new-provider-families</u></a>.</p><p>&nbsp;</p><hr><p>&nbsp;</p><p>Upbound founded Crossplane to help you build cloud control planes. These control planes sit one level above the cloud providers and allow you to customize the APIs they expose according to the needs of your organization. Platform teams at leading enterprises are increasingly adopting Crossplane to offer their developers simpler, safer, self-service interfaces to the cloud.</p><p><a href="https://crossplane.io/" target="_blank">Crossplane is an open-source project</a> incubating with the Cloud Native Computing Foundation (CNCF). It’s built on Kubernetes, making it a great fit for organizations that have embraced cloud-native tools and practices.</p><p>Crossplane has the notion of providers that are the glue between Crossplane and external APIs, such as AWS and Azure. This glue takes a different shape for almost every resource in those APIs, so you need custom implementations in most integrations.</p><h2>Provider Coverage Problem</h2><p>A typical new Crossplane user starts their journey by installing Crossplane and playing with the provider they use at their company. After the initial prototyping step, folks go to the API reference of a given provider to see if it includes support for all the cloud resources they use. At this point, we see many users drop out because of the lack of coverage. Unfortunately, it’s usually zero or one — they don’t use Crossplane even if only 10% of the infrastructure of a given application is not covered because you don’t want to have two ways of orchestrating the cloud infrastructure. We call this the provider coverage problem, which is present in every infrastructure provisioning tool that has come so far, like Terraform, Ansible, etc.</p><p>The Crossplane community has been adding <a href="https://blog.upbound.io/scaling-kubernetes-to-thousands-of-crds">CustomResourceDefinitions (CRDs)</a> to cover the API surface, but the pace is unable to catch up with users who are blocked from getting into production with Crossplane due to the lack of coverage. To give you an idea, AWS has ~1000 resources and the classic AWS provider has yet to cover ~200 as of writing.</p><h2>Solution</h2><p>At Upbound, we have concluded that even though we are able to re-use many utilities across the providers, it won’t scale to implement support for every CRD one by one. We should stand on the shoulders of what has come before.</p><p>The first iteration of this conclusion was <a href="https://github.com/crossplane/terrajet" target="_blank">Terrajet</a> — a code generation framework for CRDs and a generic controller that runs Terraform under the hood. But Terraform doesn’t have all the metadata we need to satisfy the <a href="https://github.com/crossplane/crossplane/blob/master/design/one-pager-managed-resource-api-design.md" target="_blank">Crossplane Resource Model (XRM)</a> experience that we’re all used to. We came up with a configuration framework in Go that allowed providing additional metadata that can scale to many implementations.</p><p>In fact, we experimented with having just the default configs for all resources and it resulted in thousands of working CRDs which was a first in the Kubernetes community! This uncovered bugs in the Kubernetes API server that would appear only when you reach that scale. We worked closely with API Machinery team to provide patches to accommodate that scale. More on this <a href="https://blog.upbound.io/scaling-kubernetes-to-thousands-of-crds">here</a>.</p><p><a href="https://github.com/upbound/upjet" target="_blank">Upjet</a> is the second generation of this approach that is more stable, has more customization points, and includes new code generators that enable automatically generating API documentation and example YAMLs ready to be used as well as inferring metadata configurations from the Terraform documentation such as cross-resource references so that the providers get to be production-ready with much less effort and time. Provider maintainers can replace Terrajet with Upjet with minimal code changes to utilize these new features. Our first set of Upbound Official Providers — AWS, Azure, and GCP — that Upbound uses to meet SLAs to its customers are all built on Upjet, contributing to its stability.</p><h2>Introducing Official Providers</h2><p>Official Providers are production-ready Crossplane providers that are authored or maintained by Upbound. As a vendor, Upbound can provide support and SLAs around using Official Providers, giving customers peace of mind. They have the highest number of CRDs at the v1beta1 quality level and are tested continuously using real cloud provider endpoints. The first set contains the big three cloud providers (AWS, Azure, and GCP), and we are continuously expanding the program to cover more APIs and infrastructure providers.</p><h3>Coverage</h3><p>As of writing, Official Providers have the highest coverage of the big three Cloud APIs in the Crossplane ecosystem.</p>

<p>With these ever-growing numbers, you can use these Official Providers to orchestrate your most complex scenarios. In addition to production-level quality, the Upjet-based providers have extended coverage of given APIs, i.e. more fields and features are supported in the CRDs compared to other providers. This is achieved by relying on mature Terraform providers under the hood that have already implemented most, if not all, &nbsp;features of a given API.</p><h3>Quality</h3><p>Great power comes with great responsibility. With so many APIs to deal with, it’s essential that we keep the complexity under control and don’t introduce regressions. To do this at scale, we have developed a new tool called <a href="https://github.com/upbound/uptest" target="_blank">Uptest</a> that deploys the resource into a cluster, makes sure it gets to a ready state, and that the removal succeeds. Over time, we will add more scenarios to build even higher confidence levels.</p><p>With Uptest in place, all official provider CRDs are at <a href="https://kubernetes.io/docs/reference/using-api/#api-versioning" target="_blank">v1beta1 maturity</a> — meaning they are safe to use in production, and we guarantee that even if there is a breaking change, it will be handled automatically by a standard Kubernetes webhook.</p><p>One of the concerns we had with Terrajet was the cases where the underlying Terraform provider may not provide a high-quality implementation for a given resource and we may end up stuck with it till the upstream fix is accepted. In Official Providers, we can add custom implementations, in addition to generated ones, whenever the need arises. <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/latest/resources/eks.aws.upbound.io/ClusterAuth/v1beta1" target="_blank">ClusterAuth</a> in AWS EKS is a good example where we added a <a href="https://github.com/upbound/provider-aws/blob/75f320d/internal/controller/eks/clusterauth/controller.go#L145" target="_blank">manual implementation</a> to cover the authentication story of AWS EKS in a way that provides ever-refreshing tokens through its connection details secret.</p><h3>Improved User Experience</h3><p>We want to provide the best experience for users getting started with Official Providers. A big step towards this goal is having examples for every resource. You will see that every CRD in our Official Providers has at least one example, and Uptest tests all examples you see continuously to make sure they are always up-to-date. See AWS VPC <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/v0.18.0/resources/ec2.aws.upbound.io/VPC/v1beta1" target="_blank">here</a> with 19 examples!</p><p>In addition to examples, official providers have a high bar that all fields in the API reference of a given CRD should have as much documentation as possible. To see the rich experience, see AWS EKS Cluster API Reference <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/latest/resources/eks.aws.upbound.io/Cluster/v1beta1" target="_blank">here</a>. With Upjet, this is automated, and future Official Providers will have this as well.</p><h3>Peace of Mind</h3><p>At Upbound, we talked with many customers and uncovered that while having a community around providers is great, many companies want formal support from a vendor. With Official Providers, Upbound supports its customers with timely fixes and provides patch releases immediately! All fixes we will be doing for our customers will land on the same repository.</p><h2>What’s Next</h2><p>Official Providers are released under the Apache 2.0 license, just like Crossplane. We encourage everyone to play around with them, ask questions in <a href="https://slack.crossplane.io/" target="_blank">Slack</a>, and feel free to contribute. We were delighted to see <a href="https://github.com/upbound/upjet/pull/112" target="_blank">a community contribution</a> even on the launch day!</p><p>We have a <a href="https://github.com/upbound/upjet/blob/f6b62b4/docs/manual-migration-guide-to-op.md" target="_blank">comprehensive guide</a> that will help you migrate your existing resources to official providers. In addition, we are working on a new tool that will create a migration plan, let you edit specifics when necessary and execute it; making it a breeze to migrate to official providers!</p><p>Keep an eye out for the next release since <a href="https://marketplace.upbound.io/" target="_blank">Official Providers are released every week</a>! In the coming weeks, we’ll see more CustomResourceDefinitions added, and you can expect them to reach full coverage soon, all the while providing the same high-quality level. In addition to increasing the coverage, we are getting close to the first Crossplane providers with “v1” CRDs!</p><p><i>Note: If you're interested in working on these with us, </i><a href="https://www.upbound.io/careers/working-with-us" target="_blank">view our open roles here<i>.</i></a></p>

The First Official Providers

<p>Crossplane was one of the most discussed topics of <a href="https://www.cncf.io/kubecon-cloudnativecon-events/?utm_content=inline-mention" target="_blank">KubeCon + CloudNativeCon North America</a> 2022. It was mentioned in keynotes and talks, and the surrounding chatter was all over the show floor. &nbsp;Crossplane is being deployed in production across Global 2000 organizations, and at KubeCon companies like Grupo Boticário, Adobe, and Autodesk shared how they are adopting Crossplane.</p><p>For those who might not be familiar, <a href="https://crossplane.io/" target="_blank">Crossplane</a> is a framework to build internal cloud platforms using <a href="https://thenewstack.io/gitlab-deploys-the-crossplane-control-plane-to-offer-multicloud-deployments/" target="_blank">control planes</a>.</p><h2>Control Plane-Powered Platforms</h2><p>You may be asking, “Why should I use control planes?” Let’s start with the big picture. Every bigger company has some kind of internal “cloud, DevOps, platform” organization. Let’s call them the “platform team.” They manage the operations and consumption of public clouds and internal services. After the first wave of automation with Infrastructure as Code (IaC) tools, these platform teams have realized that a pure IaC approach is not sufficient, as they often fail to address two fundamental problems:</p><ul><li>How do we govern infrastructure and services in a central place to ensure they are used efficiently and in compliance with our security and other standards?</li><li>How do we unblock development teams and enable self-service that doesn’t require deep Infrastructure as Code knowledge?</li></ul><p>Various approaches have attempted to tackle these objectives and promised self-service with a single pane of glass at reduced costs. But all the offerings have trade-offs: They lock platform teams into a particular technology or infrastructure vendor, and they are too opinionated about the layer of abstraction provided.</p>

<p>The missing ingredient here is a control plane. A control-plane-based architecture gives you a declarative approach to defining and managing resources, a continuous reconciliation to eliminate configuration drift and offer a single point of control for concerns like policy enforcement and permission management.</p><p>Which brings us back to Crossplane, an <a href="https://thenewstack.io/crossplane-a-kubernetes-control-plane-to-roll-your-own-paas/" target="_blank">open source framework</a> that runs on top of Kubernetes to build platforms using a control-plane-based architecture. Let’s see how that is actually done.</p><h2>Building a Platform with Crossplane</h2><p>Building and using a Crossplane-based platform involves three major steps: <strong>Connect</strong> to the resources you want to manage, <strong>Compose</strong> the different resources into a custom API for your team, and finally <strong>Consume</strong> those resources by developers:</p>

Why Upbound

Upbound Elevates Platforming with Crossplane Through New Builder Tooling and Platform Services

Upbound

Start for Free

Pricing

17 Added benefits of Upbound over OSS Crossplane

Using Upbound to Roll Out Cluster-as-a-Service to Your Developers

Resources

Events

Docs

Blog

Contact Support

Report a Vulnerability

Streamlining Platform Building with Crossplane: Working with with Upbound's New Platform Engineering Tools

Open Source Crossplane or Upbound? 17 Added Benefits of Using Upbound

Featured

Upbound Elevates Platforming with Crossplane Through New Builder Tooling and New Core Platform Services

Now Upbound Official Packages Meet The Most Demanding Enterprise Requirements

Popular topics:

Filter by year:

Subscribe to our Newsletter

Press Releases

Upbound Launches Spaces, Bringing the Power of Managed Control Planes to Fully Self-Hosted Environments

Upbound’s Platform for Platform Teams Now Available in AWS Marketplace

Upbound Contributes Control Plane Provider Technology to the Crossplane Project, Governed by the Cloud Native Computing Foundation