3 ms·
My company tried really hard to make serverless work on a new part of the platform we rolled out. Our cloud team and management drank the AWS koolaide on serve
by davewritescode 6y ago
My company tried really hard to make serverless work on a new part of the platform we rolled out. Our cloud team and management drank the AWS koolaide on serverless and went 100% all in for all new use cases implemented in this particular platform. It was probably one of the biggest mistakes in the history of the company because doing serverless right is at least as much work and running workloads on well-managed servers (which we have). Management won't resource it appropriately because the whole point of higher costs in serverless is to eliminate Ops budget in the first place.
As for running actual code, many types of workloads currently do not map to serverless at all and you won't find out until you hit the limits. Anything that needs to read in a lot of data from a file or do a lot of in memory computations are a lot less efficient or impossible in Lambda given the memory constraints. If any single invocation of your lambda needs more than the alloted memory, it'll just fail and you'll either need to implement some heuristics based routing to the different lambdas (same code with the appropriate amount of memory) or you'll just eat cost on every lambda invocation. You'll find you end up doing things like re-writing lambdas from Python into Go to make it easier to fit more in memory. How is that not insane?
Although it's not 100% true anymore, at the time serverless development was often easiest using SAM which ties you directly to AWS CloudFormation which is the biggest mistake any company can make. CloudFormation is easily the worst thing that AWS has ever created. It's fine for infrastructure with lower rates of change but for applications it's an absolute nightmare to the point where it comes up in every sprint retro on some of our teams.
I /won't even go into how crappy testing is. It's a complete afterthought and it shows.
That team has started moving towards ECS/Kubernetes and even running Docker containers directly on EC2 instances in some cases because it's actually saving them time over futzing with Lambda and it's enabling them to do more faster.