TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
Kubernetes

Don’t Pause Your Kubernetes Adoption ― PaaS It Instead!

Adopting a PaaS abstraction can fast-track Kubernetes for software engineering teams of all sizes and shapes.
Sep 27th, 2022 10:00am by
Featued image for: Don’t Pause Your Kubernetes Adoption ― PaaS It Instead!

If you are working with cloud-based software, it is impossible to ignore the Kubernetes factor right now. Most teams want to leverage the full benefits of containerization and orchestration, using Kubernetes of course. However, they are having trouble in two important areas:

1. The broad set of skills it takes to deploy and operate Kubernetes in production

2. The depth of business outcomes and how to justify spend for Kubernetes

In this article, let us explore the various technical and non-technical areas that have an impact on Kubernetes adoption. The insights provided here are from the personal experience of the author and countless hours of interaction with varied technologists around the world working with Kubernetes in different ways.

Defining the Starting Point

The move to Kubernetes can be complicated for software development teams depending on their present state in the cloud native evolution.

There could be teams working with Docker or containers already, in which case the move to Kubernetes is an organic one. Teams might also be invested heavily into virtual machines, from where they will have to leapfrog containerization and orchestration in one go.

There may be some teams whose workflows are dominated by cloud abstractions, thanks to PaaS tools, in which case the path to Kubernetes will require some bespoke engineering efforts to accommodate the changes. The use of modern tools and a sufficient quantum of automation are expected of all teams interested in a move to Kubernetes. Therefore, every path to Kubernetes has a puddle (or two)!

Has this Happened Before?

With Kubernetes, there are a few “firsts.” It is the first open source community that has demonstrated amazing growth! The number of contributors has grown fairly large, rather quickly. A 2021 survey by the Cloud Native Computing Foundation reports 3.9 million Kubernetes developers worldwide, representing a 69% growth from the previous year. An excess of 2.8 million contributions, shaped by 100,000+ commits, made by over 4000 organizations since the start of the open source project, forms the trajectory of Kubernetes. These numbers position it as one of the most popular open source projects of all time, and its popularity continues to grow.

This, however, isn’t the first time technology adoption has thrown up hockey-stick curves. Several trends have shown tremendous promise in the past, especially when it comes to technology trends. In particular, the adoption of Docker between 2011-2015 and the trajectory of the VM hype before that come to mind.

The PaaS Substrate

A Platform-as-a-Service or PaaS is defined as an abstraction over infrastructure that runs applications and hosts stacks. Typically they are made available as an environment to software development teams, to which applications can be deployed. Depending upon the design of the PaaS substrate, a developer is presented with an interface that allows them to tune the parameters needed of the infrastructure, while also specifying the size and shape of the application that they are deploying. Typically, PaaS tools also allow services to be consumed using extensions.

Commonly, different languages and frameworks tend to use different paths to production. When using a PaaS, the interface provides a homogenous and uniform means to deploy applications, irrespective of the language used to write the app. Apart from this, PaaS tools make use of a control plane, which plays a central role in the way it operates.

The control plane — true to its name — allows various aspects of the application management through provisioning, access, and configuration. Services are a big part of the PaaS toolchain. They are provided independently of the core PaaS capabilities, often in the form of connectors. These connectors are given different names (marketplace, foundations, services, brokers, etc.) are meant to make applications deployed using a PaaS feature complete.

The PaaS Promise

  1. PaaS can support custom workflows to enable teams to function efficiently.
  2. PaaS enables the introduction of new ways to build, run, and deploy apps easily.
  3. PaaS allows underlying technology to be swapped out with no impact on teams.

Examples of Tools

There are a number of tools that can help bridge the Kubernetes gap for teams. Here are a few examples:

OpenShift from the RedHat stable is a popular example of a successful containerization and Kubernetes platform. Cloud Foundry Korifi is an attempt from the Cloud Foundry community to help deploy workloads to Kubernetes easily. It preserves the time-tested cf push experience and is an open source tool that can be deployed to a Kubernetes cluster of choice, making it a compelling choice. Recent announcements also include Epinio, Acorn Labs, Porter, and KubeVela.

Tradeoffs (Duh!)

Caveats about choosing one opinionated workflow for the other tend to dominate the discourse when talking about PaaS platforms. About a decade ago, Gartner published an interesting paper titled: Productivity vs. Control tradeoffs in PaaS. Some of the issues highlighted in it remain in contention to this day. Engineering leadership should not have to choose between performance efficiency for their development teams versus operational excellence for their SRE folks.

Upgrades, packaging, security, and other engineering aspects that PaaS tools profess to provide are slowly being resolved due to a massive shift towards containerization. Homogeneity in builds is gradually becoming a norm, thanks to trends such as GitOps, Buildpacks, and some declarative-syntax providing automation.

Many services claim they avoid lock-in because they’re standards-based, and thus you can move your code anywhere. This may be true on one side, but the other side is that you’re locked into what the service provides.

Summary

PaaS tools have often helped facilitate technology shifts. They have demonstrated a history of success when navigating the ambiguous waters of shifting tools. Software engineering teams have plenty to gain when employing a PaaS tool to help them with adopting and adapting to new tools — particularly Kubernetes.

For small and lean software engineering teams PaaS tools can yield higher productivity per developer by allowing them to focus on application development as opposed to integrated delivery and Kubernetes readiness.  For slightly larger teams that have focused operations needs, PaaS tools can help with granular adjustment of each deployment and apply deployment best practices uniformly across the organization. For enterprise-scale teams, PaaS covers the critical areas of security and compliance in addition to providing the underlying deployment, packaging, and other basic functionality.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Docker.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.