마이크로서비스란?

마이크로서비스(또는 마이크로 서비스 아키텍처)는 단일 애플리케이션이 다수의 느슨하게 결합되고 독립적으로 배치 가능한 더 작은 컴포넌트 또는 서비스로 구성되는 클라우드 네이티브 아키텍처 접근 방식입니다. 이 서비스는 일반적으로 다음과 같은 기능을 제공합니다.

• 데이터베이스 및 데이터 관리 모델을 포함하여 자체 기술 스택을 보유하고 있습니다.
• REST API, 이벤트 스트리밍 및 메시지 브로커의 조합을 통해 서로 간에 통신합니다.
• 바운딩된 컨텍스트로 종종 참조되는 라인 분리 서비스를 통해 비즈니스 기능별로 구성됩니다.

마이크로서비스에 대한 많은 논의가 아키텍처 정의와 특성을 중심으로 전개되었지만, 이의 가치는 상당히 단순한 비즈니스 및 기업 이점을 통해 보다 일반적으로 이해될 수 있습니다.

• 코드를 보다 쉽게 업데이트할 수 있습니다. 전체 애플리케이션을 건드리지 않고도 새 특성이나 기능을 추가할 수 있습니다.
• 팀들은 서로 다른 컴포넌트에 대해 서로 다른 스택과 서로 다른 프로그래밍 언어를 사용할 수 있습니다.
• 컴포넌트를 서로 간에 독립적으로 스케일링할 수 있으므로, 단일 기능에 너무 많은 로드가 부과되어 초래되는 전체 애플리케이션의 스케일링과 연관된 낭비와 비용을 줄일 수 있습니다.

마이크로서비스는 무엇이 마이크로서비스가 아닌지를 통해서도 이해될 수도 있습니다. 마이크로서비스 아키텍처에서 가장 자주 언급되는 두 비교는 모놀리식 아키텍처와 서비스 지향 아키텍처(SOA)입니다.

마이크로서비스와 모놀리식 아키텍처의 차이점은 크고 긴밀하게 결합된 애플리케이션의 모놀리식 접근 방법과는 상반되게, 마이크로서비스는 다수의 작고 느슨하게 결합된 서비스로부터 단일 애플리케이션을 구성한다는 점입니다.

마이크로서비스와 모놀리식 아키텍처의 차이점을 자세히 알아보려면 이 동영상(6:37)을 시청하세요.

 

마이크로서비스와 SOA 간의 차이점은 다소 덜 명확할 수 있습니다. 마이크로서비스와 SOA 간에, 특히 ESB(Enterprise Service Bus)의 역할과 관련하여 기술적 차이를 유추할 수 있지만, 범위 중 하나로서 차이점을 고려하는 게 보다 용이합니다. SOA가 기업의 모든 웹 서비스가 서로 간에 통신하고 통합하는 방식을 표준화하기 위한 전사적 노력인 반면, 마이크로서비스 아키텍처는 애플리케이션에 특정합니다.

게시글 "SOA 대 마이크로서비스: 차이점"에서는 좀 더 상세한 설명을 제공합니다.

마이크로서비스가 기업에 제공하는 유용성

마이크로서비스는 개발자들과 마찬가지로 경영진 및 프로젝트 리더들에게 적어도 인기가 있을 것으로 보입니다. 아키텍처에 대한 열의가 일반적으로 소프트웨어 개발 팀을 향해 있으므로, 이는 마이크로서비스의 보다 특이한 특성 중 하나입니다. 이에 대한 이유는 많은 비즈니스 리더가 자체 팀과 개발 프로세스를 구조화하고 실행하고자 원하는 방식을 마이크로서비스가 보다 잘 반영하기 때문입니다.

달리 말하자면, 마이크로서비스는 원하는 운영 모델을 보다 용이하게 해주는 아키텍처 모델입니다. 1,200명 이상의 개발자와 IT 임원에 대한 최근의 IBM 설문조사에서 마이크로서비스 사용자의 87%는 마이크로서비스 채택이 비용과 노력의 가치가 있다고 동의했습니다. 아래의 대화식 툴을 이용하면 마이크로서비스의 장점과 문제점에 대한 보다 자세한 관점을 살펴볼 수 있습니다.

