Shipa Vs OpenShift: A Comparative Guide

With the advent of a popular PaaS like Red Hat OpenShift, developers are able to focus on delivering value via their product, not building IT infrastructure. Red Hat OpenShift is a multifaceted container application platform from Red Hat for the development, deployment and management of applications. OpenShift is a layer on top of Docker and Kubernetes that makes it accessible and easy for the developer to create applications and a platform that is a dream for operators to deploy containers on for both development and production workloads.Today OpenShift is heavily used by enterprise IT but let us agree to the fact that customizing and building a complex platform and services adds no specific value to your organization and complication is intrinsically a killer in and of itself, an exponential risk to your chances of success. 

Today you need to enable your developers to self-service through a continuous operation platform and empowering them to deploy and operate their service with minimal Ops intervention.Enabling developers to self-service means treating Ops as a product team. The infrastructure automation, deployment automation, configuration management, logging, monitoring, and production tools — these are all products and it’s these products that allow teams to fully own their services. This leads to empowerment. Products enable ownership. We move away from Ops as masters of production responsible for everything and push that responsibility onto dev teams. They are the experts for their services. They are best equipped to deal with problems that arise but we provide the tools they need to diagnose and resolve those problems on their own. 

Continuous Operation for Cloud Native Applications 

Shipa is reinventing how cloud-native applications are delivered across heterogeneous clusters and cloud environments. Our landing pad approach allows Platform and DevOps teams to build security, compliance, and operational guardrails directly into their infrastructure while enabling Developers to focus on what matters, delivering software and changes that will add value to the organization. With Shipa, teams can now focus on the application delivery and governance, rather than infrastructure.Shipa implements a clear separation of concern between Developers and the Platform Engineering teams, improving Developer experience, governance, monitoring and control. Shipa provides native services to applications that are available right at deployment, services such as different databases, queuing, canary based deployment, deployment rollback and more, allowing Developers to focus on application code delivery while platform teams support development speed and experience, rather than spending time and effort installing and maintaining different infrastructure components.

Now you might be thinking why the world needs another offering such as Shipa, and how it’s different. Under this comparative blog post, I will be taking a deeper look at how Shipa compares to OpenShift. 

Key motivation to become Cloud-Native 

Before we deep dive into the comparative world, let us first try to chart out top capabilities to consider while evaluating an enterprise Kubernetes Platform to become Cloud Native: 

– Developer Productivity 

– A Cluster Agnostic Platform 

– Application Portability 

– Resiliency 

– Multi-Cloud Support 

– Scalability 

– Out of the box Monitoring 

– Out of the box Security

– Seamless 3rd Party Integration 

– OpenAPI & Extension to Edge devices 

– Business Agility 

– Cost Saving 

– Automated Routing & Observability 

Let’s deep dive into each of these capabilities and see how Shipa fits into Cloud-Native world: 

Cluster Agnostic Platform 

The world is moving to cloud-native architectures with multi-vendor, open-cloud hybrid systems. As compared to OpenShift which locks you to OpenShift only, Shipa is purely a cluster agnostic platform. It means that users can attach any Kubernetes clusters to the Shipa pools, such as GKE, on-premises, AKS and so on.You can connect Shipa’s landing pads (also known as Pools) to multiple clusters, across multiple clouds, such as GKE, AKS, EKS and OKE to centrally configure policies at the pool level, monitor applications, monitor security, perform deployment rollback and others, helping your team deliver on governance and control goals required by your organization. 

Users can install Shipa on any existing Kubernetes cluster (1.10.x to newer versions). Shipa leverages Helm charts for the install and it supports both versions, Helm 2 and 3. Fully automated deployment and easy UI-driven wizard gets Kubernetes clusters running in a few minutes. Hence, you can manage clusters with one-click UI-based upgrades and troubleshooting. 

Application Portability 

OpenShift generally offers multi-cluster management for OpenShift clusters only. Comparatively, Shipa has the capability to offer multi-cluster management through Pools. It handles the application lifecycle across multi-cluster & clouds, no matter if it’s GKE, EKS, AKS, and irrespective of Kubernetes version difference, no matter if it is 1.14 or 1.16. 

Shipa makes the underlying cluster and infrastructure irrelevant. It means that users can move apps between different clusters flawlessly. It is responsible for moving the app and creating the required application objects, which can help in scenarios such as high-availability, cluster upgrades, multi-cloud and others. 

