Over the past decade, distributed server-side frameworks and technologies have gained a strong foothold in the market. Driven originally by web-scale companies, distributed has become a gold standard that every organization – including traditional enterprises – aspire to achieve.
The answer is fairly simple: distributed systems, due to their inherent design tenets, lead to higher quality software outcomes and the ability for higher development agility. Distributed systems tend to allow for resiliency, scalability, flexibility, and on-average-higher overall service performance.
Distributed systems also allow teams to independently modify parts of such a loosely coupled system in parallel, allowing for a fast release cadence. This does come at a cost, however. Distributed systems are notoriously difficult to build and debug. If only developers had a technology that would commoditize the complexity of distributed architectures…*cough* Kubernetes *cough*
Kubernetes burst onto the scene a couple of years ago to invert the cost dynamic; building a distributed app can be done in a fraction of the time and at a fraction of the cost than previously possible. Kubernetes took the approach of capturing the general nature of distributed as a flexible runtime, and exposing a number of primitives that allow one to shape how that runtime behaves in the context of a given application.
This “Distributed Primitives as an API” (DPAPI, anyone?) approach allowed for Kubernetes to focus on the appropriate complexity one would expect of a distributed application fabric, while exposing control through a clean separation of concerns. Now that we can build distributed apps so easily, it would seem that Kubernetes has fulfilled its destiny.
We haven’t even scratched the surface with Kubernetes. Kubernetes is a highly generalized system with no domain specificity. The real power of Kubernetes isn’t its primitives; the real power is that it is, itself, a primitive for higher order application platforms that have distributed needs.
In nearly every industry, the complexity of the problem domains that developers are tackling is very high and only increasing. From computer vision, deep data analysis, high scale systems, to domain-specific complexities such as financial modelling and scientific computing, developers are going after everything.
Most of these problem domains not only require sophisticated, domain-specific constructs to reach solutions, they also require the sort of computing horsepower available only through distributed patterns. In these cases, solution complexity is even higher than normal: you need to solve hard math and science problems *and* hard software architecture problems.
This is where Kubernetes comes in.
Kubernetes commoditized the complexity and cost of distributed & exposes control in a deep, predictable way. Anyone building a platform for developing domain-specific apps no longer needs to concern themselves with any distributed constructs. Because of this, I think we’ll find that in the future, Kubernetes becomes the primitive that powers many, many other platforms. We’re starting to see it already.
Do you want serverless? Use something like Fission (or possibly OpenWhisk in the future) on k8s. Need a distributed numerical computing platform? Write a DSL that is Matlab compatible and lay it down as an abstraction over k8s. Want a PaaS? Create a service provider oriented app platform model that consolidates Kubernetes primitives into developer workflows and services as well as platform workflows and services and lay it down over Kubernetes (and no, PaaS & Kubernetes don’t compete. PaaS is a use case, not a thing. Read more here)
Because of Kubernetes, we’re going to see an explosion of domain-specific, specialized platforms come to market. Developers are now equipped with the best distributed DNA possible, with no need to re-invent the wheel. The killer app for Kubernetes isn’t an app at all – it’s other platforms.