Scalability is the system’s ability to accept higher load (to grow) without degradation is called scalability. It´s one quality attribute to take in consideration in the architectural definition of enterprise applications. From my perspective, it´s one of the most important because bad architectural decisions that impact negatively in product scalability; it also impacts negatively in the growth of the product as well as in the growth of the enterprise which supports its business process in the underlying enterprise application. So it´s important to follow good architectural decisions on the product design to impact positively on the scalability.
Scalable hardware or software can expand to support increasing workloads. This capability allows computer equipment and software programs to grow over time, rather than needing to be replaced. Scalable software typically refers to business applications that can adapt to support an increasing amount of data or a growing number of users.
In order to impact positively the scalability of an enterprise application, we need to follow best practices. I will explain a bunch of techniques that I´ve applied during my career as a software architect to support correctly software scalability as well as I´ve confirmed by researching about this topic on these days.
The rationale behind the techniques is to split your application logic into several modules and sub-systems according to the principle of separation of responsability and the premise that if you can´t split it, you can´t scale it. Related pieces of functionality must belong together, while unrelated pieces of functionality must belong apart. Splitting your solution artifacts assures that the workload can be broken down into manageable units. These components must be decoupled and communicate each other asynchronously as much as possible.
At the application tier is implemented by the following techniques:
- applications in different application pool. This allows scaling each pool of processes and servers, according to the demand and resource consumption. Applications are further divided by sub-systems and components on separated processes or set of nodes (distributed processing)
- decoupling the components in different modules and sub-systems according to its responsability in the solution
- avoid synchronous communication (coupling) between the components as much as possible. Once the components are decoupled, then these components must communicate each other using asynchronous mechanisms using queues, multicast messages, ESB, batch process, so they can be scaled independently. The rationale is that if component A calls to component B synchronously (they´re tighly coupled), if you need to scale component A, you must also scale component B. Equally, this coupling impacts negatively on the availability of the system (if component B is not available, then component A may fail in its behavior)
- farm of applications using clustering and load-balancer techniques (if we need more processing power, we just add another node)
- business logic optimization (refactoring)
- application hosting environment tuning
- caching techniques (memcache)
- avoid distributed transactions
At the database tier is implemented by the following techniques:
- sharding (partitioning) the data horizontally and vertically
- running each partition on separated RDBMS or set of nodes
- farm of RDBMS using clustering and load-balancer techniques (if we need more processing power, we just add another node)
- optimization techniques (DBMS tuning, indexes)
At the infrastructure tier is implemented by the following techniques:
- OS tuning
- Storage system tuning
- Hardware optimization
In this article, I´ve covered the key concepts and principles of scalability in enterprise applications as well as a bunch of techniques that I´ve applied to impact positively in this important quality attribute.