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

Software Infrastructure 2.0: A Wishlist

erikbern.com

Post reply on HN
Print view View original

71–80 of 202 posts

Re: Software Infrastructure 2.0: A Wishlist

#71

Post by slver »

thundergolfer wrote: post #68
slver wrote: post #26

My impressions TLDR: 1. "Built for delight" Author wants everyone to suddenly start making nicer things. 2. "Truly serverless" Author wants to throw code at cloud, without thinking about performance or resource usage. 3. "Fast" Author wants every AWS command to take less than a second. 4. "Ephemeral resources" Author wants to test in the cloud with less effort. 5. "Code not configuration" Author doesn't like static c…

> Author wants to throw code at cloud, without thinking about performance or resource usage. Not really what Erik is saying. Taking AWS S3 as an example, you absolutely need to think about performance and resource usage when dealing with S3, but you never have to think about the servers. You never think about some cluster that is making your S3 usage possible. S3 is such a great success that there's very few (if any)…

Maybe I'm confused by all those doubleplusgood buzzwords that almost deliberately say the opposite of what's happening (like serverless servers).

Re: Software Infrastructure 2.0: A Wishlist

#72

Post by intergalplan »

esjeon wrote: post #69
intergalplan wrote: post #59

Earlier quoted context omitted.

1) It's just as shitty for everyone except the person who's selling themselves as a "consultant" for X. And actually—they're lying, it's shitty for them too. 2) A bunch of other goddamn morons managed to use this more-broken-than-not thing to make something useful, so this goddamn moron (i.e. me) surely can. Both almost always true. After the second or third time you realize something made by the "geniuses" at FAANG…

I'm slightly afraid of all the negativity here, but still kinda agree with the sentiment. However, I still want to note that there are many cases where smart people simply don't have enough time to handle all the stupidity in their products. Often times, it's just little issues like communication cost and politics. But, also often, one should care about the revenue of one's own company or clients', which slows down c…

Oh, yeah, world-imposed restrictions are a factor. Problems aren't all because people are idiots. I, pointedly, don't exclude myself from the "people are idiots" judgement, either. But I think it's also true that the Super-Serious Real World's not half as competent, or capable, or polished, as one might hope. That organization that seems impossibly amazing? They're not, actually. Look closer and they produce bafflingly-bad crap more often than not. The institution with The Reputation? It's because they sometimes get things mostly right, and are good at networking and/or marketing, but if you got a look at how "the sausage is made" you'd be absolutely shocked. The Authority on The Thing? OMG you don't want to know.

Which is horrifying or liberating, depending on one's perspective.

Re: Software Infrastructure 2.0: A Wishlist

#73

Post by pjmlp »

w7 wrote: post #51
mikewarot wrote: post #27

Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.

We've had capability based security frameworks aka MAC (ex: AppArmor) in Linux since 1999 or earlier. Containers (which also existed long before docker) have been popularized for convenience, and virtualization would still be useful for running required systems that are not similar to the host. If anything it looks like we're going towards a convergence with "microvms".

A convinience that only exists when the target hardware and underlying kernel are compatible with the development environmnet, when that isn't the case, oopla, a VM layer in the middle to fake the devenv, or in the devenv to fake the serverenv.

Re: Software Infrastructure 2.0: A Wishlist

#74

Post by intergalplan »

ravenstine wrote: post #11
henning wrote: post #6

The desire to go "truly serverless" and pretend the computer does not actually exist is absolutely delusional. The refusal to acknowledge that software will never be anything beyond executable data on some kind of computer, somewhere, is why most web-based software is so slow and shitty. Having someone build the server and assign your code to run on it does not change that one (pun intended) bit.

I don't think that's really the point, but the term "serverless" is definitely confusing. It took me a while to understand it. By "serverless", usually it's meant that your code doesn't need to concern implementing a server on a socket. All you have to do is have your execution return the right value so that the server in the cloud can do the right thing. No need to setup and configure Express/Fastify. Because cloud…

> By "serverless", usually it's meant that your code doesn't need to concern implementing a server on a socket. All you have to do is have your execution return the right value so that the server in the cloud can do the right thing.

Jesus, the "they just reinvented PHP/CGI and gave it a cute name" folks were more right than I thought.

Re: Software Infrastructure 2.0: A Wishlist

#75

Post by js8 »

mikewarot wrote: post #27

Virtualization eventually will be seen as the unnecessary layer added to make up for operating systems that lack capability based security. It's going to take a decade to refactor things to remove that layer. Once done, you'll be able to safely run a process against a list of resources.

It already exists in the IBM mainframe. But nobody wants to write apps for it..

Re: Software Infrastructure 2.0: A Wishlist

#76

Post by yjftsjthsd-h »

philipswood wrote: post #49
philipswood wrote: post #48

