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…
Serverless? There are always servers. APIs don't exist in a vacuum or scale magically. If you don't understand how to build what's underneath, then you don't understand what's involved and are at the mercy of vendors or someone else.
Ask HN: What do you think will come after Kubernetes?
131–140 of 176 posts
Re: Ask HN: What do you think will come after Kubernetes?
#132Applications will probably be flatpaks instead of containers. With some config for required data stores, NICs, port openings, CPU and RAM requirements.
In short. Plan 9 using Linux tooling.
Re: Ask HN: What do you think will come after Kubernetes?
#133Serverless 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…
The next step might be standardizing activation and dispatch, possibly with knative or a common API surface over vendor libraries.
Re: Ask HN: What do you think will come after Kubernetes?
#134The mental model of capabilities is something a 5 year old can grasp, like taking a dollar out of a wallet, the most you can lose when you give it to the child is the dollar.
You can't give a task N cycles, and these 4 files ONLY on any of the current round of frameworks. This is 50 years overdue.
Re: Ask HN: What do you think will come after Kubernetes?
#135Re: Ask HN: What do you think will come after Kubernetes?
#136I don't think the replacement for kubernetes will be something equal or even-more-lower level (more barebones, like nomad). It would be something higher level, enabling more features, not just equal.
What next could be a proper, self-hostable PaaS. There are a few out there, but most are either closed wall (fly.io, heroku, app engine, beanstalk) or self-hostable but complicated or not easily scalable (cloudfoundry, etc).
In a way, Kubernetes also did the same thing that most of it's predecessors did. But the main difference was – it offered a common low-level abstraction of APIs and operators which allowed a lot of solutions to be built on top. It was not just a CaaS, it was also the "standard model" to run things underneath. The unit of the model was always a "workload" or container.
Similarly, the next PaaS could also do the same thing as solutions today – but if it becomes the new "standard model", where the core unit of the model is an "application" (not just a container), it would be amazing. Deploy applications with hundreds of standard, open ended plugins like distributed tracing, etc. Open ended heroku.
Re: Ask HN: What do you think will come after Kubernetes?
#137people want to go back to monoliths, but don't want to lose the upsides of microservices. once you get a taste of serverless, it's really hard to go back to overprovisioning. at the same time, distributed state and logic that crosses service boundaries is hard. I don't know what comes next, but what I _want_ to come next is powerful static analysis that works across languages and services, that can "compile down" to…
Re: Ask HN: What do you think will come after Kubernetes?
#138Here is my dockerfile. Give me a endpoint, a simple ui to manage it. The end. Why is this so hard in 2021? I don't want nodes, pods, yamls, puppets, chiefs, swarms, terraforms, ghosts or even monsters. Thanks.
Re: Ask HN: What do you think will come after Kubernetes?
#139Re: Ask HN: What do you think will come after Kubernetes?
#140Infrastructure 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.
The idea of infrastructure as code in relation to Kubernetes is that you have the full power of a programming language to build with, not just yaml files. You can also tie into other functionality of cloud providers as long as your IAC provider supports it. So you could have your Kubernetes cluster connect to some serverless code, or to a managed database, all deployed from one codebase.
Having said all this I didn’t actually have a great experience using Pulumi and switched to plain K8s. It makes a ton of sense in theory though and I’ll probably try again.