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

71–80 of 176 posts

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

#71

Post by vbsteven »

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, other services, ...) and run the application from my IDE against those (so I can use the debugger instead of printf-to-cloudwatch). For production I can package the app in a container and deploy to a container orchestration platform (Kubernetes, ECS, or something else).

To answer your question, what comes after Kubernetes?: I'm hoping for a platform that is somehow a consolidation of the good ideas that we've seen in Terraform/Pulumi/Kubernetes/Cmake/DockerCompose/Swarm. I want to write a portable idempotent "deployment build script" that I can apply against a cloud provider or bare metal or localhost in a similar way. With good support for different configurations depending on the environment (like C ifdefs or cmake options).

For example: when I apply the script against my localhost it spins up a postgres container, when I apply the same script against my AWS account it configures an RDS postgres instance. Both invocations will pass along the connection string to dependant services.

Basically morph docker-compose.yml into a portable Cmake for container orchestration.

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

#72

Post by TurningCanadian »

atom_arranger wrote: post #16

Infrastructure as code. One way to do it is you have semi-imperative code that runs, the output of the code is a description of the system to be deployed. Then you have some kind of diffing system that figures out how to take your existing cloud deployment and turn it into the new version described by the output of your code. This is how Pulumi works for example.

It sounds like you're describing Kubernetes. It already does container and volume management that way. All that's left is to continue building on top of it so that it can provision managed services like storage buckets and databases.

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

#73

Post by fletchowns »

nwienert wrote: post #14

Does anyone make anything that just takes your docker compose file and run it really easily with a lot more features? I’m happy with compose. It works. I know swarm was supposed to solve this but is dead now (?).

The simplicity of docker compose and ease of using it for local development is really nice

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

#74

Post by seumars »

c0ffe wrote: post #53

Compiling every dependency into a single WASM binary (including database engine, language runtime, etc) and just deploy and scale it on a serverless platform. No more containers to develop or to deploy, and eventually, no UNIX filesystem around the runtime.

I'm thinking of this as well. Given how frontend frameworks like Svelte are moving towards a "framework as compiler" approach and how newer runtimes like are Deno now support compiling to a self-contained standalone binary, my guess is that WASM will become the main target for cross-platform development.

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

#75

Post by jhickok »

rafaelgarrido wrote: post #56
buffet_overflow wrote: post #23

Earlier quoted context omitted.

What have you seen in that space so far?

OpenShift is also an alternative: https://www.redhat.com/en/technologies/cloud-computing/opens... Had some fun a few years ago with toy projects. Can't tell its current state...

OpenShift has been kubernetes since like OpenShift 3. Their serverless/functions-as-a-service capabilities are powered by the kubernetes project "knative".

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

#76

Post by chubot »

- More serverless platforms with more heterogeneity. Each one will be better at certain things. fly.io seems to be specializing on computing at the edge (networking). Others will be better at GPU computation; others will have different types of storage and databases.

- More people using multiple clouds. Because putting all your eggs in Amazon's will start to be less acceptable, for cost reasons and lock-in reasons. Kubernetes was supposed to be a neutral interface but I don't think that has panned out. I'm curious if anyone actually uses Kubernetes in a cloud-portable way.

- Less reliance on cloud SDKs and cloud-specific features, and more open source tools. Less reliance on Docker (which is rightly being refactored away.) I hope to do something with Oil here: http://www.oilshell.org/blog/2021/04/build-ci-comments.html .

- In case it needs to be said: more usage of the cloud. It does make sense to offload things rather than host your own, but right now it's still in an awkward state.

Good thread from a few months ago about problems with serverless dev tools: https://news.ycombinator.com/item?id=25482410

Good list of obstacles and use cases for serverless: https://arxiv.org/abs/1902.03383

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

#77

Post by aclatuts »

I think edge computing with docker support will be the next big thing. Right now cloudflare lambda at edge only supports specific runtimes but someone will support docker images soon. Eventually there will be edge computing monoliths for websockets or something persistent.

They might even allow on prem edge compute. Why not have a device in each employees home or a few devices at the office.

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

#78

Post by jhickok »

thesuperbigfrog wrote: post #50

Serverless compute solutions like AWS Lambda, but with increased capabilities. Why do I need to build a container image when I can just list my dependencies and provide some code to run? For example: "I need Programming_Lang version 4.14, Library_A version 2.2, and Library_B version 1.5". I don't care what the underlying operating system / system libraries are as long as it is fast and secure. I just need to run my c…

Agreed, but the functionality you see as a dev still needs an implementation layer, and it will likely be containers. Knative is relatively mature and offers something like the experience you are describing.

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

#79

Post by eb0la »

domano wrote: post #47
justsomeuser wrote: post #10

I think there will be a rise in monoliths and a trend towards reducing as much distributed state as possible. I think this will be driven by a few trends: - Very fast disks to store data SQLite style, auto replicated transparently at the disk level. - Typed languages becoming more usable (tooling and language improvements), which makes it easier to design and operate systems (stack traces vs distributed debugging/tra…

For some serivces in a kafka-based system i replaced the Postgres some services were using with File-based BoltDB stores or SQLite DBs. With kafka as the data source every instance was autonomous and would keep itself up to date using the kafka partition offsets. Went really well, took the DB cluster out of the scaling equasion and offloaded a lot of the cost to the SSD instead of memory or a managed DB Cluster. If e…

Kafka is works very well when you have a IF "receive-this" then that kind of problem.

I find a bit complicated using streams / queues for everything because it is a paradigm shift (turning the database inside out).

BUT when you have a clear use case like ingestion -> refinement step 1-> refinement step 2 it is a _very_ natural way to do stuff with the added benefit I can have as many parallel workers as topic partitions.

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

#80

Post by mongol »

temporama1 wrote: post #11
geggam wrote: post #4

An abstract layer to automate the creation of k8s which is an abstract layer to automate application deployment and application management What we need is an abstract layer to automate the systems underneath so we can leverage that abstraction and create more complexity There are still some folks who understand the abstraction all the way up and down. We cant have that

Whatever we do, please do not solve the actual root issue under any circumstances. That will not do. We need to stick another layer on top of the pile so we can have conferences and hashtags about it.

Maybe what is needed is what zfs did to raid. A freaking layering violation that breaks old assumptions and puts pieces together in better ways.
Post reply on HN