Hacker News new | past | comments | ask | show | jobs | submit login

Kubernetes isn't an application platform though, in the same vein of Heroku. That's what Application developers want, and they're simply not going to get it. It was never supposed to be that.

Kubernetes competes with AWS, in a sense. Its a standard API for interacting with any cloud resource. I can give an AWS ASG an AMI, tell it to create 10 instances, and it will do it. I can give Kubernetes a Docker image, tell it to create 10 instances, and it will do it. You wouldn't expect application developers to enjoy creating AMIs, or maintaining them, or worrying about the global high availability of their 10 instances; they wouldn't enjoy that with AWS, and they won't enjoy it with Kube. And they shouldn't.

The confusion comes from the fact that Kubernetes needs to be deployed somewhere; well, lets deploy it on AWS. And now there's this expectation that Because we've created a layer on top of AWS, this layer should be closer to the application development process. It is! But, not as close as it could be, or should be in a productive shop. Kubernetes isn't the endgame; its just a better place to start.

There are two angles to this problem that I hope Kubernetes continues to see improvement on in the coming years:

First, cloud providers need deeper integration. Kubernetes should replace the AWS/GCloud/AZ API. If you want to access object storage, Kubernetes should have a resource for that which Ops can bind to an S3 bucket, then applications go through the Kube resource. If you want a queue, there should be a resource. This is HARD. But, over time I hope and do think we'll get there. You can already see some inklings of this with how LoadBalancer Services are capable of auto-provisioning cloud-specific LBs.

Second, we need stronger abstractions on top of Kubernetes for application development. Projects like Rancher are doing some work in this regard, as well as KNative and many others. Even, say, the Google Cloud console is an example of this, as it does a great job of hiding the internals behind friendly forms and dialog boxes.

We'll get there.




AWS is working to express their infrastructure as Kubernetes objects in this project, so things are moving in this direction: https://github.com/awslabs/aws-service-operator


I've got a very keen eye on that project as it develops.

One thing I do think is: It feels like we should be looking at this a bit more general, and saying things like "I need a Queue" not "I need an SQS Queue", allowing the operators to bind the Queue generic to an SQS queue on the backend, then using the application-facing spec to assert things like "it has to be FIFO, it has to guarantee exactly once delivery" etc. And if the backend cloud resource provider that is configured can't meet the requested spec, we get an error.

I don't know for sure if this would be better or worse. But for some generic cloud resources, like Object Buckets, Queues, PubSub, or SQL Databases, we can arrive at a commonly accepted set of generic abstract qualities that an Exemplary implementation of a system which says its a "Thing" should assert (ex: with Object Buckets, characteristics like regional redundancy, consistency, lifetime policies, immutable object locking, etc).

The interesting thing there is that now you've got a common base API for, well, common things that any application would need. Open source projects could flourish around saying "Check out NewProjectX, its a Kubernetes-compliant Object Storage provider". The backend doesn't have to be a cloud provider; it could run right on the cluster or on a different machine you own, just like how load balancers can work (see: MetalLB).

Obviously I don't expect AWS to publish an API that divorces the implementation from the spec, but I think we should think about it as a community. And also, not every cloud resource the Big 3 provide would make sense to be "more generic"; for example, having a generic "NoSQL Database" provider is far too implementation specific to account for all the differences between, say, Dynamo and Firestore. So the work AWS is doing on that project is ultimately valuable.


> Kubernetes isn't the endgame; its just a better place to start.

> Kubernetes isn't an application platform though, in the same vein of Heroku.

This, exactly

> That's what Application developers want, and they're simply not going to get it.

... that's exactly what we want, and I think the more perceptive among us doing the deciding want to choose one that is built on Kubernetes, or at least have Kubernetes ready for when one comes along, basically for the reasons you highlighted. It seems to be the winning standard, put up against AWS. It's a major improvement over the old model of how Ops has handled provisioning resources.

> 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.

https://twitter.com/kelseyhightower/status/10997101785454346...

