13 ms·

It is almost ridiculously common anti-pattern these days to see teams stringing lambda functions together for no good reason other then “cuz serverless”, or “mi

It is almost ridiculously common anti-pattern these days to see teams stringing lambda functions together for no good reason other then “cuz serverless”, or “microservices”, for what really should be just function calls in a single process. Developers are losing touch on what process boundaries mean, and the result is brittle and poor performing systems.

intothemild 3y ago
Hype driven development.
goostavos 3y ago
I regularly review design from teams that turn reading a file from S3 and putting into into a database into, well, something that requires a design review. Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. If every time you add a new feature to your application you also have to add new infrastructure, I feel very, very strongly that you're doing it wrong. Sometimes? Sure. Every time? Embarrassing. Cloud providers are surely pleased as punch that there is now an entire generation of developers that will argue vehemently that infrastructure that only grows over time is not only healthy, but the best way to build scalable software. I have no idea what to call it other than "Marketing Material Driven Development".
- BXlnt2EachOther 3y ago
  I have heard "Promotion-Driven Development" (when it's from the team/eng side)
- hawk_ 3y ago
  Resume driven development. And on the flipside - One of the funniest justifications I have heard for companies using new fangled untried tech is to attract talent - no one wants to work on boring tech apparently for the fear of being outdated.
  - beabetterdev 3y ago
    Some call it "Promotion Driven Development" :)
    - 6510 3y ago
      I'm coining Self Driving Development. You read it here first! If you like big words Autonomous Development is also fine.
  - Silhouette 3y ago
    One of the funniest justifications I have heard for companies using new fangled untried tech is to attract talent - no one wants to work on boring tech apparently for the fear of being outdated. I sometimes worry for the future of our industry because of exactly this. The culture of buzzword driven development has become enshrined in the recruitment process - often from both sides - because of this kind of vicious circle effect. Now anyone - again from either side - who tries to escape it and instead advocates using sensible, robust tech to build useful, good quality products risks becoming a pariah and seriously damaging their career as a candidate or their ability to recruit strong candidates as an employer. Of course this assumes we are judging career progress by level of seniority reached or compensation paid instead of more indirect achievements like producing something that provided real value to those who used it. But if we're being honest most people obviously will.
  - deleted 3y ago
    [deleted]
  - vhcr 3y ago
    The worst thing is that it works, I've been rejected at interviews because I didn't have micro-service experience.
    - greenbeard 3y ago
      Probably because they need someone to get them out of the mess they have created.
- deleted 3y ago
  [deleted]
- coredog64 3y ago
  > Some horrific monstrosity of step functions, lambdas, and glue I could see that. Lambda has a 15 minute timeout, and if you’re processing something large you want an orchestrator that can manage retries. I don’t like the SFN developer experience, but it’s only like 15% worse than boto3.
