Software Infrastructure 2.0: A Wishlist • Hacker News Board

Re: Software Infrastructure 2.0: A Wishlist

#61

Post by tsimionescu » Tue, Apr 20, 2021, 4:57 AM UTC

mLuby wrote: post #44

edoceo wrote: post #29

Earlier quoted context omitted.

many things are confusing if you've never done it before. my first HAproxy setup wasn't great, my 10th is rock solid, just needed a bit of context-specific learning. same with PG replication (locical and archive) but 3rd go was awesome. its a flawed expectation to get it right the first time.

> its a flawed expectation to get it right the first time. If your toilet overflows when you push the lever down and flushes when you pull the lever up, you'll learn pretty quickly how to use it. And other users will too, after they screw up or after you carefully explain so they're sure to understand. But it's just a shitty design! The fact that you've learned to deal with it doesn't excuse it or mean it shouldn't b…

There's still no way around having to learn complex features. For most software, building a really simple first try is very easy, but almost certainly useless.

Once you need to actually do something useful, uunavoidable complexity sets in and all of a sudden defaults and such don't really help anymore.

Some people try to push defaults further with templates and wizards, but that often still doesn't really work for your particular use case, and also makes you first search through many options before realizing you actually need to go for the scary blank one.

Re: Software Infrastructure 2.0: A Wishlist

#62

Post by nine_k » Tue, Apr 20, 2021, 4:59 AM UTC

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.

Virtualization, no. A hypervisor running a Windows kernel and a Linux kernel side by side is not about capability-based security. You can even see it like cap-based security approach: VMs only see what the hypervisor gave them, and have no way to refer to anything that the hypervisor did not pass to them.

Containers, yes. They are a pure namespacing trick, and can be replaces by cap-based security completely.

Re: Software Infrastructure 2.0: A Wishlist

#63

Post by ryukafalz » Tue, Apr 20, 2021, 5:02 AM UTC

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".

Ehh, isn't MAC nearly the opposite of capability based security though? At the core of capability based security is that you don't separate authority to access a resource from your designation of that resource. MAC though seems to go all-in on separate policies to control what gets access to what.

Re: Software Infrastructure 2.0: A Wishlist

#64

Post by knz42 » Tue, Apr 20, 2021, 5:05 AM UTC

XorNot wrote: post #24

Some of this I agree with, even if the overall is to me asking for "magic" (I wouldn't mind trying to get there though). For me the one I really want is "serverless" SQL databases. On every cloud platform at the moment, whatever cloud SQL thing they're offering is really obviously MySQL or Postgres on some VMs under the hood. The provisioning time is the same, the way it works is the same, the outage windows are the…

Have you tried hosted CockroachDB, aka CockroachCloud?

Re: Software Infrastructure 2.0: A Wishlist

#65

Post by nine_k » Tue, Apr 20, 2021, 5:05 AM UTC

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 disruption.

Re: Software Infrastructure 2.0: A Wishlist

#66

Post by stadium » Tue, Apr 20, 2021, 5:07 AM UTC

klintcho wrote: post #33

stadium wrote: post #28

Earlier quoted context omitted.

There is AWS aurora serverless https://aws.amazon.com/rds/aurora/serverless/

I know this perspective is not relevant for most companies: But for side-projects and a-like the cold-start time for Aurora is like 15 - 30 seconds, and the first query always times out. Having it always on (if just 1 "compute") will cost you 30 USD a month. I'm hoping for Aurora to eventually be closer to DynamoDB pricing and startup (I'm fine with 5 - 10 second cold start as long as it doesn't time out the first re…

Interesting, thanks for sharing.

How does data get loaded? Can it use s3 as an external source similar to foreign data wrappers?

Re: Software Infrastructure 2.0: A Wishlist

#67

Post by tsimionescu » Tue, Apr 20, 2021, 5:16 AM UTC

throwaway823882 wrote: post #23

There will not be a massive productivity boost in the next 10 years. We haven't had a productivity boost in the past 20 years. In fact, we're much less productive now. But I digress. We're still largely making and running software the same way we did 20 years ago. The only major differences are the principles that underpin the most modern best practices. "What the fuck does that mean," you say? It means that I can ta…

I wonder what you think is the alternative to Kubernetes that makes it easier to deploy a piece of code to run on a cluster. I hope it's not some kludge of cobbled together shell scripts and ssh.

In general these ideas of magical 'immutable' infrastructures seem to pan out much worse than just plain VMs with some orchestration solution inside. Anything that tries to capture the state of the world and reify it usually has to severly limit what you can actually do to avoid the halting problem, or just copy some things and hope for the best in terms of external dependencies being the same.

Re: Software Infrastructure 2.0: A Wishlist

#68

Post by thundergolfer » Tue, Apr 20, 2021, 5:20 AM UTC

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) examples of companies starting with S3 and then getting too big for it and needing to build their own system (thus wrangling servers and clusters etc). Dropbox migrated off of S3 to 'Magic Pocket' but I'm pretty sure this was for $$ reasons not because AWS simply couldn't handle Dropbox's massive read+write requirements. AWS S3 is a marvel of serverless computing, and we should try and get more like it.

Re: Software Infrastructure 2.0: A Wishlist

#69

Post by esjeon » Tue, Apr 20, 2021, 5:26 AM UTC

intergalplan wrote: post #59

ngngngng wrote: post #21

> but it takes 45 steps in the console and 12 of them are highly confusing if you never did it before. I am constantly amazed that software engineering is as difficult as it is in ways like this. Half the time I just figure I'm an idiot because no one else is struggling with the same things but I probably just don't notice when they are.

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 changes a lot. Even a simple feature can take weeks and months to roll out.

In short, even without stupid people, life sucks. :\

Re: Software Infrastructure 2.0: A Wishlist

#70

Post by tsimionescu » Tue, Apr 20, 2021, 5:30 AM UTC

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…

But that's exactly what the GP is railing against. Trying to hope you don't need to concern ypurself with setting uo the server and thinking about the resources it needs etc is unlikely to be a good idea, or even to work in real terms. AWS Almbda for example only really works if you understand the limitations of the VM and cluster that your code will be running in, and design your system accordingly.

I once worked on a product that didn't, and had ~10s "cold start" latency for any request, because of the size and reliance on lambda. And of course this "cold start" was actually seen all the time, because it was a new niche product that people pnly accessed occasionally, and because it's actually a "cold start" for every concurrent request.