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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Software Infrastructure 2.0: A Wishlist (2021)

102 点作者 whoiskatrin超过 1 年前

20 条评论

015a超过 1 年前
Here&#x27;s something very specific I&#x27;ve been thinking about recently.<p>I think Google Cloud Cloud Run is obscenely ahead of its time. Its a product that&#x27;s adjacent to so many competitors, yet has no direct competitor, and has managed to drive a stake into that niche in a way that makes it such a valuable product.<p>Its serverless, but not &quot;Lambda Serverless&quot; or &quot;Vercel Serverless&quot; which forces you to adopt an entirely different programming model. Its just docker containers. But its also not serverless in the way Fargate or ACS is &quot;serverless&quot;; its still Scale to Zero.<p>There&#x27;s a lot of competition in the managed infrastructure space right now (Railway, Render, Fly, Vercel, etc). But I haven&#x27;t seen anyone trying to do what Cloud Run does. Cloud Run has its disadvantages (cold starts are bad; it also could be a great fit for background workers&#x2F;queue consumers&#x2F;etc, but Google hasn&#x27;t added any way to scale replicas beyond incoming HTTP requests yet).<p>But the model is so perfect that I wish more companies would explore that space more, rather than retreating to &quot;how things have always been done&quot; (&quot;pay us $X&#x2F;mo to run a process&quot;) or retreating to the much more boring &quot;custom serverless runtime&quot;, &quot;your app is now only a &#x27;AWS Lambda app&#x27; and cant run anywhere else congrats&quot;.
评论 #39530908 未加载
评论 #39528779 未加载
评论 #39533294 未加载
评论 #39529558 未加载
评论 #39533120 未加载
评论 #39529046 未加载
评论 #39531396 未加载
throwawaaarrgh超过 1 年前
The one thing I want, that doesn&#x27;t exist, and won&#x27;t for at least 10 years: immutable infrastructure.<p>Oh, the <i>concept</i> exists. I can make <i>some</i> infrastructure mostly-immutable, myself. But the cloud doesn&#x27;t give me it out of the box. What the cloud gives me are APIs. If I write software to call those APIs, predict what the allowed values are, predict the failures I might see, write about 5,000 lines of code to handle the failures, attempt to reconcile differences, retry, store my artifacts, reference them, after implementing a build system, etc, I can get one or two things to be immutable. But for the vast majority of services it&#x27;s actually impossible.<p>Take an S3 bucket. Can you make an S3 bucket immutable? The objects inside it might be versions, sure. Can you roll back <i>all</i> the objects in the bucket to Version 123? Can you roll back the S3 policy back to revision 22? Can you make it also roll back the CORS rules? Can you diff all these changes and see a log of them? Can you tell the bucket to fix itself back to the correct expected version of itself? Can you tell it to instead adopt 3 new changes, as part of a version of the S3 bucket you tested somewhere else? The answer is &quot;no&quot;.<p>You can <i>fake it</i>, with a configuration management tool like Terraform. But that&#x27;s as immutable as a file on your filesystem. Any program can overwrite your files at any time; you have to have Puppet configured to monitor your files, and constantly fix the files when they get changed, track the Puppet code in Git, keep your own log of changes, etc. That filesystem isn&#x27;t immutable, it&#x27;s <i>mutable!</i> If it was immutable you wouldn&#x27;t have to use Puppet (or Terraform). And the sad thing is we&#x27;re all stuck on Terraform, which is actually terrible for a configuration management tool, because it mostly refuses to reconcile inconsistencies (the way every other configuration management tool in history has). It just bombs out and says <i>&quot;Oh shit, that wasn&#x27;t a change I planned, and you didn&#x27;t write this HCL code to handle this weird condition, so I&#x27;m just gonna bail and not fix this. Good luck getting production working again.&quot;</i> Puppet wouldn&#x27;t stop working if something other than Puppet updated a file. But nobody seems to mind that we literally regressed in functionality, because a company made up new marketing terms for their tools.<p>Sadly this desired built-in immutability, and the declarative nature of it, won&#x27;t be built into S3 or other tools for at least a decade or two. They would need to effectively build something akin to K8s just to manage their own components immutably and expose an entirely new API. So we are doomed to do Configuration Management in the cloud, until the cloud starts implementing immutability out of the box.
评论 #39539183 未加载
评论 #39533140 未加载
socketcluster超过 1 年前
I built a serverless SaaS no-code&#x2F;low-code platform which could be of interest: <a href="https:&#x2F;&#x2F;saasufy.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;saasufy.com&#x2F;</a><p>You can build your entire app inside a plain HTML file which can be deployed online with something like GitHub pages.<p>I&#x27;ve built a few apps with it including a real-time chat app which supports both group chat, private 1-on-1 chat with an account system (with access control), OAuth via GitHub... The entire app is only 260 lines of HTML markup and fully serverless (no custom back end code). Access controls are defined via the control panel. All the app&#x27;s code is in this file: <a href="https:&#x2F;&#x2F;github.com&#x2F;Saasufy&#x2F;chat-app&#x2F;blob&#x2F;main&#x2F;index.html">https:&#x2F;&#x2F;github.com&#x2F;Saasufy&#x2F;chat-app&#x2F;blob&#x2F;main&#x2F;index.html</a><p>You can try the app here (use the &#x27;Log in with GitHub&#x27; link): <a href="https:&#x2F;&#x2F;saasufy.github.io&#x2F;chat-app&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;saasufy.github.io&#x2F;chat-app&#x2F;index.html</a><p>Saasufy comes with around 20 generic declarative HTML components which can be assembled in complex ways: <a href="https:&#x2F;&#x2F;github.com&#x2F;Saasufy&#x2F;saasufy-components?tab=readme-ov-file#saasufy-components">https:&#x2F;&#x2F;github.com&#x2F;Saasufy&#x2F;saasufy-components?tab=readme-ov-...</a><p>There is a bit of a learning curve to figure out how the components work but once you understand it, you can build apps very quickly. The chat app only took me a few hours to build.<p>I&#x27;ve also been helping a friend to build an application related to HR with Saasufy and I managed to get the basic search functionality working with only 160 lines of HTML markup.
fhuici超过 1 年前
&gt; The speed that&#x27;s not there is setting up infrastructure. If I make a change in the AWS console, or if I add a new pod to Kubernetes, or whatever, I want that to happen in seconds. I&#x27;m not asking for milliseconds!<p>Milliseconds is now possible: <a href="https:&#x2F;&#x2F;kraft.cloud&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kraft.cloud&#x2F;</a> (e.g., an NGINX web server in under 20 millis).
评论 #39525527 未加载
评论 #39524422 未加载
mike_hearn超过 1 年前
It&#x27;s a sub-component but Oracle Labs has a project to develop something like the FaaS platform he&#x27;s asking for, called GraalOS.<p>The basic idea is that FaaS is a leaky abstraction because (a) lots of runtimes are slow to start up and (b) isolation tech isn&#x27;t good enough. So FaaS services start up VMs and containers and then the user&#x27;s function which might have to do a lot of init work, like to load reference data, and because that takes too long you have to keep idle capacity around. At that point the abstraction is broken.<p>So there&#x27;s a two-part fix:<p>1. For Java users, the GraalVM native-image tool can pre-initialize and pre-compile a JVM app so that it starts up instantly (including with pre-loaded reference data).<p>2. Change the isolation model so VMs and containers don&#x27;t need to be started up anymore. Containers alone can take hundreds of milliseconds to start.<p>There&#x27;s also some interesting stuff there that takes advantage of Oracle Cloud&#x27;s more &quot;edgey&quot; nature than other clouds, where it has more datacenters than others (but smaller).<p>The new isolation model works by exploiting new hardware features in CPUs that allow for intra-process memory isolation (Intel MPK) combined with hardware-enforced control flow integrity. This requires compiler support, but GraalVM knows about these features and so the cloud can just compile JVM apps to native for you. And what about other apps? Well, many languages run on GraalVM via Truffle, so those are covered (e.g. JavaScript) and for native code you can use a modified LLVM to compile and then do a static verification of any user supplied binaries, like NaCL used to do.<p>If you put those things together then starting user code that&#x27;s already available locally becomes just mmapping a shared library into a process, which is extremely fast. It can only exit the hardware&#x2F;software enforced isolate by going via a trampoline that&#x27;s equivalent to a syscall, but without needing an actual syscall. The Linux kernel isn&#x27;t reachable at all.<p>With that you can have functions that start and stop in milliseconds.
sethkim超过 1 年前
What&#x27;s cool is that Erik actually acted on these complaints. Modal is, by far, my favorite developer tool ever and makes me hopeful not just for the future of software engineering but the entire tech industry.<p>If you&#x27;re a naysayer in the comments, I would encourage you to go give it an honest try, and consider again why you think infra has to be done in harder ways.
评论 #39530995 未加载
friedrich_zip超过 1 年前
I get where he is going with this... but idk. Feels like a somewhat mid take. Strong abstractions always means strong vendor lock-in and more power to infrastructure providers. But AWS, Netlify and whoever runs your apps are not your friends. Vertically integrating your infrastructure can be a pretty good source of cost reduction and can create interesting assets if you have good talent in-house. So idk... sometimes the fact that building something takes time and you have to think about how you are going to set it up actually is a good thing, because you take the time to build it right and you end up understanding how everything works together.
cheptsov超过 1 年前
I have a lot of respect for Erik and his work with Modal, which I&#x27;ve heard a lot of good feedback about. What Erik says about serverless and code over configuration can benefit many users and companies. However, I strongly disagree on the main points and certainly have a different wishlist for infrastructure. My main point would be on that list – open-source and vendor-agnosticism.<p>Finally, I believe simple configuration can coexist with code.<p>P.S.: At dstack, we are building an open-source platform to manage AI infra – a more lightweight and AI-friendly alternative to Kubernetes.
mdaniel超过 1 年前
(2021) and at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26869050">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26869050</a>
评论 #39528062 未加载
pnathan超过 1 年前
One my basic design philosophies is I learn key things deeply, and fit them together, without layers of &quot;make it easy&quot; tools that introduce incessant XY problems and integration issues.<p>If something is &quot;magically&quot; easy, it either is a meaningful design&#x2F;algo revolution or it overpromises the production case while showing off the trivial. Most of the time it&#x27;s #2. Docker was #1.
samsquire超过 1 年前
I enjoyed this post, thank you.<p>I&#x27;m encouraged by the same ideas.<p>Sometimes you just want something that stays running and doesn&#x27;t go down and can scale to zero and scale upwards, ideally with revenue.<p>I kind of want a special mega HTTP form endpoint which I can define a pipeline from, that can go to database and cause background jobs and goes into a mega API automatically.
fbergen超过 1 年前
I would love to have what we were sold as a “truly” serverless (even though the name doesn’t mean no server)<p>- CloudRun did a good job, but the autoscaling is too slow to not pay for idle<p>- Lambda is great, but I want to run way more complex workloads than simple functions
评论 #39540245 未加载
评论 #39524329 未加载
shayarma超过 1 年前
So true. why are we still paying for idle resources in 2024?
swyx超过 1 年前
we recently interviewed Erik and touched on this list: <a href="https:&#x2F;&#x2F;www.latent.space&#x2F;p&#x2F;modal" rel="nofollow">https:&#x2F;&#x2F;www.latent.space&#x2F;p&#x2F;modal</a><p>and how Modal exemplifies a lot of the ideas he&#x27;s been looking for. check it out incl our show notes!
thecleaner超过 1 年前
These are bad ideas. They are software wishes which no enterprise will pay for. Infra is setup once so optimising for setup time doesn&#x27;t do the trick. Rollouts should take time deliberately so faulty software don&#x27;t lead to an outage in seconds. No infra provider will bother turning off infra as again it can have impact on availability. AWS is optimising resource usage anyway barring a few services like Cloudwatch
PaulDavisThe1st超过 1 年前
Within a few lines of each other in TFA:<p>&gt; We are, like what, 10 years into the cloud adoption? Most companies (at least the ones I talk to) run their stuff in the cloud. So why is software still acting as if the cloud doesn&#x27;t exist?<p>&gt; As in, I don&#x27;t want to think about future resource needs, I just want things to magically handle it.<p>&#x27;nuff said.
评论 #39525923 未加载
crabbone超过 1 年前
If I didn&#x27;t know better, I&#x27;d think I&#x27;m reading one of those cheesy LinkedIn advertorials... To someone who dedicated their professional life to infrastructure all of these wishes read mostly irrelevant, with a strong proprietary advertising flavor. At every turn of a sentence I expected to find a mention of some commercial product this article was going to promote. Well, at least it doesn&#x27;t seem to do that, not openly anyways.<p>So, here are some thoughts on what seems to be the key points of the article:<p>* I want to go fast.<p>Well... yeah, sure, why not... but it&#x27;s not very important. Lots of other goals will overshadow this one. Also, if we are talking in the context of whatever-as-a-service, there&#x27;s very little incentive to work on the speed aspect as long as it not taking ages.<p>Also, reducing infrastructure to whatever-as-a-service is seriously hollowing the definition. I&#x27;ve been in ops &#x2F; infra for over a decade, and I&#x27;ve barely even touched the as-a-service aspect. Also, whenever I do come in contact with it, it&#x27;s always awful, and I want to get away from it as fast as possible. Making it go faster won&#x27;t help that though. The disappointing parts are poor documentation, poor support, proprietary tech. overly narrow scope etc.<p>* Testing in production<p>Why is this even a relevant issue?.. Anyways. OP needs to take a trip to the QA department. They obviously don&#x27;t know why they have one. But it&#x27;s also possible their QA department is worthless (ours is...) But having a worthless QA department isn&#x27;t really something to wish for in Infrastructure 2.0. I don&#x27;t see how this is a good goal.<p>So, the reason why QA department is necessary, and why CI can possibly cover only a fraction of what can be &#x2F; should be done with testing is that QA, beside other things, needs to simulate plenty of different possible conditions in controlled environment to be able to investigate and to diagnose problems. Most of the work of QA is spent on RCA, and then figuring out how to present the problem, stripped of all unnecessary components to the development team to be able to fix it. It&#x27;s not possible to do good QA w&#x2F;o an ability to isolate components which calls for creation of fake &#x2F; artificial environments which are not like production.<p>* Calls to unleash the next order of developer productivity<p>This is such an MBA b&#x2F;s... Just give it a break.
评论 #39540778 未加载
phrotoma超过 1 年前
&gt; You know how crappy software is crappy in ways that are so blatantly obvious to the user that you wonder why it was released?<p>It has crossed my mind several times recently that I want a word to describe this exact state of affairs. Where a thing has a defect so blatant that it is evident to any user that the creator of the thing has never tried using it.<p>Eg. an airbnb with no towels in it.<p>What&#x27;s the word for this situation?
评论 #39524448 未加载
评论 #39525107 未加载
评论 #39525077 未加载
评论 #39525419 未加载
评论 #39525458 未加载
stavros超过 1 年前
This isn&#x27;t substantive, but it bugged me:<p>&gt; I&#x27;m not asking for milliseconds! Just please at least get it to less than a second.<p>What do we measure &quot;less than a second&quot; times in?
评论 #39527955 未加载
zsoltkacsandi超过 1 年前
The author apparently does not have any experience in building systems&#x2F;infrastructure.<p>&gt; I can set up a static website in AWS, but it takes 45 steps in the console and 12 of them are highly confusing if you never did it before<p>Anything can be confusing&#x2F;takes time if you never did before. Getting productive needs time and practice. If your goal is only to set up a static site, AWS is an overkill for it.<p>&gt; It&#x27;s sad this is the current state of infrastructure.<p>It’s sad that some people still haven’t learned to pick the right tool for a problem.<p>&gt; I could go on, but I won&#x27;t. I&#x27;m dreaming of a world where things are truly serverless.<p>I don’t even understand what the author wants here. There is no such thing “truly serverless”. Your code will be executed by a server. Period. Serverless is just a fancy marketing term for ephemeral lightweight VMs.<p>&gt; If I make a change in the AWS console, or if I add a new pod to Kubernetes, or whatever, I want that to happen in seconds<p>The author obviously doesn’t have any knowledge about distributed systems.<p>&gt; My deep desire is to make it easy to create ephemeral resources. Do you need a database for your test suite? Create it in the cloud in a way so that it gets garbage collected once your test suite is done.<p>Fortunately we have Terraform that’s made this possible for a decade(?).<p>&gt; Code not configuration<p>Terraform, Pulumi, countless of client libraries for all of the cloud providers.
评论 #39528106 未加载
评论 #39523220 未加载
评论 #39523387 未加载
评论 #39525007 未加载
评论 #39526047 未加载
评论 #39523600 未加载
评论 #39523564 未加载
评论 #39526847 未加载
评论 #39523947 未加载