5 ms·
Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns https://twitter.com/chrismunns). I'll give you that this 8
by tgeek 7y ago
Hi there, Hey there, I lead Developer Advocacy at AWS for Serverless (https://twitter.com/chrismunns https://twitter.com/chrismunns).
I'll give you that this 80% number seems pretty out there. I don't know how that is measured or what it would be referencing.
If you step back and remove all the commercial software from the argument (something like 50%+ of enterprise workloads, the kind of things you buy from a 3rd party and just run it, like Sharepoint, SAP, or similar) and then look at how many business applications take on a trivial amount of load over time, then the author's post becomes more of an outlier. Few folks have apps that do 100rps realistically. And so for data processing/streaming/batch or web/api workloads serverless actually does work out pretty well. Is this 80%, I am not sure.
There is 100% an inflection point where if your operator cost is low enough(human work+3p tools+process+care and feeding) then the "metal to metal" costs can be comparable. Even the author admits that's leaving something on the floor and so it really comes down to what your organization values most.
I would love for most of our serverless app workloads to be top-down organizationally driven but the reality of it is that it comes often from developers themselves and/or line of business organizations with skin in the game of seeing things move faster in most organizations. This will then typically require buy in from security and ops groups. If these folks you know have the trick to driving top down incompetent strategic management towards serverless I'd buy in on that newsletter.
In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. I think there's also a larger number of people that represent IT vendors that would love to see AWS fail here :)
Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns
- munns 7y agoand I totally posted this from the wrong account... sigh.. this is me. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns
- missosoup 7y ago> And so for data processing/streaming/batch [...] serverless actually does work out pretty well. This is my field of expertise. Serverless in the sense of lambda/functions is not usable for serious analytics pipelines due to the max allowed image size being smaller than the smallest NLP models or even lightweight analytics python distributions. You can't use lambda on the ETL side and you can't use lambda on the query side unless your queries are trivial enough to be piped straight through to the underlying store. And if your workload is trivial, you should just use clickhouse or straight up postgres because it vastly outperforms serverless stacks in cost and performance[1] For non-trivial pipelines, tools like spark and dask dominate. And it just so happens that both have plugins to provision their own resources through kubernetes instead of messing around with serverless/paas noise. And PasS products, well. https://weekly-geekly.github.io/articles/433346/index.html https://weekly-geekly.github.io/articles/433346/index.html >One table instead of 90 >Service requests are executed in milliseconds >The cost has decreased by half >Easy removal of duplicate events Please explain. [1] https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/ https://blog.cloudflare.com/http-analytics-for-6m-requests-p... IaaS is the peak value proposition of cloud vendors. Serverless/PaaS are grossly overpriced products aimed at non-technical audiences and are mostly snake oil. Change my mind.
- cthalupa 7y agoThat article appears to be discussing a migration from Redshift to Clickhouse. Redshift is a managed data warehouse, not a serverless solution in the same vein as Lambda. I don't understand the point you are trying to make. Edit: The comment I am replying to was originally just 'Please explain' and a link to the article in question, and contained no other context or details.
- missosoup 7y agoSorry I have a bad habit of making a comment and then actually writing it in full. I should stop that.
- munns 7y agoThe issue of the application artifact size is definitely real and it blocks some NLP/ML workloads for sure. Consider that a today problem that isn't hard in Lambda. But we've 100% got customers doing near realtime streaming analytics in complicated pipelines feeding off of things like Kinesis Data Streams. This FINRA example is one datapoint: https://aws.amazon.com/solutions/case-studies/finra-data-validation/ https://aws.amazon.com/solutions/case-studies/finra-data-val... and this Thompson Reuters one: https://aws.amazon.com/solutions/case-studies/thomson-reuters/ https://aws.amazon.com/solutions/case-studies/thomson-reuter... These are nontrivial and business critical workloads. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns edit: ------------------------------------- Missosoup i see you making changes to your comment and it greatly changes the tone/context. i won't adjust my own reply in suit but leave it as it was for your original comments on this.
- missosoup 7y agoI'm not going to make any elaborations on my comment now. Please feel free to edit yours or post another to answer anything I raised. Your original reply containing some generic sales brochures isn't what I expected from someone representing aws stepping into this discussion.
- nimish 7y ago
- shiftpgdn 7y agoKinda wild in your post history you're advocating for AWS as a cheaper superior platform without disclosing that you work there.
- munns 7y agoYup! Haven't done it in years and created this different account to be more clear/direct in who I am. That is also why I called it out at the start and bottom of all my responses. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns https://twitter.com/chrismunns
- missosoup 7y ago[meta] Please stop downvoting this. Clearly those comments were years ago and clearly the author has been doing the right thing for years since.
- kurige 7y agoMaybe that's how he got the job.
- munns 7y agoNo. I've been at AWS for over 7 years in a few different roles. Came to the serverless space >2.5 years ago because I felt passionate about it (could have literally done almost anything). Again, sorry for mis-posting under my older personal account, it was rarely used fwiw.
- kurige 7y agoI wasn't criticizing you. I was pointing out that an equally likely and more charitable interpretation is that you posted as a fan of AWS before you started posting as an employee. Turns out I was wrong in this case, but you've explained the situation and everything is hunky dory.
- milesward 7y agoHugs Chris!
- munns 7y agoHug back at ya big guy!
- hesburg 7y agoReally? Hahahha
- munns 7y agoMiles and I know each other, what's wrong with a friendly hug? Do you need a hug hesburg?
- michaelmrose 7y agoI recall a certain uptight code of conduct which explicitly forbids unasked for virtual hugs.
- milesward 7y agoYah, but I know him and we hug.
- iforgotpassword 7y ago> In terms of HN sentiment and in being a member of this community for almost a decade, I don't know if I'd say it widely represents most of the dev world as it tends to lean way more open-source and less enterprisey. They also like to join the latest hype more often than not so that should even out the anti-enterprise sentiment. I don't think serverless is over that point yet. General opinion regarding the topic: I haven't done serverless in any way yet, but if it's similar to "regular"/other cloud services then in my experience it only makes sense of you're so big that building a scalable infrastructure yourself is too expensive (unless you're Facebook or Google). The other use case is if your load is actually fluctuating a lot, to a point where having enough resources available just to handle the peaks at all time is too expensive. Whenever you can somewhat predict your load, having your own infra is almost always less expensive (at least here in Europe/Germany).
- deleted 7y ago[deleted]