어떤 서비스를 만들때에 Monolithic으로 만들어야 할지? Monolithic으로 만들고 Microservices로 구성해야 할지? 아니면 처음부터 Microservices로 구성해야 하는지에 대한 고민이 생긴다.

Microservices는 최근 급속히 발전하는 많은 기업이 소프트웨어 아키텍처로 이동할 것을 고려하고 있다.

Microservices 또는 Serverless로의 이동은 잘 만들면 금융, 소매, 마케팅, 데이터 분석 및 기타 여러 산업에서 효율성을 가져 올 수 있다.

위 그래프는 2017년에 도입되었거나 2018년도에 도입해야 하는 최우선 기술들을 표현한 그래프이다.

제품이나 서비스가 잘못 설계되었을 경우, Microservices를 적용한다고 하여 품질이 향상되지는 않는다. (그 이유는 똥을 분리해봐야 똥이기 때문이다.)

마이크로서비스를 적용해야 하는 경우

위의 똥 그림 때문이라도 이글을 읽는 당신은 마이크로서비스에 대해서 이해를 해야 한다.

Microservices 제품은 API를 통해 상호 작용하는 형태의 분리된 구성으로 소프트웨어를 설계하는 아키텍처에 대한 방법이다.

• 기능을 분리하는 동안, 여전히 일부 중복되는 기능과 코드가 존재한다.
• 주요 기능을 수행하는 것 이외에, 마이크로서비스는 API를 통해 다른 모듈과의 연결을 지원한다.
• 마이크로서비스는 개별적으로 개발이 될 수 있지만, 상호 의존성에 대한 부분이 존재하고 이는 출시 전에 테스트가 심도있게 되어야 한다. 특정 마이크로서비스의 일부 기능은 다른 마이크로서비스에서 사용할 수 있기에 특정 서비스가 업데이트되면 다른 서비스에 영향을 줄 수 있기 때문이다.

기술적으로 분리를 하더라도 마이크로 서비스는 여전히 상호간 의존하기 때문에, 이 의존성을 낮추기 위해서는 몇가지 기능을 복제해야 하는 상황이 발생할 수 있다.

이런 상황에 대한 부분은 아래와 같다.

• 제품의 일부가 개별적으로 재부팅 할 수 있어야 하며, 이는 복원력을 향상 시킬 수 있다.
• 많은 기능이 의무적인 상호 작용의 수를 줄이기 위해서 분리 되거나 하여 개발의 복잡성을 줄일 수 있어야 한다.
• 새로운 기능의 시장 출시 시간을 단축할 수 있어야 한다.

개발시에 위와 관련된 고민 사항들도 있지만, 운영의 복잡성도 상당하다는 점을 알고 있어야 한다.

즉, 기존의 Monolithic을 분할하게되면 운영의 복잡성을 증가한다는 것을 인지해야 한다.

그리고, 해당 기업의 IT부서가 이러한 시스템을 설계, 구현 및 유지 관리 할 수 있는 전문 지식을 가지고 있어야 한다.

만약, 이런 부분들이 고려되어 있지 않다면 마이크로서비스를 전환하는 것이 불행한 작업이 될 것이다.