Hacker News Reader

> I believe the joke is on us as technical people. We twist ourselves into knots to promote this new development model as a technical innovation, which it really isn't.

Not only that but the joke is on technical people for promoting a model of severe vendor lock-in. Its doubly funny when you often see the same techies complain bitterly about "walled gardens" on their smartphones !

If $cloud_vendor doubled their prices tomorrow, what are you going to do ?

If $cloud_vendor decided to kill-off a product tomorrow and replace it with another one with a different API, what are you going to do ?

In most cases, the answer to the above and other scenarios would be "suck it up and swallow the expense".

Sure you can shift the expenses from CAPEX to OPEX and construct numerous business cases to convince the boss that the cloud is the next best thing to sliced bread. But at what cost ?

Of course there are some use-cases which are genuinely well suited to the cloud model, but they are in the minority. For many business the cloud is a case of "if the only thing you have is a hammer, everything looks like a nail".

If you take this attitude you should write all of your own tools, make your own hardware, not use any libraries (I might actually be able to make a case for this one).

I am most familiar with AWS, so all I can say is their prices have gone down over times, the availability has gone up, and the total number of services is amazing.

With other cloud vendors I think you might be at more risk of them shutting down services, but if they start doing that with out giving you multi-year notice it means they are going out of business.

Exactly. If your $open_source is abandoned tomorrow, what are you going to do?...

Fork it, and continue on...

Genuinely can't tell if this is sublime sarcasm or a straightforward argument.

Stay on the version that already works and provides the features you need? Fork it to add new features if needed? You don't need to constantly update software dependencies.

> If you take this attitude you should write all of your own tools, make your own hardware, not use any libraries (I might actually be able to make a case for this one).

No. Just...no. There are more than the two possible positions, its not either "ignore technological dependencies completely and blindly give your balls to a single vendor" or "create everything yourself from the ground up". You can look at your stack and consider how vulnerable you are compared to how much you gain. Sometimes you will find that it's worth it going all in with one vendor, but it should be a conscious decision. Business have to consider their vulnerabilities all the time and it boils down to compromises and tradeoffs.

> If $cloud_vendor doubled their prices tomorrow, what are you going to do ?

> If $cloud_vendor decided to kill-off a product tomorrow and replace it with another one with a different API, what are you going to do ?

Been using AWS for close to ~10 years now and I don't recall them doing anything remotely similar to above. Of course, they could potentially do it in the coming days. But going by their past behaviour I'd say it's a low probability event.

When the cloud/AWS was new these fears were indeed valid. But this line of reasoning is getting old and tiring; especially when it's not backed by even anecdotal evidence and is purely speculative-fear in nature.

I do know that Google, Twitter and others have pulled down some fairly popular APIs/products but please don't conflate that with GCP/AWS/cloud offerings.

For most of the startups it's not even a question of if cloud now. Early days (2010-2015ish) it used to be the case that engineers had to convince management about the advantages of cloud. Primarily because one had to mostly go hybrid as many of the services weren't in cloud yet (such as Route 53, RDS etc.,). It was a pain to maintain hybrid. Now it's possible to run 100% of tech stack in cloud. So it's the other way round; VCs and business folks will frown upon tech if they run on bare-metal/data-centre.

Should we infer zero off-cloud contingency plans, then?

Depends on factors such as business size, product life cycle stage etc.,

For a typical startup trying to figure out PMF and launch an MVP or figure out customer retention I'd be really surprised if off-cloud contingency is even on top-50 priority list.

But for someone with a proven business model with a good revenue stream cloud dependency or vendor lock-in or single-vendor-point of failure does indeed become an action item to be worked upon.

Or when a regulator requires setting up a DR site which they did for us back in 2015. We had no option but to set it up in a data-centre.

Or let's say someone like Mighty (1) whose product is sort of competitor to AWS's (2). They wouldn't want to go anywhere near AWS or any cloud for that matter. And last I heard they were indeed ordering their own physical server machines.

