10주년 맞이한 마이크로소프트 애저 클라우드의 “어제, 오늘 그리고 내일”

10주년 맞이한 마이크로소프트 애저 클라우드의 “어제, 오늘 그리고 내일”

Image Credit : GettyImagesBank

Simon Bisson | InfoWorld

마이크로소프트가 애저(Azure) 클라우드 서비스를 시작한 지 10년이 지났다. 컴퓨팅 분야에서 10년은 매우 긴 시간이므로, 인터넷 아카이브의 웨이백 기기를 타고 과거로 돌아가 다시 애저의 역사를 정리해 보자.
출시 당시 마이크로소프트 애저는 PaaS(Platform as a Service)의 일종이었다. 그 위에 애플리케이션을 구축할 수 있는 클라우드 호스팅 서비스였다. 라이브 서비스(Live Services)가 기기에 통합됐고, SQL 서비스(SQL Services)는 데이터 처리를 담당했다. 닷넷 서비스(.Net Services)는 스테이트리스(stateless) 애플리케이션을 호스팅했으며, 셰어포인트(SharePoint) 및 다이내믹스(Dynamics)를 통합하는 계획이 나온 상태였다.

Image Credit : GettyImagesBank

출시 당시의 애저 : PaaS
애저의 출시 초기를 보면 당시부터 익숙한 것이 꽤 많았음을 알 수 있다. 많은 기반 기술을 자체 개발했는데, 이는 애저 개발 툴의 중추로 자리 잡았다. 그 이면에는 워커 프로세스와 관리형 서비스 패브릭 같은 현재 일반화된 개념이 있었다. 현재 윈도우 또는 리눅스에서 앱을 개발하는 것만큼 유연하지는 않았지만, 각 개발자의 통합개발환경(IDE)에서 퍼블리시(Publish) 버튼을 누르는 것만으로 소프트웨어를 배포하는 새로운 세계로 가는 출발점이 되었다.
그러나 출시 초기 애저는 저항에 부딪혔다. 당시 기업은 스테이스리스, 서버리스 애플리케이션 개발 모델을 수용할 준비가 되지 않은 상태였다. 결국 애저는 한 걸음 물러서서 주요 경쟁사인 AWS(Amazon Web Services)와 비슷하게 맞추는 것으로 방향을 틀었다. 당시 AWS는 가상 인프라를 지원하는 기능적 서비스에 집중했고, 빠른 속도로 시장 점유율을 늘려나가는 상황이었다.
이에 대항한 것이 마이크로소프트의 하이퍼-V 가상화 기술이었다. 애저는 이 기술을 이용해 IaaS(Infrastructure as a Service)로 변신했고, 지난 10년 동안 AWS와 비슷한 길을 걸어왔다. 즉, 가상 네트워크와 가상머신을 기반으로 애플리케이션을 구동하는 서비스를 내놓았다. 단, 원조인 PaaS를 완전히 포기한 것은 아니었다. PaaS는 웹 서비스와 서비스로서의 백엔드(Backend as a Service) 툴을 지원하는 용도로 여전히 사용됐다.

