I really like Figure 1. This reminds me of a particular meme wherein the extremes are ideal.
Right now, we are in the left-hand side. Trying to go straight to the right-hand side. We have zero interest in a middle ground approach.
Right now, we are in the left-hand side. Trying to go straight to the right-hand side. We have zero interest in a middle ground approach.
It absolutely is. You can build an entire webapp that runs completely on top of HTTP trigger functions. We are doing this right now and it's a fantastic experience. We arent even using SPA crap anymore. Final, server-rendered HTML coming directly out of the functions. Traditional HTTP form submissions, etc. The only JS exists to facilitate certain UX and multimedia integrations.
If the FaaS solutions in the cloud are feeling complicated, you are 100% using them wrong. The entire point is to take all the traditional infrastructure complexity and dumpster it onto the cloud vendor. Trying to maintain control over all the tiny details is where you go off rails. You have to learn to let go if you want to understand why these ideas are so compelling. Combining actual cloud-native (aka 'locked-in') serverless with containerization ideologies is like mixing water & oil.
In my experience, you basically have to start a new company from zero if you want to explore these ideas correctly. The philosophies of different technology persons in the org will almost certainly ensure none of it goes correctly. There isn't a lot of room for an ego on the deck of a properly-architected FaaS app. So, back to the original point - maybe it isn't possible in general. But, not for the reasons you seem to indicate.
> aren't drop-in replacements for one another
This is like complaining that the concrete foundation of a structure cannot be easily substituted with another not-so-exact approximation that you found down the street. If you want proper serverless, you have to pick a vendor you trust and stick with them. Anything else is complexity circus.
I mean that for all problem domains where the former is a solution the latter isn't, sorry if that wasn't clear.
Where Lambda bit us is when you need to have compute for longer than 15 minutes which happens when processing large documents. You can split the individual operations on whatever your atomic unit of thing is (eg pages) but the split/merge steps are what kills you. The moment you have to step out of all Lambda the simplicity breaks down and making serverfull/serveless work together is more complex than just going all serverfull.
The other painfully annoying thing is when you need state and storage (ie websockets) but maybe that's better now. I know for sure that EFS is still painful.
Some of us have to consider platform risk in our designs and not just ignore it. This is what makes lock-in an issue in the first place. Some times, well, most of the time it isn't an issue. But when it is, it's a huge potentially-company-destroying issue.
Different companies have different risk profiles, and it may be perfectly fine for many to just ignore this risk while others, quite reasonably, have to consider it.
Has anyone considered pushing back on the higher-order consequences of chasing a multi-platform solution?
Do you truly know how much this objective is going to cost you in terms of complexity, et. al.?
I have absolutely zero issues convincing our clients (banks/finance) that one vendor is an advantage.