마이크로 서비스로 전환해야하는 7 가지 이유 - 성공하지 못했던 5 가지 이유

실패를 두려워 하면 성공하지 못하는 마이크로 서비스 

마이크로 서비스로 전환해야하는 7 가지 이유 - 성공하지 못했던 5 가지 이유

7 reasons to switch to microservices — and 5 reasons you might not succeed

Using a microservices approach to application development can improve resilience and expedite your time to market, but breaking apps into fine-grained services offers complications. Here's what to expect.

응용 프로그램 개발에 대한 마이크로 서비스 접근 방식을 사용하면 탄력성을 향상시키고 시장 진출 시간을 단축 할 수 있지만 응용 프로그램을 세부적인 서비스로 분류하면 복잡합니다. 기대하는 바가 있습니다.

http://www.cio.com/article/3201193/it-strategy/7-reasons-to-switch-to-microservices-and-5-reasons-you-might-not-succeed.html

Microservices는 2011 년에 처음 설립 된 이래로 미래 지향적 인 애플리케이션 개발 조직들 사이에서 파문을 일으키고 있습니다. 불과 몇 년 후, 마이크로 서비스는 Nginix의 최근 설문 조사에 따르면 36 %의 기업 설문 조사에 따르면 현재 마이크로 서비스를 사용 하고 있으며 연구 단계에서는 26 %가 더 사용하고 있습니다. 그러나 마이크로 서비스 아키텍처는 정확히 무엇이며 조직의 문화, 기술 및 요구 사항에 맞습니까?

여기에서는 다음 번 응용 프로그램 개발 프로젝트를 위해 마이크로 서비스를 고려해야 하는 7 가지 이유와 성공을 위해 반드시 지켜야 할 다섯 가지 장애물을 살펴 봅니다.

마이크로 서비스의 경우

서비스 지향 아키텍처 (SOA)의 변형 인 마이크로 서비스는 응용 프로그램이 느슨하게 결합 된 서비스로 분해되는 아키텍처 스타일입니다. 세밀한 서비스와 가벼운 프로토콜을 통해 마이크로 서비스는 모듈성을 향상시켜 응용 프로그램을보다 쉽게 ​​개발, 테스트, 배포 및 변경하고 유지 관리 할 수 ​​있습니다.

[ 마이크로 서비스를 채택하는 것이 왜 이론에서는 쉽지만 현실에서는 불가능한 지 알아보십시오 . | 주의 12 '모범 사례'IT는 어떤 희생을 치르더라도 피해야한다 . | 우리의 CIO 일일 뉴스 레터 에 가입 하여 최신 통찰력을 얻으십시오 . ]

의심의 여지없이 단일화 된 다중 계층 아키텍처가 단일 코드베이스에서 전체 응용 프로그램을 생성하는 데 사용 된 모 놀리 식 시대에 개발 된 응용 프로그램으로 조직에 여전히 묶여 있습니다. 클라이언트 - 서비스 모델은 데스크톱이 IT를 지배 할 때 탁월한 선택이었습니다. 그러나 모바일 장치 및 클라우드의 등장으로 광범위한 장치에서 백엔드 데이터를 항상 사용할 수 있어야하며 모 놀리 식 아키텍처로 인해 변경이 있을 때마다 전체적으로 애플리케이션을 업데이트해야하며, 새로운 기능을 추가하거나 새로운 컨텍스트에 적응하려고 할 때마다 새로운 버그가 발생할 수 있습니다. 더욱이 모든 것이 단일 코드베이스에 묶여 있으므로 특정 기능이나 서비스를 확장 할 수 없습니다. 전체 애플리케이션을 확장해야하므로 비용이 크게 늘어납니다.

마이크로 서비스를 사용하면 코드가 별도의 프로세스로 실행되는 독립적 인 서비스로 분리됩니다. 하나의 서비스로부터의 출력은 독립적인 통신 서비스의 오케스트레이션에서 다른 것으로의 입력으로 사용됩니다. Microservices는 응용 프로그램에서 지원할 장치 배열에 대한 사전 설정 아이디어가없는 비즈니스에 특히 유용합니다. 장치 및 플랫폼에 구애받지 않는 microservices를 통해 비즈니스는 웹, 모바일, IoT, 웨어러블 및 피트니스 트래커 환경에 걸쳐 다양한 플랫폼에서 일관된 사용자 경험을 제공하는 응용 프로그램을 개발할 수 있습니다. Netflix, PayPal, Amazon, eBay 및 Twitter는 현재 마이크로 서비스를 사용하는 일부 기업에 불과합니다.

