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

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

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

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

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

7 Core Elements of an Internal Developer Platform

<h2>Millennium bcp</h2><a href="https://www.upbound.io/why-upbound/customers/millennium-bcp" target="_blank">Millennium bcp</a> is Portugal’s largest private-sector bank, with 1,334 branches serving more than 6 million customers around the world. The key to its vision and success has been continued investment in the latest technologies to generate business value. The bank was among the first in its market to introduce ATMs and alternative payment methods, and one of the first to deploy early online services like transactional websites and an online financial marketplace.<h2>Crossplane</h2><a href="http://www.crossplane.io/" target="_blank">Crossplane</a> is a popular open-source project with the CNCF that leverages the Kubernetes API and control plane model to help organizations build internal cloud platforms managed with control planes. Because Crossplane shares a foundation with Kubernetes it integrates smoothly with most popular cloud native tools.<h2>The Problem</h2>Millennium bcp spent over five years building their automation practices into their platform, including Terraform modules, HCL code, and more. While they adhered to cutting-edge industry standards, challenges such as state drift and continuous compliance still persisted. Also, although infrastructure teams were able to efficiently execute the initial delivery of resources to other teams, internal customers were not seeing the same efficiency gains as infrastructure teams, as their requests were still being queued.<h2>The Solution (or Why Crossplane?)</h2>Millennium bcp wanted to mitigate their problems while incorporating the existing infrastructure they had. Rather than rip and replace, they wanted a technology that could work with the Terraform modules and other legacy code they already had implemented. They intended it to be a phased approach to solving their issues while maintaining the experience for their developers.Crossplane presented itself as a clear option for the prime solution. It helped eliminate state drift, apply continuous and automatic compliance, and improve their inefficiencies –&nbsp;all while leveraging the existing modules. The adoption of Universal Crossplane by Upbound as a control plane was implemented in a multi-stage approach without impact to the apps or developer experience.Millennium bcp went from an SLA of <a href="https://resources.upbound.io/all-content/portugals-largest-private-sector-bank-works-with-upbound-to-save-thousands-of-hours-a-year" target="_blank">8 days for project and dependencies setup to only a few minutes</a> for full deployment of an app and dependencies to a new environment, saving thousands of man-hours in production per year.<h2>Why Upbound</h2><a href="https://www.upbound.io/?ref=upbound-blog" target="_blank">Upbound</a> is the creator of Crossplane and the industry’s first platform for building internal cloud platforms. Designed around control planes, Upbound offers a new way for building internal cloud platforms, purpose-built for your organization. Customers can build, deploy, manage, secure, and use their platforms all from a single point of control.<h2>Upbound Product Value</h2><ul><li>Building Blocks with Operations. Crossplane is the perfect solution to build an internal cloud platform that increases efficiency and reduces configuration drift. Crossplane contains the logic, machinery, and reusable components that can be assembled to achieve your organization’s unique vision of efficiently and reliably delivering infrastructure and applications to production. You can think of this framework as the “building blocks” for creating specialized and customized platforms. Millennium bcp used Upbound’s official Terraform Provider and featured configurations like custom blueprints and reference platforms to power their internal cloud platform.</li><li>Self-Managed Control Planes. Crossplane is a framework for building Control Planes which enable organizations to consolidate teams onto a single platform. A control plane-based architecture gives you a declarative approach to defining and managing resources, continuous reconciliation of resources to eliminate configuration drift, and a pattern for achieving self-service. Millennium bcp leveraged the official Terraform provider to help streamline their platform to mitigate configuration drift, reduce human error in provisioning resources, improved compliance throughout the resource’s lifecycle, and more. It gave them flexibility to work with the infrastructure they had already built, helping to save time and effort in the migration.</li><li>Integration &amp; Migration Support. Millennium bcp loves that they can leverage existing Terraform modules while simultaneously helping them migrate toward a fully-powered Crossplane solution. On top of that, they rely on Upbound’s 24/7 support and assistance to implement enterprise-grade reference architectures and integrations for Crossplane. Universal Crossplane (UXP), the commercially supported distribution of Crossplane, runs anywhere — both on-premise and on any cloud solution. It can be installed into any cluster to expose Custom Resource Definitions (CRDs) and a standard API across your entire infrastructure and service providers.</li></ul><h2>Upbound Customer Support and Customer Success</h2>Upbound’s Customer Success team exists to deliver value to customers by engaging with them from the moment they sign on. Our regular alignment calls, private Slack channels, private GitHub repositories, and quarterly business reviews ensure we’re always in close communication, and that Upbound always has the correct context to help in the right ways, quickly. We provide architecture reviews, resource support, best practices, bespoke training, and setup and installation guidance. Why? We want to enable customers to swap their business pains with business value; to do everything they want to do with Upbound.Millennium bcp knew that with Upbound, they would see results quickly, and they would see results that grow and last over time.<h2>Summary</h2>Terraform has served as the industry standard to automate various processes to optimize platform infrastructure. However, with Crossplane providing Control Plane architecture, it’s time to shift the standard. Millennium bcp took a phased approach in migrating their infrastructure to Crossplane, all while leveraging the current Terraform modules they currently have. Their migration shortened their SLA time from 8 days to 8 minutes, saving thousands of hours and heavily reducing costs.<h2>Want to know more?</h2>Nuno, Cloud Compute Lead at Millennium bcp, <a href="https://resources.upbound.io/all-content/kubernetes-called-and-it-wants-your-iac-back-using-control-planes-to-modernize-your-iac-tech-stack" target="_blank">hopped onto a webinar with a few Upbounders</a> to explain the exact steps his organization took when implementing Upbound Universal Crossplane. In addition, he has put together everything you need to know in a <a href="https://resources.upbound.io/all-content/portugals-largest-private-sector-bank-works-with-upbound-to-save-thousands-of-hours-a-year" target="_blank">useful case study</a>. To see the solution above in further detail, be sure to visit <a href="https://www.upbound.io/why-upbound/customers/millennium-bcp" target="_blank">Millennium bcp’s detailed page on Upbound’s website here</a>.

