| This seems to be a lot of post-hoc rambling to justify why a suite of serverless tools were elected, rather than posing a problem seeking a solution. The conclusion does not follow from the premise. For example, before a satisfying answer on why a serverless implementation is better, the article delves straight into tests, and how things are complexified because the serverless architecture means more hinges, glue code, moving parts which now need to be tested. Since this particular serverless interpretation involves relying on Cloud as a Service, a hermetic local development doesn’t exist, and so they build a solution around interactive serverless development. This article is a solution seeking a problem. Many of the solutions here seems like caveats of pursuing this serverless stack, rather than a feature. This is enlightening and useful to know what’s needed to get a fully integrated serverless DevEx, but it doesn’t motivate why people should elect serverless versus a monolith. > We need to make sure that the few engineers that we do hire can make the most impact by delivering product features quickly while maintaining a high quality. > This meant being able to run our services at a scale at a low cost without needing to have a whole department just looking after a homegrown infrastructure. > as well as how we’ll be able to build a successful business in the next 5 to 10 years without needing to do foundational replatforms All these points can be true with a monolith. If anything, these points make a monolith seem viable. There’s been article posting around of using Postgres as a hammer for everything. If anything, vendor lock-in to server less platforms will likely involve replatforms in 5-10 years. > serverless applications. One of the main differences is that you end up using a lot of cloud services and aim to offload as much responsibility to serverless solutions as possible This contradicts the desire to avoid replatforming. > Having personal AWS accounts allows each developer to experiment and develop without impacting any other engineer or a shared environment like development or staging. Combined with our strong infrastructure as code use, this allows everyone to have their clone of the production environment. Again, I’m not sure how this is a feature. This adds another incidental complexity to debug. Engineers may have different permissions and roles. Alternatively, if the engineers are going to have the exact same “environment” as the deployed environment, then the individual accounts don’t provide much value. > full-stack TypeScript ... The ability to move between the frontend, backend, and infrastructure code without having to This is an orthogonal concern to serverless. > developer features... this In isolation without impacting other engineers due to everyone having their own AWS account. This is orthogonal to serverless. In fact it barely seems like a concern of infra. If local environments exist, developers can just have their own local development branch in Git. They can also test and deploy in separate remote branches. Here, the problem was created because local development is against live services. Typically these developer blog posts are intended to evangelize the company. Personally I find many red flags in the company culture. Seems like a fun and cool place if you want to try out the latest and greatest tech trends, and have a chance to scratch your own engineering itches. But if you care about job security, you’d want to understand what is the business impact of all this research and development? |