4 ms·

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 wi

by 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.

by imiric 3y ago

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.