Three Questions to Ask Yourself Before Undertaking an OpenShift Project

So you’ve decided to take the plunge into the container world, adopt Kubernetes, and manage all of this through OpenShift, but have you made sure you’re ready to do so? Containers and OpenShift are fantastic tools to move your organization into more modern practices, an optimal cloud-ready position, and increase the speed of development while delivering a more scalable product to your end-users, however; we need to address some key components that need to be in place to maximize the benefits and sense of containers and OpenShift. In this post, we’ll be discussing 3 important questions one should ask themselves before taking on OpenShift.

Question #1: Are your applications even ready for containers?

Probably one of the more important questions to ask ourselves is: “Are my applications architected in a way to make maximum use of container technology?” That’s a fairly broad and loaded question, so let’s break that down into the components we should most care about.

“Is my application stateless?” aka will my application port well to containers and Kubernetes given their collective ephemeral and transitory nature? Ensuring your application is constructed in a way that it will continue to function despite not having a stateful and static source of data or communicate with other components or databases is a crucial piece of considerate information when migrating workloads to containers and OpenShift. Is your application stateful? Don’t despair quite yet, OpenShift offers native persistent storage options and 3rd party tools, like Portworx, offer highly resilient and available container-native persistent storage solutions to ensure your application still functions normally.

Another consideration is how you’ve implemented session caching and is it configured in a way that will be sustainable and functional in a microservices environment. Another question would be whether or not you application is broken up into microservices already, is SOA-based, or still exists as a monolith? These basic application architecture questions are important to ask yourself before pushing forward into OpenShift.

Question #2: Do you follow GitOps/DevOps?

“GitOps” is the term describing the way one can rely on developer tooling to drive operations. “GitOps” is an operating model for cloud-native applications such as Kubernetes that enables continuous delivery through automated deployment, monitoring, and management by using Git as the “single source of truth.” Think of it as a focused, tooling and method-specific way of achieving DevOps within your organization and especially in regards to the development process. Considerations surrounding how Feature Branching is managed, limiting control to the Master, and so on.

The four key principles of GitOps that drive its successful implementation and adoption are:

  1. Being able to describe the entire system declaratively
  2. Versioning the canonical desired system state in Git
  3. Automatically apply approved changes to the desired state
  4. Ensure correctness and alert on divergence with software agents and tools

Having an organization equipped to operationally maximize and efficiently run to leverage containers, Kubernetes, and especially OpenShift will be a strong bolster to ensuring success in the near and long-term.

Question #3: How will you handle monitoring, metrics, and other Day 2 operations?

So let’s say we’ve successfully addressed the previous questions, now what? We’ve got our OpenShift cluster up and running, well-established development pipelines, everything is automated, for the most part, applications have successfully migrated over to the platform, so where do we go from here? Continued day-to-day operations focused on stability, resiliency, and high availability are now the focus, diagnosing problems when, and sometimes, before they occur and become larger issues. Operations have a two-fold job: keeping internal operations and environments available for continual development and access while maintaining the stability of services and the underlying supporting, crucial infrastructure to ensure end-users don’t experience any interruptions of service. Thus, we must consider our “Day 2” operational capabilities and methods like “How do we increase observability into our monitoring, metrics, and logging?”. Monitoring of services and the infrastructure is critical to service stability, thankfully OpenShift contains a wide array of native tools to assist in this like Hawkular metrics gathering, Prometheus monitoring, and logging pushed through an EFK stack.

Another, related area of concern is how do we handle resource allocation and optimization. We need to ensure certain teams have access to only so many resources so that there’s enough available for everyone, all while safeguarding against runaway applications by placing policy constraints on resource utilization at the namespace and cluster level.

Security is another important factor and should be a huge part of any strategy. Internal, organizational controls like RBAC policies and image promotion policies ensure internal security while maintaining external security integrity through measures like network hardening and tooling (like SysDig) to provide container and cluster security.

Lastly, how do we handle application and cluster state data? Do we have a backup and restore procedure dependable and robust enough to prevent significant interruption to service? How do we handle database schema changes without creating application instability? Can we ensure the desired state of the cluster will come back up in the event of a restart? Through persistent storage tooling, effective database management, and application architectures, we can achieve peace of mind regarding this area of concern.

Final thoughts

OpenShift provides a gateway to the future of application development, empowerment, and agility around infrastructure, and an effective tool with a rich feature set to manage it all with. OpenShift takes an already widely loved and adopted industry-standard such as Kubernetes and transforms it into a scalable, resilient platform as Kubernetes+++ with all the Red Hat certification, security, and support surrounding it. Alas, as stated prior, this is all well and good, but a proper execution strategy from app design, to organizational development methodology and culture, to operations management post-implementation all play large roles in t he overall success of an OpenShift deployment and projects.