(출처: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

다음은 마이크로서비스의 엔터프라이즈 몇몇 장점입니다.

독립적으로 배치 가능

아마도 마이크로서비스의 가장 중요한 하나의 특징은, 서비스가 보다 작고 독립적으로 배치될 수 있기 때문에 더 이상 애플리케이션에서 코드 행을 변경하거나 신규 기능을 추가하기 위해 규율이 필요하지 않는다는 점입니다.

마이크로서비스는 사소한 변경에도 엄청난 양의 시간이 필요한 것과 연관된 감정적 좌절감에 대한 해결책을 기업들에게 약속합니다. 속도와 민첩성을 향상시키는 접근 방법의 가치를 보거나 이해하기 위해, 컴퓨터 사이언스 분야의 박사 학위가 필요하지 않습니다.

하지만 속도는 이러한 방식으로 서비스를 설계함에 있어서 유일한 가치는 아닙니다. 공통적으로 발생하는 기업 모델은 비즈니스 문제점, 서비스 또는 제품과 관련하여 교차 기능 팀들을 규합하는 것입니다. 기업이 하나의 서비스 또는 서비스 콜렉션과 관련하여 소규모의 교차 기능 팀을 구축하고 이들이 민첩한 방식으로 운용되도록 할 수 있으므로, 마이크로서비스 모델은 이러한 트렌드와 깔끔하게 들어맞습니다.

마이크로서비스의 느슨한 결합은 또한 애플리케이션에 대한 어느 정도의 결함 분리와 복원성 개선을 구축합니다. 그리고 명확한 경계 및 커뮤니케이션 패턴과 결합된 소규모의 서비스는 새로운 팀 구성원들이 코드 베이스를 이해하고 신속하게 이에 기여할 수 있도록 하며, 속도와 직원 사기 측면 모두에서 분명한 이점을 제공합니다.

작업을 위한 적절한 툴

기존의 n-티어 아키텍처 패턴에서, 애플리케이션은 일반적으로 전체 애플리케이션을 지원하는 대형 관계형 데이터베이스와 공통 스택을 공유합니다. 이 접근 방법에는 몇 가지 명백한 단점이 있습니다. 그 중에서 가장 중요한 점은 특정 요소의 경우 작업에 대해 명확하고 더 나은 툴이 있음에도 불구하고 애플리케이션의 모든 컴포넌트가 공통 스택, 데이터 모델 및 데이터베이스를 공유해야 한다는 점입니다. 이는 잘못된 아키텍처에 기여하며, 이는 이러한 컴포넌트를 빌드하는 보다 우수하고 효율적인 방법이 있음을 지속적으로 인지하는 개발자들에게는 당혹스럽습니다.

이와는 대조적으로, 마이크로서비스 모델에서는 컴포넌트가 독립적으로 배치되고 REST, 이벤트 스트리밍 및 메시지 브로커의 일부 조합을 통해 통신하므로, 모든 개별 서비스의 스택이 해당 서비스에 맞게 최적화될 수 있습니다. 기술은 늘 변화하고 있으며, 다수의 소규모 서비스로 구성된 애플리케이션은 사용 가능한 경우 보다 바람직한 기술을 통해 진화하기에 훨씬 더 쉽고 비용이 적게 소요됩니다.

정확한 스케일링

마이크로서비스를 사용하면 개별 서비스를 개별적으로 배치할 수 있지만, 이는 개별적으로도 스케일링이 가능합니다. 따라서, 장점은 명확합니다. 모놀리식 애플리케이션에서 요구하는 애플리케이션 대신에, 필요한 컴포넌트만의 정확한 스케일링이 가능하므로, 올바르게 완성된 마이크로서비스는 모놀리식 애플리케이션보다 인프라를 덜 필요로 합니다.

당면 과제

마이크로서비스의 중요한 이점은 중요한 문제를 수반합니다. 모노리스에서 마이크로서비스로 이동하는 것은 관리 복잡성의 증가를 의미합니다. 즉, 더 많은 곳에 배치된, 더 많은 팀이 작성한, 더 많은 서비스가 존재할 수 있습니다. 한 서비스의 문제점으로 인해 다른 서비스의 문제점이 발생하거나, 이와 반대 방향의 상황이 발생할 수 있습니다. 로깅 데이터(모니터링 및 문제점 해결에 사용됨)는 보다 방대하며, 서비스 간에 불일치할 수 있습니다. 새 버전으로 인해 역호환성 문제가 발생할 수 있습니다. 애플리케이션에 더 많은 네트워크 연결이 포함되며, 이는 대기 시간 및 연결 문제의 발생 가능성을 증대시킵니다. DevOps 접근 방식(아래에서 읽을 수 있음)은 이러한 많은 문제를 해결할 수 있지만, DevOps 채택에는 나름대로의 문제가 있습니다.

그럼에도 불구하고, 이러한 문제들은 아직 마이크로서비스를 채택하지 않은 사용자가 이를 채택하는 것을 막지 못합니다. 혹은 이를 채택한 사용자가 자체 마이크로 서비스 정책을 강화하는 것을 막지 못합니다. 신규 IBM 설문조사 데이터에 따르면, 현재 비사용자 중 56%가 향후 2년 내에 마이크로서비스를 채택할 가능성이 있거나 높으며, 현재 마이크로서비스 사용자 중 78%가 마이크로서비스에 투자한 시간, 비용 및 노력을 증대할 것입니다(그림 1 참조).

그림 1: 어디서나 사용되는 마이크로서비스. 향후 2년 내에, 비사용자 중 56%가 마이크로서비스를 채택할 예정이며, 78%의 사용자가 마이크로서비스에 대한 투자를 늘리고, 59%의 애플리케이션이 마이크로서비스로 구축될 것입니다. (출처: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

DevOps를 사용함과 동시에 이를 필요로 하는 마이크로서비스

마이크로서비스 아키텍처는 종종 DevOps 및 지속적 통합/지속적 딜리버리(CI/CD)에 맞게 최적화된 것으로 기술되며, 빈번히 배치될 수 있는 소규모 서비스의 맥락에서 볼 때 그 이유를 이해하기는 어렵지 않습니다.

하지만, 마이크로서비스와 DevOps 간의 관계를 살펴보는 또 다른 방법은 마이크로서비스 아키텍처가 성공을 위해 DevOps를 실제로 필요로 한다는 것입니다. 모놀리식 애플리케이션에는 이 글의 앞 부분에서 설명한 다양한 단점들이 있지만, 이에는 다수의 이동물과 독립된 기술 스택을 지닌 복잡한 분산 시스템이 아니라는 이점이 있습니다. 이와는 대조적으로, 마이크로서비스에서 제공하는 복잡성, 이동 및 종속성의 엄청난 증가로 인해, 배치, 모니터링 및 라이프사이클 자동화에 대한 상당한 투자 없이 마이크로서비스를 채택하는 것은 바람직하지 않을 수 있습니다.

Andrea Crawford는 다음 동영상에서 DevOps에 대해 자세히 설명합니다.

핵심 사용 기술 및 툴

거의 모든 최신 툴이나 언어를 마이크로서비스 아키텍처에서 사용할 수 있지만, 마이크로서비스의 정의상 필수적이고 경계를 이루는 몇 가지 핵심 툴이 존재합니다.

이는 컨테이너, Docker 및 Kubernetes입니다.

마이크로서비스의 핵심 요소 중 하나는 일반적으로 매우 작다는 것입니다. (어떤 것이 마이크로서비스인지 아닌지를 결정하는 코드의 양에는 기준이 없지만, "마이크로"가 바로 이름에 붙습니다.)

2013년의 최신 컨테이너 시대에 Docker가 소개되었을 때, 마이크로서비스와 가장 밀접하게 관련될 컴퓨팅 모델도 함께 소개되었습니다. 개별 컨테이너에 자체 운영체제의 오버헤드가 없으므로, 이는 기존의 가상 머신보다 작고 경량이며 보다 빠른 스핀업과 스핀다운이 가능합니다. 따라서 이는 마이크로서비스 아키텍처 내에서 발견되는 더 작은 경량의 서비스에 완벽히 적합합니다.

서비스와 컨테이너의 급증으로 인해, 대규모 컨테이너 그룹의 신속한 오케스트레이션과 관리는 중요 문제 중 하나가 되었습니다. 개방형 소스 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 해당 작업을 매우 잘 수행하기 때문에 가장 인기 있는 오케스트레이션 솔루션 중 하나로 부상했습니다.

"Kubernetes 설명" 동영상에서, Sai Vennam은 Kubernetes의 모든 것에 대한 포괄적인 뷰를 제시합니다.

 

API 게이트웨이

마이크로서비스는, 특히 처음 상태를 설정할 때 종종 API를 통해 통신합니다. 클라이언트와 서비스가 서로 간에 직접 통신할 수 있음은 사실이지만, 특히 애플리케이션에서 서비스의 수가 시간이 지나면서 증가하기 때문에 API 게이트웨이는 종종 유용한 중간 계층입니다. API 게이트웨이는 요청을 라우팅하고 여러 서비스에서 요청을 전개하며 추가로 보안과 인증을 제공함으로써 클라이언트에 대한 리버스 프록시 역할을 수행합니다.

API 관리 플랫폼을 포함하여 API 게이트웨이의 구현에 사용할 수 있는 다수의 기술이 존재하지만, 마이크로서비스 아키텍처가 컨테이너와 Kubernetes를 사용하여 구현 중인 경우 게이트웨이는 일반적으로 Ingress를 사용하여, 혹은 보다 최근에는 Istio를 사용하여 구현됩니다.

메시징 및 이벤트 스트리밍

가장 좋은 방법은 상태 없는 서비스를 설계하는 것일 수 있지만, 그럼에도 불구하고 상태는 존재하며 서비스는 이를 인지해야 합니다. 그리고 API 호출이 종종 해당 서비스의 상태를 초기에 설정하는 효과적인 방법이긴 하지만, 이는 최신 상태를 유지함에 있어서는 그리 효과적인 방법은 아닙니다. 서비스를 최신 상태로 유지하기 위해 AWTY(Are We There Yet?)를 지속적으로 폴링하는 접근 방법은 그다지 실용적이지 않습니다.

그 대신에, 서비스가 상태의 변화를 브로드캐스팅하고 다른 이해 당사자들이 해당 변경사항을 청취하고 적절하게 이를 조정할 수 있도록 상태 설정 API 호출을 메시징 또는 이벤트 스트리밍과 커플링하는 것이 필요합니다. 이 작업은 범용 메시지 브로커에 가장 적합한 것 같지만, Apache Kafka 등의 이벤트 스트리밍 플랫폼이 적합한 경우도 존재합니다. 그리고 마이크로서비스와 이벤트 기반 아키텍처를 결합함으로써 개발자는 대용량의 이벤트 또는 정보를 실시간으로 이용하고 처리할 수 있는 분산된, 고확장성의, 장애 허용 및 확장형 시스템을 구축할 수 있습니다.

서버리스

서버리스 아키텍처는 핵심 클라우드 및 마이크로서비스 패턴 중 일부를 논리적 결론에 적용합니다. 서버리스의 경우 실행 단위는 단순히 작은 서비스가 아닌 함수이며, 이는 종종 몇 줄의 코드에 불과할 수 있습니다. 마이크로서비스와 서버리스 함수의 구분선은 다소 애매할 수 있지만, 함수는 일반적으로 마이크로서비스보다 더 작은 것으로 이해될 수 있습니다.

서버리스 아키텍처와 FaaS(Functions-as-a-Service) 플랫폼이 마이크로서비스와의 유사성을 공유하는 점은, 이들이 모두 보다 작은 배치 단위를 작성하며 수요에 맞게 정확하게 스케일링하는 데 관심을 둔다는 점입니다.

마이크로서비스 및 클라우드 서비스

마이크로서비스가 반드시 클라우드 컴퓨팅과 배타적 관련성이 있는 것은 아니지만, 이들이 자주 함께 사용되는 몇 가지 중요한 이유가 있으며, 이 이유는 신규 애플리케이션의 대중적인 아키텍처 스타일이 되는 마이크로서비스와 신규 애플리케이션의 대중적인 호스팅 대상이 되는 클라우드를 넘어섭니다.

마이크로서비스 아키텍처의 주요 이점 중에는 개별적인 컴포넌트의 배치 및 스케일링과 관련된 활용도와 비용 이점이 있습니다. 이러한 장점은 온프레미스 인프라에서 어느 정도 여전히 존재할 수 있지만, 온디맨드, 종량과금제 인프라와 결합된 소규모의 독립적으로 확장 가능한 컴포넌트의 조합은 실제 비용 최적화가 이루어지는 곳입니다.

두 번째로, 그리고 아마 더 중요한 것은 마이크로서비스의 또 다른 주요 이점이 각각의 개별 컴포넌트가 특정 작업에 가장 적합한 스택을 채택할 수 있다는 점입니다. 클라우드 서비스가 관리 문제를 극적으로 최소화할 수 있으므로, 스택 확장은 자신이 직접 관리하되 지원 스택을 사용하는 경우 심각한 복잡성 및 오버헤드로 이어질 수 있습니다. 달리 말하면, 자체 마이크로서비스 인프라의 롤링이 불가능하지는 않지만, 특히 이제 막 시작하는 경우에는 이를 권장하지 않습니다.

공통 패턴

마이크로서비스 아키텍처 내에는, 다음과 같은 몇몇 추가적인 공통 과제와 기회를 해결하는 데 도움이 되는 다수의 일반적이고 유용한 설계, 커뮤니케이션 및 통합 패턴이 있습니다.

• BFF(Backend-for-frontend) 패턴: 이 패턴은 사용자 경험 및 해당 경험이 호출되는 리소스 간에 계층을 삽입합니다. 예를 들어, 데스크탑에서 사용되는 앱은 모바일 디바이스와는 다른 화면 크기, 디스플레이 및 성능 한계를 갖습니다. BFF 패턴을 사용함으로써 개발자는 인터페이스에서 작동하지만 프론트엔드 성능에 악영향을 미칠 수 있는 일반 백엔드를 지원하려고 하기보다는, 해당 인터페이스에 대한 최상의 옵션을 사용하여 사용자 인터페이스당 하나의 백엔드 유형을 작성하고 지원할 수 있습니다.
• 엔티티 및 집계 패턴: 엔티티는 해당 ID로 구별되는 오브젝트입니다. 예를 들어, 전자 상거래 사이트에서 제품 오브젝트는 제품 이름, 유형 및 가격으로 구분될 수 있습니다. 집계는 하나의 단위로 처리되어야 하는 관련 엔티티의 콜렉션입니다. 따라서 전자상거래 사이트의 경우 주문은 구매자가 주문한 상품(엔티티)의 콜렉션 (집계)입니다. 이러한 패턴은 데이터를 의미 있는 방식으로 분류하는 데 사용됩니다.
• 서비스 감지 패턴: 이러한 지원 애플리케이션과 서비스는 서로가 서로를 찾습니다. 마이크로서비스 아키텍처에서 서비스 인스턴스는 스케일링, 업그레이드, 서비스 장애, 심지어는 서비스 종료로 인해 동적으로 변경됩니다. 이러한 패턴들은 이러한 과도 현상에 대처하기 위한 감지 메커니즘들을 제공합니다. 로드 밸런싱은 트래픽 재조정을 위한 트리거로서 상태 점검과 서비스 실패를 사용하여 서비스 감지 패턴을 사용할 수 있습니다.
• 어댑터 마이크로서비스 패턴: 다른 국가로 이동할 때 사용하는 플러그 어댑터를 생각하는 방식으로 어댑터 패턴을 생각해 보세요. 어댑터 패턴의 목적은 달리 호환되지 않는 클래스 또는 오브젝트 간의 관계를 변환하는 데 도움을 주는 것입니다. 써드파티 API에 의존하는 애플리케이션은 애플리케이션과 API가 통신할 수 있도록 보장하기 위해 어댑터 패턴을 사용해야 할 수 있습니다.
• Strangler 애플리케이션 패턴: 이러한 패턴은 마이크로서비스 애플리케이션으로 모노리스 애플리케이션의 리팩토링을 관리하는 데 도움이 됩니다. 형형색색의 이름은 덩굴식물(마이크로서비스)이 천천히 그리고 시간이 지나면서 나무(모놀리식 애플리케이션)를 잠식하고 목을 조이는 방법을 의미합니다.

"마이크로서비스에서 개발 패턴의 사용법(파트 4)"에서 이러한 패턴에 대해 자세히 학습할 수 있습니다. 다른 마이크로서비스 코드 패턴에 대해 알아보려는 경우 IBM Developer에서도 많은 정보를 제공합니다.

안티 패턴

마이크로서비스를 잘 수행하기 위한 많은 패턴이 있지만, 빠르게 개발 팀을 곤경에 빠뜨릴 수 있는 상당한 수의 패턴들이 동일하게 존재합니다. 마이크로서비스 "금지사항"으로 달리 표현된 이들 중 일부는 다음과 같습니다.

• 마이크로서비스의 첫 번째 규칙은 마이크로서비스 구축 금지: 더 정확하게 말하면 마이크로서비스로 시작 금지입니다. 마이크로서비스는 일단 애플리케이션이 너무 커져서 이를 손쉽게 업데이트 및 유지보수하기가 곤란한 경우 복잡성을 관리하는 방법입니다. 모놀리스의 고통과 복잡성이 느끼지기 시작하는 경우에만 해당 애플리캐이션을 더 작은 서비스로 리팩토링하는 방법을 고려해 볼 가치가 있습니다. 해당 고통을 느낄 때까지는 리팩토링이 필요한 모노리스를 실제 보유하지 않습니다.
• DevOps 또는 클라우드 서비스 없이 마이크로서비스 실행 금지: 마이크로서비스를 구축하는 것은 분산 시스템을 구축하는 것을 의미하며, 분산 시스템은 쉽지 않습니다(이를 더 어렵게 만드는 선택을 하는 경우 특히 어려움). a) 적절한 배치 및 모니터링 자동화 또는 b) 현재 제멋대로의 이질적 인프라를 지원하는 관리형 클라우드 서비스 없이 마이크로서비스를 수행하려고 시도하는 것은 많은 불필요한 문제를 불러일으키는 것입니다. 상태에 대해 생각하며 시간을 보낼 수 있도록 괜히 수고하지 마세요.
• 너무 작게 만들어서 너무 많은 마이크로서비스 만들기 금지: 마이크로서비스의 "마이크로"가 지나치면, 마이크로서비스 아키텍처의 전체 이득을 훨씬 상회하는 오버헤드와 복잡도를 떠안게 됩니다. 더 큰 서비스 쪽으로 기울인 후에 마이크로서비스가 해결하는 특성의 개발을 시작할 때 이를 분리하는 게 바람직합니다(즉, 변경사항의 배치가 어렵고 느려지며 공통 데이터 모델이 지나치게 복잡해지는 경우 또는 서비스의 서로 다른 부분이 서로 다른 로드/스케일 요구사항을 갖는 경우).
• 마이크로서비스를 SOA로 전환 금지: 마이크로서비스 및 서비스 지향 아키텍처(SOA)는 가장 기본적인 레벨에서 다른 애플리케이션이 사용할 수 있는 재사용 가능한 개별 컴포넌트를 빌드하는 데 모두 관심이 있다는 점에서 종종 서로 간에 혼동됩니다. 마이크로서비스와 SOA간의 차이점은 마이크로서비스 프로젝트는 일반적으로 관리가 쉽도록 애플리케이션의 리팩토링을 포함하는 반면, SOA는 IT 서비스가 전사적으로 작동하는 방식을 변화시키는 데 관련되어 있다는 점입니다. SOA 프로젝트로 변형되는 마이크로서비스 프로젝트는 자체 무게로 인해 곤경에 처할 수 있습니다.
• Netflix 금지: Netflix는 모든 인터넷 트래픽의 3분의 1을 차지하는 애플리케이션을 구축하고 관리할 때 마이크로서비스 아키텍처의 초기 개척자 중 하나였으며, 이는 평균적 애플리케이션에는 불필요한 많은 사용자 정의 코드와 서비스를 구축하도록 요구하는 일종의 퍼펙트 스톰이었습니다. 자신이 감당할 있는 페이스로 시작하고, 복잡함을 피하며, 가능한 많은 기성품 툴을 사용하도록 권장합니다.

