<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

<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

<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

<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>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>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

<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>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

<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>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>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

<p>Platform Engineering is the “new hotness.” It’s what your engineers use to build, deploy, and operate their services in production. Companies everywhere realize the value of having Internal Platforms and restructuring Infrastructure Teams into Platform Teams with the mandate to standardize and consolidate their software development lifecycle around a consistent set of services, tooling, and processes.</p><p>While the value of an Internal Platform driven by Platform Teams is ever-so-clear, best practices around how to structure a team to execute against this vision are fuzzier. Most Platform Teams have a standard set of antipatterns that slow them down and prevent them from fully achieving the Platform Dream. So here is my Top Ten List of the things that are slowing down your Platform Team and how to fix them:</p><ol><li>Not being staffed appropriately</li><li>Having to support the most critical parts of the company</li><li>Maintaining too high a percentage of toil</li><li>Doing too much context-switching</li><li>Needing to support Shadow Infrastructure</li><li>Underestimating the time to support new technology</li><li>Constantly having to support or defend migrations</li><li>Suffering from the effects of&nbsp;<a href="https://en.wikipedia.org/wiki/Conway%27s_law"><u>Conway’s Law</u></a></li><li>Constantly taking on cost-related work with no clear customer value</li><li>No consistency in how to build and operate a platform</li></ol><p>If you want a high-performing Platform Team, you must be honest about the above pitfalls. They’re anti-patterns and will slow your Platform Team down. I’d argue that 50% of the work involved in building a platform is the same across most companies. So, focus your Platform Team on providing differentiated value for the business.</p><p>Now, how to avoid these traps?</p><h2>Not being staffed appropriately</h2><p>One of companies' biggest mistakes is not adequately staffing a platform team. Most platform teams are under-resourced and don’t have critical mass in team or organization size to meet the needs of a never-decreasing product backlog. Investing in your platform has a compounding return in terms of efficiency for your engineers. By providing consistency and giving engineers a golden path to build, deploy, and operate their software in production, you remove some of the massive amounts of context required to be productive. You allow them to iterate more quickly on features needed to operate and grow the business reliably.</p><p>A healthy ratio of engineers working on customer-facing features to engineers on technology consumed by other engineers should be 1:1. For every 50 folks working on product features, 50 folks should also work on teams that empower those engineers. This can be internal platform teams, infrastructure teams, reliability teams, quality teams, and more.</p><p>One thing that is also a challenge for platform teams is&nbsp;<a href="https://blog.upbound.io/__GHOST_URL__/not-hiring-a-bunch-of-quarterbacks/"><u>ensuring that you have the right skills</u></a>. You must ensure the appropriate mix of software and {system, infrastructure, reliability, quality, security, networking, etc.} engineering skill sets across the team.</p><h2>Having to support the most critical parts of the company</h2><p>Every time I hear about a global outage at a company, I immediately think one of three things happened:</p><ul style="list-style-type:disc;"><li>Their global service discovery system failed</li><li>Some type of internal or external network routing issue</li><li>Someone shipped a change to&nbsp;<a href="https://resources.upbound.io/all-content/whats-a-platform-its-that-thing-youre-speeding-on"><u>The Monolith and it died</u></a></li></ul><p>We keep preaching the wonders of microservices and distributed systems. Still, these critical core components exist in most organizations and are always directly supported by the platform or infrastructure team. This work has no glory, but there is all hell to pay when an outage occurs. From a staffing perspective, there is also not much investment in these areas and generally not much time allocated to improving these systems. It'd be a no-brainer if you had more resources, but as the previous item suggests, you’re always resource constrained.</p><h2>Maintaining too high a percentage of toil</h2><p>The&nbsp;<a href="https://sre.google/sre-book/table-of-contents/"><u>Google SRE Book</u></a>&nbsp;gave us this fantastic description of toil: work that is tactical and doesn’t provide strategic value, work that is repeatable and done more than once, work that can be automated if taken the time, and work that is accomplished by hand and manual. &nbsp;</p><p>While Platform Teams can only partially eliminate this type of work, automating these processes is similar to spending time on paying down technical debt—it is a form of debt. You can manage it for a while until it eventually snowballs and consumes you in the form of …</p><h2>Doing too much context-switching</h2><p>This happens when your platform team is under-resourced, has to support too many critical components in the company, and thus doesn’t have time to automate processes and reduce their toil. Your platform engineers spend all their time jumping from one task to the next and doing 50 tasks in a day. These tasks are usually never related to each other, span many different contexts and domains, and incur a cost every time a human has to unload the context from the previous task and load the context of the new task.</p><h2>Needing to support Shadow Infrastructure</h2><p>Shadow Infrastructure happens when your Platform Team takes on too much work and is incapable of meeting the needs of their customers, aka the company’s engineers. Shadow Infrastructure includes work like deploying new infrastructure or technology in the organization in a way that multiple teams and other engineers can easily consume. Platform teams tend to have a global view of the world and like to provide global solutions, but feature teams, and rightly so, need to prioritize getting value into the business's customers.</p><p>They will solve this problem independently and implement new infrastructure or technology in a locally optimized way that works for the individual or team but may not be easily consumable by others. And because the priority is shipping features for the organization, a long-term feature development team has no interest in supporting and operating an underlying technology. Ultimately, ownership gets shifted over to the platform team.</p><p>Wonder why Platform teams are constantly context-switching and unable to reduce the amount of toil while supporting the most critical parts of the business? It is because the amount of things they support is constantly growing, and Shadow Infrastructure can be one of the significant, silent contributors.</p><h2>Underestimating the time to support new technology</h2><p>While the previous five items listed were a direct result of the interactions between a platform team and its customers, these next five are things that a platform team does directly to itself. &nbsp;It starts with underestimating how much time it will take to support new technology.</p><p>Engineers love to build things and learn new technologies. That isn’t always the best thing for the business and often downplays how much effort and time creating something new takes practice. Hint: It is measured in years, not months.</p><p>Engineers often need to pay more attention to how long it will take to build, operate and adopt a new service or technology in production. Ultimately this is the classic&nbsp;<a href="https://resources.upbound.io/webinars/control-planes-the-missing-ingredient-for-cloud-native-developer-platforms"><u>build versus buy</u></a>&nbsp;argument. In either case, platform teams always need to pay more attention to the time it will take to support anything, whether it was built internally or bought and integrated. &nbsp;</p><p>Building is always more expensive than buying, so platform teams need to be honest about only building where necessary and where it provides differentiated value for their internal customers and the business. It may cost more, but it is easier to buy in most situations and offload some of that support directly onto a vendor. Engineers are not cheap from a cost and time/onboarding perspective, and you’re generally better off buying and offloading some of that support to a vendor; it is always almost cheaper in the long run.</p><h2>Constantly having to support or defend migrations</h2><p>Platforms naturally evolve, and as new technology and patterns emerge (like Kubernetes), you want your platform to take advantage of these improvements. What you don’t want to do is force your customers as a platform team to do a significant amount of new work to adopt this next iteration of your platform. This often shows up in the form of migrations:</p><ul><li>Migrating from virtual machines to containers</li><li>Migrating from one cloud provider to another</li><li>Migrating from one backend service or API to another incompatible one</li></ul><p>These are all variations of the same thing and force work on your engineers. This is another area where platform teams need to consider the support burden. You want to make it easier for your engineers to adopt new technology and do the heavy lifting for them, otherwise, they and you are running in place. Work that may provide a benefit in the future but doesn’t help solve problems today.</p><p>Platform teams should limit these forced migrations as much as possible and offload as much work as possible from their engineers. This means being honest upfront about the resources and time it will take to implement, and not having too many things on the truck simultaneously.</p><p>This is also a side-effect of platform teams not engaging enough with their customers, building without understanding their needs, and creating the right abstractions, APIs, and contracts up-front. A migration should be a seamless process.</p><h2>Suffering from the effects of Conway’s Law</h2><p>Platform teams or organizations are usually a combination of infrastructure (compute, storage, networking), managed services (database, streaming, object store), other platforms (machine learning platform, application service platform), and more. Conway’s law states that companies tend to organize their internal systems or products around internal teams or communication structures.</p><p>An anti-pattern exposes your platform in a way that mirrors your organizational structure. If you have a compute team, then you have a computing platform. If you have a network or database team, you have a networking or database platform. The problem is that your engineers don’t care how you’re organized. They will usually view your platform as a singular distinct entity. It is the single thing they use to build, deploy, and operate their services. &nbsp;</p><p>When designing your platform, you should always start with the end-user perspective and abstract the underlying complexities from them—it is optional for them to know and ultimately be leaky.</p><h2>Constantly taking on cost-related work with no clear customer value</h2><p>The above statement is not necessarily fair. Whenever a platform team takes on cost-optimization work, it is usually for the Finance Organization and usually in the form of calling out the cloud spend for being too high, heh! That said, platform teams generally take on the burden of optimizing infrastructure costs and spending, and there is no direct benefit to their engineers. An engineer does not necessarily care that the platform is cheap, only that it is reliable, fast, and does what it does.</p><p>This means that factoring in costs upfront when building out your platform, not just from a vendor perspective but also from a people perspective, is extremely important. You don’t want to think about this after the fact because it can be pretty expensive and time-consuming to make decisions around optimizing your platform after it already has significant usage. This also contributes to being unable to reduce toil, doing too much context-switching, and being under-resourced.</p><h2>No consistency in how to build and operate a platform</h2><p>This is where standardizing on an open-source technology can fit in. You wouldn’t try to create your own web server or database server today unless you had a highly specialized need, but everyone tries to build their own platform! It’s exceptionally wasteful when the foundational layers of a platform are essentially the same across companies.</p><p>Crossplane is one example of such a technology. It’s not just a control plane framework but provides the building blocks you need to provide the basic foundational layer of your platform. It includes a cloud abstraction layer via its provider ecosystem, allowing you to consistently talk to anything with a public API. It also gives you the ability of composability. It enables you to define complex relationships of underlying cloud providers, managed services, and resources, and provide your engineers with a simpler abstraction or API. Combine this with a configuration format that can quickly be packaged and shared with others, and you have the basic building blocks for any platform!&nbsp;<a href="https://blog.upbound.io/__GHOST_URL__/crossplane-first-look/"><u>Learn Crossplane once and use it anywhere.</u></a></p><p>Now that is progress.</p><p>You’ve learned about what’s slowing down your Platform Team—from team misalignments, to managing toil, to managing bespoke layers of your own platform. And now you have an idea of how to fix them–invest in your team and in your foundational tooling. 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"><u>Sign up for your 30 day free trial here</u></a>!</p>

<h4>A little bit about me:</h4><p>I am the Head of Engineering here at&nbsp;<a href="http://upbound.io/"><u>Upbound</u></a>, the company behind the open-source project <a href="http://crossplane.io/"><u>Crossplane</u></a>. I have over two decades of experience working in the platform, infrastructure, and reliability engineering space at companies like AirBnB, Uber, and Twilio but have a non-traditional background. I started my career as a software engineer. I have taken on a variety of roles over the years from founder to network engineer, software engineer, platform engineer, system engineer, reliability engineer, engineering manager, engineering leader, and more. I started my early career in several startups as the Internet grew in popularity and quickly learned how to build and scale infrastructure, striving to strike the right balance between solving the right technical challenges while ensuring the business continued to grow. I eventually started several companies because I thought I had some excellent ideas but wanted to learn more about problem-solving from a product and customer perspective. Some great (and expensive) lessons learned are a big reason why I am heavily customer-focused today. I always have my customer hat on, whether one of business or engineering.</p><p>— Sumbry</p>

Top Ten Things Slowing Down Your Platform Team

<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>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>With <a href="https://marketplace.upbound.io/providers/upbound/provider-terraform/v0.3.0" target="_blank">provider-terraform</a> we have a new Crossplane provider that runs Terraform configurations and enables platform teams to include custom Terraform code within a Crossplane powered architecture. This provider enables many integration scenarios and allows teams who have invested in Terraform to leverage a powerful control plane architecture. Please read <a href="https://blog.upbound.io/official-provider-terraform-launch/">the announcement</a> for more information. Furthermore, if you haven’t consider watching the webinar: <a href="https://resources.upbound.io/webinars/kubernetes-called-and-it-wants-your-iac-back-using-control-planes-to-modernize-your-iac-tech-stack" target="_blank">Kubernetes Called and it Wants Your IaC Back: Using Control Planes to Modernize Your IaC Tech Stack</a>.</p><p>In this blog post, we would like to explore a phased approach on how to include existing Terraform code and start migrating towards a Crossplane native solution.</p><p><strong>Example: Let developers create their own subnet</strong></p><p>Let’s say we are a platform team and are tasked to create AWS Subnets for developers. We have already spent a significant amount of time into a Terraform module, and we want to re-use that code, so developers can self-serve subnets for their application. Let’s see on how can use Crossplane to do so and port our custom code to Crossplane and possibly migrate fully to Crossplane if we'd like to.</p><h2>Overview</h2><p>We will do this in four steps:</p><ol><li>Create a common interface for developers to use</li><li>Run the full module in provider-terraform</li><li>Extract one resource (subnet) into the native AWS provider</li><li>Move the second resource into the native AWS provider</li></ol><p>The beauty of this approach is that we have a running platform after step one and can test our platform and do the subsequent steps 3 and 4 when the time is right.</p>

<p>The following steps will contain short abbreviated code examples. See the <a href="https://github.com/upbound/provider-terraform/tree/main/examples/transition" target="_blank">upbound/provider-terraform repository</a> for the complete example.</p><h3>1. Create a common interface for developers to use</h3><p>With Crossplane, a platform team offers their users a way to create a subnet by simply creating a specific Kubernetes resource. e.g. something like:</p>

<p>In order for this to materialize, we first need to create a Composite Resource Definition (or short XRD). This is Kubernetes resources that Crossplane understands. See&nbsp;<a href="https://docs.crossplane.io/v1.10/concepts/composition/"><u>Composite Resources · Docs</u></a>&nbsp;for more information. The XRD contains a spec where we can describe the interface for the developer. In this case, we want to make it easy for the developer and make him only specify the vpcName.</p>

<p>(Abbreviated. See <a href="https://github.com/upbound/provider-terraform/blob/main/examples/transition/definition.yaml" target="_blank">definition.yaml</a> for the complete version.)</p><h3>2. Run the full module in provider-terraform</h3><p>After we have created the interface, we need to create an implementation, which is called a Composition in Crossplane. In this step, we want to run the full Terraform module in this composition by using provider-terraform. As you might guess, we are creating another Kubernetes resource with the type Composition. We start by just specifying one Crossplane resource by the kind Workspace which includes the Terraform code and a patches to convert the necessary information to Kubernetes. In this example, we have in-lined all the Terraform code, but we can also specify remote resources (see <a href="https://github.com/upbound/provider-terraform/blob/main/examples/workspace-remote.yaml#L19" target="_blank">examples/workspace-remote.yaml</a> for an example.)</p>

<p><i>(Abbreviated. See&nbsp;</i><a href="https://github.com/upbound/provider-terraform/blob/main/examples/transition/01-composition-tf-only/composition.yaml"><i><u>01-composition-tf-only/composition.yaml</u></i></a><i>&nbsp;for the complete version.)</i></p><p>🎉 Success! We now have a fully running control plane with our custom Terraform logic. You can start testing it with your team.</p><h3>3. Extract one resource into the native provider</h3><p>To fully transition to Crossplane, we now want to refactor the Subnet resource to use <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/v0.26.0" target="_blank">provider-aws</a>. For this, we adapt our composition to now have two resources of kind Workspace and Subnet and use patching to combine these two.</p>

