4 ms·

> 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 reall

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

sieabahlpark 5y ago
There are a few options to replace lambda with cloudnative options that run on K8. https://knative.dev/docs/ https://knative.dev/docs/
BatFastard 5y ago
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.
- rmbyrro 5y ago
  Exactly. If your $open_source is abandoned tomorrow, what are you going to do?...
  - sojournerc 5y ago
    Fork it, and continue on...
  - sokoloff 5y ago
    Genuinely can't tell if this is sublime sarcasm or a straightforward argument.
  - JasonCannon 5y ago
    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.
- Epa095 5y ago
  > 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.
vishnugupta 5y ago
> 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.
- rhizome 5y ago
  Should we infer zero off-cloud contingency plans, then?
  - vishnugupta 5y ago
    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 https://www.mightyapp.com (2) https://aws.amazon.com/workspaces/ https://aws.amazon.com/workspaces/
NicoJuicy 5y ago
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.
dehrmann 5y ago
> 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.

sieabahlpark 5y ago

There are a few options to replace lambda with cloudnative options that run on K8. https://knative.dev/docs/ https://knative.dev/docs/

BatFastard 5y ago

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.

rmbyrro 5y ago
Exactly. If your $open_source is abandoned tomorrow, what are you going to do?...
- sojournerc 5y ago
  Fork it, and continue on...
- sokoloff 5y ago
  Genuinely can't tell if this is sublime sarcasm or a straightforward argument.
- JasonCannon 5y ago
  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.
Epa095 5y ago
> 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.

vishnugupta 5y ago

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

rhizome 5y ago
Should we infer zero off-cloud contingency plans, then?
- vishnugupta 5y ago
  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 https://www.mightyapp.com (2) https://aws.amazon.com/workspaces/ https://aws.amazon.com/workspaces/

NicoJuicy 5y ago

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.

dehrmann 5y ago

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