Some of these observations are okay, but some of them border on dangerous or not fully considered. Python is an absolutely fine tool in your tool belt for serve

Some of these observations are okay, but some of them border on dangerous or not fully considered. Python is an absolutely fine tool in your tool belt for serverless. I use it along with JavaScript all the time -- depending on which has better libraries or makes more sense for a given requirement. Quite honestly, the best part about serverless is that you can generally pick and choose which tool is right for the job up to the language in a far more compositional manner than using more traditional distributed SOA platforms. Dynamo is pretty good, but its value starts to dwindle when you want to be able to do local development, possibly even without a network connection. And most of the traditional ways of interacting with the data layer aren't really available. So for instance, you're not doing to be able to use an ORM for a simple application with Dynamo, which means writing a lot of your stuff from scratch. So given that pragmatically, you probably still want a database, you're going to run into a position where you can't possibly be 100% "serverless". A persistent database connection is a good thing, and one where you can control the number of connections is an absolute requirement at scale. Even if you can tweak your lambdas just right to accommodate your DB's maximum number of connections, you're needless assuming the cost of opening one of those connections on each invocation of your lambda. My recommendation is to use serverless where it's really well suited, which is for distributed, event-driven processing. Your data backend becomes an RPC that can help work with the top of the funnel to map and distributed well-populated messages through your system. For this, I use protocol buffers, and base-64 encode their serialized bytes into an SNS topic. Depending on message size, your mileage may vary here. You can still use some of the more clever AWS offerings to reduce your dependence on some fixed, running server. For instance, Fargate may make it possible for you to run a persistent RPC server for managing read and write requests to your RPC, which is maintaining a well-optimized connection pool with your database. I agree with using JWT for authentication. I agreed with it when stateless authentication pre-dated the service offerings that made serverless a possible paradigm. Serverless generally requires stateless, but you can still reap the benefits from doing the same thing with servers. Hosting a static SPA in S3 I think is one of the less challenging arguments in this blog post and has been a good practice for getting on five years now. Vue isn't necessarily part of it, and marrying the framework with the choice of hosting I think muddies the waters on what's good advice and what's just an opinion. In all introducing serverless technologies to your platform is a great way to significantly minimize your infrastructure costs. t comes at a similar price as building any other SOA -- an increase in the cost of maintenance as debuggability becomes more difficult, and the network becomes more complex. So it's important to think critically about what parts you should take and what parts you should leave or just defer when it comes to your architecture and your business requirements.