<p><i>(Abbreviated. See </i><a href="https://github.com/upbound/provider-terraform/blob/main/examples/transition/02-composition-tf-and-native/composition.yaml" target="_blank"><i>02-tf-and-native/composition.yaml</i></a><i> for the complete version.)</i></p><p>You can see on how this enables us to transition to Crossplane native providers gradually. And depending on the complexity of the resources you have been developing, you can repeat this step.</p><h3>4. Move the second resource into the native provider</h3><p>In our last step, we want to remove provider-terraform from our composition and fully use the native aws provider. The outcome is for folks familiar with Crossplane straightforward. One composition that contains the two resource VPC and Subnet:</p>

<p><i>(Abbreviated. See </i><a href="https://github.com/upbound/provider-terraform/blob/main/examples/transition/03-composition-native-only/composition.yaml" target="_blank"><i>03-native-only/composition.yaml</i></a><i> for the complete version.)</i></p><h2><strong>Summary</strong></h2><p>Crossplane is a great way to build a developer platform powered by Kubernetes. Terraform has a great ecosystem and existing investments from platform teams. With provider-terraform we can combine both ecosystems and enable integration scenarios. This blogpost showed a quick get started guide on how to take a step-by-step guide behind a stable developer facing API. If you want to learn more and see the above in action, please check out the <a href="https://docs.upbound.io/providers/provider-terraform/migrate-provider-tf/" target="_blank">migration guides.</a></p>

Migrating to Crossplane With Provider-Terraform

<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>Today we are very excited to announce a new open source project, provider-ansible, a Crossplane provider designed to extend the Crossplane scope by enabling its integration with Ansible.</p><h2>Why Ansible Crossplane Provider</h2><p>Ansible is a popular automation technology. It is widely adopted by many IT organizations nowadays to automate management for their IT systems, ranging from non cloud native to cloud native. It has a very mature community and an ecosystem with many existing automation assets that are publicly available at <a href="https://galaxy.ansible.com/" target="_blank">https://galaxy.ansible.com/</a>. In the meantime, many IT organizations have their own private Ansible assets accumulated for years to address their specific IT management requirements.</p><p>On the other hand, Crossplane, as a cloud native control plane framework, has evolved rapidly in recent years and now has become a very active CNCF project. It allows people to drive IT automation in a cloud native manner and orchestrate management automation for different varieties of IT resources using its powerful composition engine. All these can happen inside a Kubernetes cluster.</p><p>To combine the two powerful tools together and unleash the synergy, we have built a Crossplane provider for Ansible. It works as a bridge that can connect the two communities.</p><p>If you are familiar with Ansible and want to get benefits from what Crossplane provides, the Crossplane provider for Ansible is definitely a good option for you! For example, you can use this provider to drive Ansible automation inside a Kubernetes cluster rather than from the command line. By doing so, your Ansible automation can work with some modern IT operation methodology such as GitOps seamlessly. You can also use this provider to orchestrate multiple resource management automation approaches including Ansible using Crossplane’s composition mechanism. This will allow you to mix the use of many great automation assets from both two communities consistently.</p><p>This provider also opens a door to IT organizations who may have already invested lots of money on their IT systems management automation by using Ansible, including those traditional systems that do not behave cloud-natively, and want to adopt Crossplane without losing their investments. They can now reuse their existing automation assets without reinventing the wheels, specifically in some case when there’s no easy replacement for their traditional automation assets in Crossplane community in cloud native world. For example, to provision a VM in a LAN and install something on that is easy to be done by Ansible, but in Crossplane, it may need to introduce a new provider which is not necessary especially when people have some Ansible assets in place already.</p><p>In the next few sections, you will learn how the Crossplane provider for Ansible works at an architectural level in order to enable the above use cases. You will also learn how to drive Ansible execution using this provider by going through a couple of concrete examples step by step. Keep reading!</p><h2>Understanding How It Works</h2><p>The Ansible provider execution is driven by the Crossplane ecosystem.</p>

<p>In Fig.1, we see the high level architecture for the Ansible provider: it uses Kubernetes resource <i>AnsibleRun</i> to leverage Ansible content, e.g.: Playbook, Role, etc., to do the actual work. The <i>AnsibleRun</i> resource refers to the <i>ProviderConfig</i> resource which includes the required information for the proper functioning of our Ansible provider, e.g.: credentials, requirements, behavior variables, etc.</p><p>Within the Crossplane reconciliation process, the Ansible provider relies on standard Ansible binaries to execute the job: it uses the <i>ansible-galaxy </i>cli to download Ansible contents specified in the <i>AnsibleRun</i> resource using credentials from <i>ProviderConfig</i> resource, then depending on different run policy specified, it will invoke <i>ansible-runner</i> cli to execute them at different time.</p><h2>The Hello World Example</h2><p>In this section, let’s start with a very simple example to explore the basic use of Ansible provider. Our first example is the hello world Ansible playbook which will print a “Hello world!” message to the console.</p><p>To demonstrate the use of Ansible provider, let’s start a KIND cluster at first. KIND is a local Kubernetes cluster using Docker container “nodes”. To start the cluster, you need KIND CLI. For more information on KIND, please refer to <a href="https://kind.sigs.k8s.io/" target="_blank">https://kind.sigs.k8s.io/</a>.</p><p>Run below command to start the cluster:</p>

<p>Then, install Crossplane into the cluster:</p>

<p>And the Crossplane CLI, which is essentially a kubectl plugin that extends kubectl with functionality to build, push, and install Crossplane packages:</p>

<p>Then, run below command to install the Ansible provider:</p>

<p>After the provider is installed, you can run below command to verify if the installation is successful:</p>

<p>If everything works fine, you should see that both the column INSTALLED and HEALTHY for the&nbsp;<i>Provider</i>&nbsp;resource are True. For example:</p>

<div class="raw-html-embed"><table style="border:none;border-collapse:collapse;"><colgroup><col width="1578"></colgroup><tbody><tr style="height:0pt"><td style="border-left:solid #000000 1pt;border-right:solid #000000 1pt;border-bottom:solid #000000 1pt;border-top:solid #000000 1pt;vertical-align:top;padding:5pt 5pt 5pt 5pt;overflow:hidden;overflow-wrap:break-word;"><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">NAME &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; HEALTHY &nbsp; REVISION &nbsp; IMAGE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; STATE&nbsp; &nbsp; DEP-FOUND &nbsp; DEP-INSTALLED &nbsp; AGE</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">providerrevision.pkg.crossplane.io/crossplanecontrib-provider-ansible-6fb5112f17a6 &nbsp; True&nbsp; &nbsp; &nbsp; 1&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; crossplanecontrib/provider-ansible:v0.3.0 &nbsp; Active &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 33m</span></p><br><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">NAME&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; INSTALLED &nbsp; HEALTHY &nbsp; PACKAGE &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AGE</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">provider.pkg.crossplane.io/crossplanecontrib-provider-ansible &nbsp; True&nbsp; &nbsp; &nbsp; &nbsp; True&nbsp; &nbsp; &nbsp; crossplanecontrib/provider-ansible:v0.3.0 &nbsp; 33m</span></p><br><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">NAME&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; AGE &nbsp; TYPE &nbsp; &nbsp; &nbsp; &nbsp; DEFAULT-SCOPE</span></p><p dir="ltr" style="line-height:1.2;margin-top:0pt;margin-bottom:0pt;"><span style="font-size:10pt;font-family:'Courier New';color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;">storeconfig.secrets.crossplane.io/default &nbsp; 48d &nbsp; Kubernetes &nbsp; crossplane-system</span></p></td></tr></tbody></table></div>

<p>After then, apply the following YAML manifests which include a&nbsp;<i>ProviderConfig</i>&nbsp;and an&nbsp;<i>AnsibleRun</i>:</p>

<p>In this example, we do not really need any real credential to access a remote repository that hosts Ansible roles or playbooks, so the&nbsp;<i>spec.credentials</i>&nbsp;field in&nbsp;<i>ProviderConfig</i>&nbsp;is empty. For&nbsp;<i>AnsibleRun</i>, we define the hello world playbook as an inline playbook by&nbsp;<i>spec.forProvider.playbookInline</i>. After applying these YAML manifests, you will see something similar to the following in the Ansible provider pod logs:</p>

<p>As you can see, the hello world message was printed out to the console. This is exactly the same as you see when running Ansible playbook from command line, the only difference is that you can now drive the Ansible run in a cloud native way by applying a Kubernetes custom resource and customizing the run by modifying the custom resource at runtime.</p><h2>A More Powerful Example</h2><p>In this section, we are introducing a more complex custom resource. Our example target is to create and maintain a GCP bucket.</p><p>First of all we need to create a Kubernetes secret that handles the provider credentials, GCP in this case.</p>

<p>Then we should introduce this secret in the&nbsp;<i>ProviderConfig</i>&nbsp;resource which is used to authenticate against upstream API and repositories:</p>

<p>Once we create&nbsp;<i>ProviderConfig</i>&nbsp;ressource, the last step is always to create the&nbsp;<i>AnsibleRun</i>&nbsp;resource:</p>

<p>In the above <i>AnsibleRun</i> resource, we are using a remote Ansible role hosted by a remote git repository at: <a href="https://github.com/multicloudlab/crossplane-ansible-provider-sample.git" target="_blank">https://github.com/multicloudlab/crossplane-ansible-provider-sample.git</a>, and relying on the gcpconfig as <i>ProviderConfig</i>.</p><p>By checking the above <i>AnsibleRun</i> manifest, you may also notice that it allows us to customize the run by passing variables using <i>spec.forProvider.vars</i>. As you know, Ansible uses variables to manage differences among systems on which Ansible operates, so it can run roles or playbooks on multiple systems by using a single command. Ansible provider allows you to pass those differences into Ansible run when you define the AnsibleRun resource, in this case, to customize the gcp bucket provisioning, e.g.: specify the disk size, key, and zone, etc.</p><h2>Find the Ansible Provider in the Upbound Marketplace</h2><p>Previously, when Crossplane contributors or third-party organizations wanted to introduce new providers to the community, it took a lot of effort to ensure that users were aware of its existence and knew how to find it. With the recent <a href="https://www.upbound.io/learn/resources/upbound-marketplace-resources" target="_blank">launch of the Upbound Marketplace</a>, new providers like provider-ansible can be easily discovered by anyone searching for keywords, such as “<a href="https://marketplace.upbound.io/providers?query=ansible" target="_blank">ansible</a>”. Furthermore, the Marketplace allows package authors the ability to include documentation and examples for any resource, such as <a href="https://marketplace.upbound.io/providers/crossplane-contrib/provider-ansible/v0.3.0/resources/ansible.crossplane.io/AnsibleRun/v1alpha1" target="_blank"><i>AnsibleRun</i></a>, with minimal effort.</p><p>This ease of use empowers platform teams not only to start using the Ansible provider directly, but also to build and publish their own abstractions in the form of <a href="https://marketplace.upbound.io/configurations" target="_blank">configuration packages</a> built on its primitives.</p><h2>Conclusion</h2><p>Congratulations! You have worked through all the steps needed to run an Ansible playbook or role, either inline or hosted remotely, and customize the run by defining variables. It all happens inside a Kubernetes cluster, and driven by the Crossplane Ansible provider.</p><p>If you are interested in this project and want to join with us, feel free to open issues or submit pull requests to: <a href="https://github.com/crossplane-contrib/provider-ansible" target="_blank">https://github.com/crossplane-contrib/provider-ansible.</a></p>

Crossplane Ansible Provider: Getting Started

<p>Note: this content was <a href="https://thenewstack.io/k8s-is-not-the-platform-or-is-it-and-we-all-misunderstood/" target="_blank" rel="noopener noreferrer">originally posted on The New Stack here</a>.</p><p>Just a few years ago on the main stage of KubeCon North America, Kelsey Hightower talked about how <a href="https://www.youtube.com/watch?v=07jq-5VbBVQ" target="_blank" rel="noopener noreferrer">Kubernetes is just a low-level tool</a> and not a (developer) platform.</p><p>Companies building internal platforms to run their business would have to build abstractions and machinery above <a href="https://roadmap.sh/kubernetes" target="_blank" rel="noopener noreferrer">Kubernetes to reduce developers’ cognitive load</a>. Even more so, if done right, Kubernetes would become invisible and just an implementation detail.</p><p>For those of us deeply invested in Kubernetes and the giant ecosystem around it, this last sentence sounds like a push back. If that statement was true, we would be working on making components invisible eventually.</p><p>Now a few years later, it feels like we all misunderstood. Kubernetes is everywhere, and people are <a href="https://thenewstack.io/platform-engineering/" target="_blank" rel="noopener noreferrer">building platforms</a> more than ever with Kubernetes as the core component. So, what has changed? Let’s explore where we have ended up and what is different today.</p><h2>From Container Orchestration to More</h2><p>Kubernetes was originally a container orchestration platform, foremost built for this single use case. But while building up the most advanced <a href="https://thenewstack.io/containers/" target="_blank" rel="noopener noreferrer">container</a> orchestrator available in the open source community, the project did not end with only orchestrating pods. The project very early on built extension points into the system, most prominently <a href="https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/" target="_blank" rel="noopener noreferrer">custom resource definitions</a> (CRDs). Originally, CRDs were used to extend a compute cluster with auxiliary resources. Think of configuration resources, <a href="https://cert-manager.io/" target="_blank" rel="noopener noreferrer">CertManager</a> CAs and CertificateRequests, third-party networking layers like <a href="https://thenewstack.io/service-mesh/" target="_blank" rel="noopener noreferrer">service meshes</a>. The possibilities are endless, and a flourishing ecosystem evolved around compute.</p><p>But custom resource definitions opened the door to a lot more. Many concepts in Kubernetes are not constrained to container orchestration. When asked what will persist most likely from Kubernetes the longest, many thought leaders agree: the object model, the highly opinionated <a href="https://en.wikipedia.org/wiki/Create,_read,_update_and_delete" target="_blank" rel="noopener noreferrer">CRUD</a> API server model will likely live on the longest.</p><p>What does this mean? It means we have learned much more than how to run pods most efficiently since Kubernetes 1.0 was announced in 2015. People love the uniformity of APIs that Kubernetes offers. People love that they can use one tool like kubectl to talk to very different objects, one GitOps tool speaking the Kubernetes API language to roll out very different resources, one controller library like controller-runtime to build reconcile loops for very different domains. You see the pattern.</p><p>We all remember discussions about building solutions on Kubernetes and building APIs using CRDs, where the question arose: Why Kubernetes? Any other API machinery would do. This is true, obviously. But at the same time, you can ask the inverse: Why not Kubernetes and its API machinery with its rich ecosystem? Why shouldn’t we use CRDs to build, like developer platforms?</p><p>This discussion is kind of superfluous and quickly replaced with reality where people are doing just that. People love the Kubernetes ecosystem, the tooling built around CRDs and Kubernetes APIs. They know the tools and know how to write controllers. The question “What else?” is answered simply by “Kubernetes, because we have the knowledge, the tooling, and we are productive with it.” Plus, there is a giant community around it with the <a href="https://www.cncf.io/" target="_blank" rel="noopener noreferrer">Cloud Native Computing Foundation</a> and <a href="https://landscape.cncf.io/" target="_blank" rel="noopener noreferrer">all its projects</a>.</p><p>Let’s look at how Kubernetes helps to build the platform every business today is after. At the center of Kubernetes there is the API, an API that allows CRUD of very different objects, such as managing their life cycle in a uniform way. What do we mean by that? Kubernetes serves (clusterwide and namespaced) objects called resources. Objects have a common shape that we all know:</p>

