The Shipa Application Framework Packages Kubernetes for Developers – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn The Shipa Application Framework Packages Kubernetes for Developers – InApps Technology in today’s post !
Read more about The Shipa Application Framework Packages Kubernetes for Developers – InApps Technology at Wikipedia
Solving complex problems often involves some level of complexity, and Kubernetes is no exception. To handle that complexity, managed Kubernetes services like Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS), among many others, have popped up in recent years to abstract away some of that complexity.
Nonetheless, the central focus of these services is still Kubernetes itself, and now a new breed of abstraction has begun to appear which goes one step above these managed Kubernetes offerings to bring the focus back to the application itself. One such recently-launched company, Shipa, delivers a cloud native application management framework built to manage the full application lifecycle in an application-centric fashion.
According to Shipa founder and CEO Bruno Andrade, the problems they saw came from two directions, first at developers and then the platform engineering team.
For a developer to deploy a Kubernetes application, “they have to understand what stateful sets are, how to set up Ingress controllers, they’ve got to understand Istio and how YAML works. It adds a lot of complexity because Kubernetes ends up dragging the developer down to the infrastructure layer level,” said Andrade. “On the other side of the fence is the platform engineering team trying to abstract Kubernetes away and give their developers a better-automated way to deploy their applications. For that, organizations are scaling the platform engineering team like crazy. They’re spending a lot of time building a bunch of customs scripts, ways to automate Helm charts, and the number of objects in the clusters just goes nuts.”
Shipa’s approach to solving this problem is to give the platform engineering team a way to define a framework, within which developers are then able to deploy their applications without having to worry about Kubernetes configuration files. The engineering team defines application-level requirements and the infrastructure level components, such as storage, tracing, logging, even what flavor of Kubernetes lies underneath, leaving the developer to focus, again, on the application rather than Kubernetes.
“All the solutions that you see are very focused on solving the problem from a cluster perspective, rather than the application. So we started looking at it in a different way, where we thought about creating an application management framework that sits on top of these multiple Kubernetes clusters,” said Andrade. “Your developer could care less if it’s Kubernetes, GKE, or EKS, or 1.15, or 1.17. They don’t have to care and know about that, because now they don’t need to create one single Kubernetes object file. They just deploy their application and CI runs its process and delivers the application directly to the framework that the platform engineering team created.”
From there, the framework is responsible for enforcing the policies, patching resources and creating all the objects for your application, as well as deploying the applications on the cluster. Shipa itself, like many cloud native tools, is written in Go, and currently provides more than 30 integrations with tools like Prometheus, New Relic, Jaeger, Longhorn, OpenEBS, Envoy, Traefik, Istio, and more, with more on the way. Beyond existing integrations, Shipa also offers an open API, so that users can integrate the Shipa framework with their preferred external platforms. As a Kubernetes abstraction, Andrade says that the flexibility in swapping out these various cloud native tools is one of the main features for the platform engineering team
“The way we’re building Shipa is that if tomorrow you come in and say ‘I want to move from GKE to AKS,’ you, as a platform engineering team, have a lot of controls and you can swap those components underneath, but that does not impact the user, the developer, or the applications,” said Andrade. “We want to build something that finally breaks through that vicious cycle of the platform engineering team, where every time there’s a new cluster or a new technology or something they have to rebuild the whole platform. That’s the goal.”
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.