Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

업체종속성

글로벌 칼럼 | API, 네트워크 업체 종속의 숨은 위협

대부분 기업은 네트워크의 업체 종속을 우려한다. 기업에 종속 회피 방법을 물으면, ‘표준 인터페이스’ 또는 ‘오픈소스’라고 답한다. 오늘날까지도 종속 회피 조치에 ‘API 관리’를 포함한 기업의 수는 많지 않다. 하지만 API는 현재 가장 빠른 속도로 성장하는 종속 문제이며, 앞으로 중대한 문제가 될 것임이 확실하다.    API는 ‘애플리케이션 프로그래밍 인터페이스(application programing interface)’를 의미한다. 오늘날에는 의미가 확장돼 애플리케이션뿐만 아니라 클라우드, 네트워크에 사용하는 모든 소프트웨어 컴포넌트의 인터페이스를 가리킨다. API는 소프트웨어 조각이 서로 통신할 수 있게 해준다. 따라서 하드웨어 장치가 연결된 환경보다는 소프트웨어 컴포넌트가 연결된 환경에서 필수적이다. 표준 인터페이스만큼이나 중요한 것이다. 하지만 이렇게 중요한 API의 흐름을 추적하는 기업은 극히 드물다.  네트워크 장비에는 4개의 소프트웨어 계층이 있다. 최하단에는 이더넷 인터페이스 칩을 소프트웨어와 연결하는 드라이버가 있다. 그 위에는 일반적인 호스팅 기능을 제공하는 NOS(Network Operating System)가 있고, 그 위에는 특수한 네트워크 기능을 처리하는 ‘미들웨어’가 있다. 최상부에는 통합 커뮤니케이션이나 서비스 거부 공격 완화 등 관리 및 서비스 기능을 하는 네트워크 의존 애플리케이션이 있다. 이들 계층은 API를 다른 계층으로 노출한다.  우리는 이더넷과 광 네트워크, 무선 네트워크까지 다양한 하드웨어 인터페이스에 익숙하다. 또 이더넷 커넥터를 광 네트워크 포트에 연결할 수 없다는 것과 입력 선을 출력 단자와 연결하면 안 된다는 것을 잘 안다. 하지만 API는 물리적 커넥터가 없다.  소프트웨어에서 발생하는 API 문제 API는 메시지 교환 규격이다. 메시지 포맷, 데이터 구조, 요청/응답 동기화 등 모든 측면이 API 규격 내에 설정되어 있고, 전체 ...

네트워크 업체종속성 API 2021.12.09

글로벌 칼럼 | 클라우드에서 오픈소스의 진정한 가치

클라우드에서 오픈소스를 구동한다고 해서 업체 종속을 막아줄 것이라 생각한다면, 오산이다. 하지만 오픈소스는 분명 개발자에게 자유와 독립을 가져다준다. 최근 IBM의 후원으로 오릴리 미디어가 진행한 설문조사인 ‘클라우드 시대 오픈소스의 가치’에는 희망적인 생각이 가득하다. 예를 들어, 3,400명 이상의 응답자 중 70%가 오픈소스 기반의 클라우드 서비스 업체를 더 선호한다고 답했다. 오픈소스 지지자에게는 대단한 수치이다. 하지만 ‘오픈소스 기반’이 어떤 의미인지를 물어보면, 사정이 달라진다. 결국 현존하는 모든 소프트웨어 제품은 오픈소스를 기반으로 하기 때문이다. 그리고 79%의 응답자는 클라우드에서 업체 종속을 방지하기 위해 오픈소스로 전환했다고 답했다. 이 이야기도 여러 가지 이유로 다소 우스꽝스러운 것이 사실이다.   이렇게 오픈소스에 우호적인 응답 이면에 한 가지 눈에 띄는 사실이 있다. 클라우드 전문 기술 솔루션은 개발자가 코드를 더 빨리 출하하는 데 도움이 되지만, 오픈소스 기술은 개발자가 특정 클라우드 서비스 업체와 독립적으로 자신의 경력을 쌓을 수 있도록 해준다. 다시 말해, 오픈소스는 궁극적인 경력 관리 기술이다.   오픈소스의 마법 같은 현실주의 그렇다면, 미신으로 돌아가 보자. 우선, 약 55%의 응답자가 ‘단일 클라우드 서비스 업체에 특화된 클라우드 컴퓨팅 기술을 배우는 것은 경력 성장을 제한한다”고 답했지만, 모든 개발자 대부분이 정확하게 이렇게 한다. 이유는 대부분 기업이 클라우드 서비스 업체 한 곳에 중점을 두기 때문이다. 물론, 많은 기업이 결국에는 서로 다른 애플리케이션이나 인프라를 다양한 클라우드 서비스 업체로부터 사용한다. 하지만 필자는 ‘어쩌다 보니 멀티클라우드’이지 ‘의도한 멀티클라우드’라고 생각하지 않는다. 의도한 멀티클라우드도 있지만, 매우 드물다. 전임 시트릭스 부사장 크리스티안 레일리가 말했듯이 “언제나 그렇듯 문제는 대체 가능성의 부족이다. 대체 가능성은 매출을 끌어올리지 않는다. 서비스 ...