애저의 현재 : 마이크로서비스에 최적화된 클라우드
반전은 클라우드 산업이 발전하면서 시작됐다. 지난 몇 년 동안 애저는 원조 버전으로 회귀하는 움직임을 보이고 있다. 그 결과 오늘날 애저는 우리가 생각하는 것보다 처음 출범할 당시 플랫폼에 훨씬 더 가깝다. 여전히 주요 인프라 구성 요소를 갖고 있지만, 수년 동안 서비스 프레임워크를 발전시켜 오면서 애저는 점차 '플랫폼형 클라우드'로써 위상을 강화하고 있다.
이러한 변화의 가장 큰 요인은 분산형 클라우드 시스템 개발이 점점 더 중요해지고 있기 때문이다. 클라우드 덕분에 무제한에 가까운 컴퓨팅 자원을 쓸 수 있다고 해도 본질적으로는 여전히 개별 서버의 집합일 뿐이다. 인텔이 자사 아키텍처에 다중 처리 시스템용 코어와 지원을 계속 추가하고 있고, 애저가 여전히 스케일업보다는 스케일아웃 방식을 고수하는 것도 이 때문이다. 물론 대형 프로젝트를 위해 애저의 초대형 G 시리즈 기기를 쓸 수는 있지만, 1년에 8만 달러가 훨씬 넘는 비용을 생각하면 지속적 운영이 필요한 클라우드 네이티브 애플리케이션에 적합한 모델이라고 보기 힘들다.
스케일아웃 방식은 클라우드 하드웨어의 성능과 '일치하는' 아키텍처 접근방식이다. 즉 전 세계 데이터센터 속 오픈 컴퓨트(Open Compute) 서버 랙이 차곡차곡 새 서버로 쌓여갈수록 성능도 똑같이 늘어난다. 각 데이터센터 간에 아키텍처를 복제해 필요할 때마다 용량과 지리적 요건을 고려해 구매해 사용하면 된다. 특히 이 모델은 마이크로서비스에 안성맞춤이다. 마이크로서비스란 애플리케이션을 여러 컴포넌트로 해체하는 것을 가리킨다. 각 컴포넌트는 필요에 따라 독립적으로 확장할 수 있다.
마이크로소프트는 애저를 기반으로 한 클라우드 네이티브 마이크로서비스에 큰 기대를 걸고 있다. 쿠버네티스 툴과 컨테이너를 지원하기 위해 윈도우 서버를 완전히 뜯어고친 것만 봐도 그 기대가 어느 정도인지 짐작할 수 있다. 컨테이너에 최적화된 최신 윈도우 서버를 이용하면 마이크로서비스를 신속하게 확장, 배포할 수 있다. 컨테이너 배포에 적합한 사전 구성 서버 덕분에 새 기능과 추가 컴퓨팅 자원을 할당하는 것이 훨씬 빨라졌다. 코드와 컨테이너를 묶기만 하면 애플리케이션 또는 서비스를 지원할 수 있으므로 더는 컨테이너에서 운영체제가 만들어질 때까지 기다릴 필요가 없다.
이밖에 애저 서비스 패브릭 같은 애저 출시 당시의 서비스는 마이크로서비스에 최적화된 고객 툴이 됐고 컨테이너 및 VM 기반 솔루션에 대한 지원도 개선됐다. 그 결과 개발자는 여러 기술을 동시에 활용해 복잡한 애플리케이션을 개발할 수 있게 됐고, 애저는 이런 새로운 아키텍처를 지원할 수 있도록 진화했다.

