2020.07.15

IDG 블로그 | 2020년 클라우드에서의 서비스 현황

David Linthicum | InfoWorld
생각해 보면, 서비스란 정말로 오래된 것이다. 우리는 API를 지원하는 애플리케이션을 둘러싼 초기의 힘든 시절로부터 객체 지향 프로그래밍으로, CORBA 기반 서비스로, SOA로, 컨테이너로, 서버리스 함수로, 그리고 오늘날의 마이크로서비스까지 발전해 왔다.
 
ⓒ Getty Images Bank

이 여정에서 공통된 것이 있다면, 무엇인가를 한 번 작성하면 그것을 서로 다른 애플리케이션이나 유틸리티에서 여러 번 사용할 수 있다는 믿음이 기반이 되었다는 것이다. 물론 여러 서비스를 조합해 그 자체로 새로운 서비스를 만들 수 있는 역량은 말할 것도 없다. 이는 서비스 해체를 통해 이루어졌다.

오늘날 ‘서비스’란 말은 남용되고 있다. 클라우드 컴퓨팅 세계에서 서비스란 말은 퍼블릭 클라우드 서비스 업체가 드러내는 모든 것을 설명하는 단어로 사용된다. 최소한 필자가 이해하는 방식에서 서비스란 행위와 그 행위에 연결된 데이터 모두를 개발자가 좀 더 생산적일 수 있는 방식으로 드러내는 역량이다.

예를 들어, 서비스는 전달되는 모든 종류의 데이터 세트에서 예측 분석을 수행할 수 있도록 구축할 수도 있다. 그래서 이 서비스는 재고 관리 애플리케이션이나 영업 주문 등록 시스템에서 호출할 수 있다.

만약 서비스가 변경되거나 개선되면, 이들 애플리케이션 역시 혜택을 얻는다. 또한 단일 서비스를 변경하는 것으로 수백 줄의 코드를 골라내거나 애플리케이션에서 해당 기능을 수정하거나 개선하지 않고도 예측 분석 수행 방식을 변경할 수 있다. 개발자는 일종의 변동성을 해당 영역에 배치한 셈인데, 이는 좋은 아키텍처의 기반이 된다.

나쁜 소식도 있다. 리프트 앤 시프트 방식은 클라우드 네이티브 기능은 물론, 서비스 지향 환경의 적이다. 서비스 가능성을 고려하지 않고 최대한 빨리 애플리케이션을 클라우드로 이전하는 것은 좋지 않은 생각이다. 안타깝게도 지금까지 클라우드 마이그레이션에 가장 많이 사용된 방식이기도 하다.

이 방식은 세 가지를 놓친다. 우선 서비스 재사용성과 서비스가 가져다주는 생산성이 불능화된다. 둘째, 첨단 보안이나 성능 관리 같은 클라우드 네이티브 서비스와 섞을 수 없다. 셋째, 보통 생산성을 두 배는 높여주는 첨단 아키텍처의 이점을 이용할 수 없다. 만약 연간 유지보수 개발 비용이 100만 달러라면, 서비스만 제대로 이용해도 50만 달러로 줄일 수 있다.

그렇다면, 이렇게 단점이 분명한데도 왜 기업은 서비스 지향 환경에 모든 것을 투여하지 않을까? 물론 예산 때문이다.

클라우드 네이티브 환경과 애플리케이션 서비스의 이점을 취하기 위한 애플리케이션 리팩터링은 마이그레이션 비용을 세 배 정도 높여준다. 기업이 싸고 저렴한 것을 쫓아 광범위한 서비스 사용을 피해 가는 이유이다.

장단점을 이해한다면, 이제는 최소한 일부 애플리케이션만 서비스 사용을 위해 리팩터링하는 하이브리드 전략을 추구할 때이다. 서비스 이용을 위해 리팩터링을 추진하는 조직은 보통 이런 접근 방식을 사용한다.

필자는 서비스 지향 환경의 전도사는 아니다. 단지 생각해 볼 만한 아이디어를 제시할 뿐이다. editor@itworld.co.kr


