Cite this. I don't believe you. I'm across a pretty broad slice of industry and can only draw on anecdotes from colleagues, but the majority of people with actual hands-on experience are disillusioned and say that the biggest (only?) drive for serverless at this point is top-down organisational pressure created by technically incompetent strategic management that looks to 'thought leaders' and Gartner to tell them what technologies to use.
if serverless works for 80%, then why is that 80% not even remotely reflected in the sentiment here? HN is usually a pretty good gauge for how the wider engineering community feels about a particular technology.
People make more effort to engage if they have strong positive opinions and minor negative opinions. Minor positive opinions, which (you hope) are the average in an audience, get unrepresented if the effort required to give feedback is great. That's why metrics measuring average opinion - like NPS - aim to require as little effort as possible.
Source?
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
this is me. Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns
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
>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-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.
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.
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-val... and this Thompson Reuters one: 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
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.
Not all of it is massive ML models doing a lot of computation, and I've had a lot of success using pandas and numpy in it (and gcp cloud functions).
Serverless has its niche and is a great little tool to smooth the impedance mismatch between data stores.
Thanks, - Chris Munns - AWS - Serverless - https://twitter.com/chrismunns
Turns out I was wrong in this case, but you've explained the situation and everything is hunky dory.
Do you need a hug hesburg?
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).
We run on AWS. We log lots of stuff to CloudWatch. CloudWatch allows you to scan for regexps (more or less) and send matching lines to a destination of your choosing. There are about 5-10 such matching events per day that we care about, and when they happen, we want an alert in a Slack channel (or email or text or PagerDuty or...).
Option A:
Stand up a server. Deploy a web service on it that accepts POSTs from CloudWatch and acts on them. Update the box as OS vulnerabilities come along. Pay 24/7 for a server that accepts 10 incoming requests per day.
Option B:
Write a plain Python function that takes the contents of a POST that's already been processed and has no other idea that it's living behind a web server. Drop it in Lambda. Pay for 1000ms of processing time per day.
I wouldn't want to run our entire stack on Lambda and friends, but for certain specific situations it's brilliant and I wouldn't want to give it up.
Or you can upload a single function definition to Lambda and let it do everything else.
Again, I wouldn't use Lambda for everything, but I'll gladly let it handle the stuff I won't want to bother with.
On the other hand, you're probably all set up to do that already. It's no big deal. Introducing a new tech requires training, new deployment procedures, new documentation, etc., and now you probably have a one off component out there. There's a line somewhere, but if I were just adding a webhook for log events I'd throw it on a server I already have.
Complexity and dependency are costs too, and I would argue often more significant costs than the $30/month to run a server.
Lambda is just perfect for such a use case, and the number of processing minutes makes it almost free.
Do most people work in this kind of environment? At my company our management couldn't care less what technologies we use. They want to see reasonable cost and solid uptime, and they ask engineering to deliver that.
What defense mechanisms does your firm have against this? Unless your team leads are golf buddies with the C-suite, it is unlikely that their opinions are going to be taken seriously.
For some reason, in most firms, the c-suite isn't super keen on delegating that power.
So are they indistinguishable or not? Two things can't be a bit indistinguishable.
HN is a pretty good gauge for how a subset of a very startup focused portion of the engineering community feels about technology.
I don't know that the same can be said about it reflecting the opinions of the engineering community on the whole, or if the community is even unified enough for anything to be a representative sample. We're a pretty diverse and opinionated lot.
While we might like to think the opposite, I feel like the majority of people in our profession are like the majority of people anywhere -- going to work to work, and going on FB/twitter/reddit to waste time. I don't know many devs personally who take a big interest in the goings-on of the startup world or open-source world in the large. Do they care about spending some of their free time honing their craft or messing around with a new tool? Absolutely. But few seem like the type who would enjoy engaging in a quasi-philosophical discussion on the strengths of various design paradigms. They spend all their day thinking at work; not many want to continue thinking about the same sort of stuff during their off hours.
....no, no it really isn't. HN is a bit of an echo chamber of people who care about being on the cutting edge. 80% of the rest of the industry goes home and stops thinking about software engineering.
Anyway, here's my two cents: I'm building a web app that has the following components:
* A super simple SPA frontend
* Like...5 API endpoints? that allow people to register their emails to the service
* A mailer that sends out a daily email at the time the user specified
* Like 5 more API endpoints for manipulating some per-user data (profile, preferences, etc).
For this use case, serverless is _perfect_. I'm using the "Serverless framework" which allows you to write the definitions for your functions (think routing rules, a la `routes.py` in a Django app) and CloudFormation directly into a YAML file, then it consumes that, updates a CloudFormation stack with all your bits n' bobs all connected together, and gives me:
* 10 or so lambdas
* Monitoring for all of the above, including pings if something goes catastrophically wrong
* A DynamoDB table to hold all the data
* An API gateway hooked up to all the lambdas
* An S3 bucket with my static assets in it
* A CloudFront distro set up to CDN all my static assets
* A DNS record to hook up CloudFront to my URL
* An SMS (emailer from AWS) queue to ship out emails on an hourly or so basis
This whole stack is declared and managed with like 120 lines of YAML and deploys itself in a minute or two, no extra automation or management required. It costs me like 2 dollars a month right now since I haven't launched the site, but by my back of the napkin calculations, it'll probably cost under 50 bucks a month with my expected traffic. Serverless can be great for this sort of thing, and if I do eventually need to migrate this to VMs running containers or something it won't be _that_ hard (it is, after all, just a pile of TypeScript running on Node).
Now, I'll be honest, it took me a full day of tinkering to figure out how to get static assets in an S3 bucket to publish to CloudFront, but that's because I don't read docs very well, and now I know how to do it for the future. I imagine if I had less hubris and found someone else's tutorial for doing so, I could have had it solved in an hour or so. But lambda does work for a lot of simple use cases.
I imagine that most peoples' shitty wordpress sites from 2006 would benefit a lot from being frozen into static HTML, dumped in an S3 bucket, and put on a CDN. They'd get security patches, OS updates, a global CDN and a bunch of other goodies essentially for free. And the sad reality of our industry is that most of it isn't building fantastically intricate real time distributed systems that both cook your breakfast and brush your teeth, it's maintaining some guy's shitty wordpress site from 2006. Tech isn't sexy outside of the FAANG/HN bubble, and _that's perfectly OK_. Serverless is a great paradigm for those people that don't need anything fancy, it's like the modern LAMP stack IMO. It's a good enough default from a performance and cost perspective for most people who have no business thinking about (or who just really don't want to think too hard about) their infrastructure.
Is it a pile of bespoke garbage that sometimes feels like it's going to topple over? Sure, but so does all the software I work on at my day job. At the end of the day, people should use whatever is right for the task, and serverless is great for low- to medium-volume mostly static sites and apps that have a little bit of data manipulation and a little bit of background processing but nothing that rises to the level of _needing_ to manage your own infrastructure. And that does really cover a significant portion of the industry, even if it's not being adopted by the 80% right now.
I haven't done direct development with lambdas, but I've had to help other devs debug issues (currently in a devops role, but I was mostly a dev for like 15+ years before) and been to a few meetups where I watched people advocate, write and show severless deploys on AWS and Google.
I can see some use cases for it, but I honestly hate losing a lot of the introspection and debugging capabilities with them. I'd personally have to deal with setting up my EC2 instance or K8s/maraton deploy and being able to get to the underlying system if I need to. If things go well with a lambda, then you're all set, but the moment you need to start debugging anything serious, I feel like you're going to be in a world of pain.
In one specific instance, we had a developer who set up a lambda and also setup nginx to route to it because he didn't want to use API Gateway, which he got working, painfully after a lot of work. He should probably put up a blog post on it honestly, as I don't think it's officially supported.
Of course, this is all anecdotal. It's really difficult to measure things like speed and cost objectively with this stuff since everyone's stack and needs and uses are just a little bit different.
Every time something sympathetic to a "hyped" technology is posted it's largely derided for being the "popular, hyped" option. MongoDB absolutely ruined the idea of NoSQL for years because everyone just meme'd about "webscale", without being willing to consider that maybe there's merit to the technology.
Are you seriously doubting that lots of people are moving towards serverless infrastructure?
Even internally at big companies they use "serverless-like" models eg:
* Lots of big companies have an internal FaaS
* Those FaaS are owned and managed by other internal teams, and are treated in much the same way as how you'd treat a 3rd party offering.
Serverless just outsources what those companies are doing already.
I leverage AWS lambdas almost exclusively. Yes I am paying a higher price for worse latency. That's OK. I'll pay money for that, if what I get in return is a managed hardware, os, and runtime environment - problems that generate billions of dollars in revenue for many different companies that are working on making it easier.
Performance is a problem I wish to address aggressively, but it's 3rd on the list. A rough approximation of my priorities might be:
1. Security
2. Complexity (including operational complexity)
3. Performance
Serverless gives me the tools to manage (1) and (2) in a way that has worked extremely well for me personally, and I have not found latency to be a problem for me.
Sadly, the site is down so I can not view the article and comment on things more concretely, however I saw the 8x figure and that's fine. 8x latency is fine for many workloads, but operational overhead isn't fine for mine.
edit: OK, so they just don't support HTTPS. It loads now. 8x cost, 15% performance. Cool.
Cool numbers and article, I appreciate what they're getting at. I don't see how you can walk away with "Serverless is all hype and never an option" from it, but whatever. I will once more point to the "Any time this comes up people bash it because 'hype bad'". The top voted comment currently is someone bashing serverless and contains literally no substance.
> Finally, I'm not trying to bash API Gateway, Lambda or serverless in general here, just showing that for some workloads they are a lot more expensive than boring old EC2 and Elastic Beanstalk
Really makes sense to me! Pick the right technology for your constraints. If serverless offerings like lambda could solve every use case AWS wouldn't need other services.
Serverless is more cost effective for sporadic, bursty things where the cost of an instance sitting idle outweighs the more expensive per-operation costs of serverless. On sustained load, it is almost never cheaper.
Another price to pay is complexity; it's simply more difficult to build, deploy, and monitor serverless systems.
What do you mean by serverless systems?
My experience isn't with AWS, but with Azure, so maybe it isn't an apples-to-apples comparison.
My experience has been that building, deploying and monitoring even moderately complex, interdependent Azure Functions has been less difficult than building the equivalent services to deploy to IaaS or on-prem. FWIW, a big part of that reduced complexity has been offloading infrastructure management to Azure instead our IT guys, but deployment and monitoring has also been practically painless. Are there some complexity "gotchas" that I've missed?
We have a few lambda functions we use that send notifications or perform very specific tasks that are sort of on their own. Running on serverless is perfect for these. These functions are only invoked occasionally (a few times a month). So it is great that the Lambda only boots up the few times it is needed and I don't pay when it sits idle (most of the time). It costs me 10 cents a month instead of say $10 a month with a small EC2 server that might otherwise do the same thing.
Another great use case is bursting or inconsistent traffic/invocation patterns. For example, we have a use case where users can text/SMS in and receive a promotion code. We have this running on serverless because it runs very iradically. A nation-wide commercial will run and ask users to text a code, which triggers hundreds of thousands of Lambda instances within a few seconds. But then it might not run again for a month. On a traditional server platform, we would need a load-balanced server solution with several servers set up for redundancy on a huge influx of traffic, only for those servers to sit idle for who knows how long. You can't shut it off because people might text it at other times too, but you need to have a system that is available for "worst-case scenario" at all times (aka when a national commercial runs). You also don't know exactly when the commercial will run, so you have to always be ready. This setup might costs thousands of dollars a month on a traditional server system, but on Lambda it could cost $100 because we only pay during that huge influx of traffic. What I also like is that you can just trust that the Lamdas will boot up under nearly any traffic load. So you don't have to worry about making sure your server is "ready" or "the right size". If we get 1 hit, then we pay a fraction of a penny. If we get ten million hits then we pay $20 (really - it costs $0.20 /Million). Try to get the same reliability with a $20 server that can do that... spoiler: you can't!.
So I don't look at it as a slower solution that is more expensive. If you are running data analytics or a web server that is always on then this is surely the case. In which place I would say to use a traditional server.
But serverless has a role and it is great for infrequent usage, or for burst traffic. We love that we know we can get nearly infinite traffic and just pay per request without worrying about the infrastructure being ready. It is infinitely scalable, so that we don't need to worry about it.
It is always a pro and a con. I love serverless because it opens up new options for developers and system admins. It is another tool in our toolbelt. It is not the perfect solution for everything. We still run many vanilla EC2 instances for internal CRMs and webservers that run constantly. Or for booting up long computational processes. These are cases where servers are still far better than serverless. If we all learned to understand it as another tool available to us and not a "one or the other" requirement then there is a wonderful world where both tools can coexist.
Note: I use the word "infinite" very loosely in this post. I mean "infinitely scalable" in that it is scalable up to any reasonable amount, beyond what I would ever have to worry about. If the day comes that my servers are getting more traffic than Amazon is able to handle in their data servers then I will be far richer than anyone else here and I will come up with a new solution at that point.
I'm using serverless because it lets me deploy a new API endpoint in a matter of minutes.
There is 0 configuration, and deployment is a single command. I also have my own servers running some of my APIs, the difference how much work I have to do is huge. Serverless on Google Firebase is literally "export a function, now you have a new endpoint!".
There is, quite literally, nothing else to do.
I can move 5x-10x the speed with serverless. There is less (almost 0) infrastructure to maintain.
Yes, it costs more, although the math with Google Firebase Functions is pretty trivial, everything is bundled under 1 service, and sending data around between Google cloud services is free.
Startup, I am adding endpoints on a very regular basis as I build out the app. I probably add a couple a month.
As an example, I am writing one right now. It'll take me ~30 minutes to write+deploy it to test.
My long running and CPU intensive stuff is running on a VM of course.
I'm sure if I had spent several days learning yet another tech stack that I could create a system that let me deploy endpoints to a VM that fast, but I have Better Things To Do(tm).
I could also shove everything behind a single endpoint that has a bunch of options, but that brings in a separate set of problems.
That is where the mental savings comes in.
When I first started, I went from "never wrote an HTTP endpoint" to "wrote a secured HTTP endpoint that connects to my DB" in under 20 minutes.
There is nothing for me to maintain. Setting up a new environment is a single CLI command. No futzing with build scripts. Everything will work and keep working pretty much forever, without me needing to touch it.
The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.
(As an example, trying to tell my mobile app's build system that I want a build with production code but pointed at my test environment? Hah! Good luck, the build system is hard coded to only have the concept of dev/prod! I've had enough of that.)
It is frustrations like that Serverless solves.
You could have had the exact same experience with Heroku or many other similar products that have been around for almost a decade and a half--it has nothing to do with serverless.
>The sheer PITA of maintaining multiple environments and teaching build scripts what files to pull in on both my website and mobile app is enough work that I don't want to have to manage yet another set of build scripts. I don't want to spin up yet another set of VMs for each environment and handle replicating secrets across them. I just want a 30 line JS function with 0 state to get called now and then.
It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.
>Everything will work and keep working pretty much forever, without me needing to touch it.
If you believe that, you haven't been doing this long enough.
See below with Ander.
I don't have much infra, I don't need infra.
(I do in fact have a couple of VMs because I do have a service that is stateful.)
Not having to think about anything aside from "here is my code, it runs" is nice. Debugging consists of "did I write bad code?"
> It sounds like your architecture is far too complicated if you're managing all this by yourself. You don't need "a set of VMs" per environment if you're a small start up.
For the few things I run on VMs I still have to manage secrets so they can connect to the right DB. I also need to point my apps to the proper environment. The app being dev'd on my phone needs to point to the dev server with the dev DB secrets stored on it. Same goes for the website on localhost, or the website on the development server.
In an ideal world I'd have a script that created new environments on demand and it'd wire up all the build scripts automatically. Every developer would trivially get their own VM and could switch parts of the software (website, app, services) to point to various environments easily.
Why in the bloody world some build systems hard code only 2 options in is beyond me.
> If you believe that, you haven't been doing this long enough.
Sure old runtimes will be deprecated, but let's compare that to:
1. Setting up nginx 2. Setting up letsencrypt 3. Figuring out why my certs auto-renew but nginx doesn't pick them up (Turns out default setup doesn't actually force nginx to pick up the certs!) 4. Learning about various process management tools for JS to keep my services running 5. Setting up alerts for aforementioned daemons. 5b. Probably involves configuring outbound email. 6. Realizing something went horribly wrong in 5b and my inbox is now flooded with alerts. 7. Writing scripts to automate as much of the above as possible. 8. This legit happened, there was a security fix to SCP on Windows that changed how one of the command line parameters worked, breaking my deployment scripts when running them from Windows. 9. Does Google really want to charge me per decryption to store my API keys in their cloud API key storage service? They have to make money, but ouch. 10. Security updates not just for code, but for the VM images.
Like, I get it, if my entire job is back-end development. But I want to write some functions that maybe hit double digit millisecond run times and throw away all their state after.
Firebase says "here, export some functions, we'll give you an HTTPS URL you can call them at."
That is the sum total of my relationship with the tooling. "Run my code." "Sure."
About the only other thing that works that simply is a headphone jack, and those are going away.
If you decide you don't like the service, you're app isn't tied to a proprietary API or architecture.
And you don't need to manage additional VMs for stateful services.
With VMs I have the joy of managing my own keys.
VMs need security patches, updates, and I have to maintain images. I have to think.
It is hard to explain how simple firebase functions are.
There is literally no mental overhead. There is no worrying. There is nothing to maintain or think about, no settings up quotas or managing what machine something is running on or getting user auth setup. No certs that can expire or daemons that can crash.
I can come back 2 months later and count on everything I setup functioning just as I left it.
Some months I wrote a bunch of endpoints, I average 2 a month maybe, but if I am adding a new feature, I can pop out 3 or 4 a day, and then go on my way and work with the front end again.
Getting debugging up and running for them can be interesting (painful and bad), but everything else is just smooth.
I don't want to maintain a bunch of infrastructure, I want my users to ask for some data and get some data back.
If someone is doing non-trivial processing, serverless is probably not for them. But I have a bunch of 20-50 line functions that are all independent of each other and have 0 state.
I realize I'm paying a premium, but it is worth it to have this stuff that just works.
I've seen many projects that do the same without serverless just fine.
It's always been there, unless you had some enterprise-grade stacks. I was able to do this in early 2000s, with PHP and FTP, in a matter of seconds. Just upload that api/new_endpoint.php.
Not like this timing is the big deal, unless you really need to add those API endpoints real quick.
> I can move 5x-10x the speed with serverless.
I'd argue this is only applicable to the initial setup. There is one-time investment in designing your own infrastructure, but you can move fast on anything well-designed.
And it's not like serverless designs are immaculate. Just recently I was listening to Knative introduction talk and my obvious question was "what happens to event processing if servers that power this system fail and processing job just dies without a trace". Turned out, there are no delivery guarantees there yet. My conclusion: "uh, okay, blessed be the brave souls who try to use this in production, but I'll check out in a few years".
> There is less (almost 0) infrastructure to maintain.
It doesn't run on some sci-fi magitech in a quantum vacuum. The servers and networks are still there.
The benefit is that you don't have to design them. Saves you some (possibly, lots of) bootstrapping time when you're about to make your first deployment and ask yourself "how" and "where to".
The liability is that you can't - so when things break your can only wait, or try to re-deploy in hope that it would be scheduled to run on some servers that aren't affected.
Just understand the job and use the right tool for it. This fighting over Serverless and servers is like arguing over whether hammers or screwdrivers are better tools.
HN is a pretty good gauge for how Silicon Valley feels about a particular technology.
I just deployed my first project to PythonAnywhere and I am blown away at how much easier is. I'm going to pass the cost on to clients and that's that. I'm going to be less stressed and can concentrate on what I want to do: build applications.
I don't know if it's "severless" in the same sense as AWS Lambda or whatever, but I can imagine many solo/small shops seeing less ops work as a godsend.
Wow. Sounds like you should not be so certain.
I have also helped engineers at two other companies start making the switch and they are both happy so far... so, in my (obviously limited) first hand experience it works 100% of the time. :)
to put this into perspective we have grown about 10x and our monthly AWS bills have actually lowered. so I have no way of knowing what this workload would cost on EC2, going down that rabbit hole would produce a "savings" number easily into the millions.
A c5d.2xl (8 cores) on aws is about $1875 per year reserved, $500k per year would buy you over 2100 cores; if you only did 100 req/s per core, you'd be able to handle something like 213k req/s average.
Just the alb costs on lambda at this request rate would cost you $10MM annually... 20x the cost of doing it on VMs.
>>> 500e3 / (1875.0/8) * 100 * 60*60*24*365 / 1e6 * 1.51
10158796.8
$500k to spend
$1875 per box / 8 cores per box
100 req/s
60*60*24*365 seconds in a year
1e6 requests per $1.51 of alb spend
We have a unique workload that includes very large bursts of work that need to be worked on ASAP. Spinning up instances on demand is not fast enough, so we had a lot of servers sitting idle. Lambda allows us to execute this same work for much cheaper because we aren't paying for idle CPUs. Lambda also allows us to execute at much higher concurrency than ec2 would, for the cost. 15000 Threads spread across 100's of IPs is easy and cheap on lambda, not so much on EC2.
We went from ~250 customers per cluster(our term for a set of dedicated workload servers) to 2600(haven't pushed it past there yet). The work that was done on those instances is slowly being moved to Lambda and all new work/features are added to Lambda directly. This has effectively allowed us to drop a few clusters and also move to lower resources per instance.
FWIW we don't use ELB for Lambda, they come in via API Gateway, to Lambda/Step Functions directly or into an SQS queue in the case of workloads that have rate limits. For Lambda based workloads it breaks down something like 56% of cost is Lambda, 34% of cost is Step Functions and 9% is API Gateway.
Thanks for the explanation ;)
The idea of running your entire app as serverless sounds like pulling teeth. Thought leaders are free to pat each other on the back on that one... I won't mind being called a luddite.
If you are managing API gateway or your logging it's a failing on your initial setup and design, not on Serverless.
These don't go away because you went serverless. They are jut now outside your control -- and you will have to wait for somebody else to fix them, usually with no insight into how long it will take leaving you with a very poor messaging you can give your clients as to when things will be back on line.
Simply hand-waving -- this is running on somebody else's server is not going to make the auditors happy.
Enterprise folks don't want to manage servers for a whole host of reasons. But I would say the number #1 reasons is they don't understand the cost, and the #2 is the management team has no clue what they are doing -- and probably running a play book somebody else wrote one time long ago that happened to work exactly once.
It shifts blame, especially if it's in the contract with the provider.
You learn quickly that while AWS is “compliant”, they have enough legal sway to never be on the hook if they aren’t actually compliant.
If you don't adhere to the shared responsibility model and a contractor checks long lived IAM credentials into Github, that breach is definitely attributable to you and you deserve all the "blame" you get.
But if someone figures out how to trick AWS' IAM into issuing credentials that allow PHI to be pulled out of S3, do you think that gets passed along to a customer?
This argument only works until you reach a certain size or security requirements.
At the end of the day, if it's critical to the business it doesn't matter what the paper says, you're still responsible for any damage to the business from a bad vendor.
----
It's just like car manufacturers, nobody cares that Takata was actually responsible for faulty airbags. They simply know their GM vehicle has a dangerous recall.
Rather than thinking about GM’s perspective, think about Takata’s perspective: they screwed up making an airbag, but everything was fine because they outsourced their audit to GM, so indeed it was “GM’s responsibility.” On top of that, GM is still happy to treat them as a partner.
Now imagine that instead of some random third-party supplier, Takata was a division of GM, selling to a different division of GM. The same considerations still apply from the Takata-as-division’s perspective, even though nominally they’re part of a company of that “certain scale.”
Are you joking? Outsourcing compliance critical parts of your environment is the raison d'être of huge swaths of the enterprise IT landscape.
https://aws.amazon.com/compliance/services-in-scope/
Can you imagine how much that page costs in terms of getting the audits, developing the processes & procedures internally to execute on the requirements, etc?
That's not hand-waving away concerns: it's paying a premium to know your infrastructure was managed in scope of whichever compliance regime your business falls under, and to get attestations that prove to your auditors that things are indeed being done properly.
But somehow in marketing materials and blog posts it's instead discussed as if it was a good idea to run everything serverless. Maybe that works great for some edge cases (e.g. reaching PCI compliance), but in general that's not what it's for.
This is becoming unfashionable because it is arcane, but *nix (and Windows I'm sure) really provide some rich functionality and tunability that can let you move fast or reach performance/scale challenges that are very expensive or perhaps out of reach otherwise.
Of course, at one point I was told the same thing about managing your own hardware, and the thought of dealing with the jumpers on the back of the harddrive fills me with the same sense of frustration I'm sure a newer developer would feel when learning their disk is out of inodes for the first time.
Some of us had deploy pipelines into “containers” working like a Lambda in 2003.
Nothing in software is all that novel these days, IMO.
All these features that have been there for a decade plus are just wrapped in a corporate brand now.
Progress.
There is surely truth in this. But also, almost nothing is novel if you watch at the new stuff with the same mindset of the past.
It is wise to realize that most new stuff was already invented, but it is also wise to understand that the surrounding might have changed more than you realize.
(Talking out of my own ass here, just in philosophical terms)
In other words, the Lambda environment, as a development target, is the exact opposite point on the spectrum from an OS like Mosix: rather than trying to make a big cluster of specialized compute resources appear as a standardized local POSIX environment, Lambda instead does away with the POSIX environment entirely and forces your code to interface with the big cluster of specialized compute resource “where it lives.” You can’t just write to disk, because there is no disk. You can’t just talk to other processes on the same machine, because there is no (multiprocessing) machine. In fact, you can’t even cache state in process memory indefinitely, because your process isn’t indefinite like it is in POSIX. Etc.
This is a big benefit for ops folks, insofar as code that’s written as “Lambda code” (but generically, using libraries like Fog) can be easily run in many more modern infrastructure environments (including on-prem ones!) than regular code can, “at scale”, without modification to the code itself. As well, these restrictions (like the one on not caching state in memory) force devs to confront what turn out to be the realities of fault-tolerance, which means far less of an ops headache later on, trying to baby along workloads that rely on never dying.
I would describe Lambda as doing a very similar thing for the server, as what Google’s Native Client (PPAPI) attempted to do for the browser: to create a new, strict ABI for developers to target, that forces code written against that ABI to build its features differently (i.e. more portably, more securely, etc.)
Or, philosophically, “serverless” is just a further extension of Heroku’s “twelve-factor”: it’s an approach that hobbles developers’ available toolkit, for the sake of making the workloads they produce better-behaved and more predictable at runtime.
Not very net new for me, except I’m tethered to AWS.
As usual: ymmv
The thing that was new about Facebook wasn't that it was different than MySpace, but that it was the first social network that managed to scale such that all your friends and relatives ended up using it without your pushing them to do so.
The differentiator of the serverless model is that it's a Schelling-fence development practice, such that you can find real infrastructure components in the wild that are targeted at "serverless deployment" and use them.
Or: there was likely no version of Wordpress developed specifically for your stack; but there is likely some version of Wordpress developed to be deployed on a FaaS cluster. That's what makes "serverless" worth paying attention to. Like Kubernetes, or even Linux: they're the first ubiquitous examples of their archetypes.
Wow, FreeBSD weenies are excited about re-discovering CICS.
See how annoying and wrong you sound?
Those scenarios are probably just as happy with a PHP script on Apache.
[citation desperately needed]
Citation?
Here’s the proof of evil intent behind React, for example:
Or perhaps your idea of "proof" and mine are just vastly different.
i guess we’ll have to wait for the trail of destruction to appear as proof of everything else that has come from Facebook.