Key points: • The goal of many organizations is to build their own cloud platforms, which are typically accomplished by an internal deployment architecture and cloud vendors. • While Kubernetes does not provide a full PaaS platform service out of the box, it has a complete API, clear technical extraction, and easy-to-understand extensibility to allow other fully functional components to run on it. •Crossplane is an open source cloud control component that enables engineers to manage some infrastructure or cloud services directly through Kubernetes. The control module provides the user with a unique interactive entrance through which policy issuance, security protection and audit can be realized. • The infrastructure can be configured using K8S Resource Customization (CRD) and YAML, or it can be managed by building tools (such as Kubectl) or the Kubernetes API itself as a workflow best practice (such as GITOPS). • The Open Source Application Model (OAM) describes the core software delivery roles and defines clear responsibilities: developer, application operator, and infrastructure operator. Crossplane is the best implementation of the canonical Kubernetes. InfoQ recently spoke with Bassam Tabbara, founder and CEO of Upbound, about how to build an application platform across multiple clouds and infrastructures. The premise of this topic is that each software vendor deploys the application on a platform and whether they are willing to use it. Currently Kubernetes is the base platform for many “cloud native” architectures. While Kubernetes does not provide a full Platform Services (PaaS) experience out of the box, it does have a complete API, clear technology extraction, and easy-to-understand extensibility that allows other fully functional components to run on it. Tabbara said Crossplane is an open source project that allows engineers to manage any infrastructure or cloud service directly on Kubernetes. This cross cloud control component is built on Kubernetes ( native configuration on the statement, it allows the engineer to define architecture to take advantage of the existing K8s tool chain. The interview also touched on the Open Source Application Model (OAM) and explored how Crossplane has become a best practice for team-centric building of cloud native applications based on Kubernetes. The goal for many companies is to build their own cloud platform, usually through their own deployed infrastructure or cloud providers. Leaders of these companies recognize that reducing conflict during deployment, reducing delivery times, and providing stability and security can enhance their competitive advantage. At the same time, they recognize that any successful enterprise generally needs to build its existing “asset” applications and infrastructure on a common platform. Many companies also want platforms to support multiple cloud providers, to avoid being tied to one in search of cost reductions, and to implement disaster resilience across vendors. The platform team also wants to provide self-service for app developers and operators. However, consider how the platform is compatible with security, compliance, and regulatory requirements. All large public Cloud providers, such as Amazon Web Service (AWS), Microsoft Azure, and Google Cloud Platform (GCP), provide similar services through control components. This control component includes user interaction (UI), command-line interaction (CLI), and program interface (API) to enable platform teams and operators to perform configuration and deployment based on the underlying data. Although cloud control components are typically distributed globally, they are ultimately presented to users in a centralized manner. The control module provides the user with a unique interactive entrance through which policy issuance, security protection and audit can be realized. Just like pioneer organizations like Zimki, Heroku, and Cloud Foundry, application developers are eager to gain platform-as-a-service (PaaS) -like experience defining and deploying applications. Deploying a new application is effortless with a simple “Git Pushheroku Master”. Application operators and SRE teams want to be able to easily build, run, and maintain applications or complete their own administrative configurations. Tabbara notes that these requirements can be expensive for organizations to maintain if they choose poorly: “Modern commercial PaaS often meets 80% of an organization’s requirements, which means that infrastructure teams need to create additional platform resources to meet the other 20% of requirements.” Building a PaaS platform is not an easy task. It takes time and exploration of the technology to figure out how to extract the requirements of all the relevant roles into technical implementations. Google has thousands of highly trained engineers working on the platform, Netflix has a large team of experts dedicated to building and maintaining its in-house PaaS platform, and even smaller companies like Shopify have dedicated PaaS teams. Extracted technology implementations range from Libcloud and OpenStack to generic functionality, to workflows in general, and even complete cloud-specific configuration components like Hashicorp’s Terraform or Pulumi. The technical implementation of traditional PaaS extraction is also very common in the cloud field, typically such as GCP App Engine, AWS ElasticBeanstalk or Azure Service Fabric. Many companies are choosing to build platforms on top of Kubernetes. Either way, as Tabbara pointed out on Twitter, this can take a lot of upfront investment, combined with 80% User Scenarios challenges, which can lead to a “PaaS dilemma” : “The dilemma with PaaS is that your PaaS does 80% of what you want, and I need to spend 80% of my time maintaining Kubernetes.” According to Tabbara, the open source Crossplane project aims to be a generic, multi-cloud control component that can be used to build a customized PaaS experience. Crossplane is a fusion of “Cross” cloud controlled “Plane”. We want to use this name to mean connecting different cloud providers and acting as a control component across connections. Cross means “across the cloud” and plane adds “control level”. By building in the widely application of Kubernetes configuration ( based on the original style, with a ready-made infrastructure components and registered share other resources in two ways, This relieves the burden on the infrastructure and application operators. In addition, by providing a complete set of APIs that encapsulate the extraction of critical infrastructure technologies, it separates the concerns of platform operators (who do not rely on the “API” to work) from those of application developers and operators (who do rely on the “API” to work). “Developers just need to focus on the workload and not worry about implementation details, environmental constraints, or policies. Administrators can define environment details and policies. This leads to greater reusability and reduced complexity.” Crossplane: Control Infrastructure via Kubernetes Crossplane is an implementation of the Kubernetes add-on that extends clustering capabilities by providing and managing cloud infrastructure, services and applications. Crossplane uses Kubernetes’ style declaration, API-driven configuration, and management to control the local or cloud infrastructure. In this way, the infrastructure can be configured using resource customization (CRD) and YAML, or managed by establishing tools such as Kubectl or the Kubernetes API itself. Using Kubernetes also allows you to define security controls through RBAC or Gatekeeper’s Open Policy Agent (OPA). As part of the Crossplane installation, the Kubernetes Resource Controller manages the entire life cycle of the resource and is responsible for preparation, health check, scaling, failover, and positively responding to external changes away from the required configuration. Crossplane incorporates a continuous delivery (CD) pipeline that allows the application’s infrastructure configuration to be stored in a single control cluster. Teams can use cloud native CD best practices like Gitops to create, track, and approve changes. Crossplane lets the application and infrastructure configurations co-exist on the same Kubernetes cluster, reducing the complexity of the tool chain and deployment pipeline.

The OAM model shows the overall work situation, the clear extraction of technology, the use of different roles, and the “online and offline” approach. 4 the OAM: The Open Application Model (OAM) specification, originally created by Microsoft, Alibaba, and Upbound, defines a model in which developers are responsible for defining application components, and application operators are responsible for creating and configturing instances of those components. The infrastructure operator is responsible for declaring, installing, and maintaining the basic services available on the platform. Crossplane is the best implementation of the canonical Kubernetes. Using OAM, platform builders can provide reusable modules in the form of Components, Traits, and Scopes. Allows the platform to package them in predefined application configuration files. Users can choose how to run their applications by selecting profiles, for example, microservice applications required by High Service Level Objectives (SLOs), stateful applications with persistent volumes, or event-driven features with automatic scale-out capacity. An example of a typical application delivery lifecycle practice is described in the OAM specification introduction document. 1. The developer creates a Web application; 2. The application operator deploys an instance of the application and configures it with operational features, such as automatic scaling capacity. 3. The infrastructure staff decides which technology to deploy and operate on. To deliver the application, the application developer defines each individual component of the application in YAML. This file encapsulates the workload and the information needed to run it. In order to run and operate the application, the application operator sets parameters for the component and defines them in the YAML of the application configuration, such as copy number, automatic scaling capacity policy, entry points, and traffic routing rules. In OAM, these operational characteristics are called features and are written in the deployment application configuration file to deploy the application. The underlying platform is created based on the operational characteristics defined by the workload and application profile. The infrastructure staff is responsible for declaring, installing, and maintaining the basic services available on the platform. For example, the infrastructure staff might choose a specific load balancer to expose the service, or complete a database configuration to ensure that the data is encrypted and replicated globally. To bring the discussion into focus, let’s explore a typical Crossplane workflow, from installation to use of a project. First, install Crossplane and create a Kubernetes cluster. Next, install the provider and configure the credentials. Native architectures can be obtained from pre-allocated providers (such as GCP, AWS, Azure, Alibaba, or user-built infrastructure). Platform operators use YAML definitions to declare, compose, and publish their own infrastructure resources, thereby adding their own infrastructure CRD to the Kubernetes API for use by applications. The application developer publishes the application components, indicating required, recommended, or optional requirements for the service, as well as the infrastructure requirements. The application operator associates the infrastructure with the application components, by defining the configuration, and then runs the application. 6 summary Kubernetes ( is the basis of many of the “native” cloud platform to build, and as a result, the team and platform for interaction and integration underlying components, these two models is crucial for a company, And it has a potential competitive advantage. As stated by Dr. Nicole Forsgren et al at Accelerate, high performing organizations are able to reduce delivery cycles and increase deployment frequency. It is with this that the platform plays a vital role. Crossplane is an evolving project, and as the community expands, expect to see more and more feedback. Engineers can visit the Crossplane website to use the open source project, and they can share feedback on Crossplane Slack.

Originally written by Daniel Bryant (InfoQ)