<p>This common shape makes universal solutions possible, such as solutions for GitOps that work with all kinds of resources offered by a Kubernetes cluster. If our developer platform speaks this language of Kubernetes APIs, all those tools will just work and can immediately be part of our toolbox.</p><p>Traditionally, Kubernetes resources eventually need real code, usually Golang code. While the CRDs can be declaratively defined with a bunch of YAML lines, the actual logic requires real programming. Programming means cost, maintenance and more. It’s usually what platform builders avoid rather than embrace.</p><h2>Enter Crossplane</h2><p>The Kubernetes object model can support other ways to define logic for implementing APIs. The Crossplane project is a great example. <a href="https://www.crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a>, another CNCF project, was born in 2018 from the insight that the Kube API is perfectly suited to orchestrate arbitrary cloud resources. A year or two into the project, a concept called Compositions was invented. Compositions implement a pattern without a single line of code that we all know from Kubernetes: think of <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" target="_blank" rel="noopener noreferrer">deployments</a>, <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" target="_blank" rel="noopener noreferrer">ReplicaSets</a> and <a href="https://kubernetes.io/docs/concepts/workloads/pods/" target="_blank" rel="noopener noreferrer">pods</a>. They form a hierarchy: Deployments spawn ReplicaSets, and ReplicaSets spawn pods. Compositions implement this kind of hierarchy defining how an instance unfolds into other Kubernetes objects.</p><p>A developer platform needs higher-level abstractions to minimize cognitive load for developers. A deployment is an abstraction of pods. In a developer platform, think of a BigCorp Application, an abstraction BigCorp wants to offer to its developers: highly opinionated, highly custom for BigCorp, all API based. Crossplane makes it super easy to define such an abstraction without a single line of code:</p>

<p>A <a href="https://docs.crossplane.io/latest/concepts/composite-resource-definitions/" target="_blank" rel="noopener noreferrer">Composite Resource Definition</a> (short XRD) defines a custom resource definition with composite semantics. Concretely, a <a href="https://docs.crossplane.io/latest/concepts/composite-resources/" target="_blank" rel="noopener noreferrer">Composition</a> object defines how an (namespaced) Application <a href="https://docs.crossplane.io/latest/concepts/claims/" target="_blank" rel="noopener noreferrer">claim</a> object spawns a XApplication, spawning further resources when instantiated:</p>

<p>Imagine a developer in BigCorp using this API by creating an instance for the new customer feedback application to be deployed at a subdomain of the company website:</p>

<p>The Composite Resource Definition (XRD) defines the schema of this API. The Composition <code>xapplication-webapp</code> defines which resources this unfold into and how the specified domain value eventually ends up in the ingress definition (through <a href="https://docs.crossplane.io/latest/concepts/patch-and-transform/" target="_blank" rel="noopener noreferrer">Patch and Transforms</a>, very much like templating).</p><p>The Composition specifies two normal Kubernetes objects in this example but also one infrastructure resource for a cloud provider database. The Kubernetes resources can both land on the same Kubernetes cluster as the claim itself or be distributed to other clusters like your us-east1 application production cluster, or another one in Europe.</p><p>Note that the Application <code>customer-feedback/marketing-team</code> is just another Kubernetes API object, compatible with all the tools available in the ecosystem. For instance, the platform team wants to define guardrails about what this developer can do with an Application. Choose one of <a href="https://kyverno.io/" target="_blank" rel="noopener noreferrer">Kyverno</a>, <a href="https://www.openpolicyagent.org/" target="_blank" rel="noopener noreferrer">OpenPolicyAgent</a> or <a href="https://www.jspolicy.com/" target="_blank" rel="noopener noreferrer">jsPolicy</a>. The finance team wants to reduce cloud spend and aggregate cost onto BigCorp’s Application objects to make cost visible to the application owner? Choose <a href="https://www.opencost.io/" target="_blank" rel="noopener noreferrer">OpenCost</a> or <a href="https://www.kubecost.com/" target="_blank" rel="noopener noreferrer">KubeCost</a>. And so on.</p><p>The developer, with all this platform tooling in place, will use kubectl or the GitOps tool of choice to create the BigCorp Application claim:</p>

<p>For Kubernetes, this is just another resource: Kubernetes will manage its life cycle, define its API semantics, etc. For Crossplane, this is an instance of the <code>xapplication-webapp</code> composition. Crossplane knowns from the Composition and XRD above how to give life to the claim:</p><ul><li>Crossplane will create an XApplication composite.</li><li>It will select the <code>xapplication-webapp</code> composition for the XApplication as implementation.</li><li>It will unfold the XApplication into a database, the ingress and deployment object according to the selected composition.</li><li>It will create the SQL database at the cloud provider of your choice.</li><li>It will deploy the Kubernetes objects onto the same cluster or on production clusters of your choice.</li><li>Or, it will create another dedicated cluster with Argo CD as the GitOps tool of choice automatically installed and connected to your application git repository.</li><li>It will register the application and the specified dependencies in the company’s Backstage instance.</li><li>It will watch the status of all of these steps and report back to the developer in the status of the BigCorp Application object.</li><li>It will manage the life cycle of all the resources created.</li><li>It will tear down everything when the developer decides to delete the application.</li></ul><p>All of this happens without code. It happens on Kubernetes, and possibly involves multiple Kubernetes clusters. It is implementing a piece of a developer platform. The developer platform is not Kubernetes in the sense of the abstractions Kube as container orchestrator provides. But the developer platform is built on Kubernetes technology and the language of Kubernetes APIs and controllers. It implements high-level abstractions. It gives BigCorp a toolkit of building blocks and a rich ecosystem.</p><p>Kubernetes offers compute, merely as a side-effect. BigCorp Application could choose to deploy to some other compute service, for instance by creating a <code>lambda.aws.crossplane.io/v1beta1 object</code> for the customer-feedback application instead of a Kubernetes deployment. Compute is just a piece of the developer platform and potentially invisible to the developer. Compute is only a piece of Kubernetes, the potential it has as a foundation to solve real business problems.</p><p>So where are we today? Kubernetes and tools like Crossplane give us a powerful toolbox to build platforms. Kubernetes is not the platform. We misunderstood what this means. Kubernetes container orchestration is not a “platform as is” for developers, and it might even be invisible or unused. But Kubernetes as technology is bigger and has become the language of choice to build platforms.</p><p>Note: this content was <a href="https://thenewstack.io/k8s-is-not-the-platform-or-is-it-and-we-all-misunderstood/" target="_blank" rel="noopener noreferrer">originally posted on The New Stack here</a>.</p>

K8s Is Not the Platform – Or Is It and We All Misunderstood?

<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>At <a href="https://www.upbound.io/"><u>Upbound</u></a> we’re building your Universal Cloud Platform. Platform teams use Upbound to build bespoke cloud APIs and cloud consoles for the application development teams they support.</p>

<h2>The Upbound Cloud Console</h2><p>At the heart of Upbound is <a href="https://crossplane.io/" target="_blank">Crossplane</a>, the open source cloud control plane we founded and <a href="https://blog.crossplane.io/crossplane-cncf-incubation/" target="_blank">donated to the CNCF</a>. Crossplane can take anything with an API (like an AWS service, an SQL server, or a Kubernetes cluster) and let you build your own declarative API for it. Perhaps as a platform engineer you want to offer your application developers access to deploy and manage their own AWS RDS instances for example, but you want a very simple, opinionated API where only storage size is configurable.</p>

<h2>Crossplane enables a simpler database provisioning API</h2><p>Upbound helps you design and deploy Crossplane-powered cloud APIs. It also offers a cloud console to help manage them. Think AWS management console, but all the services and concepts are designed by you to suit your organisation’s unique needs. We can do this in part thanks to the Crossplane Resource Model, or XRM. While Crossplane encourages you to be opinionated about the <i>content</i> of your APIs (e.g. what knobs they expose) the XRM ensures the <i>shape</i> of your APIs is always consistent. Metadata is always distinct from desired and observed state, for example, while external identity, and secret properties like credentials are always presented one way. Crossplane is built on <a href="https://kubernetes.io/" target="_blank">Kubernetes</a>, and the XRM is an extension of the <a href="https://blog.upbound.io/__GHOST_URL__/how-the-kubernetes-resource-model-enables-configuration-as-data/">Kubernetes Resource Model</a> (KRM).</p><p>A typical production API powered by Crossplane will consist of bespoke types designed by your platform team, as well as types installed by a <a href="https://crossplane.io/docs/v1.5/concepts/providers.html" target="_blank">Provider</a>. The latter are called “<a href="https://crossplane.io/docs/v1.5/concepts/managed-resources.html" target="_blank">Managed Resources</a>” (MRs) and represent external systems like an AWS service. They are the building blocks used to create the former, which we call “<a href="https://crossplane.io/docs/v1.5/concepts/composition.html" target="_blank">Composite Resources</a>” (XRs). Crossplane’s API is powered by the Kubernetes API server, which serves a <a href="https://kubernetes.io/docs/concepts/overview/kubernetes-api/" target="_blank">JSON based HTTP REST API</a>.</p>

<h2>The API Server serves a JSON REST API</h2><p>The Upbound Console’s API server queries can be expensive. Take for example a platform engineer who has defined a <code>PostgreSQLInstance</code> XR. Each <code>PostgreSQLInstance</code> is &nbsp;composed of various MRs — say an <code>RDSInstance</code>, a <code>DBSubnetGroup</code>, and a <code>SecurityGroup</code>. If there were 10 <code>PostgreSQLInstances</code> the Upbound Console would have to make 31 REST API calls to show an application developer everything there was to know about these <code>PostgreSQLInstances</code> - one call to list the 10 XRs, then three calls per XR to lookup the MRs of which they are composed. To make matters worse, the responses to these requests always include every detail about the queried resource. Even if the developer just wanted to know whether or not they were all healthy, they would be forced to retrieve the entire JSON documents. These large queries get even slower when network latency between the Upbound Console and the API Server its querying increases.</p><p>Enter <a href="https://graphql.org/" target="_blank">GraphQL</a>. GraphQL is a strongly typed query language that is frequently used to build APIs. Compared to a typical JSON REST API a GraphQL API allows the caller to define the structure of the data it requires, allowing the server to omit any irrelevant data from the response. As the name suggests, GraphQL can query a graph of related types — so in our example above it would be possible to retrieve <i>only</i> the health of our 10 <code>PostgreSQLInstances</code> and all the Managed Resources of which they are composed in a single GraphQL query. GraphQL <a href="https://graphql.org/users/" target="_blank">enjoys broad adoption</a>. Invented at Facebook a decade ago, it’s now an open standard and powers high profile APIs like those of <a href="https://docs.github.com/en/graphql" target="_blank">GitHub</a> and <a href="https://shopify.dev/api/admin-graphql#top" target="_blank">Shopify</a>. Often large organisations will build a GraphQL aggregation layer to tie their many microservices together.</p>

<h2>An example GraphQL query with xgql</h2><p>The Upbound Console team identified the benefits of GraphQL early on, but despite its broad adoption GraphQL has seen little use within the Kubernetes ecosystem. Perhaps this is due to a technology stack disconnect. While language agnostic as a standard, much of the GraphQL ecosystem favors TypeScript whereas the Kubernetes ecosystem favors Go. Nascent projects such as <a href="https://github.com/qlkube/qlkube" target="_blank">qlkube</a> and <a href="https://github.com/onelittlenightmusic/kubernetes-graphql" target="_blank">kubernetes-graphql</a> weren’t a good fit as they are primarily auto-generated wrappers around “built in” Kubernetes API types like <code>Pod</code> and <code>Deployment</code>. Upbound needed a solution to support the XRM’s more advanced type system, which has subtypes (e.g. <code>RDSInstance</code> is a subtype of Managed Resource) and dynamic types that are added and removed at runtime (e.g. by defining a new Composite Resource, or installing a Provider). We decided to build our own GraphQL representation of the XRM — a Crossplane Resource Graph.</p>

<h2>The GraphQL schema of a Crossplane Composite Resource</h2><p><a href="https://github.com/upbound/xgql/" target="_blank">xgql</a> is Upbound’s implementation of the Crossplane Resource Graph. It’s open source, and part of our <a href="https://github.com/upbound/universal-crossplane" target="_blank">Universal Crossplane</a> distribution. xgql is written in Go using <a href="https://gqlgen.com/" target="_blank">gqlgen</a>. This approach has two key benefits:</p><ol><li>gqlgen is “schema first” — it generates much of its server code from a schema.</li><li>xgql can leverage the extensive caching support of the Kubernetes Go libraries.</li></ol><p>GraphQL schemas are all about types and relationships. Designing the schema up-front was an excellent test of the XRM, forcing us to think deeply about an idiomatic GraphQL representation of concepts like Providers, Configurations, Composite Resources, Managed Resources, and the relationships between them. In fact doing so highlighted <a href="https://github.com/crossplane/crossplane/issues/2255" target="_blank">one</a> or <a href="https://github.com/crossplane/crossplane/issues/2262" target="_blank">two</a> small gaps in the XRM that we intend to address in upstream Crossplane. The resulting schema enables GraphQL queries like:</p><ul><li>“Show me the ‘Ready’ status condition for the tree of resources created by this Claim.”</li><li>“Show me all events pertaining to provider-aws’s Managed Resources”.</li><li>“Tell me whether this is a Managed Resource or a Composite Resource”.</li><li>“Fetch the definition of this Composite Resource”.</li></ul><p>Building xgql in Go allows us to use best-in-class Kubernetes client machinery. xgql maintains an in-memory “watch cache” for each unique caller, meaning it subscribes to API server updates rather than making tens or hundreds of REST API calls to resolve each GraphQL query. This often results in xgql answering queries 10x faster with a warm cache.</p><p>There’s a lot more to the Upbound Console, including another GraphQL layer that uses a novel approach to route queries to thousands of xgql instances. <a href="https://twitter.com/upbound_io" target="_blank">Let us know on Twitter</a> if you’d be interested in another post about how we leverage GraphQL at Upbound. In the meantime if you’re building on the Crossplane API do try Universal Crossplane and xgql.</p><p>Finally, we’re hiring! We’re a fully remote company, deeply invested in open source, and recently <a href="https://blog.upbound.io/__GHOST_URL__/upbound-raises-60m-in-funding-to-advance-its-universal-cloud-platform/">closed a strong Series B</a> to help us build a universal cloud platform. We have open engineering roles from frontend to distributed systems to management — <a href="https://boards.greenhouse.io/upbound" target="_blank">apply today</a>.</p>

The Crossplane Resource Graph