Cloud Efficiency in Banking: Portugal’s Largest Private-Sector Bank Saves Thousands of Hours a Year with Crossplane & Upbound

Crossplane is a framework designed to streamline the orchestration and management of cloud and on-premise resources. Founded by Upbound and donated to the CNCF, Crossplane extends Kubernetes and introduces an approach to handling complex IT environments through a unified API and runtime. This article delves into the core functionalities of Crossplane. We believe it is a major part of simplifying cloud infrastructure management and is redefining Internal Development Platforms (IDPs). &nbsp;This article was <a href="https://www.itopstimes.com/itops/8-reasons-why-crossplane-is-the-ideal-engine-for-internal-developer-platforms/" target="_blank">originally published on ITOps Times here</a>.<h2>Crossplane: The Cloud-Native Control Plane Framework</h2>Crossplane is a Kubernetes-native framework that allows organizations to manage anything using a consistent API and runtime, making it an ideal foundation for Internal Development Platforms (IDPs).Organizations typically run a complex mix of cloud and on-premise resources like databases, virtual machines and network policies. IT teams must support multiple platforms to provision and manage resources, resulting in time-consuming manual processes or user-hostile and brittle home-grown systems. Using a control plane architecture, Crossplane allows any organization to run an internal self-service cloud platform with a standard API and runtime like the major cloud providers.Here are eight reasons why engineers building platforms should use Crossplane.<h2>1: Platform API</h2>One of the most important features of any platform is the API. Unfortunately, most infrastructure tooling is designed for engineers working on the command line. Crossplane is an API-first system, building upon Kubernetes Custom Resource Definitions (CRDs) to allow engineers building platforms to dynamically define new APIs called <a href="https://docs.crossplane.io/latest/concepts/composite-resource-definitions/" target="_blank">Composite Resource Definitions (XRDs)</a> that are available to end users.With Crossplane XRDs, platform engineers can easily create new APIs using an OpenAPIv3 schema. XRDs are Kubernetes objects just like Pods and Secrets. API fields can be validated using either OpenAPI data types or the <a href="https://kubernetes.io/docs/reference/using-api/cel/" target="_blank">Common Expression Language</a>. For example, an API designer can set a minimum and maximum number of cluster nodes, limit a serverType to “small”, “medium” or “large”, force a username to match a regular expression pattern, or set transition rules so that database sizes can only increase.XRDs can be created and updated by applying manifests to the cluster and are immediately available for consumption. Since XRDs are served from the Kubernetes API server, virtually all your existing Authentication, CI/CD, and Security tooling will work with XRDs out of the box. Crossplane deployments are often combined with tools like <a href="https://www.youtube.com/watch?v=SMlR12uwMLs" target="_blank">ArgoCD, Backstage and Kyverno</a>.<h2>2: Provision Anything With Providers</h2>Crossplane Providers are responsible for communicating to API endpoints. A Provider consists of a CRD for each Cloud API and a controller that manages resources. This architecture allows platform operators to select which resource types are supported for provisioning.To prevent drift, Providers reconcile Managed Resources continually, comparing them to the desired state and automatically resolving any differences found.In the <a href="https://marketplace.upbound.io/providers?collapseFamilies=true" target="_blank">Upbound Marketplace</a> alone, there are over 60 published providers, including the major cloud providers along with other services like ArgoCD, Aviatrix, GitLab, and New Relic. To ease migration to Crossplane, <a href="https://marketplace.upbound.io/providers/upbound/provider-terraform/v0.14.1" target="_blank">Provider-terraform</a> allows operators to run existing Terraform modules in a Crossplane-native manner inside Compositions.Providers are built upon standard Kubernetes libraries like controller-runtime, giving advanced organizations the ability to write their own providers using well-supported tooling.Finally, to accelerate Provider development, <a href="https://github.com/crossplane/upjet" target="_blank">Upjet</a> allows programmers to automate the creation of new Crossplane providers from existing Terraform providers. Upjet bypasses the Terraform CLI, offering significant performance improvements.<h2>3: Observability for Every Resource</h2>Internal Cloud Platforms can scale up quickly, managing tens of thousands of Managed Resources across multiple Clusters. For platform operators, having insights into Crossplane and the resources it manages is critical. As expected, all Crossplane components export performance metrics via a Prometheus endpoint. But Crossplane is capable of insights that exceed what is available from commercial offerings, answering questions like “how long does it take to provision a database in AWS?”Virtually every resource in Crossplane is a unique Kubernetes object with its own Status, Conditions, and Events. Instead of having to parse a state file to get the status of resources, platform operators can query the Crossplane cluster using standard tools like kubectl.And with addons like the <a href="https://github.com/crossplane-contrib/x-metrics" target="_blank">x-metrics</a> project, metrics can be generated from individual Composite and Managed Resources, allowing platform operators to use tools like Grafana to visualize metrics like Ready state and how long each resource takes to provision. With Crossplane, platform teams can define and track service levels of the infrastructure they manage across multiple clusters and environments.<h2>4: Composition Functions</h2>One of the major new features in Crossplane is <a href="https://docs.crossplane.io/latest/concepts/composition-functions/" target="_blank">Composition Functions</a>. These small programs that template Crossplane resources are a significant new development in infrastructure provisioning and have been rapidly adopted by the Crossplane community.Traditionally, most infrastructure engineers were forced to choose between inflexible static files like YAML, limited configuration languages found in Infrastructure as Code (IaC) tools, or the complexity of full programming languages.There are two major innovations present in Crossplane functions. First, functions focus on infrastructure data, leaving other Crossplane components to manage provisioning. A function only needs to take the existing Observed and Desired state of resources and output a Desired state.The second major innovation in functions is the runtime environment. Crossplane runs functions in a series of steps similar to Unix pipelines. Functions get and send data in standard gRPC messages, allowing functions to be written in any language. SDKs in <a href="https://github.com/crossplane/function-sdk-go" target="_blank">Go</a> and <a href="https://github.com/crossplane/function-sdk-python" target="_blank">Python</a> remove almost all boilerplate, so function authors can implement custom logic with only a few lines of code.Fortunately, many organizations will not need to write their own functions. Since Crossplane functions are packaged in standard OCI images, it is easy to run published functions. The Composition function ecosystem is growing quickly, allowing users to create desired states in multiple ways such as <a href="https://github.com/crossplane-contrib/function-patch-and-transform" target="_blank">Patch &amp; Transform</a>, <a href="https://github.com/crossplane-contrib/function-go-templating" target="_blank">Go Templating</a>, <a href="https://github.com/crossplane-contrib/function-kcl" target="_blank">KCL</a>, and <a href="https://github.com/elastic/crossplane-function-cue" target="_blank">CUE Lang</a>.<h2>5: Workload Identity Built In</h2>Infrastructure provisioning systems can present a significant security risk, as they require elevated credentials. IT teams often provision resources out of systems that have a single account with wide permissions and shared hard-coded credentials that are not rotated.Since they run as Kubernetes pods, Crossplane Providers can utilize the built-in Workload Identity trust mechanisms available in Amazon EKS, Azure AKS, and Google GKE. IAM roles can be mapped to individual Provider service accounts, enabling least-privilege, auditability, and credential rotation.Platform operators can configure Crossplane <a href="https://docs.crossplane.io/latest/concepts/providers/#provider-configuration" target="_blank">ProviderConfigs</a> to assume different roles at a Managed Resource level, allowing each team or organization to provision using their own accounts on the same cluster. And, where supported, Workload Identity can be set up so that Crossplane Providers can communicate securely between cloud providers like AWS and Google Cloud Platform (GCP).<h2>6: Shift Development and Testing Left</h2>“Shift left” is the practice of moving testing and validation to earlier in the development process. The Crossplane CLI can render and validate Composition Pipelines, allowing developers to test changes in their local development environments. Continuous Integration systems like GitHub Actions can check and test Compositions during the Pull Request Process. End-to-end frameworks like <a href="https://github.com/upbound/uptest" target="_blank">Uptest</a> and <a href="https://github.com/crossplane-contrib/xp-testing" target="_blank">xp-testing</a> create live infrastructure and ensure that provisioning is successful.Platform operators can quickly debug live systems using the crossplane trace command to view the status and dependencies for many Crossplane resources in the terminal.<h2>7: Leverage Existing Kubernetes Expertise</h2>Crossplane can run almost everywhere Kubernetes does, from the developer desktop to large cloud-based clusters. Applications and infrastructure can be deployed using the same platform, accelerating time to value. Organizations that have invested in Kubernetes tooling and training will find Crossplane a natural enhancement of their existing environments.<h2>8: Open Source with Community and Vendor Support</h2><a href="https://blog.crossplane.io/crossplane-at-5-years-past-present-and-future-of-building-control-planes/" target="_blank">After 5 years of development</a>, the strong growth and adoption of Crossplane has made it a <a href="https://github.com/cncf/toc/pull/1254" target="_blank">candidate for CNCF graduation</a>. Crossplane is licensed under the Apache 2.0 license, copyrights and trademarks are owned by the CNCF, and the project has strong governance. &nbsp;Public Crossplane <a href="https://github.com/crossplane/crossplane/blob/master/ADOPTERS.md" target="_blank">adopters</a> include Nike, Autodesk, Grafana, NASA Science Cloud, Novo Nordisk, SAP, IBM, VMware Tanzu, and Nokia. The Crossplane Slack has over 10,000 members, and hundreds of developers are working on Crossplane-related open-source projects.Vendors like <a href="https://www.upbound.io/" target="_blank">Upbound</a>, AWS, and Accenture provide 24x7 commercial support and Professional Services around Crossplane.<h3>Crossplane is for Platform Engineers</h3><a href="https://www.crossplane.io/" target="_blank">Crossplane</a> was built to support organizations creating self-service internal clouds. With low-code infrastructure APIs, powerful functions, a large and growing Provider ecosystem, and tooling for developers and operators, Crossplane is a comprehensive framework and one of the leading projects adopted by platform engineers. Join the community at <a href="https://www.crossplane.io/" target="_blank">crossplane.io</a>.-Crossplane stands at the forefront of a new era of efficient and scalable IT resource management. It powers Upbound, which provides platform engineering teams with an enterprise-grade architecture to build a secure, high-velocity, modern cloud-native platform suitable for the multi-cloud era. This includes features like managed control planes, integrated backup, and flexible deployment options, enabling higher ROI, easy adoption, and robust enterprise security. See this and more in a <a href="https://www.upbound.io/request-a-demo" target="_blank">demo with our team</a>.