- nostrebored 3y ago
  Why is spinning up new infrastructure wrong when that infrastructure is consumption based and easy to create? Cloud providers don’t care about your serverless function utilization for 95% of people. A huge chunk of people will never pay more than a single digit serverless bill, regardless of if they have 450 lambdas or 40. If creating a new function matches your mental model of how things works, simplifies ops and log reading, or gives you access to a library in a different language, I’d say you made a great call.
  - lozenge 3y ago
    Sure, creating is easy, what about monitoring, testing, rate limiting, updating (it can't be atomically updated with another resource, good luck testing that), security patching? What if you create a condition which causes an infinite loop of invocations? This is really rare in monoliths because we all agree on patterns like MVC that determine who calls what. When Conway s Law determines your infrastructure this is no longer the case.
    - rajamaka 3y ago
      I have worked with serverless for years and all of these are ranging from completely non issues to easily solvable.
      - namaria 3y ago
        "I haven't had this problem therefore it doesn't exist."
        nostrebored 3y ago
        All of the problems the OP mentioned are really trivial with every serverless stack I’ve ever used. Like many of the problems (security patching, monitoring, logging) are part of the serverless pitch.
        namaria 3y ago
- rewmie 3y ago
  > If every time you add a new feature to your application you also have to add new infrastructure, I feel very, very strongly that you're doing it wrong. Sometimes? Sure. Every time? Embarrassing. I have to call out your take because it's either outright wrong or is overgeneralizing, to put it politely. A lambda is just someone else's computer running your function, which you call through a fancy rpc interface. There is no infrastructure. Just because you can and should deploy a lambda with infrastructure-as-code tools such as CloudFormation or CDK, it still does not make a lambda "infrastructure". It's just your function running on space CPU cycles of someone else's computer, which you call through RPC. Running your lambda as a background task in someone else's computer does not make it infrastructure, just like running code in your own server is not adding infrastructure. Also, it seems you're missing the whole point of offloading background processes out of your servers. If they are computationally demanding and your servers are well provisioned them a background task can lead your system to scale up. You don't change the way your system is deployed or is operating if you run your background task as a lambda. You make a request and things run just the same. Zero potential for alarms and being paged in the middle of the night. And more importantly, for some usecases lambdas are entirely free. Does this have no value to you? Some people feel compelled to criticize everyone around them just to feel self important. A little humility would serve them well. Just because you fail to understand something's traits and properties that does not mean everyone else around you is wrong and you are the only enlightened soul who is right.
  - starttoaster 3y ago
    The term "infrastructure" has kind of a loose and fuzzy definition these days. But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. A container is infrastructure, ECS is infrastructure. Therefore a Lambda is some kind of ephemeral invocation-based infrastructure. It's infrastructure the whole way down. My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. We use Cloudflare Workers fairly heavily, for example, to perform web redirects for some statically generated sites. It's a fairly sensical use-case for "serverless" in my opinion.
- throwaway2990 3y ago
  > Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. If it’s a horrific monstrosity it’s either because you don’t understand it or it was poorly done. Seen several .NET step function implementations which were clean and easy to understand. And we’re cheaper than what they replaced. And new devs could easily pick it up and understand it.
- hk1337 3y ago
  > I regularly review design from teams that turn reading a file from S3 and putting into into a database into, well, something that requires a design review. Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. This is typically true with a lot of ClickOps teams.
- andrewstuart 3y ago
  “Cloud Driven Development”.
- chalcolithic 3y ago
  I use Lambda for personal projects because at that scale it's free. OTOH I can't find a job and when I'm lucky enough to get detailed feedback it's always "you don't have a significant cloud experience"
arwhatever 3y ago
Once had a coworker advocate for microservices because "you split everything into separate services and they all just work" quote, unquote. I've wondered ever since how typical that mindset might be whenever I hear anyone else pushing for similar such solutions.
- mattgreenrocks 3y ago
  The biggest benefit to microservices to many people is the fact that everyone else is also doing microservices. Externally mediated taste is how a lot of people operate. And they may have a vague idea that they should not defer as much to it, but they don’t have the experience to take the risk. So they double down on consensus.
giantg2 3y ago
"Developers are losing touch on what process boundaries mean," I feel like a lot of the problems are from misused Agile. Devs are building systems that haven't fully been thought out. I don't know when I've seen a fully built out process map in the past 5 years. MVP1 is easily built as severless, but then what happens when the full implementation gets more complicated? Do we rewrite all the server less architecture as a monolith? Nah, just tack on some more Lambdas. No way can we slow down for a refactor, and all the original devs that wrote it have job hopped.
- Silhouette 3y ago
  No way can we slow down for a refactor, and all the original devs that wrote it have job hopped. The most likely way to escape the current madness might be for a few companies with more enlightened management to actively look for people who have stayed in past roles for long enough to have real experience not just building but also maintaining software and pay them more. Same with loyalty incentives to retain existing staff. And then make sure those more experienced developers are choosing tools built to do a good job and not just tools built to make naive resume scanners happy. If frequent job-hopping and leaving any junk you've just built to become someone else's problem stops being the fastest way to boost your career and compensation then good people and good employers will start to prioritise building stuff properly and looking after it for the long term and almost everyone will be better off.
  - nucleardog 3y ago
    In senior roles I’ll only hire people that have had some longer stints for exactly these reasons. If you’ve never worked anywhere long enough to have to live with the fallout and consequences of your decisions, you’re not senior in my mind. You’ve never received useful real world feedback to be given a chance to refine your approach.
    - Silhouette 3y ago
      Exactly. I've encountered a small number of people who apparently reached very senior technical positions impressively early in their career but when you looked at their job history it was mostly a string of 1-2 year stays with a title bump on each jump. SE, Senior, Lead, random nine months as a cofounder of something that went nowhere but says CTO on the resume, Staff, and now after less than a decade they're running the show somewhere with a silly name but a few million in funding. In all that time they might never have worked on a single product with sustainable revenue or been responsible for the consequences of any technical decision they made as much as one year after they made it. Maybe two of those people that I can think of weren't bad anyway - sometimes their inexperience showed but at least they weren't crazy and had open minds - but others were among the most over-rated and damaging people I've ever seen in the business.
YetAnotherNick 3y ago
Have you even read the article? Leave it to HN to spam the exact same message in every thread where the word severless is mentioned or hinted. This article is nuanced as was original prime video team claim. While I do think lambda is sometimes overused, but no good engineer says "cuz serverless" for using lambda function as is implied in all these conversation. And there is no best choice in the absolute sense, and I wouldn't want to hire someone who claims that monolith is the better architecture for everything or everything should be serverless.
- Scubabear68 3y ago
  The issue isn’t “using lambda functions”. The issue is using them poorly, and in particular stringing them together into a sort of pipeline.
havnagiggle 3y ago
IMO that's the difference in calling yourself an engineer. Weighing resources and tradeoffs is engineering 101. Maybe the scope of the problem doesn't require due diligence for budget constraints, and that's fine for those problems. But if you don't have a rough idea of this then you're just not practicing engineering.
pdntspa 3y ago
I read the word "morons" instead of "lovers" in my head when I read this headline
happymellon 3y ago
It's not even just Lambda, I have mentioned it here before but I've inherited a CRUD application where the read is a separate "application" and because of this I have two databases with minimal differences with multiple applications that are basically the same. On the other hand, I've decreased costs significantly in previous positions by moving the cart functions to a lambda because it made it highly responsive, scaled up to thousands of transactions a second without concern during initial sales of certain fruit based devices which generate a rush, but basically sit idle 90% of the rest of the time. I am not concerned with "the death of serverless", there is a time for lambda, and a time for long running processes. You can stick multiple rest endpoints in a single lambda, and that's the recommended thing to do. Moving from micro to monolith isn't the death of serverless, people not knowing when the appropriate time to use different techniques will be.
- rvdginste 3y ago
  > Moving from micro to monolith isn't the death of serverless, people not knowing when the appropriate time to use different techniques will be. Exactly, people should take the time to study different techniques, learn about their advantages and disadvantages, and then use some basic common sense when choosing a specific technique in a specific context.

intothemild 3y ago

Hype driven development.

goostavos 3y ago

I regularly review design from teams that turn reading a file from S3 and putting into into a database into, well, something that requires a design review. Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. If every time you add a new feature to your application you also have to add new infrastructure, I feel very, very strongly that you're doing it wrong. Sometimes? Sure. Every time? Embarrassing. Cloud providers are surely pleased as punch that there is now an entire generation of developers that will argue vehemently that infrastructure that only grows over time is not only healthy, but the best way to build scalable software. I have no idea what to call it other than "Marketing Material Driven Development".

BXlnt2EachOther 3y ago
I have heard "Promotion-Driven Development" (when it's from the team/eng side)
hawk_ 3y ago
Resume driven development. And on the flipside - One of the funniest justifications I have heard for companies using new fangled untried tech is to attract talent - no one wants to work on boring tech apparently for the fear of being outdated.
- beabetterdev 3y ago
  Some call it "Promotion Driven Development" :)
  - 6510 3y ago
    I'm coining Self Driving Development. You read it here first! If you like big words Autonomous Development is also fine.
- Silhouette 3y ago
  One of the funniest justifications I have heard for companies using new fangled untried tech is to attract talent - no one wants to work on boring tech apparently for the fear of being outdated. I sometimes worry for the future of our industry because of exactly this. The culture of buzzword driven development has become enshrined in the recruitment process - often from both sides - because of this kind of vicious circle effect. Now anyone - again from either side - who tries to escape it and instead advocates using sensible, robust tech to build useful, good quality products risks becoming a pariah and seriously damaging their career as a candidate or their ability to recruit strong candidates as an employer. Of course this assumes we are judging career progress by level of seniority reached or compensation paid instead of more indirect achievements like producing something that provided real value to those who used it. But if we're being honest most people obviously will.
- deleted 3y ago
  [deleted]
- vhcr 3y ago
  The worst thing is that it works, I've been rejected at interviews because I didn't have micro-service experience.
  - greenbeard 3y ago
    Probably because they need someone to get them out of the mess they have created.
deleted 3y ago
[deleted]
coredog64 3y ago
> Some horrific monstrosity of step functions, lambdas, and glue I could see that. Lambda has a 15 minute timeout, and if you’re processing something large you want an orchestrator that can manage retries. I don’t like the SFN developer experience, but it’s only like 15% worse than boto3.
nostrebored 3y ago
Why is spinning up new infrastructure wrong when that infrastructure is consumption based and easy to create? Cloud providers don’t care about your serverless function utilization for 95% of people. A huge chunk of people will never pay more than a single digit serverless bill, regardless of if they have 450 lambdas or 40. If creating a new function matches your mental model of how things works, simplifies ops and log reading, or gives you access to a library in a different language, I’d say you made a great call.
- lozenge 3y ago
  Sure, creating is easy, what about monitoring, testing, rate limiting, updating (it can't be atomically updated with another resource, good luck testing that), security patching? What if you create a condition which causes an infinite loop of invocations? This is really rare in monoliths because we all agree on patterns like MVC that determine who calls what. When Conway s Law determines your infrastructure this is no longer the case.
  - rajamaka 3y ago
    I have worked with serverless for years and all of these are ranging from completely non issues to easily solvable.
    - namaria 3y ago
      "I haven't had this problem therefore it doesn't exist."
      - nostrebored 3y ago
        All of the problems the OP mentioned are really trivial with every serverless stack I’ve ever used. Like many of the problems (security patching, monitoring, logging) are part of the serverless pitch.
        namaria 3y ago
rewmie 3y ago
> If every time you add a new feature to your application you also have to add new infrastructure, I feel very, very strongly that you're doing it wrong. Sometimes? Sure. Every time? Embarrassing. I have to call out your take because it's either outright wrong or is overgeneralizing, to put it politely. A lambda is just someone else's computer running your function, which you call through a fancy rpc interface. There is no infrastructure. Just because you can and should deploy a lambda with infrastructure-as-code tools such as CloudFormation or CDK, it still does not make a lambda "infrastructure". It's just your function running on space CPU cycles of someone else's computer, which you call through RPC. Running your lambda as a background task in someone else's computer does not make it infrastructure, just like running code in your own server is not adding infrastructure. Also, it seems you're missing the whole point of offloading background processes out of your servers. If they are computationally demanding and your servers are well provisioned them a background task can lead your system to scale up. You don't change the way your system is deployed or is operating if you run your background task as a lambda. You make a request and things run just the same. Zero potential for alarms and being paged in the middle of the night. And more importantly, for some usecases lambdas are entirely free. Does this have no value to you? Some people feel compelled to criticize everyone around them just to feel self important. A little humility would serve them well. Just because you fail to understand something's traits and properties that does not mean everyone else around you is wrong and you are the only enlightened soul who is right.
- starttoaster 3y ago
  The term "infrastructure" has kind of a loose and fuzzy definition these days. But basically I think of a serverless function as like a one-shot container that is spun up when a webhook or some other invocation method is called, handles some kind of request, puts out some kind of response, and shuts down. A container is infrastructure, ECS is infrastructure. Therefore a Lambda is some kind of ephemeral invocation-based infrastructure. It's infrastructure the whole way down. My personal take here is just that serverless functions have a time and a place in one's infrastructure, and it requires good engineering to determine where that time or place is or isn't. We use Cloudflare Workers fairly heavily, for example, to perform web redirects for some statically generated sites. It's a fairly sensical use-case for "serverless" in my opinion.
throwaway2990 3y ago
> Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. If it’s a horrific monstrosity it’s either because you don’t understand it or it was poorly done. Seen several .NET step function implementations which were clean and easy to understand. And we’re cheaper than what they replaced. And new devs could easily pick it up and understand it.
hk1337 3y ago
> I regularly review design from teams that turn reading a file from S3 and putting into into a database into, well, something that requires a design review. Some horrific monstrosity of step functions, lambdas, and glue. All because they've been told that serverless is the correct way to build "scalable" software. This is typically true with a lot of ClickOps teams.
andrewstuart 3y ago
“Cloud Driven Development”.
chalcolithic 3y ago
I use Lambda for personal projects because at that scale it's free. OTOH I can't find a job and when I'm lucky enough to get detailed feedback it's always "you don't have a significant cloud experience"

arwhatever 3y ago

Once had a coworker advocate for microservices because "you split everything into separate services and they all just work" quote, unquote. I've wondered ever since how typical that mindset might be whenever I hear anyone else pushing for similar such solutions.

mattgreenrocks 3y ago
The biggest benefit to microservices to many people is the fact that everyone else is also doing microservices. Externally mediated taste is how a lot of people operate. And they may have a vague idea that they should not defer as much to it, but they don’t have the experience to take the risk. So they double down on consensus.

giantg2 3y ago

"Developers are losing touch on what process boundaries mean," I feel like a lot of the problems are from misused Agile. Devs are building systems that haven't fully been thought out. I don't know when I've seen a fully built out process map in the past 5 years. MVP1 is easily built as severless, but then what happens when the full implementation gets more complicated? Do we rewrite all the server less architecture as a monolith? Nah, just tack on some more Lambdas. No way can we slow down for a refactor, and all the original devs that wrote it have job hopped.

Silhouette 3y ago
No way can we slow down for a refactor, and all the original devs that wrote it have job hopped. The most likely way to escape the current madness might be for a few companies with more enlightened management to actively look for people who have stayed in past roles for long enough to have real experience not just building but also maintaining software and pay them more. Same with loyalty incentives to retain existing staff. And then make sure those more experienced developers are choosing tools built to do a good job and not just tools built to make naive resume scanners happy. If frequent job-hopping and leaving any junk you've just built to become someone else's problem stops being the fastest way to boost your career and compensation then good people and good employers will start to prioritise building stuff properly and looking after it for the long term and almost everyone will be better off.
- nucleardog 3y ago
  In senior roles I’ll only hire people that have had some longer stints for exactly these reasons. If you’ve never worked anywhere long enough to have to live with the fallout and consequences of your decisions, you’re not senior in my mind. You’ve never received useful real world feedback to be given a chance to refine your approach.
  - Silhouette 3y ago
    Exactly. I've encountered a small number of people who apparently reached very senior technical positions impressively early in their career but when you looked at their job history it was mostly a string of 1-2 year stays with a title bump on each jump. SE, Senior, Lead, random nine months as a cofounder of something that went nowhere but says CTO on the resume, Staff, and now after less than a decade they're running the show somewhere with a silly name but a few million in funding. In all that time they might never have worked on a single product with sustainable revenue or been responsible for the consequences of any technical decision they made as much as one year after they made it. Maybe two of those people that I can think of weren't bad anyway - sometimes their inexperience showed but at least they weren't crazy and had open minds - but others were among the most over-rated and damaging people I've ever seen in the business.

YetAnotherNick 3y ago

Have you even read the article? Leave it to HN to spam the exact same message in every thread where the word severless is mentioned or hinted. This article is nuanced as was original prime video team claim. While I do think lambda is sometimes overused, but no good engineer says "cuz serverless" for using lambda function as is implied in all these conversation. And there is no best choice in the absolute sense, and I wouldn't want to hire someone who claims that monolith is the better architecture for everything or everything should be serverless.

Scubabear68 3y ago
The issue isn’t “using lambda functions”. The issue is using them poorly, and in particular stringing them together into a sort of pipeline.

havnagiggle 3y ago

IMO that's the difference in calling yourself an engineer. Weighing resources and tradeoffs is engineering 101. Maybe the scope of the problem doesn't require due diligence for budget constraints, and that's fine for those problems. But if you don't have a rough idea of this then you're just not practicing engineering.

pdntspa 3y ago

I read the word "morons" instead of "lovers" in my head when I read this headline

happymellon 3y ago

It's not even just Lambda, I have mentioned it here before but I've inherited a CRUD application where the read is a separate "application" and because of this I have two databases with minimal differences with multiple applications that are basically the same. On the other hand, I've decreased costs significantly in previous positions by moving the cart functions to a lambda because it made it highly responsive, scaled up to thousands of transactions a second without concern during initial sales of certain fruit based devices which generate a rush, but basically sit idle 90% of the rest of the time. I am not concerned with "the death of serverless", there is a time for lambda, and a time for long running processes. You can stick multiple rest endpoints in a single lambda, and that's the recommended thing to do. Moving from micro to monolith isn't the death of serverless, people not knowing when the appropriate time to use different techniques will be.

rvdginste 3y ago
> Moving from micro to monolith isn't the death of serverless, people not knowing when the appropriate time to use different techniques will be. Exactly, people should take the time to study different techniques, learn about their advantages and disadvantages, and then use some basic common sense when choosing a specific technique in a specific context.