<p>Continuous Integration and Continuous Deployment, better known by the acronym CI/CD is the foundation of modern DevOps.</p><p>At the Crossplane Community Day Europe virtual event, Jan Willies, Platform Architect at Accenture outlined <a href="https://www.youtube.com/watch?v=KqRolAqKV_8&amp;list=PLj6h78yzYM2OFWBatWHbWgyoLNmCyAqJ0&amp;index=10" target="_blank">how to connect all the different platform pieces together for automated CI/CD</a>. Accenture is one of the world's largest consulting firms and has been actively engaged in many different cloud native efforts including Kubernetes and <a href="https://blog.upbound.io/crossplane.io">Crossplane</a>.</p><p>The first part of the CI/CD process is onboarding a new application, which can be an involved and complicated process in many organizations. Willies explained that onboarding a new application often involves lots of manual steps including finding the right settings for a Git code repository, connecting code integration systems and figuring out deployment manifests. From a platform engineering perspective, Willies said that there is a clear need and desire to automate the application onboarding process.</p><blockquote><p>"Obviously the application needs to be deployed and for the GitHub software we also need to connect the Git repo and we need to connect the execution environment," Willies said. “We can do that manually, but we can also use API's for that.”</p></blockquote><h2>Using Crossplane for Application Onboarding</h2><p>Willies explained that among Crossplane's core features is the Crossplane Provider capability that implements arbitrary API's and mirrors them into Kubernetes.&nbsp;</p><blockquote><p>"This is really helpful because we now have drivers for each of those API's and are able to configure the systems in a standardized way via Kubernetes," Willies said.<br>&nbsp;</p></blockquote><p>So for example, a YAML configuration file can be created for a given Git repository. That said, Willies noted that there is still a need to know what to put in the YAML files, since they can potentially expose everything the upstream provider based API enables. That's where Crossplane Compositions come into play.</p><blockquote><p>"A composition is a templated resource, which acts as a controller and creates a single YAML file," Willies said.</p></blockquote><p>A Crossplane Composition from a technical perspective is an XRC, a Composite Resource Claim (<a href="https://crossplane.io/docs/v0.14/getting-started/compose-infrastructure.html" target="_blank"><strong>XRC)</strong></a> which enables the composition to abstract the underlying implementation details from the assembled provider resources.</p><p>In a <a href="https://www.youtube.com/watch?v=KqRolAqKV_8&amp;list=PLj6h78yzYM2OFWBatWHbWgyoLNmCyAqJ0&amp;index=10" target="_blank">demo</a>, Willies showed how it was possible to easily onboard a new application using Crossplane. The demo involved creating a GitLab project, an Argo CD repository and an Argo CD application as well. The providers for<a href="https://github.com/crossplane-contrib/provider-gitlab" target="_blank"> <strong>GitLab</strong></a> and ArgoCD are all available in the Crossplane GitHub repository for anyone to use and create their own onboarding approach.</p><blockquote><p><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">"All of this is open source," Willies said.</span></p></blockquote>

Connecting the Platform Pieces for Automated CI/CD

<h4><span style="background-color:rgb(255,255,255);color:rgb(3,7,36);font-family:Avenir-Roman, Arial, sans-serif;">Upbound Founder and CEO, Bassam Tabbara, announces Crossplane 1.0 and details the promise and vision of Crossplane</span></h4>

<p>Bassam Tabbara, Founder and CEO of Upbound, opened <a href="https://events.crossplane.io/crossplane-community-day-modernizing-with-api-centric-control-plane-post" target="_blank">Crossplane Community Day</a> with the history and vision for <a href="https://crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a><a href="https://crossplane.io/" target="_blank"> </a>and how control planes are leading the transformation of IT modernization.</p><p>2020 clearly brought into focus the importance of IT modernization and digital transformation. Through the challenges of year, with resources constrained and teams working remotely, organizations of all sizes felt the urgent need to increase productivity and accelerate the pace of innovation. A number of common challenges were cited by Tabbara, including the need to support multiple environments like hybrid and multi-cloud deployment, while still having strong controls for policy and compliance.</p><p>While cloud is a cornerstone of IT modernization, managing multi-cloud resources can be complex and there has been a shift in the way organizations use the cloud.</p><p>"What we're seeing is essentially a shift from a DevOps culture where people are accessing the cloud directly," Tabbara said. "We're seeing the rise of platform teams."</p><p>The platform teams essentially offer a set of shared services across cloud infrastructure that abstract the underlying complexity of the cloud provider's back end. Cloud providers themselves have pioneered an approach for enabling easy access to service management with the use of control planes. Tabbarra explained that when a user is provisioning a virtual machine instance or a storage bucket or anything else in the cloud, it all goes through the control plane. It acts as a single point of entry to the cloud and is responsible for storing configuration, lifecycle management and policy for security auditing as well as compliance.</p><p>"Essentially what motivated us to create Crossplane is we wanted to bring that same approach that has caused the cloud to become the largest platform in the world, bring that to your organization, to the enterprise, to the open source community," Tabbara said. "We wanted platform teams to actually use control planes to unlock the next level of efficiency and productivity."</p>

<h2>The Core Vision of Crossplane</h2><p>Tabbara explained that Crossplane has two primary functionalities. The first is to expose a single universal API for the cloud, which is a Kubernetes-style API, that enables users to address infrastructure and services across multiple vendors in a consistent approach.</p><p>The second is to enable developers to create their own platform APIs and do that without having to write code.</p><p>"You can expose your own catalog of services, you can capture your guardrails configuration automation policy, all of that lives behind the API, &nbsp;ready for your application teams to consume," Tabbara said.</p><h3>The True Power of Kubernetes</h3><p>Crossplane is based on the Kubernetes control plane, which is often just associated with controlling container resources.</p><p>"I think when we look back five years from now at Kubernetes, I think we will see that its true power is not just container orchestration," Tabbara observed. “It's the fact that it's a framework for control planes.”</p><p>Kubernetes pioneered the model where you essentially use an API approach to manipulate desired state and a document store. Then a set of asynchronous controllers are able to take that state and essentially reconcile it with the real world. Tabbara noted that the control plane approach has worked really well for Kubernetes in the container space but it's actually widely applicable.</p><h2>How Crossplane Expands on the Kubernetes Control Plane</h2><p>One of the first challenges that Crossplane had to address was how to bring various resources exposed by different cloud vendors, into the same control plane. What the Crossplane project has done is invested in creating a set of providers that bring the different resources under the same Kubernetes style API.</p><p>"We created the Crossplane Resource Model which is an extension of the Kubernetes Resource Model, " Tabbara said. “It gives us consistency across the different vendors when you're provisioning resources.”</p><p>With the Crossplane Resource Model (XRM) users will get the same style of resources across different cloud providers. Tabbara noted that the project has worked with multiple vendors to create an entire ecosystem of Crossplane Providers. Among the cloud platforms that have enabled Crossplane Providers are AWS, Microsoft Azure, Google Cloud and Alibaba Cloud. At the Community Day Event Tabbara was also pleased to announce that IBM Cloud and Equinix have recently made their Crossplane Providers available as well.</p><h2>Crossplane Composition, Configurations and Registry</h2><p>Beyond the XRM there are multiple layers that build out the control plane vision that Crossplane enables.</p><p>Tabbara explained that with Composition, Crossplane users can create their own APIs. Crossplane has a concept known as Composite Resource Definition(XRD) which is similar to a Kubernetes Custom Resource Definition (CRD). An XRD is an abstracted API that developers use while Compositions are implementations of these APIs using templates or code.</p><p>Another layer that Crossplane provides is with Configuration which provides blueprints for comprehensive platform configurations.</p><p>"This enables you to create fully reproducible environments, made up of XRDs, policies of configurations of your managed resources, all packaged in essentially, a container that represents your platform," Tabbara said.</p><p>Finally there is also a Registry that contains a set of reference platforms and configurations for them. Over the next six months, Tabbara expects that there will be 20 to 30 reference platforms in the Registry that cover a wide range of scenarios including serverless, virtual machines and AI/ML workloads.</p><h2>Two Years of Progress</h2><p>The Crossplane project is only two years old and has made tremendous progress in a short period of time.</p><p>"We actually just released Crossplane 1.0 which is a massive milestone," Tabbara said. "The project is being used in production by a number of companies today and we believe it's ready to be deployed in production in every organization out there."</p><p>The second Crossplane Community Day was held December 15, 2020 and you can watch the complete replay on <a href="https://www.youtube.com/playlist?list=PL510POnNVaaZx1QDIn_-77igM1COuHaHV" target="_blank">Youtube</a>, as well as read the full wrap-up report. Ready to dive deeper? Join the Crossplane community on <a href="https://slack.crossplane.io/" target="_blank">Slack</a>, follow on <a href="https://twitter.com/crossplane_io" target="_blank">Twitter</a> or get started on <a href="https://github.com/crossplaneio/crossplane" target="_blank">GitHub</a>.</p>

Crossplane Community Day Keynote: Modernizing IT with Control Planes

<p>Happy New Year! We’re settled back in after a fantastic holiday and ready for the year ahead. A highlight of 2019 was attending both KubeCons, Barcelona and San Diego, as well as launching the first ever <a href="https://multicloudcon.io/" target="_blank">MulticloudCon</a>, co-hosted with our <a href="https://about.gitlab.com/blog/2018/12/04/opensource-multi-cloud-crossplane/" target="_blank">friends at Gitlab</a>. If you weren't able to attend, the talks are now available to watch.</p><p><a href="https://info.flexera.com/SLO-CM-WP-State-of-the-Cloud-2019" target="_blank">84 percent of enterprises</a> already have a multicloud strategy and most companies have an average of four clouds in use today. With this rapidly growing adoption, the multicloud community needed a place to convene and define what multicloud really means and share ways to be successful as they begin to move through their multicloud journey. That’s why we joined forces with GitLab to launch <a href="https://multicloudcon.io/" target="_blank">MulticloudCon</a>, to offer a space for end users, open source leaders and cloud providers to come together and share successful strategies and learn about ways to advance into the future. Naturally, KubeCon was the right place to launch as Kubernetes has played a significant role as the "great equalizer" when it comes to working across multiple clouds.</p><p>We've uploaded the full collection of talks to share with the broader multicloud community and we'll share more speaker and panel recaps in the coming weeks.</p><p>The first two keynotes from CEO and Co-founder of <a href="https://twitter.com/sytses" target="_blank">GitLab, Sid Sijbrandij</a> and Upbound CEO and <a href="https://twitter.com/bassamtabbara" target="_blank">Founder, Bassam Tabbara</a>, kicked off the day and framed how to think about multicloud. Sid offered a pragmatic framework to help understand how to talk about and visualize the multicloud journey, while Bassam talked about the vision and path forward to a community-driven open cloud future.</p><p>Sid introduced attendees to the Multicloud Maturity Model, a way to think about the<a href="https://medium.com/gitlab-magazine/multi-cloud-maturity-model-2de185c01dd7" target="_blank"> stages of multicloud adoption</a> throughout a company’s journey. He walked through the various stages of maturity seen across companies: Mono-cloud, No portability, Workflow portability, Application portability, Disaster Recovery (DR) portability, Workload portability, and Data portability, noting that most companies are now aiming for workflow portability.</p>

<p>According to Sid, the importance of a multicloud strategy really came into focus for companies when they began to understand that "different clouds provided different workflows and toolings. The way you worked was specific to that cloud… and teams working in different ways began to impede collaboration and lead to a loss of velocity.” &nbsp;</p><p>Bassam's keynote focused on the vision for a multicloud future, one where innovation can flourish if it’s built around<a href="https://crossplane.io/" target="_blank"> Crossplane</a>. He describes the current state of the cloud computing ecosystem and how hyper cloud providers like AWS, Microsoft Azure and Google Cloud are “master integrators” offering their customers a selection of managed services in a seamless, easy-to-use way.</p>

<p>He describes how tensions arise when this level of integration is not offered to everyone--open source companies are often on the outside, even if the technology is superior. Bassam explains that in order to advance innovation, we need to offer an open source, community-driven path in for all managed services vendors via Crossplane and level the playing field where open source companies, who are leading innovation, are on equal footing with the managed services chosen by cloud providers.</p><p>We’ll continue our recaps through the next few weeks. Until then, you can find all of the <a href="https://www.youtube.com/watch?v=-ABpPef9ibQ&amp;list=PLFGfElNsQthbiSy32TsYZyVgMk8Rv54kN" target="_blank">MulticloudCon talks here</a>. If you have questions about Crossplane or how to get involved, please check us out on <a href="https://slack.crossplane.io/" target="_blank">Slack</a> or<a href="https://github.com/crossplaneio/crossplane" target="_blank"> Github</a>.</p>

MulticloudCon Talks Are Now Live

<p>This is&nbsp;<a href="https://blog.upbound.io/__GHOST_URL__/watch-multicloudcon-talks/"><u>part two of a series</u></a>&nbsp;of blog posts recapping&nbsp;<a href="https://multicloudcon.io/"><u>MulticloudCon</u></a>, a day-long conference we hosted at KubeCon with our friends from GitLab.</p><p>While GitLab CEO, Sid&nbsp;<a href="https://twitter.com/sytses"><u>Sijbrandij</u></a>&nbsp;and Upbound CEO, Bassam&nbsp;<a href="https://twitter.com/bassamtabbara"><u>Tabbara</u></a>&nbsp;kicked off the day by providing a framework and vision for how to think about multicloud, we had a set of demos exhibiting the tangible, real-world implementations of the stages of the multicloud journey.</p>

<p><a href="https://twitter.com/eddiezane?s=20"><u>Eddie Zaneski</u></a>&nbsp;from Digital Ocean kicked off with the first live demo of the day, discussing how many users are at the workflow portability stage of multicloud adoption. With an exciting live demo using Google Kubernetes (GKE) and Digital Ocean clusters on a GitLab project, Eddie invited the audience to not only follow along but jump into building, testing, deploying, and running applications at scale within minutes.</p>

<p><a href="https://twitter.com/jbw976?s=20" target="_blank">Jared Watts,</a> founding engineer at Upbound and Crossplane, followed up with the next live demo. Jared showed how users can manage workflows for multiple cloud services from a single interface in GitLab, made possible by using the <a href="https://blog.upbound.io/__GHOST_URL__/upbound-announces-crossplane-integration-with-gitlab-12-5-release-to-advance-multicloud-future/">Crossplane integration that was part of Gitlab’s 12.5 release.</a> With the integration, developers can use GitLab to deploy Crossplane to provision and securely consume cloud infrastructure for Kubernetes applications deployed with GitLab.</p><p>Jared walked through the application portability stage of multicloud adoption — showcasing how application developers can focus on writing and developing instead of getting bogged down in the infrastructure. The combination of GitLab Auto DevOps and Crossplane that Jared showed on stage was an exciting introduction to true multicloud CI/CD.</p>

<p>Yugabyte’s Sid Choudhury closed out the demo portion of the day by completing the<a href="https://medium.com/gitlab-magazine/multi-cloud-maturity-model-2de185c01dd7" target="_blank"> multicloud maturity model </a>with a demonstration of data portability across multiple clouds using Crossplane.<br><br>Building on the <a href="https://blog.yugabyte.com/rook-operator-announcement/" target="_blank">Rook Kubernetes Operator for YugabyteDB</a> and Crossplane implementation, Sid was able to demonstrate how users can easily provision and manage multiple database clusters across Google Kubernetes Engine, Amazon Elastic Kubernetes Service, and Azure Kubernetes Service using Crossplane as the single control plane.</p><p><a href="https://blog.yugabyte.com/announcing-yugabytedb-on-crossplane-the-open-source-multicloud-control-plane/" target="_blank">With this new integration</a>, users can now deploy complete application stacks across Kubernetes clusters on their cloud of choice or on-premise.</p>

MulticloudCon Demos: Workflow, Application and Data Portability Across Multiple Clouds and On-Premise

<p>As another Kubecon + CloudNativeCon draws near, we here at Upbound are making our final preparations and getting pumped to travel to Chicago for all the festivities next week! Kubecons really do make for some of the highlights of our year as we get the opportunity to connect with a ton of amazing people from the ecosystem, as well as share all of our exciting recent progress that we’re very proud of. We’re still feeling a bit of the <a href="https://blog.upbound.io/wrapping-up-kubecon-amsterdam">buzz from Kubecon Amsterdam</a>, but we’re ready to top it off again!</p><p>Chicago is a great city to host us next week. In addition to the conference content and experiences, I personally will be aiming for more than just one dinner of Chicago-style deep-dish pizza 🍕. Unfortunately, I can’t work it into my schedule to also catch a show at <a href="https://www.secondcity.com/chicago-shows/" target="_blank">The Second City</a>, but I highly recommend their hilarious brand of comedy to any folks that can make it next week alongside everything else going on! Okay, back to conference content…</p>