8 Reasons Why Crossplane is the Ideal Engine for Internal Developer Platforms

Grupo Boticário is the second largest cosmetic company in Brazil. They built an efficient, scalable and future-proofed platform using Crossplane and Upbound. With this solution, they now deploy applications in minutes rather than over 7 days, saving over 20,000 work hours.

How Grupo Boticário Reduced Deployment from Hours to Minutes Using Crossplane and Upbound

In this talk, we'll focus on effective techniques for troubleshooting Crossplane nested composite resources. Additionally, we'll cover essential observability using Prometheus metrics, empowering you to manage Crossplane in production with confidence.This talk was presented by Christina Andonov, a Senior Specialist Solutions Architect at AWS where she guides organizations through the implementation of Internal Developer Platforms, at Control Plane Day with Crossplane, presented by Upbound, on September 19, 2023.

Getting Started with Troubleshooting and Observability in Crossplane – Control Plane Day 2023

Control planes are the future. Upbound is the best solution using it today. Convince the CIO, directors, and managers of your organization that hold the keys to the kingdom. Download this guide to get the tools prove the value of Upbound to your stakeholders.

How to Convince Your Organization to Adopt Upbound

We're Unveiling a New Release of Upbound TODAY

Terraform has served as the industry standard to automate infrastructure provisioning. However, with the rise of Kubernetes and Crossplane, it’s time to bring Infrastructure as Code (IaC) to a control planes based architecture.