애저의 미래 : 분산 애플리케이션의 산실
애저의 과거가 현재가 되었다면 앞으로는 어떻게 될까? 하이퍼스케일 클라우드 플랫폼의 가장 큰 장점은 다양한 개발 모델을 지원한다는 점이다. 앞으로도 2가지 개발이 공존할 것이다. 하나는 온프레미스 애플리케이션을 클라우드로 들어옮기는(Lift and Shift) 마이그레이션이고, 다른 하나는 처음부터 클라우드에서 개발하는 새로운 애플리케이션이다. 따라서 지금 필요한 것은 기존의 획일적인(monolith) 애플리케이션을 분산 애플리케이션으로 마이그레이션하는 방법을 찾는 것이다.
이처럼 기존 일체형 애플리케이션을 해체할 때 유용한 것이 바로 분산형 애플리케이션 디자인 패턴(Distributed application design patterns)이다. 사이드카(sidecar)와 어댑터(adapter) 등의 모델을 이용해 애플리케이션에서 기능을 해체한 후 새로운 마이크로서비스로 이전할 수 있다. 기존 애플리케이션을 계속 실행하면서 이런 기능을 서서히 떼어내는 것이다. 서비스 패브릭(Service Fabric)이 지속적으로 발전하고 있으므로, 이런 패턴에 적합한 호스팅 서비스가 등장할 가능성이 크다. 이런 서비스를 이용하면 가상머신을 계속 관리하면서도 동시에 사이드바와 어댑터 컨테이너를 위한 쿠버네티스 오케스트레이션까지 다룰 수 있다.
또한 분산 컴퓨팅에 대한 새로운 접근 방식도 떠올릴 수 있다. 프로젝트 올린즈(Project Orleans) 팀의 작업 성과를 기반으로 한 것이다. 최신 버전의 분산 트랜잭션 기능을 이용하면 기존보다 더 복잡한 애플리케이션까지 지원할 수 있다. 모든 기업이 글로벌 확장이 필요하지는 않겠지만, 이런 툴을 이용하면 개발자가 여러 병렬 마이크로서비스를 이용해 복잡한 부하를 처리할 수 있다. 중앙 서비스에 안전하게 데이터를 보내기 위해 필요한 가상 개체를 활용하는 것도 가능하다.
오늘날 애플리케이션은 기본적으로 분산형 애플리케이션이다. 퍼블릭 클라우드의 아키텍처와 기반이 되는 하드웨어의 제한을 고려해 개발된다. 서버 아키텍처가 크게 변화할 때까지는 이러한 기본적 전제가 흔들리지는 않을 것이다. 이런 상황에서 우리가 볼 수 있는 것은 마이크로소프트 같은 클라우드 서비스 업체뿐이다. 이들 업체가 분산 애플리케이션을 지원하는 더 다양하고 개선된 툴을 제공하고, 클라우드에서 개발, 실행하는 방법을 교육하고, 기존 코드를 새로운 환경에서도 사용할 수 있도록 마이그레이션하는 툴을 제공한다.
애저가 바로 이러한 작업을 하기에 적합한 공간이다. 마이크로소프트의 애저 관련 개발자들은 지난 10년 동안 분산 서비스를 개발하고 실행해 온 경험이 있다. 이제 이 경험을 더 많은 커뮤니티와 나눌 때가 됐다. 더구나 툴이 개선되면서 ASFM(Azure Service Fabric Mesh) 같은 서비스가 클라우드 제공 방식을 더 간소화하고 있고 새로운 학습(Learn) 플랫폼은 스스로 학습할 수 있도록 지원한다.
마이크로소프트는 10년 전 애저를 출시할 당시 너무 시대를 앞서 나갔던 것일 수도 있다. 그러나 이후 시장 지형이 크게 바뀌었다. 이제 마이크로소프트는 개발자가 원하는 것을 쫓기만 할 것이 아니라 글로벌 규모 분산 시스템의 장점을 활용할 수 있는 새로운 애플리케이션을 만들도록 개발자를 촉구할 시점이다. 쉽지는 않겠지만 이제 마이크로소프트는 한 걸음 더 다가가야 한다.  editor@itworld.co.kr

迎接10周年的微软Ager Cloud的"昨天, 今天, 还有明天"

Simon Bisson | InfoWorld
微软公司开始提供Azure云服务已经过去了10年头。 在计算领域，10年是非常长的时间，让我们乘坐网络存档的微机回到过去，重新整理一下自己的历史吧。
上市当时，微软是PaaS(Platformas a Service)的一种。 这是在上面可以构建应用程序的云端寄宿服务。 现场服务(Live Services)融入机器，SQL服务(SQL Services)负责数据处理。 互联网服务(.Net Services)主营了Stateless应用程序，并制定了整合SharePoint和Dynamics的计划。

上市时的爱著:PaaS
从艾哲上市初期可以看出，当时已经熟悉了很多东西。 自主开发了很多基础技术，这成了艾底开发工具的中枢。 其背后是沃克流程和管理型服务布艺等目前普遍化的概念。 虽然目前没有像在Windows或Linux上开发应用程序那样灵活，但仅通过在各开发者的综合开发环境(IDE)上按下Publish按钮，就成为了迈向软件发布的新世界的起点。
但在上市初期，爱著就遇到了阻力。 当时企业还没有准备好接受Sticeless、Cerberless应用开发模式。 最终，艾泽退一步，转向了与主要竞争对手AWS(Amazon Web Services)相似的方向。 当时，AWS集中于支援虚拟基础设施的功能性服务，正在快速增加市场占有率。
与此相对抗的是微软的"Hyper-V虚拟化技术"。 Azer利用该技术变身IaaS(Infrastructure as a Service)，在过去的10年里走过的路与AWS相似。 即，推出了以虚拟网络和虚拟机器为基础驱动应用程序的服务。 但是，他并没有完全放弃原创PaaS。 PaaS仍然被用于支持作为网络服务和服务的"后端(Backendas a Service)"工具。

