bcaxis

Start by building a business that isn't differentiated by how many 9s you have. Something customers want so badly that a few hours of inconvenient downtime doesn't move the needle at all.

In this situation, blowing up your system complexity to maybe get another 9 makes no sense. Then the revenue change is pretty irrelevant for modest downtime.

People under estimate single server uptime. If availability is really that important, buy a hot backup. Put it in another region. Done.

> I like the power that we see with cheap commodity hardware, but we mustn't forget that it's crap.

Google grew up (early days) using cheap white box consumer PCs while "best practice" was expensive server boxes.

It's a tried and true method of budget hosting.

The mini PC world is exploding and they make for a solid low cost, low power server platform.

It also makes having hot and cold spares cheap and easy.

I think it's more an architecture question. If one box works, stop building on services that force horizontal thinking, and pricing, from the get go.

You can solve one box availability with box 2 (hot backup) - all within the same architecture and price structure.

> 2. Unidirectional end-to-end latency only applies to streaming data.

Agreed that his "across the world" example is a bit silly. Because he doesn't take into account the connection construction.

His primary point is still reasonable. How many services need world wide reach? Did you build it for multiple languages also?

If you're in the US. Or you're in the EU. A nice centralized server will have <=30 ms of latency to the entire region you are serving.

Edge is over valued unless you do have true global needs and then you have to also manage global database (s).

I do something similar with stripe. I add two items to the subscription. A base unit that charges a fixed price up front and monthly thereafter. And usage based second item that bills based on usage minus the pre charged items. Usage based fires for the first time on their second charge.

If the user cancels their subscription, I run it through the next payment period for their usage based billing period and then cancel it.

I do something similar with stripe. I add two items to the subscription. A base unit that charges a fixed price up front and monthly thereafter. And usage based second item that bills based on usage minus the pre charged items.

New billing primitives. Cost per invocation on functions and edge requests where it used to included in GB/h and bandwidth.

Cost per cache read and write instead of lumping it all in the bandwidth bill.

My reading is that the criticism of the bandwidth egress fees and it's inevitable unfavorable comparisons has hit home.

Only they were using that bucket for more than just egress. So they are breaking charges apart and this is going to have winners and losers from their customer base.

Reminds me of cloudflare pricing. They don't charge you bandwidth but do charge for invocations and if you do the math on how they bill invocations, the egress is in there - you are not escaping it. But the press of no egress fees is nice.

Making stuff faster is relatively straightforward engineering. Optimisation is a favored past time of many engineers.

Getting stuff that people value enough to pay for, to make money, is the hard part.

Any friction you put into the value creation process because "optimizing for future problems" is just doing it wrong.

> 2. The founder doesn’t understand that the value in a startup isn’t the idea but the ability to execute and build on that idea.

The best startups have both.

You can execute, great. But if you have poor industry understanding and no idea what is going to work in that space. Let alone something that is going to revolutionize the space. It is, similarly, not going to work.

Your industry expert need to have 20-30 years in the space. Understand it from the ground up. That guy is actually valuable.

It's not one idea, it's comprehensive understanding of all the current struggles in the space.

I've seen such title inflation work for people.

Recently watched a relatively young person parley a position at a small company with a VP title that resulted in a slot at a regionally well known organization as a director and then president of a much larger startup.

Over about 4 years he went from front line sales to running a sizeable company with the key step being the VP title at the small company that rocketed him up.

I also recall a former co-worker that was denied promotion and generally failing to progress in his career. He took a slot at a tiny company explicitly for the title. I think it was director. He managed to parlay that into very positive career moves.

Personally, I don't care as much about titles these days. I just don't want to work for places making terrible tech decisions and forcing me to work within that. I'm happiest making the decisions and really don't want to stop, whatever it's called.

> it's not like you're going to realize equivalent margins by running your own little server

I get even better than their margins. In the neighborhood of 100x cheaper. It's not rocket science.

> equivalent availability

AWS availability isn't all that super great. Most of their services are rated for only 99.95 before they offer pittance credits. That's not difficult to meet with a single computer...

> scalability

A service only needs good enough scalability. Auto scaling is also a bug, not just a feature. Remember that it is also tied to auto billing. I can't afford to have my wallet DDOSed.

> security

Security is always a problem that needs to be solved. You don't get an auto pass on security needs because you signed up for AWS.

> support

You have to pay for that.... You can get it from other vendors too if you have budget for it.

> ecosystem

This is flat out wrong. Compare AWS offerings to the breadth and depth of open source offerings and the latter comes out far ahead.

AWS spends tons of engineering time on features you don't need. There is a lot more than 30% on the table.

The cheap instances are ipv6 only and only a couple of their regions have them. Atlanta, I think, does. But yeah, it's a teaser that isn't realistic. At least for me.

> nobody measures such metrics: size, bloat, speed...

Have you ever looked at the bloat of linkedin web? I've had tabs over 1GB memory use. Most bloated site I've ever used with any kind of regularity.

> Not related to Libkedin, but what is the carbon footprint of all electron-based apps that take hundreds of megabytes and gigantic amount of processor time?

I make an election app. It uses 70-80 mb of RAM when running. It's not that bad when you don't blow out your dependencies and code structure.

Apparently I don't understand. If the code isn't poor, why throw it away for a new even more complex system? I don't know how code isn't poor, yet is indecipherable.

Regardless, the method works even in a complex environment.