블로그

SaaS가 네트워크 인프라 자동화에 대해 가르쳐 주는 것

로리 맥비티 썸네일
로리 맥비티
2017년 3월 23일 게시

SaaS의 성공은 주로 기업이 상품화된 비즈니스 프로세스를 식별해 소프트웨어에 담을 수 있는 능력에 기인합니다. 이는 기업 내의 네트워크 및 인프라 팀에도 해당됩니다.

SaaS(Software as a Service)는 오늘날 가장 큰 "클라우드" 시장입니다. IaaS(AWS, Azure, Google Cloud 등)에 대한 기대감에도 불구하고 현실은 SaaS가 도입률과 지속적인 성장 측면에서 다른 모든 형태의 "클라우드"를 훨씬 앞지르고 있다는 것입니다.

그리고 그것은 멈출 조짐을 보이지 않았습니다. 2016년 초에 실시된 여론조사에서는 SaaS의 폭발적인 성장세를 확인할 수 있었습니다 . 응답자들은 IT에서 공식적으로 지원하는 SaaS 앱의 수가 단 1년 만에 50%나 늘어났다고 보고했습니다. 2015년에는 8개가 나왔지만 2016년에는 12개가 나왔습니다. 보고서는 이 숫자가 다시 증가해 2017년에는 17명에 이를 것으로 예측했습니다.

월간투표-2016년 3월-122

"클라우드"가 벌써 10년이나 되었다는 점을 고려하면, 전통적으로 꽤 표준적인 애플리케이션으로 여겨졌던 것에 대한 채택률은 꽤나 인상적입니다. 우리는 CRM, ERP, CMS, 생산성 관련 오피스 제품군 및 파일 공유 사이트에 대해 이야기하고 있습니다.

여러분은 SaaS가 인프라 자동화와 어떤 관련이 있는지 궁금할 것입니다. 결국, 이건 사과와 스테이크잖아요. 네트워크에서 프로비저닝과 확장을 자동화하는 것은 SaaS와는 전혀 다릅니다.

다만 그게 어떤 종류인지는 알 수 없죠. 잠깐만요. 설명해드릴게요.

모든 SaaS 애플리케이션에서 공통적으로 나타나는 주제 중 하나는 기능의 상품화입니다. 파일 공유를 위한 드래그 앤 드롭은 네트워크의 공유 폴더를 사용하여 데스크톱에서 파일을 공유하든 브라우저 기반 인터페이스를 사용하여 공유하든 파일을 공유하는 꽤 잘 알려진 패러다임입니다. 문서와 프레젠테이션, 심지어 콘텐츠 게시에도 동일한 원칙이 적용됩니다. X나 Y를 수행하는 방법을 정의하는 꽤 잘 정의된 프로세스가 있으며, 인터페이스가 웹 브라우저인지 독립 실행형 앱인지는 프로세스에 큰 영향을 미치지 않고 아이콘과 인터페이스만 변경됩니다.

많은 비즈니스 기능 역시 고도로 표준화(상품화)되어 있습니다. 고객 서비스 담당자(CSR)가 매우 중요한 전화에 응답하는 과정(실제로 그렇습니다. 모두 그렇다고 확신합니다)은 상호 작용하는 상대가 누구이든 거의 동일할 가능성이 높습니다. 케이블 회사나 소매업체에 전화해 주문하면 비교적 표준화된 서비스를 받을 수 있습니다. 하지만 제 말만 믿지 마세요. 2005년 하버드 비즈니스 리뷰에 실린 이 훌륭한 기사는 프로세스 표준화에 대한 이러한 융합에 대해 논의하고 있으며, 그 후 얼마 지나지 않아 지금은 "SaaS"로 알려진 현상으로 이어졌습니다.