Optimizing Terraform with Crossplane

Upbound Spaces is a new feature of Upbound that allows teams to run managed control planes in their own self-hosted environments—whether that may be on AWS, Azure, GKE, or on-prem—in addition to Upbounds SaaS service.Anywhere you can run Kubernetes, you can now run an Upbound Space. This is especially useful for environments that have restrictions due to compliance or regulatory needs.

Upbound Spaces: Self-Hosted Control Planes

Learn about our product, Upbound, that offers managed control planes do in one simple visual overview. Rooted in Crossplane, Upbound can be leveraged for various cloud native solutions.

Upbound: Managed Crossplane Control Planes

Continue your journey from learning about <a href="https://www.upbound.io/resources/lp/whitepaper-b/crossplane-providers-and-managed-resources-getting-started">Providers and Managed Resources</a> to understanding Crossplane compositions. These enable the ability to define what something is, enabling platform engineers to codify their expertise and expose services at higher-level abstractions.Authored by Crossplane expert Viktor Farcic, this guide is tailored for beginners eager to learn how to leverage Crossplane’s powerful composition features by:Comprehensive Coverage: Understand how to create and manage composite resources, extending Kubernetes capabilities with Crossplane.Build Production-Ready Solutions: Learn how to abstract low-level resources into higher-level services that can be easily consumed by your team.Hands-On Examples: Dive into real-world scenarios and hands-on examples that simplify complex concepts.This is part 2 of 3 of Viktor's getting started series, sourced from his book, <a href="https://www.upbound.io/resources/lp/book/crossplane-cloud-native-control-plane">Crossplane: The Cloud Native Control Plane</a>.&nbsp;Find <a href="https://www.upbound.io/resources/papers/getting-started-with-crossplane-providers-and-managed-resources" target="_blank">part 1 here</a> and&nbsp;<a href="https://www.upbound.io/resources/papers/getting-started-with-crossplane-configuration-packages" target="_blank">part 3 here</a>.

