Major software architectures: monolithic, service-oriented, and microservices

Let's start with a monolithic architecture. The concept of a monolithic software architecture implies that the application components are combined into a single program on a single platform. Typically a monolithic application consists of a database, a user interface, and a server application.

The main disadvantage of monolithic architecture is the cumbersome code base, which degrades the quality of the code and makes it difficult to understand. Implementing new technologies is also often difficult because you have to rewrite a lot of code. And because of the concept itself, the monolithic software architecture has limited flexibility.

Most companies use monolithic software architecture in one way or another. It is greatly suitable for startups that need to develop and release a product as soon as possible. Monolithic software architecture can be extremely useful if your team is at an early stage of development, you are creating an untested product, and you have no experience with microservices development.

Service-oriented architecture (SOA) is an architecture that assumes a modular application consisting of loosely coupled software components. According to this concept, the application is designed with easily integrated and reused modules.

Looking for developers who can design scalable, maintainable software architectures?

The main drawback of service-oriented architecture is its complexity and difficulty in managing all services. Also, SOA requires a lot of resources, both human and money. And the system itself has low performance when using multiple services simultaneously.

SOA is suitable for complex enterprise systems. This way, complex applications can be organized and then isolated into independent services. One striking example of the use of SOA architecture is Cisco. In 2010, Cisco introduced services to coordinate the process of ordering their products. Subsidiaries, business partners, and divisions were provided with services to add order-related processes to their websites.

Microservices architecture (MSA) is a type of software architecture characterized by the division of the system into separate components (independent services). Each individual service performs its own functions. Due to clear functions, services are easily scalable, and different programming languages can be used for their development.

The popularity of microservices among developers is growing every year. An IBM study showed that 56% of organizations plan to migrate to MSA. At the same time, 78% of organizations that have microservices plan to invest further in their development. After all, they are suitable for large web products; if one service fails, the others will continue to work.

Large companies such as PayPal, eBay, and Amazon have gone from monolithic to microservices software architecture. Microservices architecture focuses on business priorities, while monolithic architecture emphasizes technology layers, user interfaces, and databases.

But what is the reason for such frenzied popularity of microservices? Is it worth changing the architecture? Let's figure it out by discussing the advantages and disadvantages of microservices system architecture.

Advantages of microservices architecture

In a monolithic architecture, the system usually consists of 3 blocks: the user interface, the data warehouse, and the server part. The server part processes queries, performs business logic, works with the database, and fills HTML pages. Any change in the system leads to an update of the server part of the application.

In the case of a microservices architecture, only the modified service is updated. If a change affects the interface of a service, it will require coordination of all its clients. A good microservice architecture aims to reduce the need for service coordination as much as possible.

Looking for engineers to optimize your microservices architecture?

Now let's discuss the pros and cons of monolithic software architecture.

High fault tolerance

If one of the services fails, the rest remain in operation. Thanks to this, a faulty service does not affect the work of others. However, at the stage of designing microservices, attention should be paid to how the unavailability of services affects the user experience.

Fault tolerance can be achieved through the absence of interdependencies of microservices. To do this, self-recovery options such as Kubernetes are better as an infrastructure. You can also use an API gateway with built-in resiliency and cache requests in a streaming processor like Kafka.

Scalability

Scalability is the ability of a system to increase performance by increasing the number of resources allocated to it. A microservices system architecture allows each service to scale separately without affecting the rest of the system.

While vertical scaling may be limited by the bandwidth of each individual service, horizontal scaling is not. In addition, it can be fully automated and work with microservices dynamically.

Ease of development, testing, and deployment of individual services

This architecture, under the word “services”, means not part of the back-end but the full implementation of the business logic. Each service is designed, built, tested, and deployed independently. This speeds up development and release.

Due to the fact that developers release individual services rather than the entire application, the risk of releasing a program part, which will disrupt the operation of the entire system, is reduced.

Disadvantages of microservice architecture

The microservice approach involves breaking the system into services based on business requirements. Services include a full set of UI, storage, and backend technologies. This leads to cross-functional teams with enough competence to implement all the necessary services covering 100% of the business functionality. Web development teams must be responsible for all aspects of the software they develop, including supporting it 24/7.

Complicated communication between services

Each individual service is physically isolated from the rest of the application. This is an advantage and a disadvantage of the microservice architecture simultaneously because now you have to intelligently build communication between services. And as the number of services increases, so does the complexity of their communication.

What is the way out of this situation? To build smart contracts between the services. The main idea of contracts is to unite program code and specifications. A contract is a formalization of the possibilities of interaction with a microservice. Service undertakes to fulfill a contract (condition) made with another service. If one service does not meet the conditions of the other, the contract is not executed. In the case of the REST API, the service's endpoints and data schema are the contract.

Difficulty in implementation

Dividing an application into microservices entails a lot of management artifacts. MSA requires planning and resources. It also increases the role of process automation, testing, and deployment, increasing service monitoring requirements.