표준 프로세스를 통해 프로세스 역량의 아웃소싱도 더 쉬워집니다. 효과적으로 프로세스를 아웃소싱하기 위해 조직은 비용 외에도 세 가지 사항을 평가할 수 있는 수단이 필요합니다. 첫 번째는 외부 공급자의 활동 집합과 그 흐름입니다. 예를 들어, 회사 간에는 원가 계산이나 HR 혜택 관리가 정확히 무엇인지에 대한 합의에 이르지 못했기 때문에 구매자와 공급자 간에 어떤 서비스를 제공해야 하는지가 모호합니다. 따라서 조직은 아웃소싱된 프로세스를 논의할 때 쉽고 효율적으로 소통할 수 있도록 프로세스 활동에 대한 일련의 표준이 필요합니다. 이러한 프로세스 활동 및 흐름 표준은 다양한 기업과 산업에서 나타나기 시작했습니다. 일부는 800개 이상의 기업이 회원으로 있는 공급망 협의회와 같은 프로세스 그룹의 노력의 결과입니다.

어떤 프로세스가 표준화(상품화)되면 체계화하고 판매할 수 있는 프런트엔드를 적용하기가 매우 쉬워집니다. 저는 그러한 비즈니스 기능의 기본적인 상품화가 초창기 SaaS 공급업체를 스타덤으로 이끄는 데 도움이 되었다고 생각합니다. 기본적인 데이터 모델과 인터페이스를 통해 고객에게 필요한 최소한의 사용자 정의를 제공하여 프로세스를 고객의 요구 사항에 맞게 조정하는 것이 매우 쉬웠습니다. 보세요. 즉각적인 성공.

이제 이를 인프라와 네트워크에 적용해 보겠습니다. 프로비저닝, 관리, 확장과 관련된 프로세스 중 상당수가 여러 애플리케이션에서 너무나 보편화되어 있어서 넷톱은 잠자리에서도 필요한 명령을 입력할 수 있습니다. 유일한 차이점은 포트, IP 주소 및 경로와 같은 애플리케이션별 변수입니다. 이런 변화는 검토 위원회가 생각할 필요가 없기 때문에 검토 위원회가 좋아하는 변화입니다. "아, 그 앱에 방화벽 규칙을 추가하시겠어요. 승인됨."

이를 실행하는 데 넷옵스가 필요로 하는 주의와 마찬가지로, 이들의 승인은 거의 고려 사항이 필요하지 않습니다. 왜냐하면 이미 백 번이나 이루어졌고, 그 과정은 항상 동일하며, 모든 사람이 무슨 일이 일어나고 있는지 알고 있기 때문입니다. 일관성이 있고 예측 가능하며 반복 가능합니다.

승인됨.

이는 자동화 및 오케스트레이션 에 적합한 IT 내부의 상품화된 프로세스입니다. 자동화 노력에 대한 투자로 사업적 가치를 빠르게 입증하고 싶다면, 여기가 시작하기에 가장 좋은 곳입니다. 그러한 상품화된 프로세스 위에 인터페이스를 구축하고, 오늘날 사용되고 있는 수동 방식 대신 이를 프로세스에 끼워넣습니다(통합). 보세요. 해당 프로세스를 실행하는 데 드는 비용이 줄어들었고, 추가적인 이점으로 다음 변경 제어 위원회 회의를 기다릴 필요가 없으므로 작업이 더 빨리 진행됩니다(실제로, 건너뛸 수도 있는데, 이 자체로도 이점이 됩니다).

물론 시간과 돈(도구와 교육에 대한 투자)이 필요하지만 단기적인 비용은 장기적으로 볼 때 보상이 될 것입니다. 시간이 많이 걸리고 상품화된 프로세스를 자동화함으로써 엔지니어와 건축가는 다른 프로젝트에 집중할 수 있게 됩니다. 변경 제어 위원회에서 자동으로 승인될 가능성이 없는 프로젝트입니다.

SaaS는 사업을 살펴보고, 공통적인 프로세스를 이해하고, 이를 탐색할 수 있는 더 쉽고 빠른 방법을 제공할 때 성공합니다. 그건 2006년에도 사실이었고 오늘날에도 여전히 사실입니다. 인프라 자동화 노력에도 마찬가지입니다. 일반적인 프로세스를 찾아 "최종 사용자" 또는 다른 엔지니어가 탐색할 수 있는 더 쉽고 빠른 방법을 제공합니다.