There are valid reasons to look for either hybrid or purely on-prem solutions as I listed a few above. But please don't forward "what if cost doubles" type of reasoning. All that said, I'd hypothesise not going full on cloud is an exception for a typical startup now a days.

(1) https://www.mightyapp.com (2) https://aws.amazon.com/workspaces/

There was the time Google App Engine completely changed the pricing model. Although I guess that isn't technically GCP.

Google maps did that with their pricing and a lot of people changed api's.

Yes, it's a simpler change. But other serverless tech does exists on mostly the same dev language.

Additionally, price changes should be warned way upfront.

> If $cloud_vendor doubled their prices tomorrow, what are you going to do ?

They can't do this because of reputational damage. No one would consider that provider for the next 5 years. It also wouldn't squeeze out as much as you'd think because medium size and larger accounts are all on long-term contracts, so they have time to migrate.

I'm not following. Virtual servers are just as much pure OPEX as serverless. So from the customer accounting perspective, I don't think serverless adds much.

Instead I think the promise is, "Don't worry your pretty little heads about what code is running where. Trust us to handle that!" Which surely seems seductive until people realized that they still have to think about those things.

I heard about one project where consultants decided to use the sparkletastic magic of AWS Lambda so they didn't have to worry about how to scale up their crawler. But they didn't really think it through, so they just had a zillion invocations sitting around waiting for HTTP responses. First-month bill was $12k when you could have spent ~$100 to get the same results with a low-end virtual server running a basic Scrapy setup. So for Amazon I think it's less about filling in a utilization gap and more about attracting people who don't know how to optimize.

I'm guessing OP was referring to serverless vs on-prem? I don't think public cloud is significantly different than serverless in terms of CAPEX vs OPEX, whereas private cloud is big CAPEX.

Sure, but is that a versus that comes up much? It seems to me they're orthogonal. You can do on-prem serverless, after all.

Private cloud can be big Apex. Doesn't have to be though. The IBM's an HPE's of this world are perfectly happy to sell you PAYGO on prem solutions. Or you can lease the hardware.

Serverless is further towards the OPEX end of the axis because OPEX is generated and then payd whereas CAPEX needs approval first. With serverless you no longer need to request approval for new instances. The harder the management believes IT to be a cost centre the harder IT will try to wrestle control away. The story of On prem vs Cloud is the story of CAPEX vs OPEX is the story of expenditure aprooval friction.

Sad.

What kind of AWS consultants don't know how to set reserved concurrency? That's one of the most basic things about Lambda, I guess the same goes for any other FaaS providers.

They weren't AWS consultants specifically, just a couple of general software consultants fronting a contract development team. And if they had set a concurrency max, the system would have failed in a different way. Using Lambda at all was the problem here.

Agreed that this isn't about tech, but I don't think it's about CAPEX vs OPEX, I think it's about purchase / billing friction.

"Engineers buy, managers oversee" is the killer app.

The problem with this view is that the alternative to serverless is not spending money on bare metal servers, but renting actual or virtual servers on a month to month basis.

Well lambdas are also cheaper than virtual servers.

(Cheaper that is if you don't value your employees time, which most large companies don't.)

I only have experience with GCP’s Cloud Functions, but in that environment, “serverless” is only cheaper than virtual servers if your load can’t saturate the lowest end VM GCP has to offer.

Once you have enough load to justify going “unserverless” the prices drop to approximately 1/4 that of Cloud Functions for the same burst performance, and that’s before playing billing games like long-term commitments or using preemptible instances.

What’s truly scalable about “serverless compute” versus VMs is the line item on your bill. Sure, “they manage the auto-scaling” but for the per-unit price you rapidly hit a point where you might as well set up a Kubernetes load balancer and eat the setup costs. The pricing model only works out in your favor if you _don’t_ have load.

It would not surprise me to learn that the same is true of AWS prices.