<h2>Our Experts Have a Lot to Say</h2><p>There are <a href="https://www.upbound.io/resources/events/kubecon-chicago-2023?utm_campaign=2023_Q4_NALA_CEV_KubeCon-Chicago#session" target="_blank">multiple sessions</a> being delivered by Upbounders next week, all of which will make for very interesting material and experiences. Tuesday will be a bit hectic with multiple sessions going on, but we are always ready to rise to the challenge to share great content with you all! We’re even hoping to see our recent Crossplane project updates on the big stage for the Keynotes, so keep an eye out for that! Other talks we’re involved in that you should not miss include:</p><ul><li><strong>Crossplane Contribfest @ </strong><a href="https://sched.co/1R2mW" target="_blank">Tues Nov 7 11:00 </a>AM - Write code hands on alongside the Crossplane maintainers (more below)</li><li><strong>API Machinery maintainer track</strong> @ <a href="https://sched.co/1R2my" target="_blank">Tues Nov 7 11:55</a> AM- Learn more about the internals of the Kubernetes API with our very own control plane expert Stefan Schimanski</li><li><strong>Crossplane Introduction and Deep-dive</strong> @ <a href="https://sched.co/1R2ne" target="_blank">Tues Nov 7 2:30</a> PM- The maintainers of Crossplane will provide an overview of Crossplane for newcomers and then dive deeply into some of the most impactful new features like Composition Functions</li><li><strong>Streamlining Infrastructure with Crossplane: a Transformation Story</strong> @ <a href="https://sched.co/1R2p8" target="_blank">Tues Nov 7 5:25</a> PM- Hear the details, obstacles and successes of the Crossplane adoption journey of <a href="https://consensys.io/" target="_blank">Consensys</a>, along with my explanations of foundational Crossplane features to up your control plane game</li><li><strong>Introducing The BACK Stack!</strong> @ <a href="https://sched.co/1R2uS" target="_blank">Thurs Nov 9 2</a> PM- David Murphy will be walking everyone through a new architecture and practical guidance for building internal developer platforms that utilizes 4 key cloud native technology projects (of course the ‘C’ stands for Crossplane!)</li></ul><h2>Empowering New Crossplane Coders</h2><p>I’m particularly excited about the Crossplane Contribfest session that we’ll be running next week. We did the first ever Contribfest in Amsterdam earlier this year and we’ve got a few ideas to improve the experience even more. This will be such a fantastic opportunity to connect with the community in a more intimate setting and put our heads together to write new code for Crossplane. We’ll be collaborating on writing <a href="https://docs.crossplane.io/v1.14/concepts/composition-functions/" target="_blank">Composition Functions</a> to teach Crossplane new tricks and accelerate the building of your control planes.</p><p>We only get 90 minutes together, so it will be chock-full of “roll up the sleeves” hands-on learning, so bring your laptop and get ready to code with us!</p><h2>Come by for a Valuable Chat</h2><p>As usual, we’ll be hosting two booths in the Solutions Showcase - one Crossplane focused booth that is part of the <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/project-engagement/#project-pavilion" target="_blank">CNCF’s Project Pavilion</a> and an Upbound booth focusing on our products and solutions that are ready to scale with your production ready Crossplane needs. These booths are seriously where some of our best connections with the ecosystem are formed.</p><p>If you’re a Systems Integrator, Reseller or Software Vendor interested in working with Upbound to deliver Crossplane-based solutions, you can <a href="https://calendly.com/rob_upbound/upbound-partnerships-kubecon" target="_blank">connect with our partner team here</a>.</p><p>I can’t stress enough how valuable all the feedback and insight truly is from everyone stopping by and sharing their experiences with us in person. It’s not an exaggeration to say that all that data impacts our roadmap and helps shape what features we prioritize delivering.</p><p>So we highly encourage you to stop by, share your thoughts, and get your questions answered as well! I hear there’s a really cool new popsicle neon sign that will show you the way to our booths…</p><h2>See you in Chicago</h2><p>We certainly recognize its a privilege to be able to travel to Chicago next week, so for all the Crossplane and Upbound fans around the globe that can’t make it, we not only hope to see you soon too, but we invite you reach out virtually on <a href="http://slack.crossplane.io/" target="_blank">Crossplane Slack</a> and the <a href="https://www.upbound.io/contact" target="_blank">Upbound website</a> - we’d love to hear from you.</p><p>For folks fortunate enough to travel next week, there are a lot of opportunities to connect with us at Kubecon Chicago, and we encourage you to take advantage of as many as you can! Our <a href="https://www.upbound.io/resources/events/kubecon-chicago-2023" target="_blank">Kubecon Chicago page</a> has details to find us, including an exciting happy hour event and directly booking a meeting to sit down with us away from all the chaos. As we said, LOTS of opportunities to see each other!</p><ul><li><a href="https://www.upbound.io/resources/events/kubecon-chicago-2023" target="_blank">Upbound talks, events, and opportunities to connect at Kubecon Chicago</a></li></ul><p>With your help, the Upbound team is ready to make this the best Kubecon + CloudNativeCon yet. We hope to see you next week! 🍕🌬️🏙️</p>

Upbound at Kubecon + CloudNativeCon in the Windy City

<p>HashiCorp recently announced that they are changing the licenses on their open source projects from MPL to BSL including the Terraform project. At Upbound we understand and respect HashiCorp’s decision to change to a BSL license. This licensing change does not impact Upbound’s use of Terraform. <strong>As Upbound is a maintainer of Crossplane and manages the open source project's use of Terraform, this licensing change also does not impact the project's use of Terraform.</strong></p><h2>Background on Crossplane Providers and Terraform</h2><p>Crossplane Providers enable Crossplane to provision infrastructure on an external service. Providers create new Kubernetes APIs and map them to external APIs. Providers are responsible for all aspects of connecting to non-Kubernetes resources. This includes authentication, making external API calls and providing Kubernetes Controller logic for any external resources.</p><p>There are 100s of Crossplane providers today authored by different parties. Some of these rely on code generation approaches to interface with the backed vendor, and some are implemented natively. See <a href="https://marketplace.upbound.io/providers">https://marketplace.upbound.io/providers</a> for a growing list of providers today.</p><p>Upbound maintains a set of Official Providers for Crossplane that are open source (Apache 2.0), and enterprise-ready. Some of these Official Providers rely on Terraform providers underneath the covers via code generation technology called “upjet”. Upjet translates Kubernetes API calls in Crossplane to Terraform provider invocations which in turn invoke backend cloud or infrastructure API.</p><p>Upjet today invokes the Terraform CLI directly and is in compliance with the licensing of Terraform. Over the last few months we have identified a number of performance improvements that can be achieved by circumventing the Terraform CLI completely and invoking the Terraform providers directly. This work is currently underway and we expect new providers to be released over the next few months. Terraform providers will continue to be licensed under MPL2.</p><p>In summary, Upbound’s official providers are not impacted by the license change today.</p><h2>Looking forward</h2><p>Upbound is committed to ensuring the ecosystem around Crossplane is healthy and vibrant. We’ve recently announced our <a href="https://www.upbound.io/why-upbound/partners">partner program</a> and a verification program for providers. We host 100s of providers in the <a href="https://marketplace.upbound.io/providers">Upbound Marketplace</a> and work with the community to publish these.</p><p>As Crossplane grows, we believe the community will benefit from having providers being maintained and owned by the cloud and infrastructure vendors. This ensures the highest level of quality and support for their product offerings. This is why we’ve been working with cloud providers like AWS, Azure and Google Cloud, and infrastructure vendors like Datadog, Aviatrix, and more.</p><p>We are investing in <a href="https://docs.upbound.io/providers/migration/">tooling to make provider migrations</a> automatic and seamless. As we continue to improve our providers, recently with the launch of <a href="https://blog.upbound.io/new-provider-families">provider families</a>, or in the future with new features, native bindings, and more, we will continue to have automated migration tooling and always have a focus on the end-user experience.</p><p>We feel confident this will not impact Crossplane community members or Upbound customers. If you have any questions or concerns about your Upbound solutions, please reach out to your account manager directly or <a href="mailto:customer-success@upbound.io" target="_blank" rel="noopener noreferrer">email us</a>.</p>

HashiCorp's BSL License Change: What this Means for Upbound Customers and the Crossplane Community

<p>Wondering what <a href="https://www.crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a> is all about? <a href="https://blog.upbound.io/what-is-crossplane/">Read my first blog here</a>.</p><p><i>This excerpt was originally published in the </i><a href="https://learning.oreilly.com/" target="_blank"><i>O’Reilly Report: “What is Crossplane?”</i></a><i>.</i></p><h2>All About Control Planes</h2><p>In my opinion, a good control plane should do three things:</p><ul><li>Drive the data plane toward the desired state</li><li>Protect the data plane</li><li>Be reliably available</li></ul><p><strong>In this blog I’ll explore how a control plane built with Crossplane achieves the first goal.</strong> If you know how <a href="https://blog.upbound.io/control-plane-revolution/">Kubernetes’s control plane works</a>, you’ll notice a lot of familiar concepts in this blog. This is because Crossplane builds on the Kubernetes control plane and enjoys many of its benefits.</p><p>If you’d like to learn more about how Crossplane protects the data plane and is readily available, I’ve detailed everything you need to know in my report, <a href="https://www.upbound.io/resources/lp/whitepaper-b/oreilly-what-is-crossplane">“What Is Crossplane?: A Low-Code Framework for Building Cloud Native Control Planes”</a> here.</p><h2>Driving Toward the Desired State</h2><p>A control plane’s core function is to reconcile the actual state of its data plane with a desired state. <strong>A thermostat is a good example:</strong> you might desire your room to be 72 degrees F, but its actual temperature is 65 degrees. The thermostat can reconcile the actual state of your room (its temperature) with your desired state by running the heat until the room reaches 72 degrees F.</p><p>You tell Crossplane what the desired state of your data plane is by making API calls. Crossplane exposes a JavaScript object notation (JSON) representational state transfer (REST) API over hypertext transfer protocol (HTTP). JSON REST APIs are broadly supported by tools and programming languages. This makes it easier to integrate Crossplane with other systems.</p><p><strong>Crossplane APIs look a lot like Kubernetes APIs.</strong> They are compatible with popular tools in the Kubernetes ecosystem like Helm, ArgoCD, Kyverno, and of course Kubectl. All of Crossplane’s APIs are actually Kubernetes Custom Resources. This means that, like all Custom Resources, they’re declarative. You just tell Crossplane the desired state of the data plane — not how to achieve it.</p><p>APIs exist on a spectrum from purely declarative to purely imperative. Imperative APIs require you to specify how to achieve your desired state. Declarative APIs are simpler: would you rather imperatively tell your thermostat to run the heater for 20 minutes each time you notice it’s cold, or declaratively tell it to keep the room at 72 degrees?</p><p><strong>A huge benefit of Crossplane’s declarative APIs is that if you save the body of your API request to disk, you have a configuration file.</strong> This lets you keep your desired state using a revision-control system like Git. Crossplane API objects use JSON, but tools like Kubectl typically convert them to YAML ain’t markup language (YAML) when you save them to a file. A desired-state API object saved as a YAML file is often called a manifest. Example 2-1 shows a Crossplane API resource in YAML form. This will look familiar to you if you’ve ever seen a Kubernetes Deployment or Pod manifest.</p><p>Each resource in Crossplane’s API represents a data plane entity. You can create, read, update, or delete that entity using HTTP verbs (such as POST, GET, PUT, and DELETE). API resources represent things, not actions. Think back to the SimplePostgres example from the <a href="https://blog.upbound.io/what-is-crossplane/">first blog</a>.</p><p>All Crossplane API resources include at least three top-level fields:</p><h3>apiVersion and kind</h3><p>Specifies the type of the resource. This makes it easy to identify the type of the resource without knowing its URL, for example when reading a YAML manifest.</p><h3>metadata</h3><p>Metadata that is supported by all resources, including their name, creation time, and arbitrary labels and annotations.</p><p>Most Crossplane API resources contain only two other top-level fields: spec and status. The spec field specifies the desired state of the resource, while the status field reflects its observed actual state. All API resources have OpenAPI v3 schemas.</p><h4><strong>Example 2-1: A SimplePostgres YAML manifest</strong></h4>

<p>Crossplane offers a consistent, uniform API to express desired state and read actual state. This makes working with Crossplane predictable—all of its APIs look and feel similar. It reduces users’ cognitive burden and helps tools integrate with Crossplane. <strong>In many places, Crossplane APIs are more uniform than Kubernetes APIs.</strong> For example, the same API field in all Crossplane resources reflects whether they are ready to use.</p><p>You might have noticed that a thermostat must measure the temperature of the room to determine whether it needs to run the heat. The thermostat uses a feedback loop to make the right corrections over time. <strong>This is called closed-loop control, and it’s a desirable property of a control plane. Crossplane does this using controllers.</strong> A controller subscribes to the API that it is responsible for and watches for changes to its desired state. Each controller is responsible for a single kind of API resource. A SimplePostgres API is powered by a SimplePostgres controller.</p><p>When the desired state changes, the controller:</p><ol style="list-style-type:decimal;"><li>Reads the desired state from its API</li><li>Observes the actual state of the part of the data plane its API represents</li><li>Determines whether the actual state is different from the desired state</li><li>Corrects the actual state by creating, updating, or deleting something</li></ol><p>Imagine you’ve configured Crossplane to satisfy calls to the SimplePostgres API by creating RDS instances. Each SimplePostgres instance corresponds to an RDS instance.</p><p>When the SimplePostgres API is called to create a new PostgreSQL instance, its controller will:</p><ol style="list-style-type:decimal;"><li>Read the desired state from the SimplePostgres API</li><li>Attempt to observe the actual state of the corresponding RDS instance</li><li>Find that the RDS instance does not exist</li><li>Create the RDS instance, deriving its configuration from the desired state read from the SimplePostgres API</li></ol><p>Crossplane controllers use closed-loop control to ensure that your data plane never drifts from your desired state. Once you tell Crossplane the desired state of your data plane, it will constantly observe the data plane’s actual state and quickly self-heal when that drifts.</p><h2>Want the Full Picture?</h2><p>If you’d like to understand the full picture of how a Crossplane control plane works, my colleague Viktor covers everything in his book, “<a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane">Crossplane: The Cloud Native Control Plane</a>." It goes into depth about Crossplane, how a Crossplane Control Plane works &amp; how to build one, and more.</p>

<p>&nbsp;</p><p><a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane">Feel free to download it here</a> to get the full rundown of Crossplane &amp; Control planes to level up your infrastructure.</p>

How a Crossplane Control Plane Works: Driving Infrastructure Toward Your Desired State

<p><i>This excerpt was originally published in the </i><a href="https://learning.oreilly.com/" target="_blank"><i>O’Reilly Report: “What is Crossplane?”</i></a><i>.</i></p><p><a href="https://www.crossplane.io/" target="_blank">Crossplane</a> is a framework for building cloud native control planes. When the founders of Crossplane at Upbound told me what they were working on in late 2018, shortly before the <a href="https://blog.upbound.io/introducing-crossplane-open-source-multicloud-control-plane/">v0.1 release</a>, I was very excited. I’d spent a lot of my career building cloud control planes from scratch. I loved the idea of an open source framework that baked in many best practices of control plane design and could be extended to control almost anything. I immediately joined the project and have been a maintainer since Crossplane v0.1.</p><p>A cloud platform is a distributed system, and distributed systems are often architecturally separated into two parts: control planes and <a href="https://ia802905.us.archive.org/35/items/memoryprocessorc557lawr/memoryprocessorc557lawr.pdf" target="_blank">data planes</a>. The data plane is the system under control. It’s what provides direct business value. As for the control plane, it works like an air-traffic-control tower. This analogy is illustrated in Figure 1-1. The aircraft around the airport represent the data plane. The aircraft provide the business value—moving things around—but the air-traffic-control tower is crucial to ensure they can do so safely and efficiently.</p>

