Microservices

Software Architecture | blackthorn.ai

Microservices is an approach when the application is split into a set of independent components with clear boundaries and responsibilities. Each operates separately and performs one distinct function. Such a system has superior modularity and scaling capabilities — as a result, it is easier to maintain, test, and develop. Plus, a micro-component of interest can be updated, added, or deleted without modifying the whole system.

But everything comes at a price — the microservices simplify your life in one way and make it difficult in another. Here, the complexity is added to provisioning proper interplay and deployment of the components.

As usual, there are no “good” and “bad” architectures — it’s all about choosing the right approach for the case. So let’s dive deeper to understand all ins and outs of a microservices application.

The setup

To make everything clear of what microservices architecture is, let’s start with a typical example. Suppose we’re making a server-side enterprise application:

1. We want to effectively serve multiple clients: mobile applications, websites, etc. The app may vary for different devices and browsers. We also may want to connect this app to other apps through APIs.
2. Our app and accessory connections may happen through web services or a message broker.
3. Our app should reply to HTTP requests by executing business logic, interacting with a database, exchanging messages with other systems, etc.
4. The app comprises blocks subjected to various loads. These parts need to be scaled individually.

These are pervasive problems for many and deserve an intricate technique to address.

Brief

The main idea is the following: the application is arranged as a set of loosely coupled services interacting through a message broker.

Typically, each microservice has its database. The technology stack may vary from component to component, as well as engineering teams. Services interact via HTTP/REST or AMQP employing a message bus. The synchronization of the states of the microservices brings pain, lol.

Conceptual diagram

Let’s consider the characteristic components of the architecture (simplified):

• API Gateway receives clients’ requests, transforms if needed, and routes them to a target microcomponent.
• A user interacts with the service through a web or mobile app that is connected to the API gateway.
• Microservices A and B comprise the backend that encapsulates the business and interacts with databases.
• Microservices A and B communicate through the message broker.

Microservices application conceptual diagram. Image by the author. © All rights reserved

Why microservices?

Usually, a small project or a proof-of-concept is started with a monolithic application as it is straightforward and quick to implement.

A monolithic application is one inseparable unit. Everything is molded on the same platform, using the same coding language and database. The struggle comes when a piece of the monolith requires an update or a new feature is added. Unraveling one dependency after another, you end up overwriting the whole system to change or add functionality. And then another feature request comes…

You’ve got the point — the monolith is rigid due to the tight coupling of the components. Every next update is more painful than the previous one.

Use cases

Here’s the central question: when do you need microservices?

Usually, startups begin with the simplest monolithic application to move quickly. Although it may be the case — to raise money fast and move to the next phase — it is not recommended. The same thing that has helped at the beginning will stab you in the back later.

As soon as the survival stage has been passed, the business model evolvement phase comes. Here they need to scale and upgrade the application. Suddenly, it turns out that the functional decomposition takes more time than the development of the initial monolith app itself!

Thus, mind the future of the app and design it properly from day one.

AI, ML, Big Data applications

These kinds of apps:

• first, require a piece of business logic responsible for AI/ML/BigData to be detached as a separate component performing a specific task and demanding a dedicated team with a specific skill set to develop and maintain it.
• second, there are specific stages — like data collection, processing, warehousing, etc. — that must be loosely coupled with the core and able to scale fast and independently to handle spiky irregular loads.

You can learn more about how we develop AI/ML applications here.

MLOps and DevOps

The image below represents typical MLOps workflow stages:

• Model development includes training, cross-validation, hyperparameters tuning, and selection of the best ML models as the result.
• Preparing for the production encapsulates ML model runtime environment development.
• During deploying to the production step, the ML model component is integrated and deployed to the production environment.
• Monitoring and feedback loop microcomponent tracks ML service liveness, resource utilization, and records real environment feedback. The loop microservice automatically triggers retraining of the models and stores model predictions aligned with the values of features and metrics.

The steps above are naturally mapped to appropriate microservices.

MLOps workflow. Image by the author. © All rights reserved

You can learn more about how we do MLOps here.

Online streaming

Millisecond response latency, infinite and immediate scalability requirements — you’d better have these components somewhere aside and adequately encapsulated.

Examples: Media streaming platforms, search engines, large financial services

Managing big teams

Remember the joke “What one programmer can do in one day, two programmers can do in two days”?..
Consequently, applications could be split into independent services to entitle numerous development teams’ unbounded performance.

Large-scale and rapidly growing applications

There is simply no other choice in order to efficiently serve numerous users around the world. Don’t forget that in parallel with serving users we need to develop, deploy, and test new features without breaking existing UX.

Third-party services integration

Such third-party services as ETL and BI apps, logging and monitoring tools, various plugins have unique software stack demands, require 100% uptime, unique computational resources, and scaling needs. Luckily, they have apparent component borders and could be easily isolated as microservices.

Takeaways

Applications based on microservices are the most adopted type of software architecture. It has been embraced by 63% of enterprises worldwide. It enables modular software development, flexible scaling, and fast delivery of large and complex applications.

It is important to employ the proper design of the application from the very beginning. Microservices are usually a good fit for AI, ML, and Big Data applications; MLOps and DevOps workflows; online streaming; large-scale and rapidly growing application. Also, it is a well-adopted approach for the integration of third-party services and performance optimization of big dev teams.

Remember that microservices architecture is not a silver bullet — due to added complexity of provisioning interaction and deployment of the components.

Good luck and best wishes!

© All rights reserved
Oleksandr (Alex) Gurbych (LinkedIn, Gmail)
February 12, 2022