Companies should pay 1Mm everytime they use a new acronym
Rethinking serverless with FLAME
121–130 of 153 posts
Re: Rethinking serverless with FLAME
#122I’m a huge fan of Serverless. I’m also a huge fan of simplicity. My advice to anyone starting out on a purely web adventure: run your monolith on lambda. Just upload your whole app as your lambda. Use dynamodb for storage. When your app gets popular, then optimize. Make a separate lambda for the popular part. Spin up a relational database or maybe an auto scaling group. But start with a monolith on lambda. Get all th…
That advice sounds to be opposite of simple for someone starting out a new project. In addition to focusing on their core stack, they would also need to deal with Lambda details and its restrictions. How would they work around the 15 minute execution limit, for one? My advice would be to start with a plain old monolith. Even launch with it. Once, and if, you have workloads that a) make sense to run as an isolated fun…
You shouldn’t need to run anything more than a minute or two. If you do lambda isn’t for you.
I’ve set up multiple businesses this way. It works great. There are no lambda details to worry about, the defaults are fine. Just upload code and run. No load balancers, no firewall rules. It couldn’t be simpler.
If it doesn’t work then worry about that other stuff.
But it’ll just work 9 times out of 10 in my experience.
Re: Rethinking serverless with FLAME
#123This is really cool - but I would love to simply run an SSI (single system image) cluster with scaling support - a successor to openMOSIX for a post-cloud reality.
https://en.m.wikipedia.org/wiki/OpenMosix
At least shipping processes should generalize to any FFI for most any run-time/language?
Re: Rethinking serverless with FLAME
#124Author here. I’m excited to get this out and happy to answer any questions. Hopefully I sufficiently nerd sniped some folks to implement the FLAME pattern in js , go, and other langs :)
Can you run your app on a smaller vm but boot a larger one ok demand? I'm thinking bumblebee etc
Re: Rethinking serverless with FLAME
#125Earlier quoted context omitted.
A pattern I see over and over, which has graduated to somewhere between a theorem and a law, is that motivated developers can make just about any process or architecture work for about 18 months. By the time things get bad, it's almost time to find a new job, especially if the process was something you introduced a year or more into your tenure and are now regretting. I've seen it with a handful of bad bosses, at lea…
That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years. There's valuable learning (and empathy too) in having to see your own decisions and creations through their whole lifecycle. Understanding how tech debt comes to be, what tradeoffs were involved and how they came to bite later. Which ideas turned out to be bad in hindsight through the lens of the people making them…
>That's why I'm always wary of people who hardly ever seem to stay anywhere more than a couple of years
Do have some empathy for when job markets or life make people move on. I'd like to stay at an employer for more than 1-2 years, but between the layoffs (avoiding them or getting laid off) or the need for a higher salary that often only comes from switching jobs, its not always possible to build tenure.
Frankly its a big issue in the industry at large. I hate interviewing etc. but I'm not going to get paid 20% less because of it. I had to ride the job hopping treadmill for awhile, and I'd like to get off it just as much as you'd like to see people have more tenure.
When I first started out though, I worked for 5 years at the same place until it was very clear I was going to cap out on being able to advance and merit increases of 3-5% a year aren't going to cut it.
Re: Rethinking serverless with FLAME
#126Superficially, this sounds similar to how Google App Engine and Cloud Run already work ( https://cloud.google.com/appengine/migration-center/run/comp... ). Both are auto-scaling containers that can run a monolith inside. Is that a fair comparison?
They handle scaling at only highest level, similar to spinning up more dynos/workers/webservers like I talk about in the intro. FLAME is about elastically scaling individual hot operations of your app code. App Engine and such are about scaling at the level of your entire app/container. Splitting your operations into containers then breaks the monolith into microservice pieces and introduces all the downsides I talk…
> Splitting your operations into containers then breaks the monolith into microservice pieces and introduces all the downsides
A pattern here is to not split the monolith and use the same container for your main app and hot operations. The hot operations just need some different configuration eg. container args or env vars
Re: Rethinking serverless with FLAME
#127I'm firmly in the "I prefer explicit lambda functions for off-request work" camp, with the recognition that you need a lot of operational and organizational maturity to keep a fleet of functions maintainable. I get that isn't everyone's cup of tea or a good fit for every org. That said, I don't understand this bit: > Leaning on your worker queue purely for offloaded execution means writing all the glue code to get th…
Wouldn’t you lose, for example, streaming capabilities once you use Celery? You would have to first upload the whole video, then enqueue the job, and then figure out a mechanism to send the thumbnails back to that client, while with FLAME you get a better user experience by streaming thumbnails as soon as the upload starts. I believe the main point though is that background workers and FLAME are orthogonal concepts.…
Yes fair point. Celery has to pickle parameters so that they can flow through redis or rabbit to the worker pool.
It's worth pointing out this transparent remote function call ability is unique to the BEAM. The FLAME pattern in other languages (as described in the article with Javascript) would also require serializable parameters.
> I believe the main point though is that background workers and FLAME are orthogonal concepts
Yeah I think this is what the author is driving at. I appreciate you helping me try and wrap my brain around it :)
Re: Rethinking serverless with FLAME
#128Earlier quoted context omitted.
That advice sounds to be opposite of simple for someone starting out a new project. In addition to focusing on their core stack, they would also need to deal with Lambda details and its restrictions. How would they work around the 15 minute execution limit, for one? My advice would be to start with a plain old monolith. Even launch with it. Once, and if, you have workloads that a) make sense to run as an isolated fun…
You shouldn’t need to run anything more than a minute or two. If you do lambda isn’t for you. I’ve set up multiple businesses this way. It works great. There are no lambda details to worry about, the defaults are fine. Just upload code and run. No load balancers, no firewall rules. It couldn’t be simpler. If it doesn’t work then worry about that other stuff. But it’ll just work 9 times out of 10 in my experience.
> You shouldn’t need to run anything more than a minute or two. If you do lambda isn’t for you.
Right, but how do you know that on a new project? What happens if you _do_ need more execution time, RAM, CPU, IOPS, etc., than what Lambda provides? Or need some specific integration or workflow that doesn't fit the Lambda model? It would be very expensive to backtrack and implement a traditional architecture at that point, instead of starting with the traditional architecture and using Lambda only when you have a good use case for it.
Not to mention that you're going all in with a single cloud provider. Vendor lock-in at an early stage is not a good idea.
> Just upload code and run. No load balancers, no firewall rules. It couldn’t be simpler.
It's probably simple for you if you've done it many times, but it would require a considerable amount of time and effort for someone unfamiliar with the stack or AWS. The simplest thing is often whatever we're used to, and if that's a traditional LAMP stack, then I'd suggest going with that first.
Re: Rethinking serverless with FLAME
#129Earlier quoted context omitted.
You shouldn’t need to run anything more than a minute or two. If you do lambda isn’t for you. I’ve set up multiple businesses this way. It works great. There are no lambda details to worry about, the defaults are fine. Just upload code and run. No load balancers, no firewall rules. It couldn’t be simpler. If it doesn’t work then worry about that other stuff. But it’ll just work 9 times out of 10 in my experience.
> You shouldn’t need to run anything more than a minute or two. If you do lambda isn’t for you. Right, but how do you know that on a new project? What happens if you _do_ need more execution time, RAM, CPU, IOPS, etc., than what Lambda provides? Or need some specific integration or workflow that doesn't fit the Lambda model? It would be very expensive to backtrack and implement a traditional architecture at that poin…
You don’t know. You write the code, upload it, see if it runs. If it doesn’t you run it somewhere else.
It’s dead simple for a beginner, far simpler than a LAMP stack.
I think you misunderstand how lambda works because your objections don’t make sense.
Lambda is a LAMP stack. They just take care of LA for you.
Re: Rethinking serverless with FLAME
#130Having dealt with the pain and complexity of a 100+ lambda function app for the last 4 years, I must say this post definitely hits the spot wrt. the downsides of FaaS serverless architectures. When starting out, these downsides are not really that visible. On the contrary, there is a very clear upside, which is that everything is free when you have low usage, and you have little to no maintenance. It is only later, w…
> that you wish you had just gone the monolith route Going from hundreds of lambdas to a monolith is overreacting to one extreme by going the other one. There's a whole spectrum of possible ways to split a project in useful ways, which simplify development and maintenance.
Anything in between is all the downsides of both approaches.
Once you have the flow for deploying always running hot application(s) with autoscaling the benefits of lambda are basically gone.
Low volume scale to zero is just another route. No 15 minute limit, no having to marshal data through other AWS services because that's all lambda talks to, no more eventbridge for cron, no more payload size limits and having to use S3 as buffer, no more network requests between different parts of the same logical app, code deploys are atomic you're either at v1.x or v1.x+1 but never some in-between state.
I really do like Lambda but once you're at the spend where it's the same as some dedicated always-on compute the value drops off.