Today, we all know Docker and Kubernetes are paradigm-shifting concepts in the world of cloud and enterprise deployments.

Five years ago, that was not the case. For many organizations, the potential of containerization was not as clear as it is today. However, that’s where Elastic Path differs from the norm as we invested very early into becoming a fully Dockerized solution.

We were approached by a prospect and presented the opportunity to deploy Elastic Path on IBM Cloud (thank you IBM for giving us a sandbox to play with!). We usually deploy our stack on AWS and Azure, however this prospect in particular had interest in IBM Cloud. This gave us another chance to test the adaptability and flexibility of our deployment and infrastructure-as-a-service automation. We leveraged our existing work with Docker and Kubernetes, and added IBM’s Watson Content Management services. By basing our deployment on Kubernetes, we knew we had a foundation that was battle-tested by many enterprise-grade deployments.

Deploying Elastic Path Commerce

We had already put effort into ensuring that our Docker containers were 12 Factor compliant and cloud agnostic. All that remained was getting existing Docker images to run inside IBM Cloud’s Kubernetes service. Getting the Docker images into IBM Cloud was easy. We already had a set of images in Azure’s Container Registry service, so we just needed to pull, tag, and push them into IBM Cloud’s Container Registry service. That was completed in less than 30 minutes. While we could have just created a Docker Registry Secret inside the Kubernetes cluster running in IBM Cloud to allow us to pull Docker images from the Azure’s Container Registry service, by pushing the images into IBM Cloud’s Container Registry service we could ensure that the image source is closer (in a network sense) to the Kubernetes cluster. This should help ensure that Docker images are pulled faster, resulting in container based stacks being started sooner.

After that we started working on the deployment of our headless commerce containers (everything except the store in the dashboard screenshot below). We already had Kubernetes YAMLs files describing our Deployments, Services, and Ingresses which we were using in CloudOps for Azure. After just removing 3 lines (which were annotations for using Azure load balancers), we deployed the Elastic Path headless commerce containers with the same configuration that we were using in Azure. We were half way to a complete stack on the first day.

With Elastic Path’s headless commerce solution deployed, we just needed to get one of our containerized reference storefronts to run in Kubernetes as well. Using the existing Deployments, Services, and Ingress YAML files for the EP stack as a base, we created new versions of each for the storefront. We built, tagged, and pushed the Docker image for the storefront into IBM Cloud Container Registry and had it running by the middle of day 2.

Leveraging Watson’s Content Management Services

Next, we decided to leverage the capabilities of Watson Content Hub for asset management. Upon uploading images to WCH, Watson’s AI added labeling to our catalog and site images to enable searching for updated content within our set of assets. This immediately enabled our Storefront to leverage some of the AI features of WCH and operate in the fashion of a headless CMS to enable content managers to set the best content to be displayed across the site, or as specified product images.

Our Reference Storefront can easily be configured to leverage the content delivery features that any CDN may provide. This same practice has previously been proven in our consumption of Amplience’ content management services. We provided the content management URLs directly to our storefront configuration which may then fetch all site-related content (marketing images, banner content, branding logos, etc) and catalog images. We used the general flexibility of our Storefront to handle content delivery from Watson Content Hub for general digital asset management adaptability.

Within our Reference Storefront project’s configuration (src/ep.config.json), we had configured the remote asset URLs to the following to match with our WCH content base URL, then substitute the placeholder strings with the requested file names:

Improvements

Later seeing the full capabilities of Watson Content Hub, we also noticed possibilities to host our full storefront directly on Content Hub as a set of assets (similar to our approach of hosting our storefront on Amazon S3 for our AWS deployment options). In a future implementation, this would be another viable solution to hosting a front-end application on a cloud platform and further save on costs associated with containers/deployment/etc.

We also didn’t take advantage of IBM Cloud’s hosted MySQL service and instead opted to just run MySQL inside a container (which isn’t production grade). With more recent work that we’ve done around provisioning and connecting our stack to a database, this integration would have been easy.

Conclusion

It took our team just two days — from the beginning to the end — to see a fully functioning commerce storefront running on IBM Cloud and pulling images from IBM’s Watson Content Hub.