TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

141 点作者 spIrr将近 4 年前
I mean, Kubernetes became a thing after Docker became a thing before(and so on, all the way down to VMs), so it's reasonable to assume that something new will eventually emerge and become the industry-standard.

69 条评论

fredsted将近 4 年前
As businesses start to realize microservices aren&#x27;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&#x2F;Netlify&#x2F;Laravel Forge&#x2F;Beanstalk, and they&#x27;ll find out they can save a lot of money on compute and man hours by doing this.<p>For more simple workflows, e.g. a single API endpoint, there&#x27;s serverless and other SaaS services out there which will let you build off from that, and lets you save a huge amount of time and money compared to building it traditionally with a Web framework.<p>Now that we&#x27;ve had a few years of experience with how people are actually using the platform , I could see a simplified version of Kubernetes taking hold for businesses still running complex sets of services, something that&#x27;s easy to install, actually comes with batteries included and is secure by default.
评论 #27157487 未加载
评论 #27156297 未加载
评论 #27156629 未加载
评论 #27172740 未加载
评论 #27157259 未加载
评论 #27157565 未加载
评论 #27157409 未加载
评论 #27163612 未加载
vbsteven将近 4 年前
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.<p>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).<p>To answer your question, what comes after Kubernetes?: I&#x27;m hoping for a platform that is somehow a consolidation of the good ideas that we&#x27;ve seen in Terraform&#x2F;Pulumi&#x2F;Kubernetes&#x2F;Cmake&#x2F;DockerCompose&#x2F;Swarm. I want to write a <i>portable</i> <i>idempotent</i> &quot;deployment build script&quot; 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).<p>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.<p>Basically morph docker-compose.yml into a portable Cmake for container orchestration.
评论 #27157742 未加载
评论 #27158081 未加载
评论 #27157073 未加载
评论 #27157438 未加载
justsomeuser将近 4 年前
I think there will be a rise in monoliths and a trend towards reducing as much distributed state as possible.<p>I think this will be driven by a few trends:<p>- Very fast disks to store data SQLite style, auto replicated transparently at the disk level.<p>- Typed languages becoming more usable (tooling and language improvements), which makes it easier to design and operate systems (stack traces vs distributed debugging&#x2F;tracing).<p>- Improvements in Heroku-like systems from AWS&#x2F;GCP etc.
评论 #27156072 未加载
torvald将近 4 年前
I very much hope to see Hashicorp Nomad getting more traction, as a simpler, yet feature rich solution to probably most use cases in our industry. Pretty interesting to see the adoption of podman and also micro-vms (like fly.io does it), and other Nomad providers that does not nessasarly need to be docker.<p>I know there are great terraform modules out there already, but i wonder if many of Hashicorp&#x27;s products soon will be available as &quot;managed&quot; services as well, allowing people to try something new with less maintenance cost.
评论 #27156380 未加载
评论 #27157817 未加载
评论 #27164116 未加载
评论 #27156285 未加载
评论 #27156155 未加载
评论 #27156205 未加载
评论 #27157185 未加载
评论 #27172781 未加载
thinkingkong将近 4 年前
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.<p>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 integration, open service standard. That will all be where the next layer happens.
评论 #27156324 未加载
评论 #27155816 未加载
评论 #27158556 未加载
syrusakbary将近 4 年前
Docker enabled Kubernetes. Before then we really didn&#x27;t have a unit of compute that could be reproduce easily in different environments.<p>However, Docker has some downsides:<p>(1) It centers the unit of computation in the Operating System layer<p>(2) Docker relies on a completely homogeneous infrastructure (same chipset, almost same Operating System).<p>(3) It relies on a Virtualization layer (usually KVM) to be run securely<p>I believe (1) caused a vast amount of complexity when scaling, since you are scaling &quot;OS Instances&quot;, not applications or functions, which caused Kubernetes to inherit most of this issues and be perhaps much more complex than it should.<p>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).<p>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).<p>I believe most of this issues are solved with WebAssembly: simpler scaling, universal execution across diverse infrastructure and fast startup times. And I&#x27;m actually working full-time in Wasmer [1] to make of this vision a reality! :)<p>[1] <a href="https:&#x2F;&#x2F;wasmer.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wasmer.io&#x2F;</a>
jerf将近 4 年前
It can be longer than you think. While our focus is on the parts of the industry that churn endlessly, the <i>real</i> typical pattern is that there&#x27;s a cutting edge&#x2F;early adopter churn, then typically some set of technologies &quot;wins&quot; and prevents anything from developing, if only because they raise the bar so high for what the competition has to do to be even remotely credible that it becomes impossible to do the work to displace the entrenched competition.<p>I think the most likely outcome is that K8S continues to entrench itself and essentially nothing ever displaces it on its own turf. Eventually, the game will move to some other turf and the process starts over.<p>My statement here is about general trends, and not a full explanation of how all software lifecycle works. My point here is more that if you look more carefully, it is not the case that everything everywhere is always in constant churn, therefore you can safely assume that K8S is on the verge of being displaced. The antecedent is not as true as it may appear on the surface. Under the boiling froth, there are many more things in the software space that are relatively stable.
corobo将近 4 年前
I think Kubernetes will be a part of things (as Docker still is) but it&#x27;ll be the next level of abstraction -- the thing that turns Kubernetes into Heroku.<p>There&#x27;s been a few popping up recently, time will tell who wins
评论 #27155855 未加载
pm90将近 4 年前
Kubernetes automates and standardizes some of the best practices around building reliable systems in a platform agnostic way. We never got there with VMs: Amazon ec2 instances are not the same as GCE instances are not the same as VMware VMs but a kubernetes api is the same everywhere (and providers are incentivized to standardize their offerings). Whatever comes next would have to be something that can standardize even more.<p>For the next 10 years, I don’t see kubernetes going away but rather evolving into something that’s dead simple for anyone to setup and use easily. It’s flexibility in being a platform capable of easily running whatever you want to is somewhat unmatched.<p>Honestly the only way I see k8s being replaced is by a fork if there is some Governance dispute. I don’t see the platform changing for at least 10-20 years.
评论 #27155974 未加载
mhoad将近 4 年前
I’ve been looking into this for about a year. This is going to sound crazy right now but I’m saying Fuschia is going to just straight up change computing in the medium term future. I’m expecting it’s first release next week at I&#x2F;O and right now everyone just thinks it’s the “new Android” but it becomes kind of clear when you read the docs that it’s actually much much more than that.<p>Things that are interesting about it:<p>- any device and any workload from IoT to servers.<p>- totally new security model from the ground up which is how I expect it to be the main driver for business use cases<p>- new app delivery model which is kind of like a weird mix of the web as you know it currently, native apps and kubernetes.<p>- seems to be developing an interesting interop story where the goal is that you will also be able to run Android and linux apps on it despite the fact that it’s not Linux and not based on Linux. Everything is custom made from the ground up.<p>- the development story is also super interesting, all IPC happens over a gRPC like protocol and provides a nice language neutral way to develop for the platform and to integrate with everything else.<p>Some of the other projects I’ve seen coming out of Google make way more sense in this context too. Flutter for web is a good example which I know is not exactly a crowd favorite here on HN but I’m serious when I say that now might be a good time to go and look at Dart again. It’s actually a really nice modern language if you are coming from JavaScript, Typescript or Java you will be up and running very quickly.<p>I think this is about to become a hugely disruptive force. If Google manage to not screw this up that is.<p>For a slightly longer term bet I’d say by the time it hits say v5 it will be the biggest OS &#x2F; platform in the world by a considerable margin.
thesuperbigfrog将近 4 年前
Serverless compute solutions like AWS Lambda, but with increased capabilities.<p>Why do I need to build a container image when I can just list my dependencies and provide some code to run? For example: &quot;I need Programming_Lang version 4.14, Library_A version 2.2, and Library_B version 1.5&quot;.<p>I don&#x27;t care what the underlying operating system &#x2F; system libraries are as long as it is fast and secure.<p>I just need to run my code. Why should I need to manage the rest as long as it works?
评论 #27159864 未加载
评论 #27156939 未加载
tluyben2将近 4 年前
Simpler solutions that behave the same on your laptop as it does on a cloud setup. More Heroku like. Most people &#x2F; companies don&#x27;t need all the intricate settings of Kubernetes (or docker). You basically want to have a docker-compose file, put some cpu, mem, scaling, replication numbers and that&#x27;s it. Deploy locally or on a cluster and it&#x27;ll just work, scaling as you go, if available on your deployed platform.<p>I know this is already possible, but it&#x27;s not very easy, especially across laptop, cloud and baremetal; Kubernetes on baremetal is a pain (no simple ingress if you don&#x27;t have access to the router or loadbalancing).<p>I hope someone tells me this exists but I tried a lot of solutions and they all fail at something (complexity &#x2F; dependency on big cloud providers &#x2F; dependency on specific network capabilities etc).
评论 #27156571 未加载
tkiolp4将近 4 年前
I think the question is: what comes after micro services&#x2F;distributed systems? Whatever that is, will make k8s obsolete.<p>My bet: rich fat clients. Super powerful phones that can run your entire e-commerce monolith to process my checkout. I’m talking about hosting your backend (most of it) and DB on my phone. Cheap syncs from my phone to your “main” server is fine because I’m always online and I have 10G connection. This will also force a shift in the way we develop programs.<p>So you no longer need to deploy and maintain hundreds of services. You’ll only need to deploy and maintain one that gets synced to millions of devices (no app stores) rather fast (because, yes, a new compression algorithm will emerge and your whole monolith is now only a couple of megabytes).
评论 #27162266 未加载
chubot将近 4 年前
- 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.<p>- More people using multiple clouds. Because putting all your eggs in Amazon&#x27;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&#x27;t think that has panned out. I&#x27;m curious if anyone actually uses Kubernetes in a cloud-portable way.<p>- 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: <a href="http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2021&#x2F;04&#x2F;build-ci-comments.html" rel="nofollow">http:&#x2F;&#x2F;www.oilshell.org&#x2F;blog&#x2F;2021&#x2F;04&#x2F;build-ci-comments.html</a> .<p>- 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&#x27;s still in an awkward state.<p>Good thread from a few months ago about problems with serverless dev tools: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25482410" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25482410</a><p>Good list of obstacles and use cases for serverless: <a href="https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;1902.03383" rel="nofollow">https:&#x2F;&#x2F;arxiv.org&#x2F;abs&#x2F;1902.03383</a>
评论 #27157836 未加载
c0ffe将近 4 年前
Compiling every dependency into a single WASM binary (including database engine, language runtime, etc) and just deploy and scale it on a serverless platform.<p>No more containers to develop or to deploy, and eventually, no UNIX filesystem around the runtime.
评论 #27176141 未加载
评论 #27156819 未加载
sjaak将近 4 年前
Something much, much, simpler. I&#x27;m not convinced that &#x2F;for most companies&#x2F; k8s adds enough value when compared to all the added complexity (not to mention the yaml soup!).
评论 #27156013 未加载
mikeymz将近 4 年前
I genuinely worry about this community when after &gt;100 comments nobody has said &quot;k9s&quot;
rdsubhas将近 4 年前
Kubernetes&#x2F;Docker are still fundamentally &quot;CaaS&quot; (container-as-a-service). Definitely an improvement from the mostly IaaS period before, but still too low level for anyone to run services reliably on with low effort. From someone who runs 400+ services on kubernetes – I&#x27;d like to make this clear: Kubernetes is not a &quot;platform&quot; for services, it&#x27;s just the low-level container infrastructure. You have to build the platform yourself, which is not easy.<p>I don&#x27;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 <i>more</i> features, not just equal.<p>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).<p>In a way, Kubernetes also did the same thing that most of it&#x27;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 &quot;standard model&quot; to run things underneath. The unit of the model was always a &quot;workload&quot; or container.<p>Similarly, the next PaaS could also do the same thing as solutions today – but if it becomes the new &quot;standard model&quot;, where the core unit of the model is an &quot;application&quot; (not just a container), it would be amazing. Deploy applications with hundreds of standard, open ended plugins like distributed tracing, etc. Open ended heroku.
pmlnr将近 4 年前
The pendulum swings back somehow and we&#x27;ll have offline capable personal computers again.
评论 #27155785 未加载
bionhoward将近 4 年前
I&#x27;ve been agonizing over devops lately and for me K3s looks like a lighter version of the full API. Another option is NixOS, if we integrate some Kubernetes orchestration features with an autoscaling group of NixOS nodes we get a ton of benefits - version controlled declarative configuration of the hosts enables Dev Prod parity, shared immutable dependencies across containers makes them pull and cold start faster, automatic and easy rebuilds with latest updates...<p>NixOS is weird and Nix language is super weird but the concept is powerful and the dev community can benefit tremendously from it<p>If Hashicorp does substantial work to put the pieces together on a full Hashistack deployment to compete with K8s that will be a good option, too.<p>Also, there&#x27;s the option of just using cloud stuff instead of an orchestrator. You could use AWS ALB and autoscaling groups to do much of the same thing, and even manage the infrastructure in Typescript or Python with both Pulumi and CDK (or just use TF or CF)
antman将近 4 年前
Somebody wins the market and stays until the market disappears due to innovation. If we were to say that it is not established enough and it could be disrupted within the existing market then I like Nomad, good enough for most cases I think, a lot simpler.<p>Disclaimer: I have not Kubernetes experience, show a few documents and opted for Nomad with great success so far.
temporama1将近 4 年前
There will have to be something to solve all the problems that are created by Kubernetes, which itself exists to solve the problems with Docker, which exists to solve the problems with VMs, which exist to solve the problems with Operating Systems.<p>I can&#x27;t wait for the next layer of complexity to be added. It will no doubt be called something like WizzlyBobATron.
评论 #27156086 未加载
frankwiles将近 4 年前
Something will almost certainly replace Kubernetes at some point, but I&#x27;m fairly certain what replaces it will look a LOT like it.<p>By that I mean, entirely API driven, declarative, etc.
zippzom将近 4 年前
A new programming language which hides the fact that your code is running across multiple machines from you. Similar to OOP, you&#x27;ll define some level of structure and the compiler will figure out how to best distribute it across the resources given to it.
评论 #27157344 未加载
kall将近 4 年前
For serverless, the move to much lighter runtimes like cloudflare workers or deno deploy seems like an obvious improvement. If you build your entire app on the Cloudflare &quot;Stack&quot; that could mean serious lock in, but it could also go in an open standard direction. I think to &quot;replace&quot; k8s it needs to be something that many people can run in different places. Would love to see an open serverless application runtime based on v8 workers. I think a future based on a whole lot more JS and WASM is not unlikely.<p>But maybe monoliths are the way, as many commenters are hoping for, because sure, distributed systems are hard, no matter how nice the abstraction.
flyingtoast将近 4 年前
A meta OS that works like Linux, but corresponds to an array of machines that is represented via one interface. Think Plan 9. Map all resources as mount points. Make standard commands work across machines by default. ps, ls, ip, taskset and so forth. The OS will be the same regardless of which machine you log in to. &quot;Just a bunch of machines&quot; data stores.<p>Applications will probably be flatpaks instead of containers. With some config for required data stores, NICs, port openings, CPU and RAM requirements.<p>In short. Plan 9 using Linux tooling.
mgarfias将近 4 年前
Something simpler. Please god.
AtlasBarfed将近 4 年前
I think the good of Kubernetes may be the sweep-away standardization in the network layer. IIRC it prescribes a certain network visibility of all the services that a lot of IT departments may have resisted under the banners of various motivations (security! obstinance! laziness! security!).<p>Also k8s adoption standardizing the visibility and forcing security to all (ssl everywhere, encryption, authentication for each request, etc).<p>That mass organizational evolution in enterprises opens up a lot more simplicity for just-containers or bespoke scaling strategies. Go ahead and run micro, nano, macro, or mega services. Don&#x27;t be limited by docker &quot;conventions&quot; on size or complexity.<p>Of course serverless was the natural evolution to k8s, but the &quot;DC OS&quot; is still a very very very nascent thing that is far behind something like a POSIX standard or anything like that for portability. Serverless is all lock-in right now. k8s was nice in a way because at least it was SOMEWHAT non-lockin as an architecture&#x2F;framework. If you squinted. Hard.<p>Standards and portability breed true flexibility and good tools, and we probably need a lot more of that in the cloudrealm.
jackcviers3将近 4 年前
I think it will be abstracted kubernetes - something a little like ec2, but where the cpu, memory, and disk are multi-tenant, overprovisioned, and your code and aps run on the os provided, but are suspended during non use and unsuspended by the supervisor service on demand. Common architectures are available (elk, ssh&#x2F;scp, tls load balancer with lamp&#x2F;tomcat-postgres&#x2F;etc.) Out of the box with automating, overprovisioned, multi tenant bandwidth, storage, etc.<p>Virtual private servers, but suspended&#x2F;resumed&#x2F;scaled for you without you needing to worry about the underlying method of deployment. AWS lambda + aurora but running actual operating systems. You want more threads or memory - they&#x27;re there for you. Every user process is metered and monitored. Charged by cpuops + memoryops + iops + hdstorage bytes by the second. You never need to worry about how much disk you need, it&#x27;s there, unlimited except by your pocket book. You never need to worry about how much compute you need - it&#x27;s there, unlimited by your pocketbook. You never need to worry about how much memory you need. Backups of your drives are automatic.<p>All data is encrypted to allow it to live amongst all the other tenants&#x27; data. All wire traffic is encrypted.<p>It works exactly like ec2, except it&#x27;s on-demand usage and overprovisioned and multi-tenant. Alarms and user-set limits for price and scale are respected. The only thing that will leak about the abstraction is that you&#x27;ll have to mark processes as suspendable and dependent. You don&#x27;t need to run your metrics collector if your app isn&#x27;t running. Cron jobs should wake up the server, etc. Ssh&#x2F;scp just works. You get service discovery out of the box, and your point of entry is the app lb dashboard. A real, on-demand, virtual private cloud.
geggam将近 4 年前
An abstract layer to automate the creation of k8s which is an abstract layer to automate application deployment and application management<p>What we need is an abstract layer to automate the systems underneath so we can leverage that abstraction and create more complexity<p>There are still some folks who understand the abstraction all the way up and down. We cant have that
评论 #27155882 未加载
评论 #27155801 未加载
评论 #27155749 未加载
dharmab将近 4 年前
Something compatible with the Kubernetes API.
评论 #27155697 未加载
swyx将近 4 年前
<a href="https:&#x2F;&#x2F;temporal.io" rel="nofollow">https:&#x2F;&#x2F;temporal.io</a><p>if the lesson from k8s is that after containers we needed container orchestration - the business logic analog is that services will need service orchestration.<p>(disclaimer: i work here so i&#x27;m both biased and have skin in the game)
评论 #27159458 未加载
MrWiffles将近 4 年前
Maybe not quite the right specific area here, but IMO the next &quot;big thing&quot; will probably be AI-generated code of some form. This will let organizations employ fewer developers and instead license AI services (e.g. GPT-3) to have it generate code for some app, then have maybe 1&#x2F;10th the developer overhead they otherwise would go over that generated code and tweak it as necessary to make the end result better and compensate for the shortcomings of AI at present, with the eventual goal being to replace the developer all together with AI-generated apps.<p>Then, hosting those apps in some form will likely need to adopt AI-centric workflows in some way. We might even see AI-driven request routing and AI-driven WAF features at some point, too.
stpedgwdgfhgdd将近 4 年前
For small to medium sized applications; Edge workers like Cloudflare workers. Complexity and cost are much lower.<p>And perhaps geographical regulations will become so demanding that you need something like durable objects to store &amp; process data in country of origin.
kenm47将近 4 年前
I feel like it’s a bit like asking what’s next after linux. hard to say because the solution is good enough it’s going to last. There almost has to be a fundamental revolution in computing to overthrow linux at this point.<p>That will come, but it’s a ways out and difficult to see. Most of what we’ll see are different abstractions that will utilize linux under the hood. Same with kubernetes. It’s not that a new kind of OpenStack is going to usurp it, it’s that what comes next will be built on top of it as it becomes mroe and more the norm… until the next major computing revolution. (completely decentralized storage on phones a la pied piper? quantum computing?)
评论 #27164545 未加载
thdxr将近 4 年前
Plenty of comments here have documented the headaches around microservices and predict a shift back to monoliths.<p>However an alternate perspective is the microservices were not micro enough to make it worth the overhead + cost. My opinion is the reason this none of this feels great is because a container is not small enough of a base unit to enable you to completely forget about infrastructure.<p>That&#x27;s why I&#x27;m betting the next paradigm that gains traction is fully serverless architectures. The overall direction things have been going for decades is to make hardware more invisible and I think we finally get pretty close with serverless.
ransom1538将近 4 年前
Here is my dockerfile. Give me a endpoint, a simple ui to manage it. The end. Why is this so hard in 2021? I don&#x27;t want nodes, pods, yamls, puppets, chiefs, swarms, terraforms, ghosts or even monsters. Thanks.
评论 #27160050 未加载
turingbike将近 4 年前
people want to go back to monoliths, but don&#x27;t want to lose the upsides of microservices. once you get a taste of serverless, it&#x27;s really hard to go back to overprovisioning. at the same time, distributed state and logic that crosses service boundaries is hard. I don&#x27;t know what comes next, but what I _want_ to come next is powerful static analysis that works across languages and services, that can &quot;compile down&quot; to serveless services
评论 #27160020 未加载
golergka将近 4 年前
Now I don&#x27;t need to download, setup and install Postgresql, I can run it with Docker with one command.<p>Why don&#x27;t do the same for a typical Kubernetes setup with Hasura, API server, Gateway, load balancer, Postgresql, Redis, and a couple of services for logs and monitoring all in one, with all the networking stuff already setup? Just give me an image or template made by someone else, maintained on Github, and ready to customise and develop for my needs.
评论 #27169237 未加载
macando将近 4 年前
<i>It is often said that while not many people bought Velvet Underground records, those who did went out and started a band. For software developers of a certain era, Heroku carries a similar legacy. Every developer who came into contact with Heroku continues to chase some version of that legendary developer experience today. “It absolutely is the Velvet Underground of developer platforms”</i><p>We&#x27;re still waiting for that magical band to appear.
glazeshadow将近 4 年前
But Erlang &#x2F; Elixir seemed very promising to me.<p>- Supervisor processes. - Small process size. - Failure friendly design.<p>All of which allows easy vertical &#x2F; horizontal scaling, robust concurrency and scalability, and automated process management.<p>Seemed promising the way WhatsApp &#x2F; Discord have used this. Obviously not a classic DevOps deployment or a direct competitor for Kubernetes. But doesn&#x27;t disruption happen from the sidelines?
DelightOne将近 4 年前
Microservices will be integrated into a single binary developed with clear boundaries in mind to be able to be able to refactor them out where scale is needed.<p>There will be languages to design distributed systems without having to manually design each component for it. The language rather allows generating interfaces which generate a monolith while certain parts are generated as microservices to scale.
benlivengood将近 4 年前
I think complete CI&#x2F;CD+hosting solutions are somewhat likely; open versions of things like AWS lambda or GCP cloud functions. Roll the entire tech stack into a automated service.<p>What most backend devs want is to write code and stick it behind a URI endpoint and make sure it keeps running with networking, auth, security, monitoring, scaling, and reliability taken care of by someone else.
评论 #27164579 未加载
aclatuts将近 4 年前
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.<p>They might even allow on prem edge compute. Why not have a device in each employees home or a few devices at the office.
atom_arranger将近 4 年前
Infrastructure as code.<p>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.<p>This is how Pulumi works for example.
评论 #27156493 未加载
评论 #27156681 未加载
74d-fe6-2c6将近 4 年前
Skimming over the comments I get the impression that a majority is quite sure that K8s is going to make a pass any time soon. This seems delusional given its rate of adoption and reputation. My gut feeling is it won&#x27;t make way for something new any time soon. It will evolve but not go away.
sbussard将近 4 年前
A declarative solution that combines terraform + k8s + hardware management, that elegantly partitions between stateful and stateless resources. Stateful resources will have well defined, easy to understand modes of behavior, explicitly describing caching policies and persistence layers.
评论 #27155973 未加载
kodah将近 4 年前
Kubernetes was precipitated by the development of containers in the kernel while the industry was focused on virtual machines. The next iteration will be whatever foundational technology is introduced that requires more abstraction, usability, and distribution.
philipswood将近 4 年前
Fully distributed state management.<p>You want a collective that nodes can be added to simply, with compute, state, storage and networking to be fully distributed autonomously.<p>I imagine being able to address an object via some hash (IPFS style) rather than networking kludgey.
skyde将近 4 年前
Webassembly sandbox maybe?<p>I had great hope in google Native Client [1] when it came out.<p>[1]<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Google_Native_Client" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Google_Native_Client</a>
lrhegeba将近 4 年前
k8s provides standardisation (technologically as well as business-wise), that&#x27;s why is now lives at CNCF. Google wants everybody to use these as it allows for easier migration of these workloads on their cloud platform. k8s is at heart of their Anthos offering.<p>see <a href="https:&#x2F;&#x2F;www.nextplatform.com&#x2F;2019&#x2F;02&#x2F;20&#x2F;google-wants-cloud-services-platform-to-borg-your-datacenter&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.nextplatform.com&#x2F;2019&#x2F;02&#x2F;20&#x2F;google-wants-cloud-s...</a> for better explanation from Google&#x27;s Urs Hölzle
jl2718将近 4 年前
I think the VM isolation in Dalvik and iOS is probably the right model, if we can fix hardware isolation, library compatibility, and resource provisioning. Otherwise, unikernels are the next logical step.
Aqueous将近 4 年前
the truth is developers at individual companies should only have to focus on the business logic that individuate those companies. all the other concerns - logging, autoscaling, security, messaging, routing, data storage - are very similar company to company. this leads me to believe that some sort of serverless workflow engine will be the next big thing. problem right now is that the developer story behind lambdas and step functions is horrible and leads to lock in. that will need to be solved. whoever solves it will be very rich indeed.
nwienert将近 4 年前
Does anyone make anything that just takes your docker compose file and run it really easily with a lot more features?<p>I’m happy with compose. It works. I know swarm was supposed to solve this but is dead now (?).
评论 #27155854 未加载
评论 #27157725 未加载
评论 #27155853 未加载
评论 #27156793 未加载
rs999gti将近 4 年前
I&#x27;d like something like Azure container instances but crossed with Azure app services.<p>I upload a chart or compose about the cluster and kubernetes just happens.<p>No tweaking, no command line - just a GUI.
评论 #27157238 未加载
jayd16将近 4 年前
Isn&#x27;t Helm already after K8s?<p>Hopefully we have more iteration on configuring k8s. I&#x27;m not convinced we&#x27;ll so easily go back to managing instances with monoliths.
评论 #27157255 未加载
anthropodie将近 4 年前
I think it will be a mix of serverless, k8s, vms and unikernels. I personally am very interested in last one but not sure if it will ever become mainstream.
desktopninja将近 4 年前
#serverless
rektide将近 4 年前
Simpler and monolith (an endlessly re-suggested reply) has it&#x27;s place, but I see it as impossible for any &quot;simple&quot; solution to ever gain enough mindshare to win. A lot of people suggesting monoliths &amp; hosted services, but they are never going to have the community, the presence of something like Kubernetes, which unites people, which people collaborate over, in the same way we all got to learn &amp; experience &amp; co-develop for Docker. The question posted somewhat gets it wrong, &quot;Kubernetes became a thing after Docker became a thing (and so on,&quot; implies that they&#x27;re different things, that tech is about different things, but in many ways Kubernetes is a natural extension &amp; outgrowth, it is a part of the Docker scene, &amp; has continuity with it.<p>Kubernetes is a thing now, but it&#x27;s patterns are still underspoken of, underpracticed, underdeployed to the rest of the software world. We will get better at being like Kubernetes, for great benefit. Folks learning how control-loops are advantageous, and learning to use universal API Servers for all their systems will continue to drive not just Kubernetes, but the patterns underlying Kubernetes further into our applications &amp; services &amp; technologies. Tech like KCP[1] is an early indicator of this interest, in using the soul of kubernetes if not it&#x27;s specific machinery, by creating an independent, non-Kubernetes, but Kubernetes compatible API Server. Having universal storage, having autonomic system control are huge advantages when system building, and gaining those benefits is fairly easy, with or without Kubernetes itself.<p>I&#x27;m hoping we see a DIY cloud&#x27;ing become more of a thing. Leaving everything in the hands of hyperscalers is a puzzling and hard to imagine state of affairs, given the hardware nirvana we&#x27;ve experienced in the past two plus decades. Kubernetes is the first viable multi-system operational paradigm, the first diy-able cloud we have, and it&#x27;s shocking it took that long, but smaller practitioners getting good at converting their sea of individual boxes into something more resembling the Single System Image dreams of old, albeit through a highly indirect Kubernetes-ish route, is a decade or decades long quest we seemingly just started in to a couple years ago.<p>I&#x27;m hoping eventually ubiquotous and pervasive computing starts to dovetail with this world, that we start to have better view &amp; visibility of all the computing resources around us, via standardized, well known interfaces. Rather than the hodgepodge of manufacturer controlled, invisible, un-debuggable overlay networks that alas, constitute the vast majority of the use of the internet these days. Alas the news there is never good, the new Matter standard is, like Thread, inaccessible, unviewable; consumers are expected to remain dumb, ignorant, unaware of how any of it works, merely thankful for whatever magic they receive[2]. But as a home-cloud, as the manor re-establishes computing as base &amp; competency for itself (#ManorCompute), &amp; as good projects like WebThings[3] or whatever takes it&#x27;s place light the darkened damp corridors only robots patrolled, I hope for a reawakening, hope a silent majority becomes more real &amp; known, hope the fed up, sick of this shit, disgusted with remote-service-based technology world starts to manifest &amp; apply real pressure to emerge a healthy, pro-human, pro-user ubiquotous &amp; pervasive computing that gives us an honest shake, that shows what it is, that integrates into our personal home clouds.<p>I think there&#x27;s a huge pent up demand &amp; desire for flow-based&#x2F;evented systems, for Yahoo Pipes, for Node-RED[4]. The paradigm needs help, I think there&#x27;s too many missing pieces for something like Node-RED to be the one, but re-emerging user-control, giving us ALL flexible means to compute, is key. Exposing &amp; embracing some level of technical literacy is something people want, but no one knows how to articulate it or what they want. We&#x27;re mired in a &quot;faster horses&quot; stage, and it&#x27;s fundamentally incorrect.<p>Last, I have huge hopes for the web. There are incredibly awesome advances being made in the range of peripherals, devices, capabilities the web supports. The web can do so much more. We&#x27;re barely beginning to use the cutting edge ServiceWorkers, barely beginning to use Custom Elements (&quot;WebComponenets&quot;), and these aren&#x27;t even that new any more. These are fundamentally revolutionary technologies. Things like File System Access just came back on the scene after over a decade of going nowhere. Secondary screen working group is tying together multiple systems in interesting ways. There&#x27;s a lot of high-tower shit, in WebAssembly (especially when Interface Bindings starts to allow real interop with JS), in TypeScript, but to me, I think rather than just building up up up there&#x27;s some very real re-assessments we ought to be making about how and what we build. Trying to make self-documenting machines, trying to make computing visible, these aren&#x27;t concerns of industrial computing, but they are socially invaluable advances that have been somewhat on hold in the age of Pax React-us, and we&#x27;re well over half a decade in &amp; while there&#x27;s endless areas to learn about, improve, get better at in this highly industrialized toolset, I want to think there are some slumbering appetites, some desires to re-assess. I&#x27;m a bit afraid&#x2F;scared of WebAssembly being a huge tower-of-babel time-sink&#x2F;re-industrializing-focus that distracts from the need for a new vision quest, but I have hope too, I see the yearning. Albeit often expressed in lo-fi counter-culture, which to me is a distraction &amp; avoidance, rather than the socially empowering act that has been a quiet part of the web&#x27;s promise[5].<p>So I have a lot of tech&#x27;s that seem promising to me. I want to just leave off somewhat with where I started, which is about communities and winners. Whatever happens, for it to go gangbusters, it needs to be accessible. It needs to be participatory, allow a rife ecosystem to grow up &amp; flourish around it. VMs, Docker, Kubernetes, these examples each spun up huge waves of innovation around them. They pass the Tim Oreilly &quot;Create more value than you capture&quot; test, which is core to the tech metastatizing from a specific technology into a wide social practice, into something deeply engaged with by a wide range of users, each testing &amp; advancing various frontiers of the idea, of the tech. Tech that can&#x27;t seed &amp; keep vital it&#x27;s ecosystem ossifies &amp; becomes boring. Tech that can grow a healthy community of adept, knowledgable, driving practitioners has a chance of gaining the social collaboration, social presence, to matter &amp; become a new pivot, has the chance to leave a real mark. Each of the techs I&#x27;ve mentioned struggles with an industrial vs social good problem, struggles to become free enough, to matter enough to become interesting again, but I think we&#x27;re in a much better place than we&#x27;ve ever been to take any one of these- diy clouds, ubicomp, flow-based systems, the web- to the stars.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;kcp-dev&#x2F;kcp" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kcp-dev&#x2F;kcp</a><p>[2] <a href="https:&#x2F;&#x2F;staceyoniot.com&#x2F;project-chip-becomes-matter&#x2F;" rel="nofollow">https:&#x2F;&#x2F;staceyoniot.com&#x2F;project-chip-becomes-matter&#x2F;</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27123944" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27123944</a><p>[3] <a href="https:&#x2F;&#x2F;webthings.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webthings.io&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;nodered.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;nodered.org&#x2F;</a><p>[5] <a href="https:&#x2F;&#x2F;webdevlaw.uk&#x2F;2021&#x2F;01&#x2F;30&#x2F;why-generation-x-will-save-the-web&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webdevlaw.uk&#x2F;2021&#x2F;01&#x2F;30&#x2F;why-generation-x-will-save-t...</a> <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27083699" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27083699</a>
评论 #27159014 未加载
mikewarot将近 4 年前
Fuschia, Genode, or some other capability based operating system. VMs and everything that follows it is a crude approximation of capabilities.<p>The 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.<p>You can&#x27;t give a task N cycles, and these 4 files ONLY on any of the current round of frameworks. This is 50 years overdue.
r00t4ccess将近 4 年前
Twobernetes: Tokyo Drift<p>Realistically VMs, the toolsets are very mature, and it was an incredible waste to spend so much time getting them to work so well and then dumping all of it for containers. Which has you starting all over at zero again due to the lack of maturity, tooling that is all over the place and requires tons of elbow grease to integrate and make work for your use case.
lovebes将近 4 年前
BEAM based Elixir projects shall have a say in the future which might replace Kubernetes.
jenkstom将近 4 年前
Hopefully some sanity! But realistically serverless functions.
prossercj将近 4 年前
Native desktop apps running on personal PCs.<p>No, really. It&#x27;s a cycle.
tmpz22将近 4 年前
A lighter weight self-install toolchain that fits into modern Terraform workflows and allows people to remove vendor dependencies while improving SLA&#x2F;SLO at the same time.
adenozine将近 4 年前
Makefiles. One big circle.
pknerd将近 4 年前
Websites using sqlite.
Thaxll将近 4 年前
Container on the edge!
alexfromapex将近 4 年前
A competitor with a simpler API