De-Risk a Technology Startup – InApps 2022

Everything that surrounds a startup smells of risk. The business model, the team, operations and most important of all, technology choices.

There are numerous ways to help a startup reduce, and at times eliminate, risk.

Some are strategic (build vs. buy, infusing investment), whereas others are more tactical (OPEX to CAPEX, insurance, pivots).

Books, blogs and social media are full of ideas about how to anticipate and mitigate risks that have an economic, product or executive perspective.

What isn’t discussed as much is the systemic risk that is a consequence of the technology choices that startups pursue.

Numerous CTOs — and/or CIOs — have expressed how they have handled the entropy associated with technology within their startups.

Infrastructure, languages and frameworks, middleware, databases, build and release processes, internal applications — well, the digital footprint can be massive, even in small organizations.

Adding to the uncertainty are open source tooling, outsourcing and migrating to new tools.

In this article, we focus on a singular aspect of this sprawl, which is about migrating to new technologies.

Of particular relevance today is the migration to Kubernetes. This article discusses a combination of tools and techniques to help manage this migration while mitigating a large fraction of the risks associated with it.

Kubernetes is a container orchestration tool that has been open sourced. Since the introduction of Kubernetes six years ago, it has really reinvented the world of cloud-based infrastructure. Today, it represents a paradigm shift in the way engineering teams of all sizes approach their application hosting strategy. The containers craze of the previous generation, and the virtual machines vogue of the generation before, pales in comparison to the overwhelming rate of Kubernetes adoption.

Our observations of engineering teams lead us to classify them into three major categories: those who are comfortable using Kubernetes, those considering Kubernetes and those who are finding their feet with Kubernetes. We have terms for these: Kubernetes, New-bernetes and Noob-ernetes! Software engineering teams that belong to any of these categories have problems, but very different ones.

Those teams who haven’t adopted Kubernetes yet are faced with the formidable challenge of a migration to new infrastructure management methods. Those teams that have just adopted Kubernetes face the risk of demanding Day 2 problems. Those teams who have migrated to Kubernetes fully will find themselves navigating the complexity of integrating them into CI/CD pipelines, managing updates, etc. This begs the question: Does technology truly solve problems?

Technology definitely provides answers to problems. Granted they may be fixes to yesterday’s obstacles, and they may also introduce new ones. But applying these lessons and evolving is the way forward with technology. In the context of Kubernetes, there may be a few reasons to hold off on migrating, but the reasons that favor the migration far outweigh the opposing view.

By their nature, startups face numerous constraints. Raw engineering person-hours are limited. The bandwidth to focus on product features is low and available only at a premium. Quite often, that bandwidth for nonfeature development is zero or nearly. The available budget for technology migration is usually scoffed at when presented to upper management. It is for these very reasons that pragmatic migration strategies, that will help adopt new technology, can be very hard to come by. Couple that with the cost of training and upskilling for Kubernetes, finding and retaining talent, and soon the adoption of this new tech, in spite of its inspiring success stories, becomes a hesitant venture.

They say that the most value from success and failures comes in the form of lessons learned. One particularly interesting set of lessons comes from what the Cloud Foundry community has done in enabling a simpler developer experience over Kubernetes. It is a story about evolving technology to embrace Kubernetes to show how startups can de-risk their technology choices.

For background, Cloud Foundry is a platform that aims to provide a highly efficient and modern model for cloud native application delivery. Cloud Foundry comes from a history of a VM-based architecture that evolved into the use of containers as immutable artifacts for deployment using an orchestrator to effectively manage these containers at scale. Recently, its open source community opted against developing a parallel standard for container orchestration and opted for Kubernetes.

As part of the transition, many custom components were replaced with Kube-native ones — Istio for networking, Envoy service meshes, Fluentd for logging, etc. This is now available as the cf-for-k8s project, a reinvention of Cloud Foundry delivered on Kubernetes infrastructure that is in line with its proven pedigree of functioning at scale.

As a model for any startup, here are the problems Cloud Foundry open source technologies had to solve with Kubernetes and the lessons we learned, which hopefully you can apply in your organization.

Problem: Kubernetes presents a significant cognitive overhead for application developers.

Lesson Learned: Cloud Foundry abstracts the Kubernetes interface completely. Instead, developers interact with the Cloud Foundry CLI, which has a small set of commands and can provide all the necessary capabilities to work with Kubernetes clusters.

Problem: Containers make it hard to make updates and attach services to existing applications.

Lesson Learned: With the use of sidecar injections, service brokers and a simple deployment interface (Cloud Foundry and Kubernetes), updates to applications become easier and more convenient.

Problem: Maintaining several deployment pipelines due to the use of various languages and frameworks

Lesson Learned: A uniform cf push process, and the subsequent use of buildpacks, supports the deployment of applications/microservices built using any language or framework. The build and deploy process when using Cloud Foundry is language agnostic. Even nontrivial builds can be deployed with a combination of buildpacks.

In summary, startups can benefit greatly from adopting Kubernetes early in their lifetimes. This will benefit their teams greatly by eliminating a lot of toil when they scale. It is an important stepping stone toward rapid development, fast and frequent releases, and reliable applications on production. This will, at least, de-risk your technology choice, leaving you to focus on important other considerations like your startup’s business model, team and operations.

All images in this article are taken from www.freepik.com.