For many of us in the technology world, around the holidays family will always ask you to solve their technology problems. Being in February, I am only several months away from sharing the below card with my family, again.
As a software engineer, we might be viewed as the masters of technology. Though like any skill acquired over time with constantly changing paradigms, there is a long road from idea to production which continues to evolve. The rise in Full Lifecycle development practices e.g “you write it, you run it” has been an increasing burden to software engineers. With the amount of expertise being shifted left in the name of engineering efficiency actually is producing toil as disparate skills are now placed on those in charge of developing features. Prior software engineers developed features and infrastructure was left to other teams and domain experiences to manage. Today with shifting left and Full Lifecycle models, there is a lot more on engineers’ plates. We are evolving from navigating change management to navigating the entire stack.
The Golden Days – Ticket Based Infrastructure
Take a trip down technology memory lane to a decade and change ago. You might have several development Virtual Machines with various tools. Though as you march towards production, tickets will need to be created for a systems engineer to create needed infrastructure.
From a developer’s perspective, we could focus on writing our features. Other teams would create and maintain the infrastructure/application infrastructure outside of our local machines or development integration environments that we need. Though this required change and ticket management. Lead times certainly were more lengthy as they were today. With advances in Infrastructure-as-Code e.g IaCs, cloud infrastructure, and the introduction of Kubernetes, a lot of items have been shifting left.
Hello, Mighty Kubernetes
With the rise of Kubernetes, there has also been a rise in Full Lifecycle development models. If you can author code, you should be able to author a YAML? With that thinking, almost anything can be authored as some sort of Kubernetes Resource. Organizations that embrace a platform engineering mindset around Kubernetes now have split responsibility; those whose workloads go on Kubernetes and those who maintain and scale the clusters.
Though this model requires a lot of expertise and tooling on both sides. Kubernetes from a developer standpoint should be an implementation detail but as many items shift left, this creates a gap.
Something is Missing
As a feature developer, Kubernetes should be an implementation detail. Though the lines tend to blur and system engineering practices come back e.g “we provide the infra, it is your workload” comes into play. The lines are even more blurry on what constitutes a piece of infrastructure in Kubernetes vs functionality. To have a vanilla Kubernetes cluster is one thing, but most likely multiple tools and packages will need to be installed. As new paradigms appear, so do the need to learn these paradigms e.g Service Mesh and GitOps paradigms.
There is certainly a long road between your feature and being deployed on Kubernetes. As items continue to shift left, where is the line in the sand? As even Linux Internals e.g eBPF are exposed, developers should not need to dig into those components to get their features out the door. Shipa provides a common sense and plain-English-based approach for abstraction and policy enforcement.
Shipa, The Ultmate Internal Developer Platform
Shipa aims to make Kubernetes an afterthought for developers. Deploying to Kubernetes should be an implementation detail. Though for the DevOps/Platform Engineers, the ability to enforce policy and standards on the abstractions that Shipa provides is also key.
To deploy with Shipa, all you need to point to is an image. The below is an image of this in the UI. A one line Developer Experience [DX] is certainly possible with Shipa.
After your application or microservice has deployed, getting information about your running application in Kubernetes has primarily been infrastructure-centric. For example, running “kubectl describe pod -n namespace podname” will bring back a lot of items that a feature developer would have to delve through to understand. Shipa provides a clear application map e.g an application-centric view of what you have just deployed and what is running in Kubernetes. With Shipa Application Discovery, now you can point Shipa to a Kubernetes cluster and get application-centric data and graphs.
We are excited at Shipa about improving the Developer Experience and bridging the software engineer divide. Make sure to check out our webinar where leaders in the space talk about moving the platform engineering and Developer Experience needle.
Cheers,
-Ravi