I dunno... maintaining virtual servers is still a lot of work. You have to

    * monitor lots of things like filesystem usage and CPU usage
    * build new machine images (as well as possibly new container images!) to keep up with security updates
    * tune autoscaling at multiple levels based on whichever server-based systems you're using
    * maintain a secure way for production support folks to log into servers to see what is going wrong or perform emergency fixes
    * build additional failover automation as well as what you'd already need for serverless

Serverless is a bit more expensive overall and less tunable, but there's just less to go wrong: much of the underlying server SRE work is handled by provider automation and engineers for whom that is their full-time job. So, I'm still pretty happy with it.

> Serverless is purely about CAPEX, vs OPEX.

What it's really about is managing cash flow and not spending your entire round until your team has some inkling as to what it costs for the revenues it's bringing in. This is considerably easier to do with cloud vendors, serverless or not.

It's also about operational velocity, and supporting engineering teams in getting things done without planning overhead that's almost always going to be wrong. Serverless is a tool, and if used right can significantly reduce costs. I can use a hammer to build a house, but I can also smash my fingers with it. Tools be be used improperly.

So once the company is mature, such that meaningful future predictions can be made from past data, then it finds itself in a position to make significant upfront outlays in response to current or future business needs. This usually involves the CFO & FP&A team building a model to see how such a change would impact the balance sheet over the next X years. If the numbers add up, it would absolutely make sense to spend the money. But that's not always the case, even for companies at scale.

> I believe the joke is on us as technical people.

Quite the opposite? We can be paid for migrating current applications to "serverless", and when the tides of tech fashion change we can be paid again to migrate to the new fashionable tech.

If the joke is on anyone, it is on the shareholders of the companies getting locked in. But, it is their money and if they want to trade some CAPEX for OPEX that is not really my problem.

> But, it is their money and if they want to trade some CAPEX for OPEX that is not really my problem.

What if we made it your problem by granting you equity in the business? I feel like this is the #1 reason to funnel a portion of shares to your employees. Making the technical people give even 1% of a shit about the cost of doing business is infinitely better than 0%.

If you are an engineer with 1% of equity, more power to you. In all the companies I've worked at, the influence of the cloud provider bill on the eventual worth of my options has been lower than my annual beer costs.

The #1 benefit of options for startups is that they shift engineering costs from now to the future, so that you can hire any engineers at all while operating on a small budget. If the business works out, you already have so much money that the cost of the options will be negligible. If the business doesn't work out, the cost of the options was zero.

I inherited an AWS stack that cost 10k a month and turned it into 1.5k in a week. Joke was on the previous devs too though as they were fired. But I guess at a big company it would be only 100% too expensive but at a much bigger scale and no one gets fired since it is basically best practices or so.

Is holding the shares a condition of working there? Cause I'd rather sell them and diversify. I don't want the risk of the company going under to cost me my salary _and_ my investments.

I think there's a good balance with the current vesting schedules. You vest the shares at some point in the future (giving you current incentive to align your actions behind the goals of the company). Then, when they vest, you can sell them to diversify (sometimes with a short waiting period if there's a trading window blackout or something).

That's essentially what a vesting period is.

A popular vesting schedule is 25/25/25/25, which means you would be able to sell 25% one year after getting the shares, another 25% after the second year and so on. Typically they would keep giving you more shares as your shares vest so that you always have some shares that you can't sell yet.

The joke is on the customers, not the shareholders. They continue to profit from the profits of the companies they own. They feel only short term effects, every economic long-term effect is burdened by people.

Is this a comment on serverless products in general, or specifically Lambda and other instances of serverless products that require custom code and architecture? Serverless is also used by things like Fargate and Aurora which, imo, have significantly more value and are easier to learn.

The joke is also on people who have experienced career effects for (correctly) poo-pooh'ing it.

Translating the business value to Finance may be a CAPEX/OPEX discussion.

But leasing servers and getting hands on with the metal and containers are also OPEX.

Accounting doesn't care about the technical architecture. They just don't want a data center of idle servers running Pentium's from 2010.

s/serverless/cloud/

FTFY!

Ed: fixed autocorrect error