Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you think will come after Kubernetes?

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 176 posts

Re: Ask HN: What do you think will come after Kubernetes?

#111

Post by smackeyacky »

jdlshore wrote: post #91
zippzom wrote: post #39

A new programming language which hides the fact that your code is running across multiple machines from you. Similar to OOP, you'll define some level of structure and the compiler will figure out how to best distribute it across the resources given to it.

Hiding the network has been tried before, but I don't believe it's ever worked well. (See the CORBA and "distributed objects" craze in the 90's.) The costs of networking are too high.

I worked with a Corba based system back in the nineties and what killed ours wasn't network costs, it was circular hidden dependencies making the system fragile.

The support guys had a complicated procedure for restarting it that involved a very carefully orchestrated sequence, which sometimes didn't work so they had to start from scratch.

It was awful to watch.

Re: Ask HN: What do you think will come after Kubernetes?

#112

Post by syrusakbary »

Docker enabled Kubernetes. Before then we really didn't have a unit of compute that could be reproduce easily in different environments.

However, Docker has some downsides:

(1) It centers the unit of computation in the Operating System layer

(2) Docker relies on a completely homogeneous infrastructure (same chipset, almost same Operating System).

(3) It relies on a Virtualization layer (usually KVM) to be run securely

I believe (1) caused a vast amount of complexity when scaling, since you are scaling "OS Instances", not applications or functions, which caused Kubernetes to inherit most of this issues and be perhaps much more complex than it should.

I think (2) is key because with new trends coming up (such as Edge Computing, Serverless, IoT and 5G) we are starting to have the need of running software universally across a more diverse infrastructure (different chipsets).

And (1) and (3) causes a significant slow-down for startup times (see Firecracker state of the art project with a ~250ms best startup time - not good enough).

I believe most of this issues are solved with WebAssembly: simpler scaling, universal execution across diverse infrastructure and fast startup times. And I'm actually working full-time in Wasmer [1] to make of this vision a reality! :)

[1] https://wasmer.io/

Re: Ask HN: What do you think will come after Kubernetes?

#115

Post by skyde »

cjblomqvist wrote: post #89
fredsted wrote: post #18

As businesses start to realize microservices aren't really worth it due to the complexity and cost it entails, they will start reverting back to hosting monoliths on VMs or services like Heroku/Netlify/Laravel Forge/Beanstalk, and they'll find out they can save a lot of money on compute and man hours by doing this. For more simple workflows, e.g. a single API endpoint, there's serverless and other SaaS services out t…

How does serverless make more sense for a simple web api than a traditional web framework?

-cheaper (dont have a vm running 24/7 just for you)

-Easier to auto-scale because it does not have any state

-Can easily run at the Edge (look into lambda at edge of cloudflare worker)

Re: Ask HN: What do you think will come after Kubernetes?

#116

Post by vbsteven »

lamontcg wrote: post #110
vbsteven wrote: post #71

I think the pendulum has swung a bit too far from its optimum with serverless and microservices. The main issue I have with both is the huge complexity and friction between how it runs on a developer machine vs how it runs in production. For me the sweet spot is monolith(-ish) 12-factor applications packaged up in containers. In this setup I can just `docker-compose up` my dependencies (postgres, redis, rabbitmq, oth…

What I'd really like to hear is the story for after you're gone and the business has several hundred services spread out over 5-10 years of development, with varying historical stratums, and plenty of them being left on life support, where the business just doesn't want to pay barely anything to keep them running. And then how does the teams dealing with cross cutting concerns like security, logging and monitoring de…

I’m not sure what you are getting at. Several hundred services probably means going too far to the microservices side.

Cross cutting concerns like logging and monitoring are handled by 12factor. Services log to stdout and have the container orchestration pipe it to a logging backend. Monitoring can be standardised as well with healthcheck and metric endpoints. Security always has a maintenance cost attached unless you want to keep running on 12yo tomcat.

Re: Ask HN: What do you think will come after Kubernetes?

#117

Post by [deleted] »

thinkingkong wrote: post #12

The new thing thats going to “emerge” is already here. VMs and Containers were around for about a decade or more before they became really widespread. Frankly I think the serverless model will end up dominating in the long run. Whats really missing there isnt a better abstraction for k8s. Its the dx workflow and local development experience that still requires lots of work. Emulators for services, workflows, good ide…

[deleted]

Re: Ask HN: What do you think will come after Kubernetes?

#119

Post by vbsteven »

devonbleak wrote: post #84
vbsteven wrote: post #71

I think the pendulum has swung a bit too far from its optimum with serverless and microservices. The main issue I have with both is the huge complexity and friction between how it runs on a developer machine vs how it runs in production. For me the sweet spot is monolith(-ish) 12-factor applications packaged up in containers. In this setup I can just `docker-compose up` my dependencies (postgres, redis, rabbitmq, oth…

I'm pretty sure you just described the value prop for CloudFoundry. Seriously though you're talking about another abstraction layer on top of whatever cloud provider(s) you're using. And the issue with such abstraction layers is that to really make them portable you're stuck with the lowest common denominator of features. Such a thing doesn't really play well with the immaturity and velocity of cloud providers - we n…

The abstraction layer with lowest common denominator is the tricky problem that The Next Big Thing will likely need to solve.

Terraform tries to do it but as you mentioned it’s often a frustrating experience because of lagging providers and Terraform itself is a moving target (at least it was 1-2 years ago). This quickly leads to code rot and dependency hell.

I think containers are the right abstraction for packaging, but orchestration wise we’re still trying to figure out the optimal workflow. K8S, TF and Ansible have shown idempotency is an interesting concept to have. Pulumi improves on that by having procedural logic to describe the desired state. And in my eyes The Next Big should build on those ideas while avoiding or fixing the current rot/lag/dependencyhell problems.

Re: Ask HN: What do you think will come after Kubernetes?

#120

Post by jdlshore »

smackeyacky wrote: post #111
jdlshore wrote: post #91

Earlier quoted context omitted.

Hiding the network has been tried before, but I don't believe it's ever worked well. (See the CORBA and "distributed objects" craze in the 90's.) The costs of networking are too high.

I worked with a Corba based system back in the nineties and what killed ours wasn't network costs, it was circular hidden dependencies making the system fragile. The support guys had a complicated procedure for restarting it that involved a very carefully orchestrated sequence, which sometimes didn't work so they had to start from scratch. It was awful to watch.

I was on a team that used CORBA to distribute across five machines: input, output, logic, UI, and whatever the CORBA object discovery thing was. (I don’t know what they were thinking.)

They didn’t try to run it all together until it was time to ship.

Networking overhead definitely killed us. That, and incompetence.

Post reply on HN