Earlier quoted context omitted.

Agreed. Operating systems abstract resources, the fact that we needed containers and VMs point to the fact that the first set of implementations weren't optimal and needs to be refactored. For VMs, security is the one concern, the others would be more direct access to lower levels and greater access to the hardware and internals than just a driver model. For containers I'd say that the abstraction/interface presented…

(I'm not holding my breath for the refactor though... We're stuck at a local maximum and we're better at adding stuff,rather than removing/refactoring them. Also- just about EVERYTHING is built on top of these current layers)

You just subsume layers. Maybe as simple as Xen++ with a containerd frontend.

Re: Software Infrastructure 2.0: A Wishlist

#77

Post by pm90 »

__jem wrote: post #43
bob1029 wrote: post #31

Earlier quoted context omitted.

Yes we have a 2 stage process with the customer. There is still a test & production environment, but test talks to all production business systems too. Only a few people are allowed into this environment. We test with 1-5 users for a few days then decide to take it to the broader user base.

> but test talks to all production business systems too I'm not sure I understand this, would you mind explaining more? Do you mean you have multi-tenancy in databases and application (the "tenants" being stage/test and prod)?

I think what op’s referring to is a staging app version that talks to production services and databases. Eg you have a “clone” of your production UI, accessible only to devs. This clone is configured to talk to the same DB and call the same dependencies as the production service but since it’s access is limited it’s used by devs to test their new feature(s).

This pattern is used where I work too. It’s been incredibly powerful. Some of our services allow for multiple staging replicas so that nobody is blocking one another; the replicas are ephemeral and nuked after testing.

Re: Software Infrastructure 2.0: A Wishlist

#78

Post by [deleted] »

nine_k wrote: post #65
bob1029 wrote: post #2

I love the test-in-production illustration. This is a fairly accurate map of my journey as well. I vividly remember scolding our customers about how they needed a staging environment that was a perfect copy of production so we could guarantee a push to prod would be perfect every time. We still have that customer but we have learned a very valuable & expensive lesson. Being able to test in production is one of the mo…

You can test in production by moving fast and breaking things (the clueless guy). You can test in production by having canaries, filters, etc, and allowing some production traffic to the version under test. This is the "wired" guy. For many backend things, you can test in production by shadowing the current services, and copying the traffic into your services under test. It has limitations, but can produce zero disru…

[deleted]

Re: Software Infrastructure 2.0: A Wishlist

#79

Post by pm90 »

esjeon wrote: post #69
intergalplan wrote: post #59

Earlier quoted context omitted.

1) It's just as shitty for everyone except the person who's selling themselves as a "consultant" for X. And actually—they're lying, it's shitty for them too. 2) A bunch of other goddamn morons managed to use this more-broken-than-not thing to make something useful, so this goddamn moron (i.e. me) surely can. Both almost always true. After the second or third time you realize something made by the "geniuses" at FAANG…

I'm slightly afraid of all the negativity here, but still kinda agree with the sentiment. However, I still want to note that there are many cases where smart people simply don't have enough time to handle all the stupidity in their products. Often times, it's just little issues like communication cost and politics. But, also often, one should care about the revenue of one's own company or clients', which slows down c…

The smartest people can build utterly useless crap if the teams they work on don’t prioritize UX. I think of it as “emergent stupidity”; individually they will optimize for and build the best components but if they aren’t well put together the UX is horrible and the product sucks sucks sucks.

On the contrary, users will be ok with suboptimal components if the overall UX is good.

Re: Software Infrastructure 2.0: A Wishlist

#80

Post by zmmmmm »

deepzn wrote: post #46
zmmmmm wrote: post #30

This post mingles different interpretations of "serverless" - the current fad of "lambda" style functions etc and premium / full stack managed application offerings like Heroku. Although they are both "fully managed" they have a lot of differences. Both though assume the "hard" problem of infrastructure is the one-time setup cost, and that your architecture design should be centered around minimising that cost - even…

what would you say is the architectural sacrifice of pushing things out to the edge, or using lambda functions per say in your opinion? There are issues about resolving state at the edge, though Cloudflare has solved some of that with durable objects, and Fastly is working on something too. Think there are memory constraints as of now however. Security too is better in these platforms at the edge - true zero trust mo…

It's similar to the issues with microservices. You've broken something that could be "simple" single monolithic application into many pieces and now there is huge complexity in how they are all joined together, fragemented state, latency, transactional integrity, data models, error handling, etc etc. Then your developers can't debug or test them properly, what used to be a simple breakpoint in the debugger and stepping into a function call and directly observing state requires a huge complexity to trace what is happening.

All these things got much harder than they used to be, and you're living with that forever - to pay for a one-time saving on setting up some self-updating, auto-scaling infrastructure.

Post reply on HN