To implement a microservice architecture, companies will have to adopt a DevOps culture and ensure interaction between developers, testers, etc. That is, change the way of thinking, especially when transitioning from monolithic architecture.

Reduced performance

When moving to microservices architecture, network latency increases. It is worth understanding that there will always be latency when communicating services. You can minimize the loss only by planning the product architecture.

Regression testing complexity

You need regression testing to make sure that fixing some bugs doesn't introduce new ones in other services. During regression testing, you must bring up all the microservices simultaneously.

The difficulty here is that you have to test more: separate services and their interactions with each other. This greatly increases the time and resources spent on testing, and the business, alas, is not ready for this.

We also recommend you read our article on how to scale a dev team.

What businesses should use microservices architecture

Microservices architecture is not for everyone. Often the consequences of the choice of this or that architecture become apparent only after some time has passed.

MSA suits you if the team is planning to develop a medium-sized web application that consists of a set of modules. And the modules are loosely coupled or isolated from each other.

MSA may also be a choice driven by business requirements to constantly make changes to the product and speed up the development process. This architecture is suitable for projects that require point-to-point scaling and changes at different points in the application.

Microservices are also applicable to products that are intended to use different technologies, such as multiple programming languages. Or when integration with external services (payment systems and banks) is planned.

For example, in 2013, Netflix switched from monolithic software architecture to microservices and continues to actively develop in this direction, creating more and more services. And Amazon has developed AWS using a microservices architecture. It is the world's largest cloud platform, which provides access to individual services on a subscription basis.

Choosing an architecture for a project is a complex task. Microservices are not suitable for all applications. Definitely, microservices are not your variant if your team doesn't possess enough knowledge and resources to implement them. MaybeWorks can augment your development team with microservices development experts that have over 5 years of experience in this domain.

Tools for microservices development

The logic of the service must fit completely in the mind of a single developer, regardless of the amount of code and people. When designing a microservices system architecture, you can choose how to design each microservice. For example:

Node.js for simple report pages
C++ for real-time applications
Python for data analysis
React for a high-loaded service
Java for integration with enterprise

Microservice architecture gives complete freedom in the choice of technologies and tools. In microservice architecture development, using CI/CD systems, orchestration systems, Service Discovering, monitoring, and logging is a great advantage:

GitLab CI, TeamCity, Jenkins, GitHub Action, and Circle CI are actively used for CI/CD
You can try Nomad or Apache Mesos as an orchestration system, and if you use Docker - Kubernetes and Docker Swarm
For Service Discovering, you can use Consul, Eureka, or Zookeeper
For monitoring and logging, you can choose the ELK or TICK stack or build your own monitoring system from individual products, including Prometheus, Grafana, and Graphite.

You need to be sure that the application is working correctly. This is done by running automated tests (Automated Deployment). A chain of synchronous calls to microservices will lead to waiting for all services' responses. So use the rule "One synchronous call per user request" as The Guardian or a completely asynchronous API as Netflix. One way to make an asynchronous API is to use a queuing system like RabbitMQ, Apache Kafka, or ActiveMQ.

MaybeWorks expertise in microservices software architecture development

Microservices carry a certain amount of complexity. So if you have an application that works well, you shouldn't ruin everything for fancy trends. If you've already decided to move to microservices, consider all possible implications to the business.

The team should not include more people than can be satiated by two pizzas. This is the rule Amazon used when transitioning from monolithic architecture to microservices architecture in 2002. The rule of developer per service is quite acceptable.

The last project where we assisted in microservices development was a platform for retail investors. It helps them track stocks, options, and crypto. It provides up-to-date news, accurate forecasts, and access to a community of like-minded traders and investors. MaybeWorks developers assisted in the development of the following microservices:

Price check. It checks alerts on the stocks page and is based on data from the Intrinio and Polygon services.
SMA check. It receives SMA50 and SMA200 values for specific stocks from the Polygon service, and based on them, MAs indicators are displayed.
Worker. It processes events from the AMQP queue.
Webhook. It receives data from third-party services using the webhook mechanism and adds an event to the AMQP queue to create a new history.
Websocket. It implements clients' notifications about various changes or events on the server side using the WebSocket ReactJS protocol. We have an article about WebSocket advantages and disadvantages.
Stock. It handles certain events from the AMQP queue.
Backtest. It calculates the strength bars for stocks.
Backend. It processes the main client requests by performing certain checks for platform security.

Using cutting-edge algorithms, the platform opens magnificent features such as real-time stock & options flow. To achieve this, MaybeWorks developers worked on performance optimization\refactoring, integration with third-party services (Stripe, Intrinio, Polygon, Slack, Sendgrid), and UI enhancements.

Feel free to contact us to discuss the assistance of microservices software architecture development.

Microservices Software Architecture: Everything You Should Know

CONTACT US

Microservices Software Architecture:
Everything You
Should Know