경력개발 업체종속성 멀티클라우드 2021.02.23

IDG 블로그 | 멀티클라우드라고 업체 종속성이 사라지지는 않는다

필자는 여러 미디어를 통해 멀티클라우드(Multicloud)을 선택하는 주된 이유가 업체 종속성(vendor lockin) 때문이라는 얘기를 들었다. 클라우드 제공업체가 많으면 더욱 독립적일 수 있다는 이 가정의 논리는 이해가 가지만 현실은 크게 다르다.   예를 들어, 클라우드에 애플리케이션이 있고 멀티클라우드 아키텍처를 사용하는 경우 해당 애플리케이션 작업 부하와 관련된 데이터를 AWS, 마이크로소프트 애저, 그리고/또는 구글 클라우드 플랫폼 등 2-3곳에 분산시킬 수 있다. 해당 애플리케이션을 위해 1개의 클라우드를 선택하고 표준 마이그레이션 프로세스를 수행해 구성한 후 실행할 것이다. 대부분의 사람은 이런 마이그레이션의 일환으로써 애플리케이션 작업 부하를 클라우드에 네이티브화시켜야 한다는 사실을 모르고 있을 가능성이 높다. 즉, 애플리케이션을 살짝 또는 대대적으로 변경해 API 관리, 거버넌스, 보안, 저장소 등의 네이티브 클라우드 서비스를 활용하게 되는 것이다. 애플리케이션을 클라우드에 네이티브화하면 해당 애플리케이션에 대해서는 스스로 해당 클라우드 제공업체에 종속되는 것이다. 클라우드 네이티브화 접근방식을 취하지 않으면 해당 애플리케이션을 추후에 다른 제공업체로 마이그레이션하기가 더 쉽겠지만 클라우드 네이티브화가 되지 않아 배치가 덜 최적화된다. 고급 애플리케이션 기능(클라우드 네이티브화)을 사용해 업체 종속성을 인정하든지 종속성 탈피를 위해 독립적이지만 덜 최적화된 앱에 만족해야 한다. 단일 클라우드 또는 멀티클라우드 아키텍처를 사용하는지 여부에 상관없이 종속성의 타협은 똑같다. 물론, 필요 시 다른 퍼블릭 클라우드 옵션을 이용할 수 있도록 아키텍처에 다른 퍼블릭 클라우드가 연결, 통합되어 있는 것은 큰 이점이 된다. 하지만 여전히 클라우드 네이티브화와 종속성 탈피 사이의 상충점은 피할 수 없다. 컨테이너를 사용하거나 휴대 가능한 애플리케이션을 작성해 상충점을 피할 수 있다고 생각할 수도 있다. 하지만 거기에도 문제가 존재한다...

록인 lockin 멅티클라우드 2018.12.20

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.