<p><a href="https://resources.upbound.io/aws-partnership" target="_blank">Amazon Web Services (AWS)</a> is another example of control planes and data planes. AWS’s data planes are the virtual machines, databases, caches, and other services folks use to build products. Each of these services has a control plane that is responsible for starting, stopping, and configuring them. When you use the AWS console or call an AWS Application Programming Interface (API), you’re interacting with one of AWS’s control planes.</p><p>You can also think of a cloud control plane as having a backend that orchestrates the data plane and a frontend that exposes an API. That’s where Crossplane comes in: it takes the Kubernetes control plane and makes both its backend and its frontend highly extensible. You can extend the backend to control any kind of system, and you can extend the frontend APIs to expose whatever concepts make sense for your organization. Figure 1-2 shows an engineer making an API call to the control plane’s frontend API, and the control plane backend orchestrating a cloud provider.</p>

<p>Imagine you’re part of the platform engineering team at a growing technology company—say, a music streaming service. Your team supports 40 engineers, who are split across 7 other teams. These teams deliver your company’s core product: streaming music. Perhaps they also work on social features or recommendation engines. Let's call these folks product engineers. Most of your product-engineering teams want to use PostgreSQL databases to build their features, but they’re not experts in securing and scaling them.</p><p>Your team’s job, as <a href="https://blog.upbound.io/top-ten-things-slowing-down-your-platform-team/">platform engineers</a>, is to make it safer and more efficient for the product engineers to do their regular tasks. This is a form of <a href="https://en.wikipedia.org/wiki/Force_multiplication" target="_blank">force multiplication</a>: the platform engineers multiply the effectiveness of the product engineers.</p><p>How could you make it safer and more efficient for the product engineers to provision PostgreSQL databases?</p><p>You can learn even more about how a Crossplane Control Plane works and how to build one, and more from my colleague Viktor in his latest book, “<a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane">Crossplane: The Cloud Native Control Plane</a>”.&nbsp;</p>

<p>&nbsp;</p><p><a href="https://www.upbound.io/resources/lp/whitepaper-a/oreilly-what-is-crossplane" target="_blank">Download it here</a> to get the full rundown of Crossplane and control planes to level up your infrastructure.</p>

What is Crossplane?

<p>Hello, my name is Stefan Schimanski, or sttts how many in the community know me from <a href="https://github.com/sttts" target="_blank">GitHub</a> and <a href="https://twitter.com/the_sttts" target="_blank">elsewhere</a>.</p><p>I had the pleasure to start working on Kubernetes very early on in 2015, before 1.0, working for Mesosphere building Kubernetes-on-Mesos. Shortly after in 2016, I moved to Red Hat to work in their upstream/kubernetes/control-plane team, with lots of upstream contributions — eventually becoming <a href="https://github.com/kubernetes/kubernetes/graphs/contributors" target="_blank">#7 of the top-contributors to the main k/k repository</a>. For several years, I was leading the OpenShift apiserver and auth team at Red Hat, working on making the OpenShift control-plane enterprise-ready for production critical workloads.</p><p>Early on during my time at Red Hat, I started focusing on kube-apiserver, and within that eventually on CustomResourceDefinitions. I had earned my doctorate in mathematical logic, doing research on type systems for lambda calculus so consistency and type safety was always near to my heart. Consequently, lots of my contributions in Kubernetes were about that. Both in code type safety, but also in enforcing sane type structures in CRDs (schemas), with OpenAPI validation, pruning, defaulting and structural schemas. Today taken for granted and used by a whole industry, at that time, I didn’t dare to think CRDs would play the role they play today in the cloud native landscape, lifting so many products off the ground and leading to a flourishing ecosystem.</p><h2>So Why Upbound?</h2><p>There is the immediate, more superficial and obvious answer: Upbound is heavily basing all product offerings, and with that the future of the company, on CRDs — trying to use the established kube-apiserver as a foundation to build an orchestration system that goes beyond just containers.</p><p>There is a deeper motivation though. There is a strong alignment of vision. A former colleague of mine, Derek Carr, Senior Distinguished Engineer at Red Hat, wrote in an old promotion doc about me:</p><blockquote><p>“[...] at his core, Stefan wants to build platforms for others to leverage”.</p></blockquote><p>Derek is right. My passion is and always has been building platforms. Clearly, this led me into Kubernetes in the first place and made me stay in that project for 8 years by now, still excited by what we have built and what we are building for the future.</p><h2>Platforms, Platforms Everywhere</h2><p>Kubernetes is a platform for container-based workload orchestration.</p><p>Yet, the ecosystem has not found a similar, unified platform beyond that. Outside of the actual container workloads, the world is fragmented. Cloud management is fragmented. Hybrid Cloud is a reality for many enterprises. But Hybrid Cloud is hard, very hard. <a href="https://www.crossplane.io/" target="_blank">Crossplane</a> has a giant potential role to play in unifying how cloud resources are managed, across the cloud and with the learnings from Kubernetes.</p><p>No non-trivial application consists of containers alone. There is nearly always infrastructure around it that must be deployed. Be it the Kubernetes cluster itself to run on, but also other resources like databases, S3 storage buckets or monitoring infrastructure. That’s where Crossplane shines.</p><p>The <a href="https://community.cncf.io/tag-app-delivery/" target="_blank">TAG App Delivery working group</a> has been working on <a href="https://tag-app-delivery.cncf.io/whitepapers/platforms/" target="_blank">a whitepaper to define what we mean by a platform built using tools in the CNCF landscape</a>. Crossplane is at the core of that definition, a tool to provide resources and environments for applications.</p><p>The term of an Internal Developer Platform (IDP), as the CNCF whitepaper describes it, is gaining a lot of momentum currently in the community. Everybody talks about IDPs. Every larger organization wants to have an IDP. KubeCon talks have long queues in front of the rooms when people talk about IDPs. This seems to be the next kind of platform thing everybody is rallying around. Maybe it will lead to a de-facto standard platform architecture beyond containers, beyond Kube. Exciting times.</p><h2>Platforms and Portals and Control Planes</h2><p>An IDP inherently contains a user interface — to developers using the platform and the admins operating the platform. With Backstage a prominent Developer Portal is developed in the open, originally donated by Spotify to the community. Backstage is a portal to visualize existing systems, integrate different tools and kick off the creation of new system environments. A portal alone is not enough though, nicely summarized by my former colleague and TAG App Delivery chair <a href="https://blog.joshgav.com/posts/kubecon-amsterdam" target="_blank">Josh Gavant in his blog</a>:</p><blockquote><p>“Customers asking for portals really want a portal <i>with</i> a backing platform”.</p></blockquote><p>What is a backing platform? It’s that thing that orchestrates the environments and applications visible in the portal. It stores their existence, tracks related resources, and orchestrates their life-cycle behind the UI of the portal. This sounds a whole lot like what Kubernetes does for container deployments. But environments and applications are more than just container deployments. This closes the loop where Crossplane can shine as a machinery to orchestrate all the resources on-prem and in the cloud in a unified way, leading to control planes that are more than just for containers, but to control planes that are universal and scalable for the future ahead.</p><p>When I met with Bassam, Upbound’s CEO, at KubeCon Valencia in April 2022, it was obvious to both of us that we speak the same language. Bassam was trying to pitch what they were doing, and I was pitching the work on <a href="https://github.com/kcp-dev/kcp" target="_blank">kcp</a>, why we were building it and why control planes are the future. We were saying essentially the same things. We kept in touch and have been talking ever since up to today.</p><p>Hence, I am super excited to finally join Bassam with Upbound on the mission of democratizing control planes beyond containers. The opportunities ahead are huge. Upbound has formed an awesome team. Upbound originally started off from Seattle, but by now spread over many countries and time zones, building a remote first company. I am beyond excited and happy to be here and part of that journey.</p><p><a href="https://slack.crossplane.io/" target="_blank">Join me and the community in the Crossplane Slack</a>.</p><p>If you want to see how we are accomplishing this mission of democratizing control planes, you can try it out for yourself in a <a href="https://upbound.io/register?ref=blog.upbound.io" target="_blank">free trial of our latest product</a>.</p><p>Thank you.</p>

Why I Joined Upbound: Democratizing Control Planes – Beyond Containers

<p>Another KubeCon + CloudNativeCon is now in the books, and<a href="https://www.linkedin.com/feed/update/urn:li:activity:7056990954842443776" target="_blank"> we’re still feeling the energy</a> from the sights and sounds of Amsterdam and another successful cloud native conference. As the excitement starts to wind down, and we successfully found our way out of the labyrinthine halls of the RAI (has there ever been a more confusing KubeCon venue to navigate?), we wanted to take a minute to reflect on what we learned and experienced, especially compared to KubeCons of years past.</p>

<h2>KubeCon Attendees ❤️ Crossplane</h2><p>As the creators of the <a href="https://www.crossplane.io/" target="_blank">Crossplane</a> project, we are always thrilled to see the enthusiasm and engagement from attendees at each KubeCon. There was never a dull moment in the Solutions Showcase, as traffic to the Upbound and Crossplane booths was always flowing. We continuously had people coming up to us and asking something similar to “I keep seeing and hearing Crossplane everywhere - please tell me more about it!”, which we can assure you we’ll never get tired of hearing. While this excitement is nothing new compared to previous KubeCons, we did notice there were more folks approaching us this year that were already well familiar with Crossplane’s vision. We’re confident some of the “what is this Crossplane I keep hearing about” folks from Detroit are now well into their adoption journey with Crossplane and have already become valued members of the community. If you’re still curious to learn what Crossplane does and why it’s valuable, we encourage you to check out this post we recently authored for the <a href="https://thenewstack.io/crossplane-what-most-people-get-wrong-and-how-to-get-it-right/" target="_blank">New Stack</a>.</p>

<h2>It’s so Good to Connect in Person</h2><p>We presented more sessions and talks in Amsterdam than at any previous KubeCon. The most recent addition to our stable of sessions was the Crossplane <a href="https://sched.co/1Hzcf" target="_blank">Contribfest</a>, where developers interested in becoming contributors gathered together for an interactive session with hands-on labs. By the end of the productive session, attendees had learned how to write, build, and test new code for Crossplane as well as write their own <a href="https://docs.crossplane.io/knowledge-base/guides/composition-functions/" target="_blank">Composition Functions</a>. We are looking forward to the developers that joined the Contribfest to continue participating as contributors to the project, and even becoming deeply involved to the point of joining the <a href="https://github.com/crossplane/crossplane/blob/master/GOVERNANCE.md#becoming-a-maintainer" target="_blank">maintainer team</a> as well! A great place to start getting more active in the project is our <a href="https://slack.crossplane.io/" target="_blank">Crossplane Slack</a>, as well as the code base and issue backlog in the <a href="https://github.com/crossplane" target="_blank">Crossplane GitHub</a>.</p><p>We also hosted a very successful <a href="https://sched.co/1HySE" target="_blank">Maintainer Track talk</a> that had more than 1,000 registered attendees. These talks are always really interesting because they combine an introduction to the project along with a deep dive into some of its advanced concepts and architecture, so there’s something for all levels of experience with Crossplane. During this talk, we gave three separate live demos that covered the most exciting and highly demanded new features, and we hope attendees left the session inspired to accomplish new scenarios with their Crossplane powered platforms.</p><p>In addition to the ContribFest and Maintainer Track sessions, we also took advantage of all the opportunities to connect with the community in the CNCF Project Pavilion, with Upbound customers at our booth in the Solutions Showcase, and a select set of top contributors to the Crossplane project for a special appreciation dinner at <a href="https://brouwerijtroost.nl/depijp-amsterdam/" target="_blank">Brouwerij Troost De Pijp</a>. It was such a fantastic week connecting with old friends and building great new relationships!</p><h2>Everyone was Wondering…</h2><p>From the myriad of conversations during the week, we heard some common questions that folks were frequently asking. Let’s review these questions and dive into some answers here.</p><h4>“I’m already using Terraform, but Crossplane looks awesome! How can I start using it?”</h4><p>Lots of Crossplane adopters have (or have had) Terraform in their environment, and it’s totally reasonable to run both within your environment at the same time - it’s not an all or nothing proposition with Crossplane. There are a few strategies for adopting Crossplane in a phased approach over time that are worth reading more about in this resource for <a href="https://resources.upbound.io/all-content/optimizing-terraform-with-crossplane?ref=blog.upbound.io" target="_blank">optimizing Terraform with Crossplane</a>.</p><h4>“All the CRDs that Crossplane installs impact the performance of my cluster, what can I do?”</h4><p>This is priority number one in the Crossplane <a href="https://github.com/crossplane/crossplane#roadmap" target="_blank">roadmap</a> right now. Kubernetes was designed with some key scaling properties in mind, but unfortunately the number of CRDs was not one of them. We’re attacking this issue from two major fronts: We’ve already made a handful of fixes to upstream Kubernetes to start scaling the supported number of CRDs in general, and we are rapidly executing on a plan within Crossplane to <a href="https://github.com/crossplane/crossplane/blob/master/design/design-doc-smaller-providers.md" target="_blank">install only the CRD groups</a> that are important to you. These parallel efforts should greatly improve the control plane performance soon, so we appreciate all the feedback and patience while we thoughtfully roll these out.</p><h4>“What do I use to provision a cluster for Crossplane, is this a chicken and egg problem?”</h4><p>Crossplane has very few requirements to get up and running, so one simple approach here is to create a cheap and ephemeral bootstrapping cluster, for example <a href="https://kind.sigs.k8s.io/" target="_blank">kind</a>, and leverage that to provision your long term Crossplane instance. Viktor Farcic did a great video on this that can be found on the <a href="https://youtu.be/IlaYGgyg06o" target="_blank">Upbound YouTube channel</a>. An even easier approach though would be to offload this problem entirely, including the full spectrum of operational burdens and concerns, to the experts at Upbound by taking advantage of our latest product, Upbound, which hosts <a href="https://www.upbound.io/product/upbound" target="_blank">managed control planes</a>.</p>

<h2>Looking Forward to Chicago</h2><p>The cycle for the next KubeCon + CloudNativeCon in <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" target="_blank">Chicago</a> is already ramping up, as the <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/program/cfp/" target="_blank">Call for Proposals</a> is now officially open. It won’t be long before we’re all together again and we are definitely looking forward to it. What’s not to love about Chicago? With its characteristic <a href="https://en.wikipedia.org/wiki/Chicago-style_pizza" target="_blank">deep-dish pizza</a>, marvelous <a href="https://en.wikipedia.org/wiki/Architecture_of_Chicago" target="_blank">architecture</a>, and hilarious <a href="https://www.secondcity.com/" target="_blank">comedy scene</a>, we know it will be a fabulous week together. Just keep thinking warm thoughts for the week until then!<br>&nbsp;</p><p>We will submit proposals for multiple talks about Crossplane and cloud native control plane concepts, so we hope to have many opportunities to connect with you all again at the booths and Crossplane sessions. We’re always eager to support the community in submitting ideas of their own, so feel free to share your ideas in the <a href="https://slack.crossplane.io/" target="_blank">Crossplane Slack</a> or reach out directly to Jared (<a href="https://crossplane.slack.com/archives/DEFND2TS8" target="_blank">@jbw976</a>) for feedback on any proposals you are thinking about. &nbsp;Finally, we have exciting ideas for how to continue evolving the next Contribfest and keep investing in our amazing Crossplane community, so get ready to write more code together!</p><h2>What’s Next?</h2><p>In the meantime, if you’re curious about Upbound and what we can offer, we invite you to 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>, and we’ll see you in <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/" target="_blank">Chicago</a>!</p>

