As we kick off the new year and our release of Shipa 1.5.0, dabbling in the art of the possible, what if it was possible to provide your developers with a single line of configuration to get their ideas into production. Shipa is an application and policy abstraction layer which easily integrates with your DevOps toolchains.
Looking at where major DevOps trends are headed, a common theme across many tools and practices is improving the Developer Experience or DX. One paradigm of thinking is that if you improve your internal customer experience, then your external customers will benefit too. However, up until now, the Developer Experience has been quite siloed and segregated for a multitude of reasons, such as scaling or having best-of-breed technologies to support individual concerns. Presentation on DX.
In this article, you will learn a bit about how you can deploy an app in IaC way to Kubernetes using Shipa and Azure Pipelines. Shipa is a unique product that solves one of the main issues that developers face while developing Cloud Native applications on Kubernetes. The underlying issue of learning Kubernetes in a faster phase is a difficult task for most of the new developers, that is where Shipa comes to the rescue.
A while ago, we wrote about using GitHub Actions to enable a developer-friendly CD process for Kubernetes. The goal was to show how DevOps or Platform Engineers could give developers an easy way to define and deploy their applications themselves with the target of implementing a self-service model.
Much has been written over the years about DevOps and, maybe a bit more recently, about Platform Engineering. Both jobs focus heavily on designing, building, maintaining, extending, and automating underlying infrastructure components (e.g., Kubernetes, monitoring, security, pipelines, etc.), so their end-users, often developers, can consume it as an integrated platform.
Shipa in your organization/team can help usher in the next generation of engineering efficiency and developer experience. Though like any platform, there requires some wiring to bind Shipa to infrastructure. In this modern example, can plug into your IaC strategy in creating Kubernetes clusters then auto-wires all of the needed Shipa pieces at cluster creation time.
One more “ops” phoneme like DevOps is ChatOps; or conversation-based development/operations. ChatOps has been growing in popularity as communication platforms such as Slack is ingrained in our day-to-day engineering lives. A team lead once told me “if it didn’t happen in Slack, it didn’t happen” showing the emphasis of communication platforms as a system of record.
Systems and platforms continue to grow more complex and distributed. The march towards distributed microservices has been accelerated with Kubernetes; arm yourself with a Kubernetes manifest and up your replica count and like magic, you have more than one endpoint for your workload. In the Kubernetes ecosystem, there has been a lot of investment on the infrastructure side of the house for example in making sure clusters are performant and have the ability to scale.
As Kubernetes becomes the key target environment across many organizations, it automatically becomes an essential topic for developers. However, Kubernetes was created for operations and, unless you spend a considerable amount of time learning and specializing yourself, it is still challenging to use. Developers should rather focus on delivering applications instead, and a developer or application-focused platform is needed to enable that.
Kubernetes is viewed as one of the great equalizers between development and operations teams. Simply write a manifest and the declarative power of Kubernetes is off to fulfill your desired state. Kubernetes is certainly pluggable and has the ability to be extended / opinions being swapped internally. As any IT organization can tell you, even with Kubernetes there is a lot of integration work, and several parts of the stack such as IaC have been left outside of Kubernetes.
