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.

Sometimes API calls make 5-10 queries to the database. So it's 600ms to setup TLS and make a call at the origin server and the number of db calls is irrelevant. Or a quick TLS connection to the edge and 1000-2000ms to fulfill because of db distance.

Maybe you can do some of the calls in parallel, but sometimes not. Session lookup plus another query after permissions are established and your edge latency savings are almost entirely gone.

Follow-up API calls will always be worse because TLS is a one time issue and db distance will continuously bite you call after call after call.

Then there's a cold start where the edge function has to link up with the database and do it's own TLS or equivalent.

Edge functions have a lot of issues you have to worry about that increase system complexity to solve.

You could solve this other ways. Build a new better monolith and have a reverse proxy route between them and slowly update and move routes over. You will get through a rewrite slowly one bit at a time.

If you keep the same database schema this should generally work pretty well.

I migrated a terribly written web app this way, it worked pretty well.

If your database is a long ways off an edge connection could end up with a worse latency situation than TLS setup.

Distributed database is usually painful.

Fewer IT staff for systems mgt

This hasn't been my experience. Replace sysadmin with cloud engineer/architect, salary bump, no reduction in quantity. This assumes you are mildly competent as an organization.

On managed services, say the database. My experience is that the extra costs of the service are larger (usually much much larger) than any salaries or head count reduction. I'd rather employ more people than not, and actually control my data, given the choice. Particularly when the savings are questionable or false.

I generally prefer a lower dependency count. Code and vendor. Even at modest immediate cost increases, you gain better flexibility and there are less things to bite you.

Reduced costs in off peak hours with on-demand instances.

Agreed. You do increase system complexity to accomplish it. But there are actual cost savings here.

Right sizing resources to application needs.

This isn't unique to cloud, you can do this in any hypervisor. This is a basic feature.

There are wins that one can have, but nothing is guaranteed

It does not "always" hold. This is critical missing nuance in the original claim.

1:1 lift and shift is always obscenely more expensive.

Is it? Managed services cost a lot more than a vm. Re writing software cost a lot more.

Where are the savings?

first of all, ahrefs discounts the "people" cost, but that's a huge cost to ignore!

It's the hardest to compare. Cloud has a significant people cost too, particularly in the complexity. EC2, lambda, S3, RDS, IAM, cognito, glacier, light sail, EBS, fargate, cloud front, SNS, dynamo, elastica he, etc etc.

If you ignore this, you fail to completely understand a service you start to use. That's the quickest way to a surprise mammoth bill or insecure service.

they _could_ save significant amounts of money by moving to the cloud AND re-architecting their apps to spend compute more efficiently.

This is a bad argument generally. If an org, institutionally, can't properly size services or they leave a lot of fat in their services.

Why would a move to the cloud fundamentally change that? You can even more easily over provision and overspend when it's a mere button click away.

I fail to see how a move to the cloud basically creates greater institutional ability to trim fat and optimize that just wasn't there before.

And I just love how convenient re-architecting is so casually thrown in like it's a walk in the park... Yikes. Rewrites can and do kill companies. Not a casual thing to undertake because a new vendor comes along with a shiny new tool.

You save money by re-architecting and using more managed services.

Managed services are more expensive, not less, per unit compute, per operation, etc. How exactly does that make things magically cheaper?

Modifying the base alphabet is simple if there are a couple of problem characters.

I use 85 in json just fine without escaping overhead. Never tried for URLs or XML.

For your trouble, you save some extra bytes with 85 vs 64.

Rumors are of mainline support pretty quickly.

But the proof will be when it actually happens.

Power limits probably affect this. And scaling cores isn't linear, their cores clearly scale poorly.

Though Geekbench particularly scales poorly with cores.

Yeah, if you make a bad faith effort to comply you deserve to be sued.

If you did your honest reasonable best, a suit shouldn't go anywhere. Systems aren't perfect. They aren't really expected to be either.

Given the way the porn industry historically operates by addicting the young and the huge levels of abuse towards women. I'm not holding my breath for good faith efforts.

I'm in a similar boat. Rural Midwest.

Worked for 23 years now in professional development. Started in big companies, then moved to smaller companies/startups.

I'm very very good at what I do and my salary is up to the point where small companies are starting to choke on it a bit, and I'm just a tiny bit higher than yours.

Been a senior, team lead, principal, architect, dabbled in some management. Also with successful product launches under my belt.

If I want to move up in salary - it probably won't be in startup land unless I find a relatively big one and I'm CTO.

More likely that I'm just going to start my own companies even if I have to do everything myself.

It feels like jobs, while somewhat available, just aren't what I'm looking for anymore. And the market is turning, or has turned, unfriendly to the super senior.

From my experience the 400k base is very very niche. Plenty of top end engineering talent out there available for less.

Metered GB is fine if there isn't a 8,000% markup. 200-300% would be much more reasonable and the angst over this would probably just go away.

They are also already doing 5 on ingress. But maybe you consider it 2.

Ssh struggles with high connection counts and has performance issues that crop up and require the forward to be torn down and rebuilt occasionally when I have high connections over time.

Performance, while it's working, I've found to be generally good. But there are clear ceilings to the method that you hit when trying to use it heavily.

I never saw any issues when I used it to forward ports for myself. But the moment I tried to use it for production for a small service it falls on it's face regularly unless I baby it.