Scalability Analysis of Microservices Architectures

Zarema — Fri, 29 Mar 2024 20:28:45 +0000

What are Microservices?

Microservices are a software development architecture that organizes an application as a collection of loosely coupled services. Each service is self-contained and performs a specific task. Microservices communicate with each other through APIs.

For example, the user authentication microservice can provide an API that allows the product catalog microservice to verify the identity of a user before returning product information.

Importance of Scalability

Scalability is paramount in microservices architectures due to their distributed nature. The ability to handle increasing loads efficiently ensures that applications can meet user demands without compromising performance or reliability. Scalability also plays a significant role in cost-effectiveness, as it allows for optimal resource utilization.

How to Scale Microservices
Thera are two ways to scale microservices

Horizontal
This involves adding more microservice instances to handle the increased load. It’s the most common type of scaling for microservices. You can add new containers or virtual machines to distribute the load across multiple instances.
Vertical
This involves increasing the resources (CPU, memory, etc.) of an existing microservice instance to handle additional load. While it can provide a short-term performance boost, it has limits. In the long term, it’s more cost-effective to use horizontal scaling.

Performance Testing

I have conducted some performance tests on scaled and unscaled service. The service is a really simple one, so we will not go in depth into it. It is written using Flask snd tested using Locust, and here are the results:

Requests: 124465

Fails: 18154

Median (ms): 11000
95%ile (ms): 28000
99%ile (ms): 35000
Average (ms): 12237.01
Min (ms): 1
Max (ms): 40469

This is the unscaled server results, it was tested by sending 1000 requests every second. So was the scaled version:

Requests:112234

Fails: 689

Median (ms): 2
95%ile (ms): 3500
99%ile (ms): 6700
Average (ms): 364.78
Min (ms): 1
Max (ms): 19605

I used 3 instances for scaling, and on the graph we can clearly see where one of the instances crashed and others had to work overtime because of it, but because of this "teamwork" the amount of fails decreased drastically.

Summary

Scaling microservices is important because it allows your application to handle increased demand and traffic efficiently. By scaling microservices, you can ensure that your application remains responsive, reliable, and performs well under varying load conditions. This scalability enables your application to meet user demands, maintain high availability, and support business growth without sacrificing performance or user experience.

Comparative Study: RESTful vs. GraphQL Architectures for GitHub APIs

Zarema — Sun, 03 Mar 2024 18:15:13 +0000

In this study, I compare the performance, flexibility, and client experience of RESTful and GraphQL architectures for GitHub APIs.

Architecture Selection
I selected GitHub APIs implemented in RESTful principles and GraphQL query language to ensure a fair comparison.

Performance Testing
As part of my performance testing, I measured the time it takes to fetch repositories from IBM, as well as the time it takes to create and delete repositories using both APIs.

Fetching Repositories:

As we can see
REST fetched 700 repositories in 10.719 seconds.

And GraphQL fetched 900 repositories in 10.345 seconds.

Creating and Deleting Repositories:

my usage

REST created 15 repositories in 16.887 seconds and deleted them in 9.311 seconds.

GraphQL created 15 repositories in 16.040 seconds. But, unfortunately, had no support for deleting.

Flexibility and Extensibility

With RESTful APIs, adding features and modifying endpoints can be straightforward, especially for developers familiar with RESTful principles. Endpoints are typically designed to represent resources and actions, making it intuitive to add new resources or modify existing ones. However, as requirements evolve, RESTful APIs may face challenges such as endpoint proliferation or the need to version endpoints to maintain backward compatibility.

In contrast, GraphQL offers a more flexible approach to adding features and modifying endpoints. Its single endpoint allows clients to request precisely the data they need, eliminating the need to create multiple endpoints for different use cases. This simplifies the process of adding new features or modifying existing ones, as developers can extend the GraphQL schema to accommodate new requirements without impacting existing clients.

Evaluation and Recommendations

While both architectures offer capabilities for accommodating evolving requirements, GraphQL's flexibility and ease of schema evolution provide a significant advantage in adapting to changing needs. With RESTful APIs, careful planning and versioning strategies may be necessary to manage endpoint complexity and ensure backward compatibility as requirements evolve.