Introduction and review of Monolithic and Microservice (Part 1)

In this article, I’m going to provide you with microservice architecture and the advantages and features of this type of architecture as well as data management in microservice architecture and when and where we use this architecture. In three sections: Introduction and review of Monolithic and Microservice part 1, introduction and review of Monolithic and Microservice Part 2 and introduction and review of Monolithic and Microservice Part 3. Stay with me.

Introduction of Monolithic and Microservice

Today, due to the pervasive and growing needs created by enterprise applications and applications, a new discussion about microservice in the field of software development has opened. The reason for this is also that developers are forced to use the microservice architecture to expand large trading systems. In recent years, microservices, as one of the most up-to-date and popular methods of architectural design of software systems, have been able to assume a significant role and be recognized. During this period, many articles and discussions have also been raised in this regard to the extent that many of the leading companies and companies such as Netflix, Sound Cloud, Amazon, etc. have been raised. They also use microservice architecture extensively.

We know that server-side applications are involved with many users and data coming into the server on their behalf, as well as responding to this data and providing web services. These programs should not merely perform these tasks, but they should also have time to update and upgrade themselves, this is known in the software world as the development of programs. To develop an app, 2 microservice architecture models or Monolithic architecture can be used. Before entering the microservice architecture discussion, we first talk a little bit about Monolithic architecture.

Monolithic Architecture

In this type of architecture, different parts of the server-side app, such as online payment, account management, notifications, and other sections, are all assembled in one unit. In other words, if the web application, which is located on the server side, uses all its sections to respond to user-side requests and work with databases or to perform algorithms, we say that it is based on monolithic architecture. In this situation, the whole system runs in the form of an integrated software. To understand the nature of microservices, it is best to first get acquainted with the performance of monolithic architecture. In this type of architecture, there are three layers. The Model layer or logic of the program, the View layer or the output of the program and the Controller layer or the interface between logic and the output of the program.

Monolithic architecture problems

In monolithic architecture, you need to increase the size by increasing the program traffic on the server side, in order to respond to the program. This means that the web application must be re-run on different servers. In fact, according to the monolithic architecture description, the entire program runs on each server with all its parts, regardless of whether or not these sections are needed.

Monolithic architecture, also known as MVC architecture, also has disadvantages. One of these disadvantages is the very close relationship between the three layers of this architecture, so that for example, we can’t take the model layer of a program written with the MVC architecture and use it in another project.

As you can see in the image above, in monolithic architecture, there is a central core to connect users and other services with it. This core is modular (partitioned), all modules are located together under the supervision of a single platform and system, and it is almost not possible to separate the modules from each other because of its excessive difficulty. Although in the MVC architecture, unlike in the past when the modular concept did not exist and all the files were in the same folder, the codes are modular, but these modules need other modules to function properly and cannot be separated from each other. If we want to categorize problems with monolithic architecture, we can point to the following:

1. Since there is only one source code, all team members include front end developer, server-side programmers, etc. , must work on a source code. For example, if a team member wants to work on user management, he or she should get the whole project, create a local host and work on the project.
2. Any changes to one of the modules may change the performance of other modules.
3. During working with a program based on MCV architecture, due to the proximity and overconnection of layers with each other, it is practically very difficult to distinguish these layers from each other.
4. In a program that uses this type of architecture, components cannot be easily replaced with one of the newer and more optimized architectures, as in this case the whole architecture of the program will change.
5. The presence of any bug in one of the modules, with a strong probability, will affect the whole project.
6. If you use architecture in a program, there is no variety of programming languages, different databases, labs and different frameworks anymore, as it will be very difficult to communicate between them despite the MCV architecture.

Despite all these problems with MCV architecture, large companies such as Raisi such as Netflix orAmazon prefer to use microservice architecture.

Service-oriented architecture

Before we start talking about service-oriented architecture, or SOA, we first talk a little bit about two concepts of business logic or Business Logic and infrastructure or Plumbing.

To build an application, we first need to determine what to expect from the program and how is the computer going to do it? Business applications include a set of codes written by programmers that actually do what the computer needs to do. Converts to an understandable language for computers.

Some of these codes are suppliers of business logic requirements (such as adding one product to the user’s request) and others are infrastructure codes (such as codes for checking printer connections). The existence of both types of code is mandatory because if you do not describe the activities of the application in the logic section of the business (activities such as order registration, products, customers, user account, etc.) you will forget the output, or if you do not specify the operations related to the infrastructure, the computer will not be able to perform its tasks and practically your application will be unused.

One of the biggest problems that programmers have been dealing with in the past was that when writing the codes of an application, they were barely able to separate the code from the underlying layer from the logic layer of the business, so they had to control the two layers simultaneously. There is no problem in service-oriented architecture and they can be considered separately even though both layers are related to each other. If these two layers are separated correctly, if you want to make a change to one of the layers (e.g. call an application at some stage of the process), this change will be very low cost and simple if the layers are not properly separated, such changes will take a lot of time and cost from the programmers and will be very complicated and in need. Will be tested.

