Microservices are a popular option for application modernization. For one thing, they are cost-effective, making them ideal for smaller companies. Also, microservices can be cloud-native, saving the space required for on-premise systems. More importantly, microservices deal with the issues of monolithic applications. To name a few:
- Hard and slow to maintain and test.
- Fixing a feature with bugs or under maintenance represents downtime for the whole application.
- Difficulty to manage different languages.
Still, the main perk of microservices in comparison with monolithic applications is scalability: microservices capacity can be configured to scale dynamically to match how much they are demanded in a given time.
In this article, we will discuss defining and administrating microservices. We will see that defining microservices and their scalability is as much of a business question as a technical one.
What is microservice scalability?
The microservice architecture is a way of designing applications in which each of its modules, components, or functions fit into separate programs. By design, each microservice is meant to have a single functionality. Despite microservices working together, they are independent: they have their own database and communicate with other microservices through their APIs instead of relying on language-level communication or function calls.
These design choices are what separate microservices from monolithic applications. In comparison with monolithic applications, the microservice architecture offers the following perks:
- Integration: Due to their modularity, microservices can communicate with the client-side without calling another microservice first. Also, since microservices are language agnostic, they can communicate with each other without problem despite which language they are written in.
- Fault tolerance: Their independence ensures that a fault in one microservice won’t make another fail.
- Maintenance: They are easier to fix given the size of their code and independent diagnosis. In addition, systems can be maintained with short downtimes before redeployment.
Withal, the most important feature of microservices is scalability. Monolithic programs share the resources of the same machine statically. Microservices, in turn, scale their specs when demanded. In this way, microservices architectures can administer their resources and allocate them where and when they are required.
How to define microservices and scalability
We interviewed Richard Reukema, software architect at Optimus Information with decades of experience in the IT field, about microservices scalability. For starters, he believes that granularity (how minimal microservices can be) can be detrimental if not properly defined: “I’ve seen microservices used to the point where they’re so granular, that there are so many microservices, that there are so many REST calls that the whole system just can’t operate at scale.” As the number of microservices increases, so does communication complexity. Plus, since they have separated databases and logs, maintaining a large number of microservices is more demanding. Likewise, converting small applications into microservices is not worth it in most cases; in comparison to small applications, a microservices architecture is more complex to maintain and implement. Therefore, the main problem with microservices is correctly defining their size.
Yet, taking into account the application functions as a whole and the optimal balance between granularity and independence is just part of solving the issue. According to Richard, what defines applications as monolithic is their companies’ business operations. In his own words, “application architecture never defines implementation; it only defines the responsibilities of the business.” He understands that “if a business had a help desk and the help desk took calls from every aspect of the organization, it would be a monolithic application because every time the phone rang, somebody would have to answer that call.” In this way, an application will be as monolithic as the business processes of its organization let it be.
Hence, a way of avoiding microservices becoming monolithic is decentralizing their communication channels. “If you want the delivery calls to go to the delivery people, and sales calls to go to the salespeople and the inventory to the inventory people, you suddenly have a department that either has an operator that routes the calls to the right department or you give the phone number to the people, and say, this is our area of the business that handles these different aspects of the business, and that’s no different to the API.”
How to define scalability
After defining the right size for the microservices, these can be implemented and mapped up to containers. According to Richard, “the benchmark for containers is scalability: If I have a very small API, but it is handling three hundred thousand requests per second, it’s got to be able to scale very quickly, and more importantly, it should scale in”. Container servers scale in when their system capabilities (CPU, memory, network bandwidth, etc) are increased to match the demand the system requires. Containers autoregulate their resources in two main ways:
- Scale up or vertical scaling: Increasing the application capacity by augmenting the capacity of your servers—virtual or physical. Preferred for stateful apps since these require keeping the client information between sessions to work.
- Scale-out or horizontal scaling: Increasing the number of server instances to manage demand. Preferred for stateless applications since these don’t store client info.
In the case of scaling out, there’s also the idea of “scaling in,” that is, reducing server instances when the demand goes down. In this way, scaling can also improve microservices’ cost-effectiveness. To Richard, learning when to scale in is as important from a business perspective as scaling out: “If you can scale out as you’re generating revenue, and scale in when you are not incurring revenue, you’re saving expenses.” Hence, the business practice of minimizing expenses should also be taken into account when designing computer systems.
The bottom line
Microservices have made it possible to administer a system’s capacity much more easily and efficiently than monolithic applications. However, as we have seen, microservices are not the end of monolithic applications. As such, when designing microservices, we need to keep an eye on our business operations, and not exclusively focus on the technical aspects of the implementation.
To learn more, check out our blog about Legacy Systems: The Risks of Postponing Application Modernization.