2020.07.15

IDG 블로그 | 2020년 클라우드에서의 서비스 현황

David Linthicum | InfoWorld
생각해 보면, 서비스란 정말로 오래된 것이다. 우리는 API를 지원하는 애플리케이션을 둘러싼 초기의 힘든 시절로부터 객체 지향 프로그래밍으로, CORBA 기반 서비스로, SOA로, 컨테이너로, 서버리스 함수로, 그리고 오늘날의 마이크로서비스까지 발전해 왔다.
 
ⓒ Getty Images Bank

이 여정에서 공통된 것이 있다면, 무엇인가를 한 번 작성하면 그것을 서로 다른 애플리케이션이나 유틸리티에서 여러 번 사용할 수 있다는 믿음이 기반이 되었다는 것이다. 물론 여러 서비스를 조합해 그 자체로 새로운 서비스를 만들 수 있는 역량은 말할 것도 없다. 이는 서비스 해체를 통해 이루어졌다.

오늘날 ‘서비스’란 말은 남용되고 있다. 클라우드 컴퓨팅 세계에서 서비스란 말은 퍼블릭 클라우드 서비스 업체가 드러내는 모든 것을 설명하는 단어로 사용된다. 최소한 필자가 이해하는 방식에서 서비스란 행위와 그 행위에 연결된 데이터 모두를 개발자가 좀 더 생산적일 수 있는 방식으로 드러내는 역량이다.

예를 들어, 서비스는 전달되는 모든 종류의 데이터 세트에서 예측 분석을 수행할 수 있도록 구축할 수도 있다. 그래서 이 서비스는 재고 관리 애플리케이션이나 영업 주문 등록 시스템에서 호출할 수 있다.

만약 서비스가 변경되거나 개선되면, 이들 애플리케이션 역시 혜택을 얻는다. 또한 단일 서비스를 변경하는 것으로 수백 줄의 코드를 골라내거나 애플리케이션에서 해당 기능을 수정하거나 개선하지 않고도 예측 분석 수행 방식을 변경할 수 있다. 개발자는 일종의 변동성을 해당 영역에 배치한 셈인데, 이는 좋은 아키텍처의 기반이 된다.

나쁜 소식도 있다. 리프트 앤 시프트 방식은 클라우드 네이티브 기능은 물론, 서비스 지향 환경의 적이다. 서비스 가능성을 고려하지 않고 최대한 빨리 애플리케이션을 클라우드로 이전하는 것은 좋지 않은 생각이다. 안타깝게도 지금까지 클라우드 마이그레이션에 가장 많이 사용된 방식이기도 하다.

이 방식은 세 가지를 놓친다. 우선 서비스 재사용성과 서비스가 가져다주는 생산성이 불능화된다. 둘째, 첨단 보안이나 성능 관리 같은 클라우드 네이티브 서비스와 섞을 수 없다. 셋째, 보통 생산성을 두 배는 높여주는 첨단 아키텍처의 이점을 이용할 수 없다. 만약 연간 유지보수 개발 비용이 100만 달러라면, 서비스만 제대로 이용해도 50만 달러로 줄일 수 있다.

그렇다면, 이렇게 단점이 분명한데도 왜 기업은 서비스 지향 환경에 모든 것을 투여하지 않을까? 물론 예산 때문이다.

클라우드 네이티브 환경과 애플리케이션 서비스의 이점을 취하기 위한 애플리케이션 리팩터링은 마이그레이션 비용을 세 배 정도 높여준다. 기업이 싸고 저렴한 것을 쫓아 광범위한 서비스 사용을 피해 가는 이유이다.

장단점을 이해한다면, 이제는 최소한 일부 애플리케이션만 서비스 사용을 위해 리팩터링하는 하이브리드 전략을 추구할 때이다. 서비스 이용을 위해 리팩터링을 추진하는 조직은 보통 이런 접근 방식을 사용한다.

필자는 서비스 지향 환경의 전도사는 아니다. 단지 생각해 볼 만한 아이디어를 제시할 뿐이다. editor@itworld.co.kr


X