SOA architecture is a new and growing and evolving way to build applications distributed with Distributed Application. In this architecture, the Services are actually distributed with defined and specific interfaces that process and exchange XML messages. With this architecture, solutions can be presented that Muhammad is not bordering on the domains of the organization or company. Using soa architecture, we can build a solution for integration with high autonomy in a company that has different systems and applications on different platforms that ensures a uniform and uncoordinated flow of work.

Example:

A person who has made online purchases from store sites is almost familiar with the concept of the services. Once you have registered your order, you will need to enter your bank card information to complete the purchase. In this case, the amount of credit on your card is checked and verified by a secondary service (such as the Shaparak service in Iran). After final confirmation of the purchase and definitive registration of the order, the company receiving the order will deliver your goods to you through a transport service provider (e.g. post). The need for service-oriented architecture, in another aspect, is also quite evident in ecommer applications. For example, if the component for payment by credit card is offline or disabled, the sales process will not stop and orders will be registered and payment operations will be postponed to another time.

Like other distributed architectures, SOA architecture also makes it possible to build applications using components located in separate domains. The SOA architecture uses web services as points for application entry, which is conceptually similar to proxy and stub components in old distributed systems, except that here, the connection between the user and the web service is much freer and more independent.

In addition, soa architecture is unique due to its important factors such as service reliability, message comprehensiveness, transactionality and messaging security. In the real world of trading, one cannot count on services that process a request solely for the sake of understanding. In fact, in business matters, there is also more certainty and certainty. Of course, it is natural that sometimes different systems are inactive or offer different answers on different occasions, but none of this should be done solely to exclude or not respond to a unique request.

In addition, there should be no ambiguity in the way a service is called. If a system offers its capabilities as a web service, then the way that service is called should also be clearly documented and announced. Many of the issues related to accessibility and scalability of applications in the past have been solved today despite the SOA architecture, which is likely to be violated at any stage of the application process. In the SOA architecture, we assume that there is an error and that it can happen. Therefore, strategies and strategies have been developed. For example, if a service fails to accept a message in the first step, due to the solution provided in the SOA architecture, this message will be resended, or if the system is not fully available (something that should never happen in the system with soa architecture), then the architecture is designed so that errors that lead to a complete disconnection of the service request are not possible.

The SOA architecture increases reliability because temporary errors that occur as part of the program’s implementation process cannot stop the entire trading process. In general, soa architecture presents an evolved process and hence can be considered as an evolved example of web services and integration technology. In the SOA architecture, it has also been noted that high-importance systems built on the basis of distributed technologies must provide certain guarantees. In these systems, there should be assurance that the routing and guidance of service requests is done correctly, and in addition, responding to these requests is done at the right time. It should also introduce the communication policies and interfaces of these services in a very clear manner.

SOA is an architecture that serves a service to simplify integration activities as well as to use reusable components in the loose connection method in the form of a building block. In fact, SOA architecture is a kind of design pattern. This template is designed to provide services through protocol to other programs. In fact, SOA architecture is a concept, not a programming language or a platform.
One of the primary problems for implementing SOA architecture is the lack of agreeableness of most people with the basic concept of block building or service. Many definitions of the service, such as flexibility and speed of action, represent concepts such as instability and brevity. Naturally, no one is in favor of a slow or uncompromising software that doesn’t meet practical needs, but in reality, people have an opinion contrary to this thinking, and despite the compatibility and speed that SOA architecture has, there aren’t many fans for it.

Service features and service-oriented calculations

Service-oriented computing, or SOC, is an example of calculations in which the design and development of functional systems is based on the service as the main element. Services are elements that are separate from platforms and are responsible for assisting in the construction of fast and inexpensive distribution systems. The Services also enable organizations to implement their functions through XML-based languages and protocols and place them on the Internet or intranet. Since the Services are provided through different organizations and companies and must be available to users 24/7, they must comply with the features we refer to below.

1. The services must be technology-independent. This means that the use and calling of the Services must be performed through all environments (different operating systems and different programming languages) and do not depend on a particular platform.
2. There should be minimal communication between the requester and the service provider. In other words, the applicant should not need to know the internal structure or how to implement the service. For this purpose, calling a service instead of calling an API is done through the use of a message mechanism.
3. The applicant should not need to know where the service is located. In other words, the service-oriented architecture should support Location Transparency. In this feature, the location of the service and its specifications are placed in a repository and the requester obtains the necessary location and information by calling it from this repository.

And in the end,

The Services can be provided in two simple and hybrid forms. Hybrid services are services that are created based on the use of a few simple or combined services with each other. For example, it is possible to have a distributed system based on a few simple services such as billing, order registration, customer relationship management, etc. Create wider, professional-related hybrid services. Service-based systems are a community of standalone services that provide users with their functions through defined interfaces.
WSDL or Description Language Web Service is one of the most widely used ways to define these interfaces, by which details are defined to connect the requester to the service provider.

To view the following article, see part two: