7 ms·

I have a theory that even though the serverless trend is sold as a technical revolution, it's mostly due to accounting practices. Serverless is purely about CA

I have a theory that even though the serverless trend is sold as a technical revolution, it's mostly due to accounting practices. Serverless is purely about CAPEX, vs OPEX. Companies are so loath to make capital expenditures (CAPEX) that they will willingly let their employees waste thousands of extra hours learning a new development model so they can pay Amazon using operating expenses instead. And it's funny because even though amazon has no choice but to use capital expenditures to populate their datacentres with machines, they are offering lambda as a way to monetize the unused cycles. So lambdas are being twice used as a kind of compromise to fill in the gaps on an accounting sheet. 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. We have just made the time-sharing service (they used to have them in the 60s and 70s) fashionable again. (Along with the long feedback cycle which makes working on these systems so frustrating.)

WJW 5y ago
> 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.
- bob1029 5y ago
  > 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%.
  - WJW 5y ago
    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.
  - nasmorn 5y ago
    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.
  - ReactiveJelly 5y ago
    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.
    - sokoloff 5y ago
      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).
    - TheCoelacanth 5y ago
      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.
- funcDropShadow 5y ago
  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.
dempseye 5y ago
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.
- gerbilly 5y ago
  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.)
  - djsweet 5y ago
    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.
  - randallsquared 5y ago
    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.
traceroute66 5y ago
> 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?...
jjoonathan 5y ago
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.
oldmanhorton 5y ago
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.
matchagaucho 5y ago
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.
wpietri 5y ago
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.
- abstract_put 5y ago
  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.
  - wpietri 5y ago
    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.
  - Melkman 5y ago
    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.
  - alexvoda 5y ago
    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.
efitz 5y ago
s/serverless/cloud/ FTFY! Ed: fixed autocorrect error
rhizome 5y ago
The joke is also on people who have experienced career effects for (correctly) poo-pooh'ing it.
tomnipotent 5y ago
> 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.

WJW 5y ago

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

bob1029 5y ago
> 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%.
- WJW 5y ago
  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.
- nasmorn 5y ago
  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.
- ReactiveJelly 5y ago
  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.
  - sokoloff 5y ago
    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).
  - TheCoelacanth 5y ago
    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.
funcDropShadow 5y ago
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.

dempseye 5y ago

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.

gerbilly 5y ago
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.)
- djsweet 5y ago
  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.
- randallsquared 5y ago
  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.

traceroute66 5y ago

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

jjoonathan 5y ago

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.

oldmanhorton 5y ago

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.

matchagaucho 5y ago

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.

wpietri 5y ago

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.

abstract_put 5y ago
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.
- wpietri 5y ago
  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.
- Melkman 5y ago
  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.
- alexvoda 5y ago
  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.

efitz 5y ago

s/serverless/cloud/ FTFY! Ed: fixed autocorrect error

rhizome 5y ago

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

tomnipotent 5y ago

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