[hunter_n]

One thing that hasn't really been covered as much but does seem to get some interest with Enterprises (that I've spoken to) is being able to understand the cost of business in more detail. As the unit of deployment shrinks (monolith -> micro service -> function) the visibility increases.

I can see that function X costs $Y per invocation and a whole business process comprising of a particular set of functions is going to cost me $Z. With that sort of granularity an architect can give better estimates for new projects or optimising existing. It may even lead to non-technical members of the business building processes by connecting functions together (like AWS Step functions?)

With a marketplace or "Function Store", the code can be switched out for something more efficient or more feature rich. eg. a new image recognition function that improves accuracy at the same time as decreasing execution speed (charged by the author only 1% more per invocation than the previous code).

Its still early days and a lot missing to get to this point (the marketplaces, common APIs, better granularity for things like databases - eg. per row billing) but it can be a compelling vision for Enterprises to get a more accurate idea of the cost of business.

Microservices (and monoliths) should be able to head in the same direction with advanced tracing and operational metrics. Ultimately I think there will be a combination of all three types of architectures rather than a single winning architecture. All of the approaches will need to lead to a better understanding of the costs involved in building and running code. Functions may be slightly easier to achieve that visibility.