Shipa uses the concept of a landing pad, called Pools, to bring application context to your application delivery and management workflow. Pools are where your CI/CD pipeline will deliver the application code and where the process starts with Shipa. Once code is received, Shipa pools are responsible for creating application objects, run security scans, attach policies, start producing application metrics and more. A Shipa pool can host nodes from multiple cloud providers and will distribute your application units/containers across multiple clouds/nodes 

Enhanced Out-of-box Monitoring 

In Shipa, monitoring comes out-of-the-box, with the option to also export it to 3rd party tools, such as New Relic and Datadog. Since application objects are created, deployed and monitored automatically, now developers can focus solely on delivering application code rather than worrying about monitoring tools. 

Enhanced Out-of-the-Box Security 

OpenShift requires you to install additional tools to have security in place and still be somewhat complex for the operations team. To harden OpenShift, you need to be aware of sophisticated tools like SELinux, Stateful and stateless inspection firewall, process/network/storage separation, OAuth to authenticate using an identity provider, such as LDAP, GitHub, or Google and much more. 

Under Shipa, Security comes out of the box.While Shipa allows security configuration at the pool level, which makes it flexible, especially when there are scenarios of multi-tenancy and/or services deployed across different pools with different requirements and because its native to the pool, no additional tools or setup is necessary 

OpenAPI & Extensible to Edge Devices 

Capability of using docker nodes, not only Kubernetes (Shipa nodes), so you can leverage cloud instances such as EC2 and others as well as extend it to edge devices that are linux based. Shipa’s APIs are open and documented, allowing Platform and DevOps teams to integrate Shipa with additional external platforms as well as leverage Shipa as the center of their automation strategy. In addition to that, Shipa has the concept of Plugins, which allows DevOps and Platform teams to build even further automation inside Shipa that can be used at different stages of the application operation lifecycle. 

Say “No” to YAML 

If you are looking out for a platform that allows you to think and operate applications rather than infrastructure when delivering services, across any infrastructure. Shipa abstracts away the need for creating and maintaining object yaml files, not only for applications but across, such as with volumes management. Many of the components on OpenShift still require you to deal with Kubernetes object yaml files as well as custom scripts for actions such as certificate generation and encryption for apps. With governance, guardrails and automated object creation and management in place for applications, developers can focus on writing code that delivers value and services to the organization, not worrying about the infrastructure that runs them 

Since application objects are created, deployed and monitored automatically, Developers can focus solely on delivering application code rather than learning Kubernetes related requirements. And as Shipa integrates into your existing CI/CD workflow, Developers do not need to change or learn additional tools. the need to learn or create any yaml or volume related files, improving Developer experience and application delivery speed. 

Automated Routing & Observability 

Shipa’s DNS capability ensures that users can reach your application from the moment it launches, with no extra effort required with capabilities such as Canary Deployment and

Deployment based rollback, which allows Platform teams to ensure applications are also available. At application deployment time, Shipa provides automated monitoring and application related metrics, helping you better understand the status of your applications, which can also be exported to 3rd party monitoring platforms. 

Support to Persistent Application 

Shipa supports connection to all major CSI providers, allowing Platform Engineering teams to make volumes available across different clusters and CSI providers at the pool level, so Developers can just attach these available volumes to their application, without the need to learn or create any yaml or volume related files, improving Developer experience and application delivery speed. 

Conclusion 

In nutshell, Shipa has re-addressed the traditional PaaS model compared to Red Hat OpenShift & added extra value to enterprises cloud native successes, especially for enterprises key objectives listed below: 

● Even though OpenShift helps a bit on the developer side, it still hold “object oriented/context” rather than application context, so you can expect your platform, devops and development team to still be tied to infrastructure and objects rather than on app only. 

● With OpenShift you will end up locking you up on an OpenShift only platform, which becomes expensive in the long run . Additionally, the platform doesn’t allow you to use different clusters, versions and others that might be best for your application requirements. 

● Shipa leverages and creates the application and its objects inside the cluster, so in future, if you decide to move away from Shipa, your apps will continue working (you will just have to take on the burden of managing everything and every object manually) 

● OpenShift upgrades are painful, takes time and if not planned right, can impact your environment and applications. 

Hence, Shipa provides native services to applications that are available right at deployment, services such as different databases, queuing, canary based deployment, deployment rollback , out of the box monitoring & security and more, allowing Developers to focus on application code delivery while platform teams support development speed and experience, rather than spending time and effort installing and maintaining different infrastructure components.

Leave a Reply

Your email address will not be published. Required fields are marked *