Software architecture has gone through several phases in the last 30 years. Now that we are on the verge of a new seismic shift in the software architecture, let's go through the evolutionary steps of software architecture and perhaps imagine what the future might bring. The focus of the article be on web/mobile applications as they present majority of applications we interact with today. Techniques described here can be applied to client-server/desktop apps as well, with slight modifications.
I would like to start the architecture journey by looking at the scalability cube as defined by AKF Partners. It is a three dimensional scaling space where each axis represents a way to scale an application. The ultimate goal of any architect is to design an application that works as expected under near infinite load. By employing a combination of different architectural styles, architects can navigate through the scalability cube in order to reach the Holy Grail of architecture - the infinite scalability point.
If the scalability starts becoming an issue, the first thing you can do is to put it on a bigger server (scale up).
Bigger boxes with enough resources (Memory, CPU, Bandwith, IOPS) can drive your scalability up to 50k-100k users.
But make sure your wallet can scale infinitelly as well since these monster boxes are anything but cheap.
If you look at the biggest Amazon instance (x1.32xlarge), you get 1952 GB of memory, 128 CPUs, 4 TB storage, and
all that for just $13.338 per hour.
This is the point when you turn back to your architect and ask for another solution.
When the application layer starts falling behind, the cure is to implement another load balancer in front of the business layer. At this level certain changes to the application logic is probably needed. If the presentation and business layers are stateless then load balancers can easily throw users on any of less busy web and application servers. In case any of these layers are stateful then settings on load balancers such as sticky-sessions need to be used.
To further move our architecture towards infinite scalability, a third load balancer can be introduced. The one that distributes load over several database servers. Load balancing databases is not a very common method. The more databases there are in the cluster, the more time-consuming replication jobs between databases need to happen in order to preserve data consistency.
The better way to increase database scalability is with data sharding. That is database partitioning per some logical separation of a domain.
You can often see data sharding being implemented in government institutions - one desk accepts applications for people whose initials are from A to D,
the next desk takes from E to K and so on. With data sharding the load on databases can be spread among many servers
while still keeping consistency and simple transactional model.
All previous scaling scenarios are workarounds for the monolithic architecture. The monolith is still present but fully or partially distributed on more servers.
Distributed monolith is moving our architecture one step closer towards the infinite scalability point. Horizontal scaling and data sharding are traversing our architecture along X and Z axes of the scalability cube. However, without going up on the Y axis we would soon hit the scalability limit with the distributed monolith. It is hard to say to how many users a distributed monolith can support, but the fact is that more you scale out or more you partition your data in shards, the more difficult it becomes to maintain your system. Before we go to the architecture that would push you up on the Y axis, it is important to mention one more concept - SOA.
As previously mentioned, two main pain points with monoliths are dependency and scalability restrictions. As the scalability was more or less being
successfully solved with the distributed monolithic architecture, the dependency still remained as problem. As applications were growing, they
started exchanging data with surrounding applications. The overall landscape became complex and overcrowded with peer to peer connections.
A new architecture emerged as a possible solution to this problem - Service Oriented Architecture (SOA).
SOA is basically a way to connect different monoliths in a consistent way.
SOA was well received by enterprises. There are SOA opponents who are saying that Enterprise Service Bus (ESB), as the main component of SOA infrastructure, became just another complex monolith. I personally think that any technology can be abused. SOA brings many benefits when implemented rationally and according to the best practices / design patterns.
SOA didn't do anything to the application scalability but the SOA concept introduced an important integration solution that helped applications talk to each other. The traditional implementation of SOA, offered by big vendors in this space, didn't do much favour to the integration architecture style but it paved the way to the more lightweight services.
Finally, our scalability cube becomes complete. By employing a combination of previous architectures, you can almost find your way to the
infinite scalability point and get that Holy Grail of architecture. Almost...
The journey through the architecture styles now meets Cloud. No application can scale infinitely unless the underlying infrastructure can scale infinitely. Luckily, one bookstore came up with the solution several years back. Amazon was the first to open its infrastructure to the public. Soon after, other major players (Microsoft, Google) followed and now we have over 15 cloud providers out there.
Not only has cloud introduced managed services for all of our application and network components (managed databases, DNS, load balancers, storage, computing etc.), it went even further and invented something completely revolutionary - Serverless architecture.