모놀리식 대. 마이크로서비스 아키텍처: 마이크로서비스는 사라지고 모놀리스가 돌아왔습니다.

여러분 중에 기술적인 데자뷰 현상을 심하게 겪고 있는 사람들이 있다면, 그건 틀린 생각이 아닙니다. 이것은 앤 토마스 메인스가 SOA(서비스 지향 아키텍처)의 종말을 선언한 2009년경의 상황과 동일합니다. 이 링크는 메인스의 게시물에 대한 데이비드 린시컴의 해설로 연결되는데, 원본 게시물은 인터넷에 퍼진 듯합니다.

이제, Manes는 과장된 표현을 했고 다소 비꼬는 말을 했습니다. 왜냐하면 우리가 잘 알고 있듯이 서비스 지향 아키텍처는 사라지지 않았기 때문입니다. 그것은 마이크로서비스로 매우 빠르게 부활했고 인터넷의 한탄으로 인해 설계자들은 여전히 "네트워크"가 성능에서 얼마나 큰 역할을 하는지 배우지 못했습니다.

SOA는 두 가지 이유로 '죽었습니다'.

1. 경쟁적이고 부풀려진 XML 기반 표준으로 인해 아키텍처가 지나치게 복잡해졌습니다. WSDL, SOAP, UDDI를 좋게 기억하는 사람은 아무도 없습니다. 아무도.
2. 물리 법칙과 상호 운용성 표준은 네트워크 패킷 교환을 빛의 속도와 1500바이트로 제한합니다.

우리는 첫 번째 도전은 극복했을지 모르지만 두 번째 도전은? 두 번째 질문에 대한 유일한 답은 서비스 설계의 세부성과 서비스 간 데이터 전송에 걸리는 시간에 대한 적절한 이해 사이의 섬세한 균형을 맞추는 것이었고 지금도 그렇습니다.

데이터 전송은 무료가 아닙니다. 시간이 걸리죠. 서비스 간 통신에 있어서 "비용이 0원"이라는 것은 없습니다. 패킷을 전송하는 데 걸리는 시간, 패킷을 전송하는 데 걸리는 시간, 패킷에서 패킷을 제거하는 데 걸리는 시간, 그리고 최종적으로 처리하는 데 걸리는 시간이 있습니다. 그리고 운송 수단에 대한 통신에도 시간이 걸린다는 사실을 잊지 마세요. 소켓을 열고 요청을 수락하는 일도 무료가 아니며, 서비스가 처리할 수 있는 형태로 페이로드를 직렬화하고 역직렬화하는 데 걸리는 시간도 무료가 아닙니다.

이제, 그 총 비용을 당신이 사용하려고 하는 서비스의 수로 곱하세요.

시스템을 더욱 세부적으로 설계할수록 요청을 처리하는 데 걸리는 시간이 더 많아집니다. 즉, 요청을 처리하는 데 걸리는 총 시간은 요청이 통과해야 하는 서비스 수에 따라 달라집니다.

더욱 세부적인 정보? 처리 시간이 길어짐. 더 많은 서비스를 원하시나요? 네트워크 혼잡이 심화되고, 네트워크 카드와 장치가 패킷을 정리하고 재전송을 요구하면서 처리 시간이 늘어납니다.

따라서 SOA와 마찬가지로 마이크로서비스도 지나치게 세부성에 의존하는 디자인 패턴으로 인해 어려움을 겪을 수 있습니다.

Amazon은 자사의 마이크로서비스를 대체하기 위해 모놀리스를 선택했습니다. 즉, 해당 사용 사례에서는 모놀리식 아키텍처가 가장 좋은 옵션이었습니다. 그렇다면 마이크로서비스는 사라졌다는 말인가요?

아니요. 대신, 우리는 두 가지 핵심 요점을 알아야 합니다.

• 첫째, 우리는 아마존에서 힌트를 얻어 서비스에 의존하는 시스템을 설계하는 방법에 대해 더욱 신중하고 사려 깊게 접근해야 하며, 너무 많은 소규모 서비스에 업무를 분배하는 것이 성과에 미치는 영향을 이해해야 합니다.
• 두 번째로, 모놀리스는 실행 가능한 애플리케이션 아키텍처 선택이라는 점을 기억해야 합니다. 기업 앱 포트폴리오의 60%가 "기존" 아키텍처를 기반으로 하는 애플리케이션으로 구성되어 있고 , 조직의 16%가 이를 폐기할 계획이 없는 데에는 이유가 있습니다.

애플리케이션 아키텍처는 좋고 나쁨이 없으며, 모든 사용 사례에 적합한 것도 아닙니다. 조직은 한 걸음 물러나서 자신들이 달성하려는 것이 무엇인지 신중하게 고려하고, 유행이라는 이유만으로 가장 "현대적인" 아키텍처를 선택하는 대신 어떤 아키텍처가 그러한 요구에 가장 잘 부합할 수 있는지 고려해야 합니다.

미래가 하이브리드 IT라고 말할 때, 우리가 의미하는 것은 단순히 멀티 클라우드와 온프레미스 배포를 혼합한 것 그 이상입니다. 또한, 예측 가능한 미래에도 기업용 앱 포트폴리오는 전통적 앱과 현대적 앱을 섞은 하이브리드 형태로 유지될 것입니다. 이것이 F5 포트폴리오가 온프레미스나 퍼블릭 클라우드, 혹은 둘 다에 있는 모든 애플리케이션을 계속 지원하는 이유입니다.