예를 들어 Walmart Canada 는 2012 년에 소프트웨어 아키텍처를 마이크로 서비스 로 리팩토링했습니다 . 당시 분당 600 만 페이지 뷰를 처리하지 못했던이 회사는 전환율이 크게 증가하면서 즉시 결과를 얻었습니다. 다운 타임도 최소화되었고, 값 비싼 상용 하드웨어를 저렴한 가상 x86 서버로 대체 할 수 있었기 때문에 전체 비용을 20 ~ 50 % 절감 할 수 있었습니다.

귀하의 조직이 Walmart 또는 Amazon의 규모가 아니더라도 마이크로 서비스는 여전히 큰 가치를 제공 할 수 있습니다. 다음은 마이크로 서비스로 전환 할 때 조직에서 누릴 수 있는 혜택 중 일부입니다.

탄력성 증가

마이크로 서비스를 사용하면 전체 응용 프로그램을 분산시키고 별도의 엔터티 역할을하는 서비스로 분리 할 수 ​​있습니다. 코드의 오류가 하나 이상의 서비스 나 기능에 영향을주는 모 놀리 식 아키텍처와 달리 마이크로 서비스를 사용하면 오류의 영향을 최소화 할 수 있습니다. 유지 관리를 위해 여러 시스템이 중단 되더라도 사용자는이를 인식하지 못합니다.

향상된 확장 성

확장성은 마이크로 서비스의 핵심 요소입니다. 각 서비스는 별도의 구성 요소이므로 전체 응용 프로그램을 확장하지 않고 단일 기능이나 서비스를 확장 할 수 있습니다. 업무상 중요한 서비스를 여러 서버에 배포하여 다른 서비스의 성능에 영향을주지 않고 가용성과 성능을 향상시킬 수 있습니다.

올바른 작업에 올바른 도구를 사용할 수있는 능력

마이크로 서비스를 사용하면 단일 공급 업체와 묶일 필요가 없습니다. 대신 올바른 작업에 적합한 도구를 사용할 수 있는 유연성이 있습니다. 각 서비스는 자체 언어, 프레임 워크 또는 부수적 인 서비스를 사용할 수 있지만 응용 프로그램의 다른 서비스와 쉽게 통신 할 수 있습니다.

시장 출시 시간 단축

마이크로 서비스는 느슨하게 결합된 서비스와 함께 작동하기 때문에 전체 코드베이스를 다시 작성하여 기능을 추가하거나 수정할 필요가 없습니다. 특정 서비스에만 변경을 가합니다. 독립적으로 테스트 및 배치가 가능한 작은 단위로 애플리케이션을 개발함으로써 애플리케이션 및 서비스를 보다 신속하게 출시 할 수 있습니다.

더 쉬운 디버깅 및 유지 보수

또한 Microservices를 사용하면 응용 프로그램을 쉽게 디버그하고 테스트 할 수 있습니다. 더 작은 모듈이 지속적으로 전달 및 테스트 프로세스를 거치면 오류가없는 응용 프로그램을 제공 할 수 있는 능력이 크게 향상됩니다.

TCO 감소로 향상된 ROI

Microservices를 사용하면 리소스를 최적화 할 수도 있습니다. 마이크로 서비스를 통해 여러 팀이 독립적 인 서비스를 수행하므로보다 신속하게 배포 할 수 있으며 필요에 따라 더 쉽게 피벗 할 수 있습니다. 개발 시간이 단축되고 팀의 코드가 더 많이 재사용 될 것입니다. 서비스를 분리하면 값 비싼 기계에서 작업 할 필요가 없습니다. 기본적인 x86 시스템은 그렇게 할 것입니다. 마이크로 서비스의 효율성 증대는 인프라 비용을 절감 할뿐만 아니라 다운 타임을 최소화합니다.

지속적인 배포

