After working for the past ~3 years with a microservice oriented architecture, I can only imagine the horrors of having to work on a project built with lambdas.
We're a team of only 2 backend engineers which have to touch up to 4-5 repositories for implementing some features. Orchestrating the deployments of the changes to all those repositories, debugging across all those microservices, having sane rollback strategies for each feature, really brings down the developer experience and speed of development when compared to working with monoliths. I don't want to imagine what happens when one would have to treat every function as a separate entity.
Yes, these architectures have their benefits, but for 99% of the projects in the wild the burdens outweigh the benefits drastically: every day, for every feature developed, for every deployment and for every bug being debugged.
I’m a strong proponent of microservices but only for one thing - the ability to scale the number of engineers working on a product. If you can abstract out a contract between each service then developers are unburdened to iterate as fast as they can without constant communication overheads.
The idea of a 2 dev org deciding to replace simple maintenance free function calls with authenticated, TLS-secured, retry-able, service-located, rate-limited remote procedure calls (in the general sense of the term) and replacing simple method parameters with serialisation and deserialisation overhead… it’s all just pretty absurd.
The consequence of that is that every release is a fairly big deal requiring a lot of coordination overhead among a huge number of people, which bottlenecks how often they can happen. That's fine for a foundational piece of technical infrastructure like an operating system kernel, but Web apps and other forms of continuously delivered software want to release weekly or more frequently, and there's no way that could happen if every release incorporated 12,000 people's work. That is the problem that microservices solve.
Not that I'm super-familliar with Linux kernel development, but that's kind of a special project that has a benevolent dictator and worldwide interest from several industries willing to throw resources at it. I think what you said is sound, but I'm not sure how comparable the Linux kernel is to the way that most for-profit software firms are run. And maybe that says a lot about FOSS.
I’ve found AWS’s SAM to be a real pleasure to use (though I’ve only used it a bit), and it would solve the pain points you’re talking about here (basically include all your functions in a single repo with a sam template and accompanying cli that makes deployment and orchestration a breeze). May be worth a gander.
> FWAs do not require any specific domain expertise or specialization to build or manage
I volunteered to help out with a project that had been built using FaaS by someone with no specific domain expertise. After a day of reading the code and prototyping solutions, I ended up having to duck out of the project because it was in such a bad state.
Admittedly, this was mostly down to the fact it had been all set up manually by copy/pasting files into the FaaS provider's web interface, and FWA is recommending some amount of Infrastructure as Code which would help, but I do think FWA vastly underestimates the amount of knowledge and experience to do this well.
I would take a Django/Rails starter project on a Digital Ocean template box in an instant over a FWA application if it was a made by an inexperienced developer.
My point is that I think FWAs are less beginner friendly, and will result in worse systems, than more "traditional" web apps.
There's less teaching material, the material is of variable quality and pulling in different directions, it's less clear how things fit together, and it all depends on technology that's very much in flux.
I'd probably suggest that basic PHP sites are a simpler mental model (as the page/template/URL structure is more directly related) and therefore better for beginners.
This feels a lot like the growing Vercel + Planetscale solution. (or Netlify/Cloudflare/Amplify + Cockroach/Supabase/Aurora)
Vercel provides CDN caching for static assets, edge functions, and lambdas. Planetscale provides MySQL as an interface on top of an effectively infinite scale Vitess cluster.
My app is a stupid pipe from my db to my user that goes through a single lambda function on Vercel. Pretty hard to beat.
This is really cool to see in this format. Over the last few years I have spent my free time crafting a framework under similar ideologies. I think a lot of web devs end up making similar tools throughout their career, but perhaps never get to the point of sharing what they make. I finally formalized my framework last year and am well into battle testing it with clients and different projects. https://awayto.dev
In a similar light to what this FWA group is presenting, I also have put forth some points about why this style of web dev architecture is important and effective. https://awayto.blog/posts/webapps/
Actually, I started out reading Million Dollar Consulting last year and one of the first chapters essentially talks about the importance of having a portfolio of work, and being able to capitalize off that body of knowledge within to grow more as a consultant. Well, I took that as a sign to formalize a framework that would allow me to do my development work in a much more effective manner, as well as provide more out of the box functionality for my clients.
Overall, the experience has been really positive. Obviously I don't get to use my own framework with every client, and that's a good thing. But, when working with clients who need basic business problems solved, having an FWA style framework is going to allow you to iterate so much faster than traditional MVC platforms. At least this has been my experience. Specifically to that point, with templated and loosely coupled parts, you don't have to spend too long building your web app to get it to do something exceptional.
The problem here is that these types of workflows are great for small-to-medium size CMS websites but do not scale into CRM/ERP-integrable enterprise architectures. Imagine migrations/webhooks to and fro. Imagine developing on it.
