[HN Gopher] Serverless to monolith - Should serverless lovers be...
___________________________________________________________________
Serverless to monolith - Should serverless lovers be worried?
Author : fagnerbrack
Score : 30 points
Date : 2023-07-01 20:03 UTC (2 hours ago)
(HTM) web link (beabetterdev.com)
(TXT) w3m dump (beabetterdev.com)
| arter4 wrote:
| This is the main insight I got:
|
| >the original architecture was based on a tool that was not
| designed for scale. Based on the article, it read as if this tool
| was used for diagnostics to perform ad-hoc assessments of stream
| quality. This means it likely wasn't designed for scale or put
| through the pressure tests of a formal design document / review.
| If that were to happen, any run of the mill Software Engineer
| would have been able to recognize the obvious scaling / cost
| bottlenecks that would be encountered.
|
| Lesson learned: ensure your design is sane before turning your
| PoC into a full blown production system.
| miked85 wrote:
| PoCs turning into full blown production systems happens quite
| often, even if not planned.
| PathOfEclipse wrote:
| The real lesson to be learned is to always assume your PoC
| will, if successful, get shipped to production pretty much as-
| is!
| berbec wrote:
| hugged. https://archive.is/EDyUx
| SoftTalker wrote:
| Serverless always seemed to me like a stupid name. Of course
| there's a server. It's just not _your_ server.
| talideon wrote:
| Not unless they're service providers.
| angarg12 wrote:
| That article has been analyzed to death. Here is a good one from
| another ex-Amazon.
|
| https://news.ycombinator.com/item?id=35853148
| beabetterdev wrote:
| Daniel here, author of this article.
|
| Thanks for re-sharing. I was quite disappointed to see the
| negative community reaction to the original Amazon article. I
| felt that those knocking it didn't analyze the circumstances that
| lead to the Serverless Architecture's gaps and just saw some
| problems with it and assumed "serverless bad".
|
| In reality, the series of decisions made a lot of sense. Take
| something that exists, try using it, learn from it, and make
| better decisions as a result of it. It just so happened that in
| this case, serverless architecture was the wrong tool for the job
| and dedicated machines were a better fit.
|
| Anyways, happy to see my take being shared. If you enjoy this
| kind of content, I have a newsletter and Youtube channel where I
| discuss / make videos about more AWS & cloud concepts:
|
| Newsletter: https://mailinglist.beabetterdev.com Youtube:
| https://www.youtube.com/c/BeABetterDev
|
| Cheers,
|
| Daniel
| cagenut wrote:
| you can run a giant multi-gb monolith serverlessly. just because
| you use lambda doesnt mean you need to use dozens of them.
| piyh wrote:
| Agreed, serverless and monolith are not on the same spectrum
| [deleted]
| Scubabear68 wrote:
| 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 wrote:
| Hype driven development.
| arwhatever wrote:
| 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.
| goostavos wrote:
| 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".
| hawk_ wrote:
| 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 wrote:
| Some call it "Promotion Driven Development" :)
| [deleted]
| coredog64 wrote:
| > 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.
| BXlnt2EachOther wrote:
| I have heard "Promotion-Driven Development" (when it's from
| the team/eng side)
___________________________________________________________________
(page generated 2023-07-01 23:00 UTC)