noogle

No, I do not.

However, I've heard (too) many stories like "our payments/ads/infra vendor banned us out of the blue for suspicion/politics/obscure-AI-decision" to ignore this. It could be fine for a start-up that is inherently risky, intended to fail early and risks Other-People's-Money (TM), but not always.

Based on my limited experience, VCs could be dissuaded from investing in co-ops by:

1. No prospects of a big payout (IPO, acquisition).

2. VCs like to have a single point-of-contact (the CEO) and few other owners. In a start-up, the CEO is answerable and serves only the investors. Co-ops behave more like a member-driven organization whose obligation is first and foremost to its members.

3. No option for majority ownership. A co-op eventually has to be majorly owned by the employees rather than by investors.

What's wrong with paid hosting? For the people who do pay for software (essentially commercial entities), the management and support are as important (if not more) than the software itself. The code being open-source is actually a great advantage because it alleviates concerns around lock-in and vendor going under (If e.g. AWS's RDS is for some reason no longer available to us, I can still run Postgresql myself, at least until I find an alternative).

The median salary for software engineers is not that high. Still ~double the median household salary, but it's not the only profession that yields that.

So you were not completely wrong.

The efficiency of our bodies (or the amount of calories in food) is astounding. Makes one think whether there is any acceptable use case for serving snacks and other high-calorie-density food.

> It's solvable with appropriate tooling. I.e. you can store API definitions in a separate repository and make the services or CI/CD check API usage is valid at build time. Makes sense, though it feels somewhat like re-inventing the wheel (same-codebase tooling are generally easier and faster to use).

> What do you mean by that? Data and workflow have to be unified across the company's products to provide the user with a seamless experience. As above, to me this seems may contradict some components of microservices like splitting the database, since one ends up with the same constraints (synchronization, shared schema) while complicating the orchestration (since now cross-system integration is needed).

Sure, something like Reddit or HN can break the unified experience, but any important or productivity system will greatly suffer from such fragmentation. I assume it can be achieved with micro-services, but it seems somewhat harder.

That's what makes the whole idea of microservices seems weird to me. If a functionality has merit on its own (e.g. an authentication service), then it will naturally fall outside of the main application. If a service is tightly coupled to other parts of the app, then microservices seems like intentionally hindering yourself: the coupling remains (as evident by the need for backward compatibility), but now we it's harder to keep everything aligned due to the extra separation (e.g. different code bases, multiple databases, no static validation of remote interfaces etc.).

The point of organizations and products is to work as a tightly coordinated machine. The decoupling that microservices create seems opposite to that goal.

Happy to hear different perspectives.

How can accumulation of versions be prevented? Now the same team has to maintain two products, and the underlying mechanism is still limited by the older version.

Anecdotally, a robust backward-compatibility has been seen as a hinderance to e.g. Java's progress (so much that a newer language, Kotlin, was created to break free from that burden).

But you also need to hire someone to manage the AWS infrastructure.

And the need to use-only-as-needed creates additional burden that doesn't exist with cheaper monthly-paid hardware.

The answer might very well be "it will take less time to manage AWS", but it's not clear. Some might need a pay-stack to handle the cloud's pricing.

But moving off of the cloud is not always realistic. If the start-up leveraged cloud-specific services, they are now locked in. If they remained cloud-agnostic, they were under-utilizing the cloud.

How many companies actually shift their infra vendor?

> so you don't need to spend months working up a contract with a new vendor and doing the security audit dance.

That's a very big moat. Many decision makers are risk-averse w.r.t to infrastructure vendors and don't mind paying (or making someone else pay) a premium for that.

The only thing that changed in the saying "no one was fire for choosing IBM" is the name.

COVID has a strong absolute-calendar trends (variants, waves), so removing the absolute dates might harm the analysis.

From another comment: > Seems to be worth the inflation IMO.

Some things will become expensive. Some might be balanced. Construction cost will increase, but land value may decrease (since there is no necessity to crowd in job hubs).

Taxis and Uber will probably increase as people are not forced to work at all costs, but people might find this trade-off favorable: unemployment is far more painful than having to take the bus.

And everyone could still work to afford expensive things, if they chose so. They will also have much better working conditions, since they will have much more negotiation power.

Yet that did not deter us from creating trillions of dollars and giving them to financial institutes.

What if we printed the same amount and gave it directly to people? the $6T/year could yield ~$40K to each of the ~150M working-age Americans.

The biggest impact is to give employees more power in the negotiation with employers: currently, employees are far more pressed to find work than the employer needs to fill in a position (if the employee fails to pay rent, they are evicted; if an employer fails to meet a deadline, nothing happens immediately), and have the inherent disadvantage of having orders of magnitude more employees than employers.

UBI will help the public by reducing the pressure on employees to find job, thus improving the negotiation power and conditions for all other employees. Even the slight help during COVID created the best conditions for working people in decades. Seems to be worth the inflation IMO.

> Money doesnt just have some "value" you can share like a pie.

The trillions of dollars printed by the Federal Reserve in the past two years beg to differ.

Honestly, if the country is going into deficit, you might as well give it directly to people instead of injecting it via financial institutes.

Society in general may greatly benefit from having people not HAVING to work.

Because often someone else is paying for it (organization/investor/government) or the money cannot be used for something else. Another common reason is as a way to circumvent internal politics.

