Monolithic Architecture and Micro Service Architecture
Monolithic Architecture
모놀리식 아키텍처(Monolithic Architecture)란,
마이크로 서비스의 각광에 따라 마이크로 서비스가 아닌 전통의 아키텍처를 지칭하는 의미로 생겨난 단어이다.
모든 모듈은 서비스 내부의 Product 형태로 종속되어 있으며, 서비스에만 집중할 수 있는 구조로 되어 있다.
이는 Monolithic 이라는 단어의 뜻 그대로 하나의 Massive 한 Context 형태의 아키텍처를 의미하며
하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 가질 때, Monolithic 하다고 한다.
모놀리식 아키텍처 Software의 특징은 그 자체로 강건하며 내부 요소간의 Dependency를 크게 가질 수 있다는 점이다.
그리고 이는 필연적으로 구조적인 Coupling 이 강력하게 유지되는 결과를 초래한다.
또한 각 비즈니스 컴포넌트들이 하나의 강한 결합 구조를 지니며 통일성이 있다.
이는 비즈니스 로직이 서비스에 최적화된 코드를 만들어내는데 좀 더 집중할 수 있는 반면
복합적인 예외를 만들 수 있는 위험성을 내포하게 된다.
The monolithic architecture is considered to be a traditional way of building applications.
A monolithic application is built as a single and indivisible unit. Usually, such a solution comprises a client-side user interface, a server side-application, and a database.
It is unified and all the functions are managed and served in one place.
장점
단순한 아키텍처 구조로 개발, 빌드, 배포, 테스트가 용이하다.
Less cross-cutting concerns : Cross-cutting concerns are the concerns that affect the whole application such as logging, handling, caching, and performance monitoring. In a monolithic application, this area of functionality concerns only one application so it is easier to handle it.
Easier debugging and testing : In contrast to the microservices architecture, monolithic applications are much easier to debug and test. Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster.
Simple to deploy : Another advantage associated with the simplicity of monolithic apps is easier deployment. When it comes to monolithic applications, you do not have to handle many deployments – just one file or directory.
Simple to develop : As long as the monolithic approach is a standard way of building applications, any engineering team has the right knowledge and capabilities to develop a monolithic application.
단점
프로젝트의 규모가 커질 경우 복잡도가 증가한다.
작은 수정 사항에도 전체를 새로 빌드하고 배포해야 한다.
Understanding : When a monolithic application scales up, it becomes too complicated to understand. Also, a complex system of code within one application is hard to manage.
Making changes : It is harder to implement changes in such a large and complex application with highly tight coupling. Any code change affects the whole system so it has to be thoroughly coordinated. This makes the overall development process much longer.
Scalability : You cannot scale components independently, only the whole application.
New technology barriers : It is extremely problematic to apply a new technology in a monolithic application because then the entire application has to be rewritten.
Micro Service Architecture
마이크로 서비스 아키텍처(Micro Service Architecture)란,
소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합된 모듈로 분해하여 서비스를 제공하는 아키텍처이다.
각 모듈은 개별적인 작업을 담당하며 독립적으로 개발, 배포가 가능하다.
모듈들은 잘 정의된 API를 통해 서로 다른 모듈과 통신한다.
While a monolithic application is a single unified unit,
a microservices architecture breaks it down into a collection of smaller independent units.
These units carry out every application process as a separate service.
So all the services have their own logic and the database as well as perform the specific functions.
장점
특정 서비스의 변경이 다른 서비스에 영향을 미칠 가능성이 적다.
따라서 개발과 배포, 수정이 유연하다.
모놀리식에 비하여 구조가 단순하며, 새로운 기술을 적용하는 것이 용이하다.
Independent components : Firstly, all the services can be deployed and updated independently, which gives more flexibility.
Secondly, a bug in one microservice has an impact only on a particular service and does not influence the entire application. Also, it is much easier to add new features to a microservice application than a monolithic one.
Easier understanding : Split up into smaller and simpler components, a microservice application is easier to understand and manage. You just concentrate on a specific service that is related to a business goal you have.
Better scalability : Another advantage of the microservices approach is that each element can be scaled independently.
So the entire process is more cost- and time-effective than with monoliths when the whole application has to be scaled even if there is no need in it.
Flexibility in choosing the technology : The engineering teams are not limited by the technology chosen from the start. They are free to apply various technologies and frameworks for each microservice.
The higher level of agility : Any fault in a microservices application affects only a particular service and not the whole solution. So all the changes and experiments are implemented with lower risks and fewer errors.
단점
서비스 간의 통신에 대한 처리가 추가적으로 필요하다.
데이터의 정합성을 맞추기 위해 추가적인 트랜잭션 처리가 필요하다.
분산되어 있는 서비스들을 통합 해서 테스트하고 운영하는 것이 어렵다.
Extra complexity : Since a microservices architecture is a distributed system, you have to choose and set up the connections between all the modules and databases.
Also, as long as such an application includes independent services, all of them have to be deployed independently.
System distribution : A microservices architecture is a complex system of multiple modules and databases so all the connections have to be handled carefully.
Cross-cutting concerns : When creating a microservices application, you will have to deal with a number of cross-cutting concerns. They include externalized configuration, logging, metrics, health checks, and others.
Testing : A multitude of independently deployable components makes testing a microservices-based solution much harder.
참고자료
1. Microservices vs Monolith: which architecture is the best choice for your business?(Eng)