Wrapping Up KubeCon + CloudNativeCon Amsterdam & Looking Ahead

<p>Hi, my name is Oren Teich. I'm joining Upbound as our Chief Product Officer (CPO). I've been working in this space one way or another for a <i>long</i> time. For 4 years I ran product management for all developer products at Google Cloud, where I created<a href="https://cloud.google.com/run" target="_blank"> Cloud Run</a> and oversaw 35 other products. I founded a real-time note taking app for nerds<a href="https://www.youtube.com/watch?v=3RHQd4b1iPA" target="_blank"> this youtube demo</a> acquired by Google. Before that I joined Heroku as the 9th employee and first product hire. We did $1,100 revenue in the first month I joined. I wound up running all of Heroku post Salesforce acquisition, leaving at 130 people and &gt;$3M/month revenue. I've worked at Sun (twice), embedded Linux companies, and dang… this list is making me feel old.</p><p>Upbound is a unique opportunity and company. I'm incredibly excited to be joining. Upbound stands out for 3 big reasons to me:</p><ul><li>Market opportunity</li><li>Riding a huge wave</li><li>Proxy model</li></ul>

<h2>Market Opportunity</h2><p>As much as I loved Heroku, an unhealthy amount, PaaS products keep hitting the same issue. "If you can't run everything you won't run anything." Standalone PaaS always struggle because of what they can't do. Even though they might solve 100% of a customers’ problems today, there's always a theoretical future situation where the PaaS might not have coverage. Real or not, those edge cases require that customers have a reasonable escape valve. For a true stand-alone platform like Heroku, this meant that jumping to AWS was the only option. Once you've started moving one piece to AWS, why not move everything? Having one thing on AWS requires you to understand the hard parts—IAM, VPC, etc. The actual service itself is usually pretty easy.</p><p>Cloud providers are a bit better positioned—Lambda or Cloud Run can solve specific problems, come integrated with the platform concepts like identity, and can offer reasonable off-ramps such as migrating the workload to a GKE cluster. But they still have a flavor of this problem. Lots of customers still want something different from what a more managed offering has, and an 'all or nothing' product often means nothing.</p><p>Companies have been trying to build their own internal development platforms for decades. Cloud Foundry was explicitly created in 2011 to enable companies to build their own 'internal Heroku'. BEA in the 90's. What's different now?</p><p>Cloud is everywhere, K8S has become a universal runtime (for better or worse), and declarative configuration/reconciliation is a really different model. That all leads into the next reason why I joined Upbound.</p><h2>Riding a Huge Wave</h2><p>No company stands alone. Despite not surfing, I think about companies in a surfing analogy—you need a great rider, with a good surfboard, and you need the right waves. Cloud + K8S is the wave we're riding. And it's a<a href="https://www.youtube.com/watch?v=QBVt8pzjnL8" target="_blank"> big one</a>. The explosion of innovation in every area, from policy management, sidecars, GitOps, etc means a huge opportunity to help wrangle the mess.</p><p>We also need to go where the money is.<a href="https://thenewkingmakers.com/" target="_blank"> Developers are kingmakers</a>, but they aren't moneymakers. Getting a company to spend $250K/year (or $2.5M/year) isn't a choice an individual developer makes. K8S and its ecosystem is flourishing partially because it plays to company org dynamics. It recognizes that these decisions are complicated ones and empowers the complicated needs organizations have.</p><p>Unbounded complexity leads to exhaustion and failure over time. A standard model for dealing with overly complicated systems is:</p><h2>Proxy Model</h2><p>There are only a few models for making money. You can 'put an API on it', and you end up with Stripe or Twilio. You can 'make it mobile' or 'make it cloud', and end up with Salesforce and enterprise SaaS , while my favorite model is 'put a proxy on it'. When you have technically complicated problems, putting a proxy in front of that complexity unlocks entirely new modes of operation and use cases. See Cloudflare, or Tailscale, and now Upbound.</p><p>At Heroku it became a running joke that almost anytime we had an insurmountable problem, the answer wound up being a proxy. How do we collect logs from distributed dynos? A proxy. How do we deal with postgres failover? A proxy. How do we horizontally scale apps? A proxy.</p><p>Upbound is positioned to redefine how platform teams build their offerings by creating a new abstraction layer. We can help these teams hide the complexity where possible, build their own new things that aren’t possible today without Upbound, and enable the complicated challenges enterprise companies face without compromising the experience individuals value in getting real work done.</p><h3>Thank You</h3><p>Upbound is perfectly positioned on all 3 of these fronts. We have a huge market opportunity, a huge wave, and we're doing it in a way technically that I love. Combine that with amazing OSS traction and &nbsp;great team—it's a job I am immensely excited about and grateful for.</p>

Why I Joined Upbound

<h2>A reflection on leadership values and perpetual learning</h2><p>The Engineer/Manager Pendulum is a concept that Charity Majors <a href="https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/" target="_blank">popularized in 2017</a> and has since become a pillar of many career development philosophies in tech. It recognizes the immense breadth and depth required to achieve excellence at being an engineer <i><strong>and</strong></i> a manager. It also posits that we can build competency in both by going back and forth between them throughout our careers without sacrificing development.</p><p>This year, I took time to reflect on how I ended up swinging on this pendulum and why I chose to follow my current arc with Upbound. While there is already a lot of excellent writing on these topics that I’ll reference throughout, I hope sharing my experience sheds some light on Upbound’s leadership values through authentic introspection.</p><h2>I wanted to be an engineer forever</h2><p>Let’s get this out of the way: I’m relatively early in my engineering management journey. One of the first things I told my manager at Upbound was that I was riding the E/M pendulum, and wanted to give this management thing a fair shake because I feel I’d only scratched the surface. He knew exactly what I meant.</p><p>Like many others, I was at a fork in the road as a technical lead a few years ago. I loved what I was doing and wanted to find the limits of my learning ability in a deeply specialized field. I also had some incredible role models of leadership that created the space for me to grow in the first place, and I wanted to learn how to pay that forward.</p><p>The more I expanded my network, the more I found myself increasingly far from being the smartest person in the room (I already never was to begin with). I noticed we succeeded as a team less when I made the right decision individually, but more when I entrusted the decision to the right individual.</p><p>This mode of operation clicked quickly: &nbsp;I could scale it effectively by building our teams to work together instead of becoming heroes, becoming self-regulating over time. It was one of the first times I had to <a href="https://ajstorm.medium.com/imposters-53feb3a6f440" target="_blank">embrace impostor syndrome</a> rather than fight it, beginning my first arc on the pendulum from Engineer to Manager. Simultaneously I jumped into a foreign land called the cloud-native ecosystem during one of the peaks of my career.</p>

<h2>Learning to engage as a manager</h2><p><i>“Should managers be in the codebase?”</i></p><p>This question shouldn’t get asked as often as it does because it focuses on the wrong thing.</p><p>A common rationale is that healthy, well-composed engineering teams have enough aggregate experience to become autonomous. It creates space for managers to focus on execution, process, and career coaching and naturally makes them more in tune with the team’s core needs. You avoid the failure mode of overly-opinionated managers that risk disempowering engineers by controlling technical decisions, which can make or break teams.</p><p>The converse argument says that one of the most effective ways to build empathy for your team is through technical fluency. When engineers make difficult things look easy, we need to recognize it. We wouldn’t be able to do that if our skills were monotonically decaying.</p><p>Trying to process both lines of reasoning can be paralyzing to a new manager as they both have merit in theory. Did I choose the wrong path? Have I “frozen” my pendulum?</p><p>What if we changed the question to “<i>how should managers engage with engineers?”</i></p><p>We would have to look at each engineer’s personal preferences, the things they value most, and what growth means to them as an individual. Fortunately, we have some excellent <a href="https://larahogan.me/blog/first-one-on-one-questions/" target="_blank">resources</a> to equip us. We can develop their careers or partner with them meaningfully without resorting to arbitrary changes in the scope of their role or their preferred mode of operation. In our case, it was curating self-reflection exercises to determine what sponsorship opportunities we could create for them. Other times, it was joining the production on-call rotation when a team member was overextended. Perhaps my most memorable time seeing this in practice was watching a Twitch live stream where I learned about some of <a href="http://crossplane.io/" target="_blank">Crossplane’s</a> build machinery and then applied that new knowledge to help onboard some community repositories to our <a href="https://blog.upbound.io/__GHOST_URL__/marketplace-launch-announcement/">Upbound Marketplace</a>.</p><p>Engaging with engineers means immersing yourself in the culture, and sharing in both the joy and the pain. It doesn't capture the full scope of what we do and isn't terribly precise, but it provides intuition enough about how to build genuine relationships, and for some of us, how to keep our pendulums in motion.</p><h3>The engineering manager at Upbound is a partner</h3><p>Without avoiding the original question, every engineering manager at Upbound so far has contributed or reviewed code. These contributions:</p><ol><li>Made something better for the team without the team relying on it happening.</li><li>Reduced stress for a team member.</li><li>Go through the same lens of scrutiny just like any other contribution.</li></ol><p>This doesn’t mean Upbound will now create a policy that engineering managers must be involved this way— you won’t see this in a job description. It just means that we chose to engage the team in that capacity and did so in specific situations where we were in a unique position to help. The path to doing that work began with a question: “<i>Would this be helpful to you / the team?” </i>“<i>Yes! I was actually pretty stressed out about that.”—</i>that’s a clear response. Sometimes, the answer is a simple no. We learn to adjust to this stream of observations over time and as team membership fluctuates.</p><p>Engineering managers at Upbound are partners. The relationship we strive to have with others requires <a href="https://docs.google.com/document/d/16hCEaKM0NQFTF6ri0xa0tBxyNu0Pppj6ZRM7XYFNs9k/edit" target="_blank">decisive collaboration</a> founded on trust but expects us to challenge each other candidly. Engineers are not our implementers, and product managers are not our backlog prioritizers. We learn from them just as they learn from us, and learning happens when we can assume a default position that our perspective may be wrong.</p><h2>Learning creates the perpetual motion of the pendulum</h2><p>The concept of the pendulum I share most with others at a similar crossroads is that it <i><strong>isn’t an irreversible decision</strong></i>, even in <a href="https://stackoverflow.blog/2022/02/04/moving-from-ceo-back-to-ic-a-chat-with-mitchell-hashimoto-on-his-love-for-code-ep-412/" target="_blank">exceptional cases</a>. That’s part of the beauty of leadership roles: there’s no universal recipe to succeed at them. Even reflecting on our leaders here at Upbound with similar roles and job levels, no two are alike. Yet, they are all incredibly effective at what they do. From my manager, I’ve learned how to strengthen my frameworks on team composition and how to develop market intelligence. From our principal engineers and OSS maintainers, I’ve learned to be a better writer and gained a new appreciation for formal specifications and community dynamics. From the squads I am a member of, I’ve seen how each new perspective could be the next catalyst for innovation. All these experiences don’t tell me where I’ll hop off the pendulum next, but they keep it in motion through constant exposure to learning opportunities.</p><p>If I’m honest, I don’t have many original facets in my management philosophy - it is a mashup of role models that I have been fortunate enough to know both past and present. Will I get off the pendulum after this Manager arc, or swing back to Engineer? Only time will tell, but I no longer need to manipulate its path.</p><h2>Interested in Upbound?</h2><p>If my experiences resonate with you, consider joining our team. Not only do we <a href="https://docs.google.com/document/d/16hCEaKM0NQFTF6ri0xa0tBxyNu0Pppj6ZRM7XYFNs9k/edit" target="_blank">uphold the values</a> we hold all of our members to, but we go past them to build a cohesive environment— even while fully remote. <a href="https://grnh.se/54d95d844us" target="_blank">We have various roles open for you to explore.</a><br><br>&nbsp;</p>

Riding the Pendulum

<h2>Building the Upbound Marketplace to Run Anywhere.</h2><p>When we set out to build the <a href="https://marketplace.upbound.io/" target="_blank">Upbound Marketplace</a>, we knew the functionality it offered would be useful in a variety of contexts. With that in mind, we architected a system that could fit into existing customer environments while still being able to scale to handle large amounts of traffic from the Crossplane community, which <a href="https://crossplane.devstats.cncf.io/d/74/contributions-chart?orgId=1&amp;var-period=d7&amp;var-metric=contributions&amp;var-repogroup_name=All&amp;var-country_name=All&amp;var-company_name=All&amp;var-company=all&amp;from=now-4y&amp;to=now-2d" target="_blank">continues to grow at an impressive rate</a>. Today we are going to take a deeper look at some of our design decisions, explore how they were implemented, and talk about the places we can go from here.</p><h2>Just an OCI Image</h2><p>One of the decisions we made early on in the Crossplane ecosystem was to standardize on OCI images for package distribution. This choice has paid dividends as we continue to leverage the features offered by the <a href="https://github.com/opencontainers/image-spec" target="_blank">image</a> and <a href="https://github.com/opencontainers/distribution-spec" target="_blank">distribution</a> specifications. One of the immediate benefits it offered was access: nearly every Crossplane user had access to a registry, and tooling to interact with them generically.</p><p>The generic aspect is not to be overlooked. When Crossplane packages were first being designed we considered leveraging <a href="https://github.com/opencontainers/image-spec/blob/main/artifact.md" target="_blank">OCI artifacts</a>, which were in their early stages of development, as a solution. However, <a href="https://www.docker.com/blog/announcing-docker-hub-oci-artifacts-support/" target="_blank">until recently</a>, some registries did not support artifacts and some only supported some subset of them. In contrast, every registry implementation we have heard of Crossplane users interacting with has supported Crossplane packages from day one because they are <i>just OCI images</i>.</p><blockquote><p>Thanks to the tremendous efforts of working groups in the OCI organization, much progress has been made around the standardization of artifacts, as well as the more recently introduced <a href="https://github.com/opencontainers/image-spec/pull/934" target="_blank">reference types</a>. We are excited to explore how this work may be leveraged in the Crossplane community and the Upbound Marketplace in the future.</p></blockquote><p>Making this decision wasn’t without a cost. Namely, we needed to be explicit about how Crossplane packages bundled as OCI images would be processed by any conformant Crossplane distributions. Like many open source projects, Crossplane is both an API specification and a reference implementation. Downstream distributions, such as <a href="https://github.com/upbound/universal-crossplane" target="_blank">Upbound Universal Crossplane (UXP)</a>, must handle Crossplane packages in a uniform manner. To enable this, the <a href="https://crossplane.io/docs/v1.10/reference/xpkg.html" target="_blank">xpkg specification</a> was proposed and ratified.</p>

<p>Defining a dedicated standard in the context of OCI images allowed for some creative optimizations and extension points. For example, Crossplane Provider packages include both YAML content, which is processed by the Crossplane package manager, and controller binaries which ultimately get run as a container on a node in the cluster. Typically, the binary and supporting content is much larger than the YAML content, and because Crossplane only needs to consider the latter, a convention has been established to store the YAML content in a dedicated layer, which is annotated in the image manifest. Crossplane first fetches the manifest, and if any layer is annotated with <code>io.crossplane.xpkg: base</code> only that layer is fetched and processed.</p><p>The xpkg specification also defines extension points that can be optionally honored by third-party systems. Extensions can be useful if a given Crossplane distribution or registry wants to add custom functionality to packages. Defining extensions within the bounds of the OCI image specification decouples image storage and distribution from other features that may enrich the package management experience. This model provides the foundation for the Upbound Marketplace. If we take a look at the manifest for <a href="https://marketplace.upbound.io/providers/upbound/provider-aws" target="_blank">Upbound’s Official AWS Provider</a>, we’ll notice not only the <code>base</code> layer, but also a layer annotated as <code>upbound</code>:</p>

