March 12, 2018 | Written by: Robert Zante
Share this post:
IBM is rolling out an exciting transformation of our digital commerce portfolio. This is the fifth blog post in a series that formally introduces these advancements and reviews the architecture of the services from a technical point of view.
In this post, the author discusses immutable images, containers and deployment pipelines that are critical to the success of every digital commerce platform.
Post #1: Monolith to Pebbles: Transformation of the IBM Commerce Portfolio
Post #2: A New Approach to Customization for Commerce Platforms
Post #3: How to Build a Cognitive System
Post #4: How to Strengthen the Security of your Online Store
What are immutable images and containers and how do they work within a container management framework?
Immutable images have sparked a paradigm shift in application deployment. This shift moves deployments from a lengthy, time-consuming, manually-intensive, error-prone approach to a clean, fast and simple process. With immutable images, you can now deploy a pre-installed, pre-configured instance of the application in a repeatable automated fashion across one or more environments. When architecting a deployment approach for a SaaS solution that needs to be not only highly scalable and reliable, but also capable of rapid and seamless delivery to all environments with near-infinite up time, this change is critical.
Immutable images can be implemented in several ways. Let’s look closer at two very popular technologies: VMWare images – hardware virtualization/isolation and Docker containers – OS-level process isolation. Although sometimes contrasted as direct competitors, they can be used as complementary if you target your use cases to their strengths, with VMware more at the IaaS layer and Docker more at an SaaS application layer. Docker containers allow the creation of immutable images that include only the minimal requirements needed for the application to run. That includes the application, dependent run time libraries and system tools resulting in images that can be deployed to multiple environments and configured on start up. IBM Digital Commerce, and by extension our customers, enjoy the benefits of application portability and consistency, ensuring exact parity across different environments. The possibility of error when delivering new code into production is dramatically reduced as a single set of images are built only once and deployed to all environments.
For IBM Digital Commerce, our requirements include both a base set of immutable images and a process to enable customers to build immutable images specific to their organization on top of the base in a streamlined fashion, without incurring a lot of build or deployment overhead. Docker containers offer several key differentiating benefits over VMWare images from an application point of view. While VMware images deliver similar portability and consistency benefits, they are significantly larger in size, because they include a full OS required for hardware emulation. Docker by comparison, is much more streamlined as they only include the minimum requirements for running the application, resulting in quick and lightweight deployment.
Layering capabilities unique to Docker are a perfect fit for our requirement to enable customers to build customer-specific images on the top of our base. By building only the delta changes into a new layer on top of the base, the docker build process is simplified and allows efficient reuse. There is an additional benefit when it comes to deployment — once the base layer is deployed on a machine, only the additional layers of the new container are pulled, resulting in faster deployment times. This allows our customers to only worry about creating and submitting customization packages as we handle everything else for them. Behind the scenes they are leveraging our common build and deploy pipeline to rapidly build and deploy images tailored to their business. This same pipeline also enables IBM to update the base images to deliver new capabilities effectively in-place to the customer specific images.
Our approach to dockerization is largely agnostic to the underlying platform or container orchestration framework. This allows us to easily adopt the best-of-breed or move from one to another to unlock additional capability. Pairing Docker containers together with a sophisticated container orchestration framework such as Kubernetes or Marathon simplifies the approach to creating and managing containers, while introducing several key benefits. Docker provides both encapsulation and isolation, which allows us to deploy multiple applications into a multi-tenant platform, and to ensure no awareness or interaction from a memory or filesystem point of view across containers. Through the entry point, Docker gives you the ability to define logic on startup. This provides some key benefits when it comes to configuration management, as described later. The container management framework allows you to take advantage of deployment constraints and define CPU, memory and disk usage constraints for each container. Processes of one container will not interfere or interact with another container, plus, you can take advantage of idle capacity through over subscription. Leveraging the concept of container health checks together with constraints at the container management framework level that ensure a minimum number of services remain active at any point in time, allows us to define the set of conditions at which the application is considered “healthy”. These constraints are used during initial deployment, rolling restarts and upgrade scenarios to ensure near zero downtime.
What challenges did we overcome?
Dealing with environment-specific configuration data was a key challenge when we created our digital commerce application deployment architecture, since it has the potential to limit some of the benefits of immutable images. The naïve approach with containers is to include every aspect of the application inside the container. The problem with that approach is that the unique images for each environment are no longer truly immutable. Hence, the challenge was to create common images that can be deployed to all environments while abstracting out the environment-specific configure data. This was overcome by a combination of identifying and storing environment-specific configuration data outside the container in a central location such as HashiCorp Vault, and by leveraging the entry point and the read/write layer within the container. When each container starts up, it reads the configuration data and configures the variables defined in the container accordingly. Startup of a typical IBM Digital Commerce environment of multiple containers generally consists of reading configuration specific data for an environment, such as the username or password for a data source, encryption keys or third-party integration certificates. With this approach, we were able to ensure the exact images could be deployed across different environments, while being able to configure the container with unique environment-specific configuration data.
We covered another challenge that we faced and another key differentiating factor for IBM Digital Commerce in an earlier blog post, A New Approach to Customization for Commerce Platforms. We needed to allow our customers to programmatically customize and built on top of the base image, in addition to enabling IBM to deliver updated base images. As we outlined in the post Monolith to Pebbles, IBM Digital Commerce is not just a single application but rather multiple customizable and configurable services across multiple containers that together make up the entire running application. This process needs to be highly reliable, robust as well as efficient for both IBM and our customers. To achieve this, we leverage modern continuous integration and orchestration tools to design a common reusable pipeline for building and deploying containers for initial base images, customer custom images and updated base images. Base images plus custom packages from the SDK are built together in a pipeline to produce unique customer-specific (tenant) images. This allows our customers to only worry about creating and submitting customization packages that will trigger build and deployment of their immutable images to any of their environments directly or trigger promotion of existing images. The pipeline is 100% automated and covers all three flows, guaranteeing consistency and ensuring coordination of changes between customers and IBM. By defining a common, reusable orchestration pipeline leveraging Docker and a container management framework, we achieved a robust, reliable and efficient approach to delivering customer specific immutable images and updated base images across all environments.
Summary of key benefits
Let’s summarize the critical benefits that are achieved from this paradigm shift — leveraging Docker containers to build immutable images and deploying and managing them using a container management framework.
- By designing a simplified, reliable and 100% automated delivery pipeline that is re-usable for updates from IBM as well as customer programmatic customization and application-specific configurations, IBM can build and deploy any new changes to existing environments and promote images across all environments quickly and efficiently. This serves our customers’ needs for a highly scalable robust environment and they only need to create and submit packages while we handle everything else for them. With immutable images, problem determination of issues in any environment is much faster since we can be sure that what is in a QA environment is exactly the same as in production.
- Leveraging container health checks and deployment constraints means all of this can be done with near infinite up time on top of a multi-tenant platform in complete encapsulation and isolation from all other tenants. Using health checks and deployment constraints, the container orchestration framework will manage containers and distribute them with optimal capacity management within one or across multiple data centers.
- Using immutable images and a simplified deployment pipeline also allows us to scale up the capacity of a tenant’s IBM Digital Commerce environment quickly to respond to increased workload. By simply deploying or removing existing customer specific immutable images, we can rapidly scale up or scale down capacity on demand to meet changes in workload. The container management framework lets us quickly add more nodes to scale up capacity in the data center, as well to ensure that your application can always meet your demands and grow with your business.
This same paradigm shift has been applied to WebSphere Commerce V9 to allow our on-premise customers to achieve similar benefits.