6 ms·

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

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.
    - peteradio 3y ago
      Then they'd want de-micro-service experience!
  - s__s 3y ago
    I was job hunting about a year ago and got rejected several times for this reason. The worst part? Each one was a small startup just trying to get a new product off the ground. In one interview the engineer interviewing me explained how they didn’t have any paying customers, and then went on to describe an elaborate over-engineered micro-service based architecture he was working on. The real kicker was that instead of asking me about my 20 years building products, or our infrastructure at my last gig that handled millions of customers across the globe, he instead wanted to watch me code some goofy coding quiz he had prepared.
- hhanda788 3y ago
  That's because hiring managers and team leads genuinely care about this stuff. Your last job had you working in a giant monstrous horrible Java EE thing from 2005, and you refactored 500k lines and saved the company $10 million? Sorry, we are only looking to hire somebody who is good enough to know they need to always be learning and keeping up to date with modern standards". It's horseshit but at least half of the people in charge of hiring think exactly that way and so I end up leaving the work I'm the most proud of off my resume a lot of the time.
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"

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.
  - peteradio 3y ago
    Then they'd want de-micro-service experience!
- s__s 3y ago
  I was job hunting about a year ago and got rejected several times for this reason. The worst part? Each one was a small startup just trying to get a new product off the ground. In one interview the engineer interviewing me explained how they didn’t have any paying customers, and then went on to describe an elaborate over-engineered micro-service based architecture he was working on. The real kicker was that instead of asking me about my 20 years building products, or our infrastructure at my last gig that handled millions of customers across the globe, he instead wanted to watch me code some goofy coding quiz he had prepared.
hhanda788 3y ago
That's because hiring managers and team leads genuinely care about this stuff. Your last job had you working in a giant monstrous horrible Java EE thing from 2005, and you refactored 500k lines and saved the company $10 million? Sorry, we are only looking to hire somebody who is good enough to know they need to always be learning and keeping up to date with modern standards". It's horseshit but at least half of the people in charge of hiring think exactly that way and so I end up leaving the work I'm the most proud of off my resume a lot of the time.

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"