Illustration of MicroServices, Monoliths, and Hybrid approach that can be fully automatic when AWS, Azure, and GCP allow us to automatically and dynamically re-combine them.

I predict that in the next 2-6 years AWS, Azure, and GCP will allow us to dynamically combine FaaS (Lambdas) into the different configurations of services, and even monoliths.

There are seem to be certain shapes and numbers that the universe likes. One of the shapes is a spiral. A lot of things move in spirals, the first time I heard it – it was about fashion, fashion always repeats itself. These days I tend to think similar, look at APIs:

WebServices with SOAP were popular. SOAP effectively allowed clients to invoke procedures on WebService.
Then RESTful replaced it, it exposed WebService as a set of resources instead of operations.
And now gRPC and GraphQL are again popularising the idea of invoking procedures remotely.

I call it a circle and not a spiral – because we are improving. I would never want to go back to SOAP, and when something else resource-based replaces current roster of gRPC and GraphQL I would prefer the next thing over good old REST.

Let's consider a sample case, of Security Trading App – AcmeTrade. AcmeTrade is a company that allows people to trade securities, such as ETFs, Bonds, Stocks, etc. They have 2 types of clients:

Retail Clients, who trade once per month or per quarter.
Day Traders: who use our platform to place hundreds of trades per day.

Those two types effectively use the same product, the answer to "What" question is the same, the difference is in the "How" and "Why" questions, we usually call "How" and "Why" – Architectural Characteristics, Quality Criteria, or Non-Functional Requirements. There is a huge list of them, technically any word ending with "ility" can be considered one, but for now, let's just go with four parameters: Usability, Security, Availability, and Performance.

Retail Clients want:

Usability – They want to give us money, and they don't use our product often enough, to remember how details work. They want to to be able to see their financial situation, and place orders with the least amount of actions and have clear feedback.
Security: They need retail-bank level security.
Availability of 99.9% is good enough for a retail client. 8 hours of downtime per year wouldn't be noticed. Ideally 99.99%.
Performance: Retail Client can wait for a second or two to navigate between pages. They'd prefer not to though.

Retail Clients need good experience, but they don't necessarily need a scalable and available system.

Day Traders want:

Usability – They want a usable product, but they use the product every day and will develop spacial memory and muscle memory. It's important not to change the look, feel, keyboard shortcuts too much. They know how trading works, and need feedback just to confirm and in cases when something went wrong. They don't mind investing time into reading / watching instructions to become more productive.
Security: They need retail-bank level security, and in some cases higher.
Availability of 99.99% is minimum (averaging at 1-hour downtime per yeat). They would prefer 99.999%.
Performance: Day Trader want's navigation to be as fast as possible.

Day Traders would like to have a good experience, but they absolutely need a performant, scalable, and available system.

These days we would probably approach the problem in one of two ways:

Build system according to most-demanding requirements across all customers and actors. Which is expensive, and can add additional risk from the point of view of operations and delivery.
Build two different systems. It's actually cheaper (counterintuitively I know), but effectively splits organisation in two, and adds drift of systems, which has to be accounted for and managed.

But what if we were able to implement our software as a bunch of functions, and then dynamically combine them either into a set of microservices or monoliths?

On the left image of multiple microservices, which provide scalability. On the right same functionality put into monolith, which is less scalable, but can be cheaper to maintain as a single unit. Current wisdom says that Microservices are better as … — On the left image of multiple microservices, which provide scalability. On the right same functionality put into monolith, which is less scalable, but can be cheaper to maintain as a single unit. Current wisdom says that Microservices are better as strategic move, however it would be nice to have option to go to monolith from time to time.

And maybe then even use machine learning to automatically add/remove functions. Maybe customers that only buy ETFs only need modules with logic for ETFs? While it's highly unlikely that architects would do it, I can imagine ML-powered system could automatically re-combine services for given customer archetype.

Maybe even CloudFlare would make first move?

Prediction – Cloud Providers will let us Recombine Lambdas into Monoliths and MicroServices