<p>This layer is not considered by the Crossplane package manager, but includes data that can enrich the Upbound Marketplace experience. In this case, the layer contains a YAML stream of examples that are processed when packages are pushed. <strong>The secret behind the Upbound Marketplace is that it is not an OCI registry at all (per se), but rather a proxy that sits in front of any OCI registry</strong>. This proxy is internally named <code>shimmer</code> – it is a registry shim that implements the OCI distribution specification but doesn’t handle storing blobs or manifests, it simply passes them along to another registry.</p><h2>Bring Your Own Registry</h2><p>This architecture provides a number of advantages. Perhaps the greatest benefit is that it, in tandem with Crossplane’s package specification, allows for flexibility in what registry is used to actually store and serve any given image. This is useful internally as we can easily migrate from one registry to another, or, even more interestingly, proxying across multiple registries. For example, for packages used internally at Upbound we may opt to proxy the images to the registry offered by the cloud provider where our services are running, while for some customers we may proxy to a registry running in a specific geographic region. Similarly, Upbound customers who operate in an air-gapped or heavily regulated environment could deploy an on-prem version of the Upbound Marketplace in front of their own internal registry, allowing them to experience all the benefits of automatic documentation, discovery, and searchability, without compromising on compliance.</p>

<p>When packages pass through <code>shimmer</code>, in addition to deciding where to direct them, <code>shimmer</code> enqueues the image for parsing and indexing. Much like Crossplane’s package manager, <code>shimmer</code>’s indexer only fetches the layers that it needs. In this case, the base layer is required to serve documentation about the package and the API types it offers, while the upbound layer provides additional content that is only relevant in the context of the Upbound Marketplace. In other words, a package may support extensions for many different consumers, without increasing the overhead for any one consumer to process just the bits that they care about.</p><p>An alternative model to the <code>shimmer</code> proxy approach would be to utilize webhook functionality <a href="https://docs.docker.com/registry/notifications/" target="_blank">supported by some existing OCI distribution implementations</a>. However, doing so would both eliminate guaranteed compatibility across all implementations (i.e. webhooks are not part of the OCI distribution specification), and restrict introducing custom behavior when pulling a package. Up to this point we have primarily been concerned with validating and indexing content from packages that are already formatted as OCI images, but sitting in between the client and some registry means that what happens when a user pulls can vary widely. In fact, an “underlying image” doesn’t even have to exist as long as content is returned to the user in a manner conformant with the distribution specification. This opens up some interesting possibilities, such as just-in-time (JIT) package building from source on pull… but that’s a post for another day.</p><h2>Expanding the Use of Content Addressability</h2><p>Much is made of the benefits of leveraging content addressability, the practice of referencing a set of data by the digest of its content, to <a href="https://youtu.be/Ve_CFyVYo3M" target="_blank">improve security posture</a>. However, two of the other major benefits of such a system are <strong>storage</strong> and <strong>caching</strong>. When data is stored with a content addressable identifier, subsequent uploads of the same data does not result in occupying twice the storage space. Instead the system will simply add another reference to the existing data.</p><blockquote><p>Some systems will only partially deduplicate storage. For example, a multi-tenant service may only deduplicate data within the context of a single tenant.</p></blockquote><p>While avoiding storing the same data twice is all about space, caching is all about speed. You have likely experienced the benefits of caching content addressable data if you have ever attempted to docker pull the same image twice. If you haven’t give it a try right now:</p>

<p>The second pull was drastically faster because we already had all of the layers cached. How did we know that? The client, in this case Docker, fetched the manifest associated with the <code>v0.20.0</code> for <code>xpkg.upbound.io/upbound/provider-aws</code>, and because all of its layers were identified by the hash of their content, the client can evaluate against the locally stored content.</p><blockquote><p>In reality, evaluating whether local content is up to date can be performed even more quickly by caching the manifest and checking whether its digest has changed via a <code>HEAD</code> request.</p></blockquote><p>The behavior of the Upbound Marketplace is not so different from that of an OCI registry. It ingests content (Kubernetes manifests) and serves it to a wide variety of consumers via client applications (browsers). Much like a registry doesn’t want to store unchanged layers every time a new version of an image is pushed, we do not want to store the same manifests used to generate documentation every time a new package is pushed and indexed. To avoid doing so, <code>shimmer</code> stores manifests by digest, and generates a document that somewhat resembles an image manifest for each package version. For example, the resource manifests for the previously referenced <a href="https://marketplace.upbound.io/providers/upbound/provider-aws/v0.20.0" target="_blank">upbound/provider-aws:v0.20.0</a> package can be observed <a href="https://api.upbound.io/v1/packages/upbound/provider-aws/v0.20.0/resources" target="_blank">here</a>, and the content of a single manifest, Certificate, can be viewed <a href="https://api.upbound.io/v1/packages/upbound/provider-aws/v0.12.0/resources/acm.aws.upbound.io/Certificate" target="_blank">here</a>.</p><p>The reduction in storage is also paired with the ability to perform aggressive caching in many cases. Perhaps the best example of this is the written documentation you see when visiting one of the <a href="https://blog.upbound.io/__GHOST_URL__/first-official-providers/">Official Provider</a> pages. While currently an alpha feature, we intend to support providing documentation for any package in the Marketplace, once again leveraging the Crossplane package extension model to do so. The existing documentation is fairly lightweight, but the service is designed to support serving more extensive content, once again by leveraging content addressable storage.</p>

<p>The documentation is especially interesting because the Marketplace is built on <a href="https://nextjs.org/" target="_blank">Next</a>, allowing us to Server-Side Render (SSR) most pages for efficient search engine indexing. However, with potentially large content, such as documentation and its supporting assets, we don’t want to load all of it up front and we want to fetch it as infrequently as possible. To achieve both of those goals, documentation is served from a content addressable URL on a Content Delivery Network (CDN) and fetched client-side. This enables caching the content both at the edge node of the CDN (i.e. a server close to the user) and in the browser itself. Invalidation is straightforward as the documentation index is rendered server-side, meaning that any change in documentation content will be reflected by a new content-addressable URL being supplied to the client. If that URL has been accessed before by the client, it may still be in the browser cache. If it has been accessed by another user in the region it may be cached at the edge node. Making a full round-trip to the origin server becomes an infrequent operation.</p><h2>Where We Are Going</h2><p>So where do we go from here? Ultimately, that is up to you! We are excited about continuing to build on the foundational architecture of the Upbound Marketplace. Features such as automatic identification of breaking API changes from one package version to another, searching by API types, and enhanced package consumption metrics are all enabled by the design decisions outlined in this post. If these features, or any others, are top of mind for you, make sure to <a href="https://accounts.upbound.io/register" target="_blank">create an Upbound account today</a> and <a href="https://upbound.io/contact" target="_blank">drop us a note</a>. If you love writing and reading design documents, working on complex multi-tenant systems, and building highly scalable services used by platform builders all over the world, <a href="https://boards.greenhouse.io/upbound" target="_blank">check out our open roles</a>!</p>

My Other Registry is a Proxy

<p>The short answer is that I dream of a world where there is 'One Cloud to Rule Them All' and a single Cloud API for everything. The real answer is a bit more involved. <a href="https://upbound.io/">Upbound</a>, the Enterprise Company behind <a href="https://crossplane.io/" target="_blank" rel="noopener noreferrer">Crossplane</a>, is solving a problem that has existed internally at every company I've worked at for the past twenty years. I believe it is time for the industry to finally rally around a standard way of building internal platforms for their developers to build, deploy, and operate their services.</p><blockquote><p>Wait, What?</p></blockquote><p>I join companies that have products that solve real problems. The fact that platform engineers keep building internal platforms with similar functionality at thousands of companies has always struck a chord with me. Engineers should focus on delivering value that will accelerate the business' core competency versus yet another set of cloud APIs, developer dashboards, build &amp; test pipelines, provisioning tools, and the hacky shell scripts to glue it all together.</p><p>Six years ago, I wrote a blog post simply titled '<a href="https://medium.com/@sumbry/the-curious-case-of-linux-containers-328e2adc12a2" target="_blank" rel="noopener noreferrer">The Curious Case of Linux Containers.</a>' It sparked a considerable amount of online commentary, landed me several speaking engagements, and even had the subsequent <a href="https://news.ycombinator.com/item?id=10677693" target="_blank" rel="noopener noreferrer">Hackernews thread</a>. Containers were gaining popularity, but my hypothesis was they alone were not enough to solve the problem. Containers are an implementation detail and only step one of a thousand in building a full-featured platform.</p><p>Crossplane is the other 999 steps and moves beyond container orchestration and management. It leverages Kubernetes and the power of its control plane, extensive open source cloud provider coverage, and custom resource definitions to easily compose infrastructure into a custom platform for your engineers. And you can do it in under a day.</p><p>It doesn't just stop there because now that you can represent anything with an API as a resource, Crossplane lets you compose complex multi-cloud and SaaS configurations and manage them as simple as the equivalent <strong>apt-get</strong> install. Thomas Watson famously said he thought there was market potential for maybe five computers. Crossplane can make that a reality and reduce the cloud into a single interface.</p><p>Now Product Vision wasn't the only thing that brought me to Upbound, but it was a tremendous driving force. There are four criteria that I use when evaluating opportunities and what allowed me to see how amazing this was:</p><ul><li>Strong Product &amp; Vision</li><li>Interesting Engineering Challenges &amp; Strong Team</li><li>Organization Growth &amp; Leadership Opportunities</li><li>Compensation Upside</li></ul><p>While I've already elaborated on Product &amp; Vision, I'm an engineer at heart. I started my career writing code and coming up with technical solutions to interesting problems. Even as I moved to engineering management, that urge did not disappear. The Crossplane open source project and Upbound's Enterprise Crossplane Distribution are two enormous opportunities to attack a pretty significant problem space across all clouds and from an engineering perspective we have only begun to scratch the surface.</p><p>We tend to learn the most when challenged, which is why it's so important to find companies and opportunities that have ample room and space for you to grow. An easy way to accomplish that is to join a fast-growing startup like Upbound. As we scale the company, there are so many exciting organization and technical challenges to solve, and it's one of the best ways to gain the knowledge, skills, and abilities to accelerate your career. &nbsp;This is especially true because you're working with a strong team of leaders, managers, and contributors from which you can learn and grow. The dividends of betting on yourself will always pay off over the long term.</p><p>This brings me to the last criteria in my evaluation framework, Compensation Upside. When you join a startup, you're taking on a considerable amount of risk, and if it pays off, you should be rewarded. &nbsp;Startup life means that the work you do will be more critical to the company's success and why I think this is a fair tradeoff and why the upside can be so significant. The upside is realized at many larger established companies already. You're gambling in a sense, but more on yourself and your team and your ability to execute. I'll take that bet, especially if the product fit is already there.</p><p>So here I am today. At a fantastic company with a great vision for its product, helping scale the engineering organization as we grow and tackle some exciting organizational and technical challenges with an enormous upside if we execute well.</p><p>The Upbound Vision is 'All Clouds under a Universal Cloud Platform,' and I get to be a part of making that happen.</p>

Why I Joined Upbound.

<p>Terraform is a widely deployed and popular technology that is used to enable an Infrastructure-as-Code (IaC) approach. While Terraform can be extremely useful, it does have some limitations that Crossplane can help organizations to overcome.</p><p>In the session <a href="https://www.youtube.com/watch?v=wRgQxfrFJYU&amp;list=PLj6h78yzYM2OFWBatWHbWgyoLNmCyAqJ0&amp;index=4&amp;t=7s" target="_blank" rel="noopener noreferrer">Outgrowing Terraform</a> at the Crossplane Community Day Europe event, Dalorion Johnson, software engineer at Guidewire and Nic Cope, principal software architect at Upbound detailed the challenges of scaling operations with Terraform and the opportunities presented by the Crossplane control plane approach. <a href="https://www.guidewire.com/" target="_blank" rel="noopener noreferrer">Guidewire Software</a> develops a Platform-as-a-Service (PaaS) for the Property and Casualty Insurance industry.</p><p>Johnson explained that prior to entering the PaaS market, Guidewire was largely engaged with providing an on-premises solution development process. She noted that the process used to develop complex software installations at Guidewire's customers' offices was not cost effective and did not scale very well. &nbsp;As such, Guidewire decided to make a shift to the cloud, using Terraform as a core component to help build its platform.</p><p>A core element of Terraform is the HashiCrop Configuration Language (HCL) that is a declarative language used for defining desired infrastructure state.</p><p>"We are now managing 73,000 lines of HCL so we're starting to feel the limitations of Terraform," Johnson said. "We've really been using the heck out of it."</p><h2>Limitations of Terraform – Drift</h2><p>One of the key challenges that Guidewire has faced with Terraform as it has scaled out usage is the issue of drift. That is, over time the actual state of a deployment varies or 'drifts' from the desired state as defined by HCL.</p><p>Johnson explained that Terraform defines Guidewire's resources with a set of files. Those files are not constantly being updated with what is actually running in production. In reality what that means is that over time drift can occur that isn't noticed or even reconciled until a new Terraform change is introduced and pushed out to the infrastructure.</p><p>Cope noted that like Terraform, Crossplane uses declarative configuration to define the desired state of infrastructure.</p><blockquote><p>"The big difference that Crossplane has is that it is an always-on control plane," Cope said. "Whereas the open source version of Terraform, at least, is a command line tool that is invoked on demand."</p></blockquote><p>Cope added that part of the problem is that terraform doesn't know to go check the world unless you ask it whether something has changed and that can lead to surprises.</p><p>&nbsp;</p><h2>Limitations of Terraform – Access Control</h2><p>Another key limitation that Guidewire has faced with Terraform is how access control is handled. Johnson detailed a complex layering of identity and access management (IAM) rules that her team needs to have to control infrastructure and tenant &nbsp;deployments.</p><blockquote><p>"We rely heavily on AWS to configure resources within our cluster," Johnson said. <strong>"Terraform has no concept of access control."</strong></p></blockquote><p>That limitation means that Johnson's team needs to be much more hands on to help enable deployments, than the self-service model that she'd much rather have. As such, instead of working on new features to expand the platform, Johnson and her team have to worry about a lot of special configurations to help enable access control.</p><p>Crossplane's approach to access control is very different, according to Cope.</p><p>"The nice thing is that in Crossplane, access control is framed around your business's concepts, not necessarily cloud concepts," Cope said.</p><p>Cope explained that with Crossplane, an administrator grants the control plane access to act on the administrator's behalf on any cloud or API that is called. The administrator then uses the integrated Role Based Access Control (RBAC) to restrict what people can ask Crossplane to do on their behalf.</p><h2>Limitation of Terraform: Cognitive Overhead</h2><p>Initially, Terraform was useful to Guidewire helping it to scale quickly when it was moving to a PaaS model.</p><p>Johnson noted that as the platform has grown, its usage of Terraform has become more complex and sophisticated. Terraform for Johnson has now become—just another thing that her organization has to maintain. It's a challenge that she referred to as—Cognitive Overhead.</p><p>Cope emphasized that with Crossplane the Cognitive Overhead can be reduced significantly. Since Crossplane makes use of Kubernetes, it uses many of the same tools and processes, enabling more efficiency for users—without the need to learn and maintain entirely new tools.</p><p>Guidewire is now taking its first steps in migrating to Crossplane, helping to optimize its PaaS and make it easier to develop and maintain.</p><p>"We are experiencing the freshness of this bleeding edge technology and the Crossplane community has been very responsive and very helpful," Johnson said.</p>