Scalability

Applications may be small or large depending on the needs of the project. We have to consider multiple types of scalability such as performance, maintenance, and cost to succeed with our applications over long periods. Let’s take a look at the different types of scalability.

Scalability of performance

Performance is the most common consideration of scalability. As our application gains more users, more data, and more features, we want it to be fast and responsive. An application that has successfully scaled performance-wise will have similar, or at least acceptably slower, response times with 1,000 client connections as it does with 50,000 client connections.

Scalability of maintenance

Maintenance scalability is a significant concern to application developers. Maintenance occurs when we add new features, debug issues, or ensure uptime of an application over time. Poor maintainability means that developers have to spend more time—often in frustration—when adding features or diagnosing existing problems in an application.

Leveraging programming best practices and clear boundaries in our application is time-tested to ensure future maintenance.

Luckily for us, Elixir gives us the ability to write our systems with very clear layers and boundaries. Layers can nominally increase the amount of computation in our application, but well-designed layers give us many maintenance benefits by making it easier for us to make changes.

Scalability of cost

Cost is easy to take for granted. As developers, we’re often separated from the financial cost of our applications. However, we can control several different components that contribute to the cost of our application. We can conserve, or spend, server resources such as CPU, memory, and bandwidth. We will also experience costs associated with future development time that we want to minimize.

Elixir, and more specifically Erlang/OTP applications, can have relatively low costs compared to other languages. There are examples of large Erlang applications, such as WhatsApp, running with millions of users but with a small number of servers and a small team of engineers. These types of success stories are rare, of course, and depend on the type of application being developed. However, the technology has been vetted and proven to be successful at keeping costs low in large applications.

The tension of scalability

The different types of scalability exist in tension with each other. This can end up causing our applications to reduce one type of scalability when we increase another. It would be ideal if we could maximize every type of scalability perfectly, although the reality is that this is very difficult to do.

We might know the old rule of thumb: “Fast, reliable, cheap—pick two.” Let’s look at how the different types of scalability hold each other in tension.

Performance vs. cost

We can often increase application performance by paying for additional server resources and throwing hardware at the problem. This technique improves performance without addressing the root cause that causes the performance problem. It may also be early in an application’s existence, and new feature development is prioritized over performance.

Example

An example of acceptably reducing cost while also reducing potential performance is to scale the number of servers down during periods of application inactivity. You can successfully reduce cost this way, as long as the application can properly serve requests.

Performance vs maintenance

Writing high-performance code can also mean writing complex and harder-to-maintain code. One way to increase application performance is to reduce or remove boundaries in code. For example, tightly coupling a communication layer to the server implementation could optimize a solution that directly processes incoming requests. However, boundaries exist to create more understandable and maintainable code.

By removing the layers, we could potentially reduce the ability to maintain the code in the future.

Most applications should focus on maximizing their maintenance ability because this allows new features to be easily added over time. However, there may come the point when performance needs become greater than the need to add new features.

Maintenance vs. cost

Maintenance involves people, and people are expensive. By reducing the difficulty of maintenance, we can save development hours in the future and reduce costs. We can also minimize costs by not fixing technical debt over time. This could reduce immediate costs but potentially increase maintenance costs.

Maintenance and cost are often very important to technical managers or non-technical stakeholders in an organization. As developers, we must consider their perspectives to help ensure the long-term success of our projects.