전담 팀이 UI, 데이터베이스, 서버 측 로직 및 기술 계층과 같은 개별 기능을 수행하는 단일 응용 프로그램과 달리 마이크로 서비스는 교차 기능 팀을 사용하여 연속 배달 모델을 사용하여 응용 프로그램의 전체 수명 주기를 처리합니다. 개발자, 운영 및 테스트 팀이 단일 서비스에서 동시에 작업 할 때 테스트 및 디버깅이 쉽고 빠릅니다. 이 점진적 개발 방식을 사용하면 코드가 지속적으로 개발, 테스트 및 배포되고 휠 재발 사 없이 기존 라이브러리의 코드를 사용할 수 있습니다.

Microservices가 모든 비즈니스에 적합한 것은 아닙니다.

마이크로 서비스를 채택한 기업은 상당한 이점을 실현했으며 이러한 사실을 무시한 조직은 뒤에 남을 수 있습니다. 그러나 마이크로 서비스가 유망 해 보이지만 모든 비즈니스가 이 아키텍처를 활용할 수 있는 것은 아닙니다. 귀하의 비즈니스가 그것을 관리 할만큼 충분히 능력이 있는지 확인하십시오. 다음은 조직의 주의 사항입니다.

빠른 프로비저닝 및 앱 배포를 위해 장비가 필요합니다.

점진적 개발 및 지속적인 제공을 통해 마이크로 서비스는 귀사의 조직을 발목을 고수합니다. 직원은 마이크로 서비스를 최대한 활용하는 데 필요한 속도를 따라갈 수있는 자원을 즉시 제공 할 수 있어야합니다. 서버를 프로비저닝하는 데 며칠 또는 몇 달이 걸리면 심각한 문제가 발생합니다. 마찬가지로 새 서비스 또는 응용 프로그램을 신속하게 배포 할 수 있어야 합니다.

강력한 모니터링이 필수적입니다.

각 서비스는 자체 언어, 플랫폼 및 API를 사용하고 마이크로 서비스 프로젝트의 여러 엔티티에서 동시에 여러 팀을 조율 할 것이므로 강력한 모니터링을 통해 전체 인프라를 효과적으로 모니터링하고 관리해야합니다. 서비스가 실패하거나 장비가 다운 된 경우 문제가 발생했을 때이를 추적하는 것이 불가능할 수 있습니다.

당신은 devops 문화를 받아 들여야 합니다.

다기능 팀에서 일하기 위해서는 비즈니스가 devops 관행과 문화를 통합해야합니다. 전통적인 환경에서 개발자는 기능 및 기능에 중점을 둡니다. 운영 팀은 생산 관련 문제를 해결하기 위해 노력하고 있습니다. devop에서는 모든 사람이 서비스 제공 및 실패에 책임이 있습니다.

테스트는 복잡 할 수 있습니다.

마이크로 서비스의 경우 테스트가 간단하지 않습니다. 각 서비스에는 고유 한 종속성이 있으며 일부는 직접적이며 다른 일부는 이행 적입니다. 기능이 추가되면 새로운 종속성이 나타납니다. 이 모든 것을 신속하게 파악하는 것은 비실용적입니다. 또한 서비스 수가 증가하면 복잡성도 커집니다. 데이터베이스 오류, 네트워크 대기 시간, 캐싱 문제 또는 서비스 사용 불가능 여부에 관계없이 마이크로 서비스 아키텍처는 합리적인 수준의 오류를 보다 잘 처리 할 수 ​​있습니다. 따라서 탄력성 테스트와 폴트 인젝션이 필수입니다.

실패로 염두에두고 설계해야합니다.

실패를 위한 설계가 필수적입니다. 시스템 중단 시간, 서비스 지연 및 예기치 않은 응답과 같은 여러 가지 장애 문제를 처리 할 수 ​​있도록 준비해야 합니다. 여기서로드 밸런싱은 중요하지만 B 플랜을 갖는 것이 또 다른 중요한 옵션입니다. 오류가 발생하면 문제가 발생한 서비스는 전체 시스템을 손상시키지 않으면 서 기능이 저하 된 상태로 실행되어야 합니다.

관련 기사

• 왜 마이크로 서비스를 채택하는 것이 이론상 쉽지만 실제로는 그렇지 않습니다.
• 12 가지 '모범 사례'IT는 모든 비용을 들이지 않고 피해야한다.
• 오늘 IT 클라우드 전략을 정의하는 6 가지 추세
• 8 가지 실제 디지털 변환의 내부 모습
• 나쁜 IT 아키텍처의 9 가지 경고 신호
• 여전히 통치하는 구식 IT 10 원칙