Azer的当前:最适合微型服务的云端
反转是从云产业的发展开始的。 在过去几年中,艾杰表现出要回归原创版本的迹象. 其结果，今天的艾泽比我们想象的更接近刚成立时的平台。 虽然仍然具有主要基础设施构成要素，但随着多年来服务框架的发展，艾哲逐渐强化了作为"平台型云"的地位。
这种变化的最大因素是开发分散型云计算系统越来越重要。 即使借助云计算可以使用接近无限制的计算资源，本质上仍然只是个别服务器的集合。 英特尔继续在自家的架构中增加多重处理系统用核和支援，而Azer仍然坚持规模化而非规模化方式也是因为这个原因。 当然，可以为大型项目使用Azer的超大型G系列机器，但考虑到每年超过8万美元的费用，很难认为这款产品适合需要持续运营的云计算应用。
规模化方式是与云硬件的性能"一致"的架构处理方式。 即，全世界数据中心中的Open Compute服务器架层层堆积在新服务器后，其性能也会同样增加。 各数据中心之间复制架构，必要时根据容量和地理条件购买即可。 特别是这款手机非常适合微型服务。 微型服务是指将应用软件拆解成多个软件。 各个组件可以根据需要独立扩张。
微软对以Ager为基础的云计算微型服务寄予厚望。 为了支援库伯内蒂斯工具和集装箱，彻底修改了视窗服务器，由此可以推测出其期待有多大。 如果使用最适合集装箱的最新视窗服务器，就可以迅速扩张和分发微型服务。 得益于适合集装箱分配的前置服务器，分配新功能和追加计算资源的速度大大加快。 只要将代码和集装箱捆绑在一起，就可以支援应用程序或服务，因此没有必要再等到集装箱里建立操作系统。
除此之外，像Ager服务、布艺等Ager上市当时的服务成为了最优化微型服务的顾客工具，对集装箱及VM基础解决方案的支援也得到了改善。 其结果，开发者可以同时利用各种技术开发复杂的应用程序，而艾泽则进化成可以支援这种新的架构。

小猪的未来:分散应用程序的摇篮
如果孩子的过去变成了现在，以后会怎么样呢？ 超规模云平台的最大优点是支持多种开发模式。 今后两种开发共存。 一个是"Lift and Shift"的应用，另一个是从云端开发的新应用。 因此，现在需要的是寻找将现有的单一（monolith）应用分散应用的方法。
像这样，在拆解现有的一体型应用程序时，有用的就是分散型应用程序设计模式(Distributed application design patterns)。 利用sidecar和adapter等模型，在应用程序中解除功能后，可以转移到新的微型服务上。 也就是说，在继续执行现有应用程序的同时，逐渐将这种功能移除。 服务布艺(Service Fabric)持续发展，因此，适合这种模式的寄宿服务很有可能登场。 如果使用这种服务，在继续管理虚拟机器的同时，还可以处理为侧边栏和适配器集装箱的库伯内蒂斯管弦乐团。
另外，还可以想起分散计算的新方法。 这是以项目"奥利纳斯(Project Orleans)"小组的工作成果为基础制作的。 如果利用最新版本的分散交易功能，可以支援比现有版本更复杂的应用程序。 虽然并非所有企业都需要全球扩张，但利用这些工具，开发者可以利用多种并联微服务处理复杂的负荷。 为了向中央服务发送安全数据，也可以利用必要的虚拟个体。
如今的应用基本上是分散型应用。 考虑到公共云结构和基础硬件的限制而开发。 在服务器架构发生巨大变化之前，这些基本前提是不会动摇的。 在这种情况下，我们能看到的只有微软等云服务企业。 这些企业将提供支持分散应用程序的更加多样和改善的工具，教育在云端开发和实行的方法，并提供在新的环境下也能使用现有代码的微缩工具。
艾瑟就是适合做这些工作的空间。 微软公司的有关开发者在过去10年里有开发和实施分散服务的经验。 现在是时候和更多的社区分享这一经验了。 再加上随着工具的改善，非洲猪瘟（Azure Service Fabric Mesh）等服务正在进一步简化云端提供方式，新的学习（Learn）平台将支持学生自主学习。
微软在10年前推出Ager时，可能过于超前了时代。 但此后市场格局发生了巨大变化。 现在，微软不应该一味追求开发者想要的东西，而是应该敦促开发者开发利用全球规模分散系统优点的新应用程序。 虽然不容易，但微软应该更进一步。 editor@itworld.co.kr