IT's Fun2015.12.08 06:40

API 는 서로 다른 서비스 혹은 소프트웨어나 플랫폼들이 필요한 정보를 주고 받는 프로토콜(규약)과 스킴을 일컫는 말입니다. 인터넷이 대중화되기 이전 API 가 주로 플랫폼과 소프트웨어 / SDK 간에 이루어졌던 정보 교환에 사용되었다면 인터넷 혹은 웹(Web)이 대중화된 이후 API 의 중심은 단일 머신에서의 규약을 넘어서 서로 다른 서비스들간에 유기적인 결합을 위한 필수 요소가 된지 오래입니다. 글로벌 CDN 시장에서 활동하고 있는 많은 기업들 역시 자사의 플랫폼을 쉽게 활용할 수 있도록 OPEN API 를 열어두는 경우가 많습니다. 특히 아카마이의 경우 도커(Docker)를 이용하여 테스트용 컨테이너(Container)를 이용할 수 있도록 하여 현재의 개발환경의 변경 없이 쉽게 자사의 API 를 이용하고 테스트 할 수 있게 제공하고 있습니다.


아 카마이가 제공하는 OPEN API 를 이용하기 위한 절차들은 개발자 공식 웹사이트(http://developer.akamai.com) 에서 확인이 가능합니다. 개별적으로 제공되는 API 의 스펙에 대하여 이야기 하기 전에 아카마이가 제공하는 API 테스트 환경 구축의 장점 혹은 편리한 점은 일종의 가상 머신을 통해 별도로 분리하여 복잡하기 그지 없는 근래의 개발 환경에서도 마음 편하게 독립된 환경을 구축할 수 있다는 점일 것 같습니다. 이런 형태의 환경 제공을 통하는 경우가 많은지 모르겠습니다만 API 를 이용하는 입장에서는 "Why not?" 이라는 생각이 듭니다.




기존에 우리가 익숙하게 사용하던 하이퍼바이저(Hypervisor) 기반의 가상머신(Virtual Machine) 역시 도커(Docker)와 컨테이너(Container)가 제공하는 방식과 사용자 입장에서는 비슷한 경험을 줄 수 있겠지만 실제 기술적인 백그라운드 차이가 주는 성능, 쾌적함 관점에서 분명 차이는 있습니다. 특히 도커를 서비스용 인프라에서 이용하기 위해서는 고민할 것들이 적지 않겠지만 새로운 개발 환경에서의 작업, 테스트 등을 위해서 독특한 가치를 제공해줄 수 있을 것 같습니다.


개발 환경에 만들어 놓은 각 라이브러리 혹은 툴킷들 간에 완전함을 유지하는 것이 쉽지 않은 상황이 되면서 패키지를 관리해 주거나 라이브러리들간에 의존성 관리/체크를 쉽게 해주는 프레임웍이 각 언어별로 많은 사람들이 이용하고 있고 사랑받고 있습니다. 꼼꼼하게 관리해 주면 문제가 없을 부분들이지만 행여나 잠깐의 목적으로 테스트 하던 요소들로 탄탄하게(?)만들어 둔 환경이 흔들린다면 개발자 입장에서 이만한 짜증도 없을 것 같습니다. 아카마이 OPEN API 가 선택한 개발/테스트용 컨테이너처럼 다른 많은 플랫폼, 개발사에서도 배려를 해줄 수 있다면 더 많은 개발자들이 쉽게 특정한 플랫폼이나 라이브러리/패키지를 부담없이 활용해 볼 수 있지 않을까요?







저작자 표시 비영리
신고
Posted by 노피디
IT's Fun2013.04.22 09:26
클라우드 컴퓨팅이 대세로 자리 잡고 있지만 개발 환경의 변화는 그리 극단적으로 바뀌고 있지는 않습니다. 물리적인 자원들은 가상화라는 기술을 통해 편리하게 사용할 수 있도록 웹 기반, API 기반으로 많이 바뀌고 있지만 개발 환경의 변화는 많이 않다는 의미입니다. 이는 서비스가 운영되는 서버, 스토리지, 네트워크 등의 자원이 가지는 성격과 사용하는 개발 언어를 비롯, 프레임워크, 엔진 등이 요구하는 자원의 성격이 다르기 때문에 발생하는 문제입니다.

흔히 클라우드 컴퓨팅 업계에서 IaaS (Infrastructure as a Service, 이아스) 라고 불리우는 레이어가 전자의 서비스 운영을 위한 자원들이고 PaaS (Platform as a Service, 파스) 라고 불리우는 레이어가 후자에 속하는 영역입니다. IaaS 의 경우 그 변동의 폭이 크지 않고 사용자들이 요구하는 A to Z 가 명확하다는 특징을 가지고 있습니다. 요구사항이 명확한 만큼 표준화하여 제공하기가 쉽다는 장점이 있습니다. 반면 PaaS 의 경우 너무나 다양한 개발 환경, 오픈소스가 대세로 자리잡으면서 발생하는 프레임워크 현행화, 변경의 이슈등을 커버하기 어려워 상대적으로 서비스화 하기 어렵다는 단점을 가지고 있습니다.


그렇다면 파스의 영영은 언제나 서비스화가 어렵기 때문에 그대로 두어야만 하는 것일까요? 최근 등장하는 웹 기반의 IDE 와 PaaS 서비스 등은 그런 한계를 극복하기 위한 다양한 시도로 인정받고 있습니다. 마이크로소프트의 애져 (Azure) 서비스는 PaaS 에서 시작해 IaaS 로 진화하고 있는 클라우드 서비스의 대표적인 예 입니다. 웹 롤 (Web Role) 과 워커 롤 (Worker Role) 이 최초 서비스 되기 시작했고 최근에 들어서야 VM Role 을 IaaS 형태의 서비스로 제공하기 시작하면서 그 가치를 만들어 가고 있습니다.


그렇지만 마이크로소프트의 애져는 비주얼 스튜디오 (Visual Studio) 라는 걸출한 개발 환경을 서비스와 결합하여 편리한 개발 환경을 만들었을 뿐, 언제 어디서나 개발을 할 수 있는 환경은 아닙니다. PaaS 가 제공하는 편리한 서비스 환경의 편리함과 언제 어디서나 개발할 수 있는 개발 환경을 제공받고자 하는 개발자들의 요구는 웹 기반의 IDE 들이 등장하면서 어느정도 해소가 되어가고 있는 모습입니다.

Nitrous.io 역시 그런 시도 중 하나입니다. Nitrous.io 는 서비스의 디플로이 형태로 추정해 볼 때, 뒷 단에 아마존 EC2 를 적극 이용하여 서비스의 가용성을 높이고 있는 것이 주요한 특징으로 관찰됩니다 (현재 Closed Beta 만 진행하고 있어 동영상과 도움말을 통해서 서비스를 추정해 보았습니다 ^^) Ruby 환경을 현재 제공하고 있는데 향후 Node.js 등 시장에서 인기있는 프레임워크 등으로 제공되는 서비스의 영역을 넓혀 나가는 전략을 가지고 있습니다. (창업자 세명중 한명이 우김지훈 님이라는 우리나라 분이라는 것도 눈에 띕니다! Peter Jihoon Kim (@raingrove) 님께 트위터 친추요청을!)


서브라임 텍스트(sublime text)를 보는 것 같은 깔끔한 IDE 의 UI 와 콘솔을 동시에 볼 수 있도록 알차게 구성된 화면은 언제 어디서나 개발을 하고 서비스 환경에 디플로이 하고 싶게 만듭니다. 동영상 상에서는 Deploy 와 같은 메뉴 구성을 확인할 수 없어 아쉽지만 완성도 측면에서 상당한 수준에 올라 있는 웹 IDE 가 아닐까 추정해 봅니다. 개발 환경은 이제 PaaS 들이 알아서 만들어 주고, 개발도 브라우저만 있으면 쉽게 할 수 있는 세상. 개발자들에게 좋은 것인지 나쁜 것인지 쉽게 판단하기는 힘들지만 개발이 대중화 되고 누구나 코드를 짤 수 있는 세상을 만드는 데는 큰 도움이 될 것 같습니다.


저작자 표시
신고
Posted by 노피디

티스토리 툴바