Getting Started with Crossplane Compositions

It’s exciting how Crossplane has ushered in the next generation of cloud-native infrastructure management with control planes. To really unlock the potential of Crossplane, you need Upbound. It increases developer productivity and velocity, offers better compliance and security practices, and makes it easy to build and manage your platform at scale. Eliminate your ops burden with a truly cloud-native Crossplane solution.

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

Learn how Upbound makes building your internal cloud platform easy with it’s great benefits: future-proofed platforms, faster deployment times, lower CAPEX, lower OPEX, reduced risk, and more.

Upbound: A Platform for Platform Teams

Increase developer velocity with a future-proof self-service platform.

Internal Developer Platform (IDP)

Build an internal developer platform in under two minutes.

Finance & Banking

Retail & E-Commerce

Upbound Managed Control Planes

Upbound Spaces

Upbound Marketplace

Terraform Migration

Community

Configuration Drift

Control Planes

Crossplane

Customer Stories

Getting Started

Infrastructure as Code (IaC)

Kubernetes

Partner

Product News

Providers

Self-Service

AI and ML Workloads

Cloud Native Infrastructure Management

Cluster-as-a-Service

Database-as-a-Service

See how Crossplane extends Kubernetes to allow for declarative, adaptive management of IaC to scale your infrastructure in technical detail.

Kubernetes Changes the Way We Manage Infrastructure

See how Crossplane extends Kubernetes to allow for declarative, adaptive management of IaC. Use it to scale your infrastructure while minimizing overhead.

The Future of Infrastructure as Code

This live session originally occurred at KubeCon North America 2023 in Chicago, and the on demand version is hosted on the <a href="https://www.youtube.com/watch?v=pcpm4HiRktY&amp;list=PLj6h78yzYM2MYc0X1465RzF_7Cqf7bnqL&amp;index=44">CNCF's channel here</a>.Streamlining Infrastructure with Crossplane: A Transformation Story — Clément Blaise, Consensys &amp; Jared Watts, UpboundInfrastructure management can rapidly become a labyrinth of repetitive and complex tasks, leading to inefficient operations. This was our story – managing individual Terraform repositories for every project in our organization, each with its unique requirements. Our pursuit of a sustainable solution led us to Crossplane, a CNCF project that allowed us to create an internal developer platform. This platform, built in less than six months by a team of two, transformed our infrastructure approach. The time-consuming process that used to take weeks or months is now available in an efficient low-code experience that takes mere hours. In this session, we will walk through our journey of building this platform with Crossplane, discussing how we used the concept of “composition” to enforce architectural standards while still providing flexibility for customization based on project requirements. Finally, we will show how you can start your own journey to build your platform too.

