The Apprenda Cloud Platform (ACP) has supported docker-based deployments for a while, but for the last year and half we’ve been aggressively adopting and integrating K8s into almost everything we do.
For example- with version 7, you can attach a K8s cluster to the Apprenda Cloud Platform as an optional cluster manager and resource provider. Rakesh Malhotra, Apprenda’s senior VP of product strategy and development recently recorded a detailed demo of this functionality. I encourage you to watch it when you get a chance.
Let’s explore a more specific combination: attaching an OpenShift cluster to an ACP instance. As you probably know, starting with version 3, OpenShift is based on Kubernetes; we can therefore attach the underlying cluster to ACP, just like you can do with “pure” Kubernetes clusters. This means that OpenShift customers can now enhance their clusters with Apprenda capabilities in a unified architecture. For instance, they can now easily modernize a legacy .NET application by cloud enabling its components and seamlessly integrating it with a cloud-native microservice- all the while simplifying the deployment model and operations under one roof. This is the use case explored in the quick demo video, below.
We start with a previously configured, single node OpenShift Origin instance to keep it simple for the demo, but we could have used a multi-node production cluster instead. By grabbing the proper credentials we can use the standard Kubernetes command-line client (
kubectl) to access the underlying Kubernetes cluster directly. We can confirm this by using the
kubectl cluster-info command to verify that we’re connected to the same API server endpoint that OpenShift’s command (
oc) uses. If you’re curious, you can discover how OpenShift implements some of it’s features by using standard Kubernetes resources behind the scenes. You may notice, for instance, that OpenShift “Projects” are basically K8s namespaces.
We then use the ACP operations portal to attach the OpenShift instance to the platform. In this case, we will use the certificate-based authentication mechanism, since this is what OpenShift expects. ACP runs a set of tests to validate the connection information and the proper functioning of the target cluster.
Once configured, we can now see the OpenShift Origin node(s) in the Infrastructure > Servers table, denoted by the letter K, for Kubernetes. For a multi-node cluster we would see all the nodes listed there. Going back to the command line, we can verify that ACP has created its own namespace to manage ACP orchestrated workloads, which shouldn’t interfere in any way with existing projects or apps on the OpenShift side.
Now lets consider a hypothetical example in which we are part of an enterprise development team that is tasked with modernizing a legacy application that has some .NET WCF Web Services that provide basic access semantics for an underlying SQL Server database. The modernization task was requested by the business because they want a shiny new HTML5 front-end to better compete in the market.
There’s nothing wrong with the web service middleware or the Database, so there’s no need to rewrite those pieces. Only the front-end needs revamping. So, we have come up with an approach to replace that component with a new node.js app, running in OpenShift/Kubernetes, that communicates with the legacy WCF web service via its native API.
With our new setup, this solution becomes trivial. We can package all three components of the new application as an Apprenda archive and deploy them as a unit. The database schema definition file will leverage ACPs Database as a service feature to create a relational database on the fly. The schema itself doesn’t need to change, we just benefit from the improved database provisioning. Secondly, our legacy middleware .NET code, written in C#, requires no code changes, and with only minor configuration tweaks this legacy component becomes cloud-enabled. Finally, we include a Kubernetes resource definition file for our new node.js front-end. This references a Docker Image that was built by a CI/CD server and uploaded to an approved Registry. Note that we can use ACP’s features for this last component just like with any other workload type. For example, we can use Token Replacement to have the platform inject dynamic values into the
We can use standard ACP workflows to deploy this new application through the HTML developer portal, REST API, command-line client or any of the other mechanism for interacting with the platform. ACP will properly recognize the 3 different components and deploy them to their corresponding targets. If we use the dev portal, we will see a promotion report card that informs us of sequence of actions being taken by the platform and the time spent on each. For our example app, ACP dynamically provisions a SQL Server database and initializes it with the schema definition we provided. It then deploys the WCF legacy service component into an Apprenda custom Windows container and uses token replacement to properly configure the database connectivity for it. After that, it coordinates the deployment of the K8s Replica Set of the node.js front-end onto the OpenShift/Kubernetes cluster.
In a few seconds we have our new cloud-enabled application up and running and we can immediately see it working by visiting it’s dynamically assigned URL. If we examine the Kubernetes cluster directly, we can now confirm the existence of a new ReplicaSet, its corresponding Pod and Service. Continuing with our hypothetical scenario, let’s imagine that the new application becomes very popular and the small front-end container is no longer able to serve all the incoming requests in a timely fashion. We can simply use Apprenda’s scaling controls to manage the underlying ReplicaSet’s replica count. We can just as well scale the middle-tier if it ever becomes a bottleneck. This legacy .NET component is now cloud-enabled without the need for any code changes.
And that’s it! We now have a revamped application with a shiny new front-end, running in OpenShift, connecting to the legacy components, running on ACP’s classic containers, using a modern architecture. We can easily extrapolate this pattern to a large number of similar hybrid use cases that are present within every enterprise.
If your company has already made an investment in OpenShift and you’re trying to figure out how to manage your legacy app portfolio, there is now a great way to bring both together in a unified and coherent platform.
Until next time!