In my experience, whenever someone actually had to "foot the bill" for the AWS premium, your argument that the cloud is cheaper overall came under a very heavy scrutiny, including justifying those extra "9s" that increase administration effort.

How does the compensation compare? Aside from finance, does any other industry pay as well as SV and startups?

But a dynamic language needs all the tests a compiled language needs AND type/syntax tests (that are handled by the compiler in a static language).

There are reasons dynamic language (or specifically Python), but I haven't heard one explanation how it helps writing fewer tests.

This system creates a vicious cycle - cannot get a rental without history, and cannot accumulate history without rentals.

It creates a gatekeeper that enables discriminative behaviors.

Is it really necessary to index EVERYTHING? It's true that we have much more data today than 26 years ago, but not all of these websites qualify or provide value (duplicate results, promotional content, outdated content).

The challenge then moves to the curation, but it's no longer infeasible.

But if someone chose DoorDash over a smaller delivery service because "DoorDash is big and reliable so the x5-10 cost is worth it", and then DoorDash fails repeatedly, it makes sense to ask "is DoorDash really better than using the smaller vendor?"

Agree. I would add the Netflix/Spotify are more in the content business rather than software (a huge chunk of Spotify revenues actually goes to paying royalties, and Netflix spends substantial amounts on original productions).

So indeed, consumers do not buy software - they buy other things (that businesses do not buy): Services and solutions to "real-world" problems.

Some of these things are new, but some have been around for years and decades. No one HAD to buy a server - co-location/bare-metal hosting has existed for years before AWS. The same for printing. Stripe perhaps made the biggest difference, mostly because this field is more tightly regulated so there is more value to a one-stop-shop solution.

While they might provide "a" solution, those "API" services also don't solve provide a complete/optimal solution (You still need to understand information retrieval to make your search work well), and they sometimes create new problems (as demonstrated by the plethora of cloud consultants).

For non-core activities it could be fine, but for activities the affect the product itself (E.g., search is essential for e-commerce), outsourcing all responsibility to a vendor is risky.

The logical conclusion is to move to the US, then. But seriously, the software industry concentrates in the US. The high salary represents (in part) this concentration rather than something about the US itself. Thus, it makes sense that companies are not looking outward - employees that are worth this kind of salary have already moved to the US. Similar to how other industries chose other places to concentrate. Any "market" of numerous agents requires an agreed-upon "marketplace" - not just geographically, but also legally.

But isn't employment in the US largely at-will? Meaning that the employer can fire the employee for any reason except for protected classes discrimination?

So it doesn't matter if it's fraud or the employer just doesn't like the employee. The implications are the same.

Why is the comparison always between public cloud and building your own data center from scratch?

There is a middle ground of bare-metal hosting. Abstract away the hardware and networking. Do the rest yourself.

One thing that is missing is the unit economics and customer subsidization. If the company sells a product worth $5, for $1 (essentially subsidizing the customer), then it cannot become profitable just by a decision to stop growth.

So in your example, and offer of 13% annual yield but with %400 commission is not a profitable one.

> So did you send your database logs to a centralized logging system?

Not needed.

> Did you set up roles and keys to access those systems?

Yes.

> Are your roles integrated with the rest of your permissions system?

Not needed. Access to the DB is limited to a very small circle, by design. Postgresql's mechanisms suffice.

> Do you have a perf dashboard where you can see the real-time usage of your DBs?

htop/task manager and Postgresql's internal monitoring have so far been sufficient.

> Have you already rehearsed updating your database version?

Indirectly yes, although AFAIK (happy to learn otherwise) major version update are also not supported by RDS.

This has been working for years now, with actual paying customers (so "in production"). It's always about opportunity-cost and diminishing returns: RDS costs about as 3 developers. The benefit the product gets from 3 more developers far outweighs the benefit of another "9" in the SLA.

Even if all of the savings would have gone to pay for a DBA, we'd still get a better deal: an in-house DBA will focus on addressing our specific needs. RDS also has a serious opportunity cost since it prohibits using extensions that are very useful for us, forcing us to spend time on workarounds.

And frankly, it's not like RDS is even that reliable. We had multiple incidents where the database stopped responding or slowed down to a crawl for several hours, and we had now way to debug this (since we cannot access the server itself). They also don't seem to handle anything about Postgresql tuning.

For the customer, the app slowing down (because RDS has a very limited IO bandwidth) is an outage (and is much more frequent than some system error).

tl;dr: Many people can meet their needs with a Ford, and living on the streets to pay for the extra features of a Ferrari is not a good tradeoff for them.

EDIT: line spacing

There it is - the hidden cost of AWS. For bare-metal the risk of hardware failure is so low that it's faster to just handle the interruption when it happens (e.g. just restart the process) than to implement interruption tolerance. The hardware fails only once in many years. The chances of that happening during the 24 hours we train a model are almost zero. On a spot instances, the risk of the same are almost 100%, requiring investment up-front.

For the price of a spot instance we can get an always-on bare-metal server without having to worry for how long it will remain available.

Spot instances for GPU are shutdown within hours. As frequently touted in favor of AWS, engineer time is the most important thing. The time to adapt the code to frequent failure, and the delays in getting the results, costs money as well, negating the financial saving from spot instances.