About a month ago, I went for Juval Lowy’s iDesign – Architects Masterclass training. My biggest takeaways from the training were the decomposition of software in the past, present and future and the factors that have influenced it.

Decomposition in the past:

The first abstraction came in the form of components. This allowed developers to compile and move the same reusable piece of code to different platforms.

Decomposition in the present:

The basic building block of a modern software development is ‘Microservice’ or simply ‘Service’. A reusable piece of code is decomposed into a service.

This decomposition extends to every piece of code including UI. This by definition is true service-oriented decomposition. Imagine a ‘Button’ deployed on a machine as a service. Every software on that machine that needs a button calls this service instance!

I know, I know this sounds absurd or bizarre to most software engineers. I felt the same and we are not entirely wrong to feel that way. Why don’t we do it? The reason why we won’t do it is ‘overhead’.

But wouldn’t the problem of overhead be solved by the faster microprocessors? This is where the problem starts.

Most software developers decompose software into both components and services. We live in the past and present for a reason: the end of Moore’s Law. It’s been 5 years since I wrote my last article “Age of Moorepocalypse”. What does end of Moore’s Law mean for Software Engineers? Compute per core in a CPU has been nearly stagnant. We have hit the limits of how small we make a transistor. Unfortunately for us, this happened in our lifetime. This means we won’t be able to create higher abstraction above services as they will be expensive! So how will decompose software in the future?

Decomposition in the future:

It is true that compute per core in a CPU might be limited in the future. But the number of cores per CPU might double every few years. This provides an opportunity and a challenge. The challenge is how do we decompose a software that can effectively utilize all the cores in the CPU. Most programming languages provide constructs like threads, task parallel libraries, and concurrent collections. However effectively decomposing applications using such primitive constructs are often difficult.   

One effective model to address this problem is the “Actor Model”.

What is the Actor Model?

It was a computational model defined in 1973 for dealing with the problem of concurrent computation. The model defines an ‘actor’ which is the primitive unit of computation. It can send or receive a 'message' and perform some kind of computation based on it. Actors emulate simple processing unit. All actors execute concurrently to other actors. Actors manage an internal state thought this should be limited and simple. Actors pass messages to other actors to convey their internal state. Actors should not directly change other actor’s state.  Actors are small, networks of actors are large. We should strive for dumb actors and smart networks.

Popular implementations of the Actor Model:

• Project Orleans
  • Halo, the popular Xbox games, run on Orleans. Orleans is also used for Internet of Things, communications, and telemetry
• Erlang
  • The concurrency implementation of Erlang programming language is based on the Actor Model.
• Akka
  • Arguably the most popular implementation of the Actor Model available for Java and .Net

Conclusion:

In the future, it is the number of core and not the transistors which will double every few years. Decomposition of software in the future will depend on how the computational model can address Concurrency and Parallelism. The simplicity of the constructs of the Actor model makes the compelling argument for being the perfect decomposition model of the future.

Reference : 
https://youtu.be/ukgjQaiZDYM
https://www.brianstorti.com/the-actor-model/