Kubernetes is for people building platforms. If you are a developer building your own platform (AppEngine, Cloud Foundry, or Heroku clone), then Kubernetes is for you.

Where is my AppEngine clone on k8s?

I think you gotta build it

Coming relatively soon.

Relatively? April?

Let me clarify as I was being a bit flip, it’s not an App Engine clone, but it is CF on K8s. And though there are no firm dates the alpha already works , some work for it to be prod quality.

Thanks! That was my guess.

IMO in the coming years most compute workloads will be some form of hybrid between FaaS, “edge compute”, container-based stateless and stateful services. The cloud providers might be better positioned to deliver this unified platform.

the cloud vendors themselves might use Kubernetes under the hood - but that becomes an implementation detail. It’s going to be difficult for in-house platform teams to build a platform that can compete with what the cloud providers might be able to offer.

This is basically the bet that Pivotal Cloud Foundry is making right now— that developers need a variety of abstractions, that Kubernetes is a tool for delivering abstractions, and that orgs want on-prem & “multi-cloud” but that it’s uneconomical to roll and *maintain* your own.

Pivotal’s been a little slow on the Kubernetes uptake because we were like “What? Developers, why would you want something where you have to do your own logging/packaging/DNS?” So it’s fun to watch people explore k8s and discover that these PaaS things are pretty cool actually

But, it now looks like there will be industry-wide economies available from using k8s as our implementation for all kinds of things, so we’re pursuing that in a bunch of directions

Genuinely interested in how BOSH fits in that world. Anything you feel is shareable?

Currently unclear. We’re exploring! It’s already less externally facing— partners are moving to deploying services on PKS rather than BOSH natively. In the near future BOSH is our k8s deployer. As k8s matures in its own “day 2” capabilities we may have less need of that layer.

But that’s like years off— too long to make predications about implementation.

This echos my own experience with teams trying to clone Heroku. We were in year two of ECS+Convox+various services. Heroku is *deceptively* simple and you really don't have to worry about it. For us it was always unclear what "broke" -- was it our platform or the app? Every time.

But why would cloud providers be uniquely positioned to provide that platform? Why not open source / community?

This future can’t come soon enough. It’s such drudgery to wire up the same PaaS things over and over. Deployment Pipelines, AuthN/Z (cluster & app level), Observability, network load balancing, cluster upgrades...on and on, for what unique value? It’s pure toil :/

Back to the "mainframe" model in a nutshell where developers will be less and less in control

There aren't very many of those. And shouldn't be either

We use it in production. I don't know if you could call it a platform but it's an amazing solution for scaling our infrastructure.

The ideal situation would be that the application developer is unaware where their code runs. So Kubernetes like other platforms falls under the platform.

I find Docker Swarm is enough for most of use cases.

All of this just depends on what you’re doing.

Hmm, ok, I see your point. That works in a giant corp, but in small shops where everyone does everything, and the spirit of DevOps is alive, I think that no longer holds.

So everyone should learn Kubernetes?

Phrasing of the question is almost a trap :) ... Directly, sure - to some degree. OP: If building a platform (which lends to a broad interpret.), yes, as part of the value proposition to connect consumers <=> producers. YMMV

Fair but not my intention. I look at something like Heroku which has such a great dev friendly approach to this that the underlying k8s (or whatever) don’t even show. That feels to me more like the future, but I’m open to being wrong and worry I’m blind to other approaches.

Cool! not trying to "haha!" You into any wordsmithing on T. Heroku experience take into account other primitives off of native "the app"? Ex: I _need_ object store, k8s is a place to start and extend. Do I complicate H and then simplify? Am I better off?

I see it a bit like Windows or Linux, you have folks who like to dive deep, reveling in the more arcane and folks who want a GUI or simple commands to just get things done. OpenShift provides a number of abstractions, making Kubernetes easier

I feel the problem is that we fail to explain what we mean when talking about Kubernetes. Think about Linux: It's a concept. Just like Kubernetes. We have common kernel, modules, distros and managed solutions. K8S kernel & modules is for people building platforms. Rest is for all

Is it useful for providing a DevOps system for an organization?

No, but it can enable the practices for an organization and teams. Doesn't directly "DevOps" a ________ {org unit construct}

I would not say it's only for that. Helm made it easier to deploy stuff on kubernetes and Cloud Foundry has no answer for legacy code and steful apps yet.

That's why I used the word clone. Kubernetes opens up additional use cases that traditional PaaS offerings don't including batch and cron jobs.

Actually no, as you can have (optional) persistency and can deploy whatever container image you want. Those are not headline features simply because that's not how you're supposed to build modern apps.

Oh yeah, and that includes batch and "cron-like" jobs, obviously.

Lots of legacy code runs on CF (including batch and cron jobs). However it’s just a matter of months (how many is??) before it’s all K8s down anyway.

They have an answer for stateful services, they did long before k8s actually : it’s the open service broker API that Redhat is currently implementing in OpenShift

If you have local data then yes. Once Google or AWS co-locates IBM DB2 mainframes that local data will shrink a lot for large companies.

strong on what k8s is for

Exactly :) Your platform may be BIG or small depending on how many features you want in it. This is exactly what we're doing @Kintohub

Yup! This is also precisely what @snaproute did with their new CN-NOS (cloud native network operating system), building it with k8s baked into the mgmt plane: snaproute.com

- sweet way to demystify. Is it fair to say K8s is a datacenter OS or platform?

Kelsey, what do you think about Netflix Conductor, which relies on the idempotence of services, in addition to their statelessness?? Is It kind of competition or even alternative to K8s?

That’s good validation of the CF value line narrative

refunc.io open source serverless compatible with AWS Lambda, just built on k8s

sometimes I think that we have some sort of quantum entanglement thing going. Working hard back at the @pivotal @VMware ranch. Harden @kubernetesio as fast as we can in an open upstream, any cloud way + make app abstractions and services curated and easy.

Fellas, you just made it into several of my presentations. Thank you!

Problem is there is no OSS high level platform that you can install on premise or fully managed in a VPC. There’s a huge void between « couple apps on Heroku/app engine » and « installing myself a full blown app platform in a private network »

Is this...Kubernetes?

On this front, do you have any resources for people trying to build serverless-style platforms on top of K8S? It seems like there are a hundred things I haven't thought about yet, and when I uncover one I only discover 10 more questions to ask.

Is kubernetes up to the task of building these platforms largely by itself, or only as the"naked robotic core" of a larger system?