3 ms·

I’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

I’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 the benefits without the downsides.

imiric 3y ago
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 function, and b) would help offload some processing from your main app, consider splitting it and using a Lambda. Doing so prematurely, or worse, starting with it, opens the door to complexity you just don't need early on.
- jedberg 3y ago
  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.
  - imiric 3y ago
    > 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.
    - jedberg 3y ago
      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.
zxt_tzx 3y ago
This advice sounds rad! Do you know of any open-source codebase that does this? > Use dynamodb for storage. So far I've done the opposite, i.e. use a relational database at the beginning, and, if the access pattern is clear and there are some parts of the application that would not scale well with SQL, move those parts to DynamoDB.
- anonyfox 3y ago
  can not give you a codebase for permission reasons, but ie in nodejs land you rather easily can do: 1. write a bog standard express.js backend (might or might not use a SPA/SSR frontend) 2. make the normal (dev mode) server start with an index.js (which boots the express app on a port) and ontop of that an additional lambda.js next to it, which wraps the app (not booting it) with `@vendia/serverless-express`. 3. use AWS CDK (which is typescript anyways!) and ship it as a "NodejsFunction", which also will use esbuild under the hood to bundle your app into one JS blob (no need or a ZIP container with node_modules!) on deploy. The entry file is the "lambda.js" from step 2. 4. in addition use the CDK to configure some traffic origin for the lambda, the cheapest one being a CloudFront function URL - which also acts as a quite good cache in general when you send the appropriate HTTP response headers from your express app! 5. Point a domain to the Cloudfront. 6. Profit! ... I've used this excessivbely in the past years for lots of microservices/microfrontends and it basically works as promised: scale to zero, scale horizontally on demand automatically, and being rather cheap (esp when in the free tier then its basically free to run small-mid loads). Having said that, this WILL become a maintenance trainwreck when scaled up, telling from my devops experience. All the libraries/apis/infrastructure (especially in nodejs land) tend to have breaking updates all the time, so better have at least one FTE dedicated to maintenance of all the moving parts. And tbh: all this pain goes away for like <100$/mo with Elixir/Phoenix/LiveView on fly.io. a single phoenix app on a single server can deal with _suprising_ amounts of traffic, and even if you get to serious load, scaling horizontally is outright trivial with Elixir+Fly. And there is no need for additional infra like Redis or Message Queues, since these things have natively built-in equivalents in Elixir (or: the BEAM itself). So only an appserver and a database you need here in terms of infrastructure/maintenance.
  - 3y ago

imiric 3y ago

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 function, and b) would help offload some processing from your main app, consider splitting it and using a Lambda. Doing so prematurely, or worse, starting with it, opens the door to complexity you just don't need early on.

jedberg 3y ago
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.
- imiric 3y ago
  > 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.
  - jedberg 3y ago
    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.

zxt_tzx 3y ago

This advice sounds rad! Do you know of any open-source codebase that does this? > Use dynamodb for storage. So far I've done the opposite, i.e. use a relational database at the beginning, and, if the access pattern is clear and there are some parts of the application that would not scale well with SQL, move those parts to DynamoDB.

anonyfox 3y ago
can not give you a codebase for permission reasons, but ie in nodejs land you rather easily can do: 1. write a bog standard express.js backend (might or might not use a SPA/SSR frontend) 2. make the normal (dev mode) server start with an index.js (which boots the express app on a port) and ontop of that an additional lambda.js next to it, which wraps the app (not booting it) with `@vendia/serverless-express`. 3. use AWS CDK (which is typescript anyways!) and ship it as a "NodejsFunction", which also will use esbuild under the hood to bundle your app into one JS blob (no need or a ZIP container with node_modules!) on deploy. The entry file is the "lambda.js" from step 2. 4. in addition use the CDK to configure some traffic origin for the lambda, the cheapest one being a CloudFront function URL - which also acts as a quite good cache in general when you send the appropriate HTTP response headers from your express app! 5. Point a domain to the Cloudfront. 6. Profit! ... I've used this excessivbely in the past years for lots of microservices/microfrontends and it basically works as promised: scale to zero, scale horizontally on demand automatically, and being rather cheap (esp when in the free tier then its basically free to run small-mid loads). Having said that, this WILL become a maintenance trainwreck when scaled up, telling from my devops experience. All the libraries/apis/infrastructure (especially in nodejs land) tend to have breaking updates all the time, so better have at least one FTE dedicated to maintenance of all the moving parts. And tbh: all this pain goes away for like <100$/mo with Elixir/Phoenix/LiveView on fly.io. a single phoenix app on a single server can deal with _suprising_ amounts of traffic, and even if you get to serious load, scaling horizontally is outright trivial with Elixir+Fly. And there is no need for additional infra like Redis or Message Queues, since these things have natively built-in equivalents in Elixir (or: the BEAM itself). So only an appserver and a database you need here in terms of infrastructure/maintenance.
- 3y ago