튜토리얼: 마이크로서비스 스킬 구축

마이크로서비스의 사용법에 대해 자세히 알아볼 준비가 되었거나 마이크로서비스 스킬을 구축해야 하는 경우에는 다음 튜토리얼 중 하나를 사용해 보세요.

• 마이크로서비스 소개
• 속성 랩: Node.js를 사용한 고확장성 웹 애플리케이션 마이크로서비스 구축
• Spring Boot 및 Cloudant를 사용한 Java 마이크로서비스 시작하기
• 5분 내에 Spring 마이크로서비스 구축, 실행 및 배치
• 마이크로서비스, SOA 및 API: 친구 또는 적?

마이크로서비스 및 IBM Cloud

마이크로서비스는 현대 비즈니스의 속도로 혁신적인 개발을 가능하게 합니다. 독립형 마이크로서비스를 클라우드 환경에 배치하여 클라우드의 확장성과 유연성을 활용하는 방법을 알아봅니다. IBM의 도움을 받아서 애플리케이션 현대화가 무엇인지 알아봅니다.

다음 단계로 진행:

• IBM 클라우드 네이티브 개발 툴의 도움을 받아 자동화된 반복을 활용하여 개발 팀에게 여유 시간을 제공합니다.
• Red Hat OpenShift on IBM Cloud 또는 IBM Cloud Kubernetes Service를 시작하여 관리형 Kubernetes에 대해 자세히 알아봅니다. 또한 서버리스 컴퓨팅의 세부사항에 대해 IBM Cloud Code Engine을 확인합니다.
• 마이크로서비스는 기술로서의 팀 프로세스와 조직에 관한 것입니다. IBM DevOps의 도움을 받아 DevOps 접근 방식을 전략적으로 계획합니다.

지금 IBM Cloud 계정으로 시작하세요.