I started to have a look but that first diagram arrows everywhere, does no one do simple any more?
It does look like what a normal web app would do in say PHP or Django. Is there really an advantage to splitting it into microservices and putting it in AWS Lambda over a load balancer and extra instances when needed? A normal app would have those services split into classes / modules and would run on the same machine (the aysnc tasks being an exception). I imagine my approach would need a lot less ops and coordination between the parts.
That was my conclusion after getting all excited about serverless initially. I was seeing lower latency, no coldstart concerns, and easier log access/ability to debug just by going back to having a server. Plus having your entire deploy be completely governed by a gigantic YAML file that no one's ever bothered to fully (or even properly) document gets old very fast. So I'm back to using servers.
In my experience, when a single engineering team owns the entire service, a single web app >>> cluster of microservices.
The advantage to splitting up systems is when multiple teams own part of the service and do not want to be dependent on each other for testing and deploying and signing off on features.
Although given the amount of time I spent this week to be able to send a string from my microservice to a partner teams' microservice and get a different string back, I'm not feeling microservice love today...
Not sure yet I like how aws does this but I started to think that serverless and microservices are about state after all. It is about ephemeral apps that hold only the bare minutes state. For instance you don’t need user management as identity is better when decoupled into another service. A lot of it sounds like Unix philosophy as in one good tool for one job. HashiCorp YouTube videos explain a lot of those ideas quite nicely. In this world stuff like aws lambda makes sense. However you can build your own lambda and deploy as a container service. So again not exactly sure if aws is doing things right, but the concepts make sense. Apps as functions.
There are a few advantages. Not worrying about maintaining and securing underlying infrastructure is huge. Not worrying about load balancing logic is helpful. Having isolated blast radius of application failures is nice. Overprovisioning can be a real problem depending on the underlying machines.
And then when you get into the surrounding services and features you really start to feel the benefits. Want to have canary deployments? Want to have a queue of failed events? Want to start piping data into a data lake for future analytics? Need to introduce a decoupling message queue in front of an expensive operation? All of it is almost turnkey.
It does look like what a normal web app would do in say PHP or Django. Is there really an advantage to splitting it into microservices and putting it in AWS Lambda over a load balancer and extra instances when needed? A normal app would have those services split into classes / modules and would run on the same machine (the aysnc tasks being an exception). I imagine my approach would need a lot less ops and coordination between the parts.