Imagine an information technology (IT) world where everything is ideal: Every company has switched over to cloud-native applications, every application is containerized, everything is automated, and the IT people see that the world is good. Things are not so ideal in the real world, though, as we know. Applications remain tightly coupled with traditional virtual machine (VM) resources such as software libraries and hardware resources. The effort to migrate them from VMs to containers seems insurmountable, requiring years of dedicated spending and hours from developers and software architects.
The dilemma is that companies want all of their applications to eventually run on containers, but they also need to support applications running on VMs until that glorious shift happens. Given that application migration from VMs to containers will happen over the long haul, some companies are exploring a lift-and-shift approach. In theory, lift-and-shift would let us migrate tightly-coupled legacy applications to a container platform like Red Hat OpenShift. Rather than rewriting application code, developers would simply write interfaces (essentially, code with patterns) that are compatible with the existing structure.
Unfortunately, this scenario is unrealistic for legacy projects involving hundreds of application modules and packages. Therefore, it is logical to ask: What if there was a way to support existing applications running on virtual machines and new applications running on containers in one unified container-based platform?
Luckily, there is a way: Use a Kubernetes-based platform like OpenShift.
In this article, I introduce OpenShift Virtualization, a feature for Red Hat OpenShift Container Platform (OCP). OpenShift Virtualization allows you to run and manage virtual-machine workloads alongside container workloads.
Note: As of version 2.4 when CNV went GA, Container-Native Virtualization was renamed OpenShift Virtualization.
Continue reading “Enable OpenShift Virtualization on Red Hat OpenShift”
Within the context of Kubernetes, a namespace allows dividing resources, policies, authorization, and a boundary for cluster objects. In this article, we cover two different types of Operators: namespace-scoped and cluster-scoped. We then walk through an example of how to migrate from one to the other, which illustrates the difference between the two.
Namespace-scoped and cluster-scoped
A namespace-scoped Operator is defined within the boundary of a namespace with the flexibility to handle upgrades without impacting others. It watches objects within that namespace and maintains
RoleBinding for role-based access control (RBAC) policies for accessing the resource.
Meanwhile, a cluster-scoped Operator promotes reusability and manages defined resources across the cluster. It watches all namespaces in a cluster and maintains
ClusterRoleBinding for RBAC policies for authorizing cluster objects. Two examples of cluster-scoped operators are istio-operator and cert-manager. The istio-operator can be deployed as a cluster-scoped to manage the service mesh for an entire cluster, while the cert-manager is used to issue certificates for an entire cluster.
These two types of Operators support both types of installation based on your requirements. In the case of a cluster-scoped Operator, upgrading the Operator version can impact resources managed by the Operator in the entire cluster, as compared to upgrading the namespace-scoped Operator, which will be easier to upgrade as it only affects the resource within its scope.
Continue reading “Migrating a namespace-scoped Operator to a cluster-scoped Operator”
Apache Kafka is one of the most used pieces of software in modern application development because of its distributed nature, high throughput, and horizontal scalability. Every day more and more organizations are adopting Kafka as the central event bus for their event-driven architecture. As a result, more and more data flows through the cluster, making the connectivity requirements rise in priority for any backlog. For this reason, the Apache Camel community released the first iteration of Kafka Connect connectors for the purpose of easing the burden on development teams.
Continue reading “Extending Kafka connectivity with Apache Camel Kafka connectors”
Apache Camel K is a lightweight cloud-integration platform that runs natively on Kubernetes and, in particular, lets you automate your cloud configurations. Based on the famous Apache Camel, Camel K is designed and optimized for serverless and microservices architectures. In this article, I discuss six ways that Camel K transforms how developers work with Kubernetes, Red Hat OpenShift, and Knative on cloud platforms.
Continue reading “Six reasons to love Camel K”
Kubernetes is becoming much more than just a platform for running container workloads. Its API can be extended with application-specific Custom Resource Definitions(CRDs), and you can implement your own logic adapting your applications dynamically to changes in the cluster. In this article, we’ll be writing a simple Kubernetes Operator in Java using the Fabric8 Kubernetes Client.
Continue reading “Write a simple Kubernetes Operator in Java using the Fabric8 Kubernetes Client”
We have pretty exciting news this week as Red Hat is announcing the General Availability of their Apache Kafka Kubernetes operator. Red Hat AMQ Streams delivers the mechanisms for managing Apache Kafka on top of OpenShift, our enterprise distribution for Kubernetes.
Everything started last May 2018 when David Ingham (@dingha) unveiled the Developer Preview as new addition to the Red Hat AMQ offering. Red Hat AMQ Streams focuses on running Apache Kafka on OpenShift. In the microservices world, where several components need to rely on a high throughput communication mechanism, Apache Kafka has made a name for itself for being a leading real-time, distributed messaging platform for building data pipelines and streaming applications.
Continue reading “Welcome Apache Kafka to the Kubernetes Era!”