I think there are enough different choices for that "top layer of the dev stack" now, which DOES provide developers with the kind of experience they/we want, while usually protecting us from the underlying infrastructure like deployment YAML and service/ingress, that it really is a realistic concern that we'll choose the wrong one.

We want to make a choice and be stuck with it. We don't want to choose wrong and have to choose again. (Especially if we're planning to buy a support contract, which we almost definitely are. But how can we even predict which stack layer vendor we'll ultimately need support from?)

Our IT moves at an institutional pace, and guidance councils seemingly prefer we have a comprehensive plan in place before we take the first single solitary step.

My perception is that they want to wait for the market to narrow before committing to any new shiny, but it's clearly still expanding, and my sense is that I really don't want to see the market narrowing (as that might be a signal that the grand experiment just isn't going so well anymore.)

By the way, it does look like this is coming, too:

> Kubernetes should replace the AWS/GCloud/AZ API. If you want to access object storage, Kubernetes should have a resource for that which Ops can bind to an S3 bucket, then applications go through the Kube resource. If you want a queue, there should be a resource.

https://www.operatorhub.io/operator/aws-service-operator.v0....

I'm excited about work like OperatorHub, which promises to raise the visibility of this kind of stuff!


> We want to make a choice and be stuck with it. We don't want to choose wrong and have to choose again.

I don't know anything about your organization.

But my take is that this isn't a quality that you see in healthy organizations. We're human. We can't see the future. In the best of cases, we ingest as much information as we can find and we use that to make the best decision we can. And, truly, the best of cases never happens, but even if they did: New information is discovered. The Environment develops and changes. And that change has to respond with internal change as well.

One of the phrases I've heard people in my organization say is something along the lines of "are we sure this is the right decision?" or "how can we be sure this is the best path forward?" That's a mindset I'm trying to move people away from. The better question is "how are we accounting for a need to change in the future?" If you view a system as "X", then changing "X" becomes very hard. If you view a system as "X+Y+Z", then you can ask "how can we change Y to V without throwing away all the work we did on X and Z?" And then, in 12 months when you have X+V+Z, maybe you want to change X to W. And so on. That's continual improvement and true agility.

Its damn hard; in both implementation and changing mindsets from the "we want this perfect thing from day 1" to "its alright if it isn't perfect; its more important that we can easily change it." And, actually the hardest part is convincing people that this Is Not Optional; the most productive, highest performing organizations on the planet are the ones who know how to do this, and they'll eat your lunch if you're not ready. Maybe in 6 months, maybe in 50 years, but it'll happen.


> But my take is that this isn't a quality that you see in healthy organizations.

It might help if I told you something about my organization. I'm in University IT. We're not building a product, the product is the education, and we merely support that with technology (the students, the research, and the administrative efforts.)

That's part of the problem, to be honest, is that the organization will not rise or fail due to the tireless efforts or minor failings of IT. We like to shoot for perfect, we want to do the best thing, but unfortunately if it's a choice between making a decision that leadership sees as a little shaky or uncertain, versus maybe making a more conservative choice that doesn't have as many bells and whistles, but that we're sure we can live with for a long time, they'll have us go the conservative route every time, so we can get this one important thing off of our plate and get back to the central focal business of the University.

I appreciate the way you're decomposing the issue, because I think you're right about all of this. The problem all this time has been, (and I've started to recognize it more and more)

1. we propose Kubernetes, knowing that it solves a lot of problems for us, right out of the box. X is Kubernetes.

2. Leadership asks "what problem does X solve" looking for the big show-stopper answer that says "well obviously, we have to solve that. We'll make it a priority!"

3. For each "well obviously" the honest answer is, "X doesn't really solve that without additionally Y and Z."

We don't even really truly get to the point in the conversation where we're worried about picking the wrong X. It's in the back of everyone's head, who has done any research on Kubernetes. There are so many flavors to choose from, how do we even know that Y and Z will work when we get there, if we start with X first?

Fortunately I think the glacial tides are turning, but they don't call it an "institutional pace" for no good reason.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: