Implementing storage: Approaches for stateful financial services applications on Kubernetes configurations

Financial institutions face technical and compliance challenges when implementing storage on Kubernetes platforms. We outlined some of the regulatory overlays affecting financial institutions and technology solutions that can help with compliance in a previous post. In this post, we describe the considerations possible from an architectural viewpoint.

Transition from stateless to stateful: logistical and technical components

Application delivery, which has expanded the capability of the financial services organization, has been accompanied with technical challenges to be surmounted as well. By necessity, new approaches and deployment models have been utilized, including storage concepts on Red Hat OpenShift.

The delivery of applications to production is a complex activity with many moving parts - and the challenge increases with stateful applications. Initially most organizations used containers for stateless applications where storage was not necessarily required. With the maturation of Kubernetes, more stateful applications with storage requirements are finding their way to the platform, including databases, caching platforms, documents, and images. 

In response to these new demands, Kubernetes and containers have arisen as a new paradigm of how applications are packaged and distributed--and are simplifying the deployment process. This is especially applicable as different teams must sync efforts and time deliveries-- all while remaining in technical and regulatory compliance.

Workload differences and storage formats

Differing workloads require a tailored format in the interests of optimized efficiency and performance. 

There are three types of storage formats, with suitability to various workloads:

1. File storage (e.g. NFS, CIFS) - best suited for storing and sharing files as data stored in a single piece of information in a single folder, and can be shared between different users or applications. 

2. Block storage - allows a storage system to place the smaller pieces of data wherever most convenient. Allows data to be retrieved quickly, and suited to enterprises performing large quantities of transactions which deploy massive databases. 

3. Object storage - a flat structure in which files are stored as discrete units (objects) and kept in a single repository. Well suited for static data, an agility and flat nature allows scalability to extremely large quantities.  In financial institutions, suitable for storing check images, monthly statements, and official documents. 

Our Kubernetes platform, Red Hat OpenShift Container Platform, has long incorporated storage capabilities. We also offer Red Hat OpenShift Container Storage, which is optimized for Red Hat OpenShift and is based on Ceph. It provides File, Block and Object storage to containerized applications, which allows optimal performance according to the specific workload required. Flexibility is provided via local disks or through cloud storage depending on where OpenShift Container Platform is installed. Additionally, an existing or new external Ceph cluster can provide those three types of storage to containers through OpenShift Container Storage.

Both architectures (OpenShift Container Storage with an internal or an external Ceph cluster) offer the capability for system administrators to provision Persistent Volumes to be claimed by containers, as depicted. 

Storage deployment - OpenShift and Red Hat flexibility

OpenShift Container Storage provides storage to containerized applications, allowing more  flexibility to accommodate unique requirements and situations. 

How might this help the different roles within an organization? Let’s first understand their typical challenges. 

Developers: Require the ability to define the storage requirements and claim it for their applications. Traditionally, they make requests to a storage administrator to gain allocation. As the application moves through environments (Development, QA, and Production) the request is repeated and subject to variations for the underlying infrastructure, which can cause promotion challenges and inevitable troubleshooting. 

Hybrid Cloud Administrators: Provide oversight for the platform, but also have the responsibility of providing storage facilities. OpenShift administrators have access to Persistent Volumes (PV) and ensure they are available, whether manually or dynamically, for developers to create Persistent Volume Claims (PVCs). As a corollary inherited task, their role also might make them accountable for storage life cycle management and storage content custodianship.  

Storage Administrators: Provide and allocate storage to the OpenShift Container Platform. Traditionally, they have worked with server administrators to provision storage to the applications. With OpenShift, the process for provisioning storage changes as the storage is allocated globally to the platform and not to the applications directly. Volumes can be claimed directly by the developer or the application once the administrator configures the storage classes that will create Persistent Volumes in the cluster. 

We see two possible solution implementations which ease coordination among involved parties:

1. OpenShift Container Storage installed directly on the OpenShift cluster with the Ceph engine running inside containers, consuming different raw storage sources depending on where OpenShift is installed (e.g. Amazon Elastic Block Store (EBS) storage on Amazon Web Services (AWS)). In a single pane of glass, totally integrated in the OpenShift console, this configuration offers File, Block and Object storage and enables applications to leverage it for their unique needs. The advantage of this implementation is that it provides the development teams with a minimal, but easy to use storage space, based on File, Block, and Object to get applications operational with a minimal organizational overhead, involving only the OpenShift admins for the initial configuration.

2. An external Ceph cluster serving as the storage source for OpenShift Container Storage. OpenShift Container Storage will still provide the same full integration of OpenShift to consume the Block, File and Object storage from the external Ceph cluster through simple Claims. However, in addition to providing storage to OpenShift Container Storage and OpenShift Container Platform, it has a wider range of support and Ceph capabilities to serve storage needs for applications on OpenShift, Virtual Machines (VMs), Red Hat OpenStack and bare metal. An inherent advantage is that the organization can leverage mature storage practices including, backup, retention policies, data classification and other compliance requirements.

Within both implementations, organizational models for separation of responsibilities and data custodianship can be met without adding burden to each set of distinctive duties and operating tasks. They both can address the distinctions between the storage life cycle and the OpenShift life cycle management. The involved OpenShift personnel can work to see that the Kubernetes services are stable and scalable, but do not assume the regulatory responsibility for the transient data through it. 

Conclusion and next steps

With data volumes and complexities increasing, financial institutions continue to embrace new methods and technologies to accommodate these ever-present challenges, including implementing storage on Kubernetes platforms. OpenShift Container Storage helps simply the management of storage along the life cycle of hosted applications--from development to delivery in production--with consideration of security and adherence to regulatory compliance. 

We invite you to learn more in our container storage Storage patterns for Kubernetes for Dummies ebook, or take advantage of our interactive learning scenarios for a hands-on experience.