[CNCF Hosted] Streamlining Infrastructure with Crossplane: A Transformation Story

This video is originally published on the <a href="https://www.youtube.com/c/devopstoolkit">DevOps Toolkit channel</a>, created and hosted by Viktor Farcic.Shifting left by saying "now you do it" does not work. If you want to enable developers to be productive and self-sufficient, you have to build an IDP (Internal Developer Platform).&nbsp;

[DevOps Toolkit Hosted] DevOps MUST Build Internal Developer Platform (IDP)

This video is originally published on the <a href="https://www.youtube.com/c/devopstoolkit">DevOps Toolkit channel</a>, created and hosted by Viktor Farcic.What do we need to do to enable everyone to self-serve themselves when infrastructure is concerned? How can we create, operate, and destroy Kubernetes clusters without the need to involve anyone else? How can we customize the experience to fulfill the needs of our users? How can we provide a good user experience through services? How can we ensure that we are following best practices?

[DevOps Toolkit Hosted] Internal Developer Platform (IDP) For Infrastructure

This video is originally published on the <a href="https://www.youtube.com/c/devopstoolkit">DevOps Toolkit channel</a>, created and hosted by Viktor Farcic.Which Infrastructure as code (IaC) tool is the best? Is it Terraform, Pulumi, or Crossplane? Which one should you use?

[DevOps Toolkit Hosted] Terraform vs. Pulumi vs. Crossplane - Infrastructure as Code (IaC) Tools Comparison

This talk occurred at KubeCon SLC, 2024In the realm of developer platforms, individuals without extensive experience in the cloud-native ecosystem are now venturing into the creation of Kubernetes-based APIs. Tools like Crossplane are transforming every platform engineer into an API designer. Ten years in, the ecosystem still offers little guidance on Kubernetes versioning and API evolution in practice. A naive understanding is not helpful, and many have been burned by relying on intuition. This talk will provide deep, yet applicable knowledge, starting from the first principles of the invariants to maintain when changing APIs in Kubernetes. It will cover tools like schemas, conversion, validation, and admission, and present very concrete and directly applicable API Evolution Patterns. These patterns will help navigate the life cycle of CRD-based projects. This talk aims to educate on how to evolve APIs effectively and safely without inadvertently breaking users.

[CNCF Hosted] The Missing Talk About API Versioning & Evolution in Your Developer Platform

Offering developer self-service is the holy grail for many organizations seeking to drive developer productivity. But how to do this?You need to set up the ability to support developers in creating new services, applications, or even infrastructure. You then need to think about abstracting information to developers, to reduce cognitive load and provide them with the information they need.This is especially important when K8s is involved since most developers need help dealing with it.Explore how to form a platform with Kubernetes, in conjunction with Crossplane Control Planes, and how Crossplane can extend the capabilities of Kubernetes. You’ll learn to create the basics of the platform and connect it to Port, acting as an internal developer portal. In the portal, we show what a self-service action is, how to think about the software catalog, and how to drive standards using scorecards, using cost as an example.

Drive Developer Self-service using an Internal Developer Platform

During this session, we'll explore how Kubernetes, in conjunction with Crossplane Control Planes, can be leveraged for enhanced system visibility and management. As Kubernetes continues to be a key player in building Internal Developer Platforms, understanding its full potential becomes crucial. We will delve into how Crossplane can extend the capabilities of Kubernetes, allowing us to observe and manage both the control and data planes effectively. This includes a comprehensive view of the internal dynamics of the Kubernetes cluster as well as the external infrastructure it manages. Throughout the session, we'll provide practical insights and techniques for using Kubernetes and Crossplane Control Planes to better understand and control your entire system.Learning Objectives:<ul><li>Experience a live demonstration of using Prometheus for data collection and analysis, displaying essential metrics in Grafana, uncovering valuable logs with Loki, and efficiently tracking Kubernetes events.</li><li>Understand how Crossplane Control Planes can enhance the functionality of Kubernetes in managing complex systems.</li><li>Gain insights into monitoring both the control and data planes within the Kubernetes environment for complete system awareness.</li><li>Learn how to use Prometheus for gathering system metrics and analyzing this data for actionable insights.</li></ul>