Guest: Julian Fischer (LinkedIn)
Company: anynines (Twitter)
Show: TFiR: T3M

anynines utilizes Kubernetes as a primary framework to build new-generation products. With large enterprises as its primary customers, it provides a particular perspective about the current Kubernetes landscape. In this episode of TFiR: T3M, anynines CEO Julian Fischer shares his insights on what is happening and what is still needed in the market, particularly around Kubernetes complexity.

Highlights of this video interview:

• The ability of Kubernetes to be extended by custom resource definitions and controllers has made it the framework for building cloud automation these days.
• An ecosystem with a lot of possibilities for extensions adds a layer of complexity. Having a lot of Kubernetes clusters where each cluster may look different adds to the complexity that creates a lot of operational friction.
• There are more solutions out there to deal with Kubernetes complexity, in the sense that it is simpler to bootstrap Kubernetes clusters today. However, there are also more Kubernetes features and extensions that are in demand regularly, so any Kubernetes offering requires the popular Kubernetes extensions to be there.
• When using libraries in your code, you need a good package manager that does complexity management and dependency management. It’s one of the bleeding edges in Kubernetes these days, especially with a large number of Kubernetes clusters. With a good CI/CD (continuous integration/continuous delivery) pipeline, you can manage the lifecycle of a single cluster with a few extensions with ease, but for larger organizations, that’s a different story.
• From anynines’ perspective, with large enterprises as its primary customers, the tooling to deal with large platform environments gracefully is still missing. When it comes to data service automation, anynines has tried several lifecycle management tools, but none of them is suitable to cover at all.
• There are a lot of tiny building blocks being developed in the Kubernetes ecosystem. Crossplane, for example, is trying to bring inter-cluster and configuration beyond Kubernetes into a declarative language that’s based on Kubernetes.
• anynines utilizes Kubernetes as a primary framework to build new-generation products. One of the problems it sees is tenant management, i.e., how to represent organization units of a large client and be able to restrict their access and management of a certain number of users to a particular tenant.
• anynines believes in having a healthy relationship with the underlying infrastructure, which means not to depend on their tooling too much. Take the commonalities, but shy away from those vendor-specific constructs wherever possible, especially if they are provided by the infrastructure vendor.
• A marketplace is about 1) browsing and discovering the backing services that are available, and 2) provisioning and, to a certain degree, configuring it. For a large enterprise using Kubernetes at scale, having such a marketplace to tell the developers of individual departments which tools they can choose from is essential.

What’s ahead for anynines:

• Release a framework to build a marketplace. It will be easy to download metadata for anynines products, but you can also import data from AWS, GCP, or any other provider so that developers within large organizations can discover and choose from the tools that have been cleared by platform operations or the platform managers within an enterprise.
• Release a user interface (UI) framework to be able to do white labeling and write components for each cloud service you want to integrate in the console. The marketplace will also be built on the same UI framework.  

This summary was written by Camille Gregory.