선언적 인터페이스가 인프라를 민주화하는 방법

API는 새로운 CLI입니다. 하지만 어떤 종류의 API를 빌드하는지에 관해서는 선언형이 우세합니다.

API(애플리케이션 프로그래밍 인터페이스)는 오늘날 매우 중요한 기능입니다. 조직에서는 소위 "시민 개발자"에 의한 파트너 통합과 혁신을 촉진하기 위해 비즈니스 계층에 이를 적용합니다. 애플리케이션은 통합을 용이하게 하고, 자주 변경될 수 있는 비즈니스 로직과 자주 변경되어서는 안 되는 인터페이스를 분리하기 위해 이러한 기능을 제공합니다. 그리고 인프라가 그것을 가지고 있습니다. 스위치에서 라우터까지, 애플리케이션 서비스에서 미들웨어와 데이터베이스에 이르기까지, 전달 및 배포 파이프라인을 구성하는 인프라는 API를 통해 활성화됩니다.

그 자체로, NetOps 커뮤니티의 미래에 대해 잠시 멈추어 생각해 볼 만한 이유가 됩니다. 조직이 몇 가지 핵심 애플리케이션 인프라 구성요소를 표준화하는 경향이 있는 반면, 몇 가지 핵심 네트워크 및 애플리케이션 서비스 인프라 구성요소만으로는 표준화할 가능성이 낮기 때문입니다.

평균적으로 조직에서 앱을 더 빠르고 안전하게 만들기 위해 사용하는 16가지의 다양한 애플리케이션 서비스는 소수의 인프라 구성 요소를 통해 제공된다는 것은 확실합니다. 구성 요소당 애플리케이션 서비스가 3개라고 관대하게 가정하더라도 여전히 5개의 서로 다른 장치, 즉 5개의 서로 다른 API가 있습니다.

여기서 문제점은 인프라 제공업체가 "API는 새로운 CLI입니다"라는 진술을 너무 문자 그대로 받아들이는 경우가 많다는 것입니다. 즉, API는 CLI를 REST 방식으로 반영한 것일 뿐입니다.

인프라 구성 요소 전반에서 CLI를 사용해 본 사람이라면 CLI 탐색이 인프라의 개체 모델과 매우 밀접하게 매핑된다는 사실을 알고 있을 것입니다. API는 이 디자인을 HTTP로 옮겨 적용하는 것 이상의 역할을 하지 못하는 경우가 많습니다. 즉, API를 활용하려면 해당 장치의 개체 모델도 반드시 알아야 합니다.

이러한 수준의 추상화는 자동화 및 오케스트레이션의 진전을 방해하고 있습니다. 왜냐하면 이제 우리는 자동화 인재뿐만 아니라 5개 이상의 다양한 네트워크 인프라 모델에 대한 어느 정도의 전문성을 갖춘 자동화 인재를 찾아야 하기 때문입니다. 필요한 전문성 수준을 위해서는 VLAN 구성과 라우팅에 대한 기초적인 이해부터 가상 서버, 가상 IP 주소, 노드, 멤버 및 풀 간의 관계까지 다양한 도메인 지식도 필요합니다.

인프라의 기본적인 복잡성을 노출시키는 것은 도입을 촉진하고 자동화를 실현하는 데 해롭습니다. 인터페이스의 목적은 사용자와 운영자를 복잡성으로부터 보호하기 위해 모델과 논리를 추상화하는 것입니다. GUI는 간단한 서비스를 구성하기 위해 개체 계층을 탐색할 필요성을 제거하여 이를 수행합니다.

그렇기 때문에 API가 이러한 탐색 악몽을 다시 불러왔다는 사실을 발견하면 종종 실망스러워집니다.

이 문제는 네트워크와 애플리케이션 인프라에서만 나타나는 것이 아닙니다.  즉, MuleSoft는 " API의 상승하는 가치 " 조사에서 고객 및 파트너가 API 통합에 대해 가장 많이 요구하는 것(응답자의 47%)이 "특정 비즈니스 요구 사항에 맞는 맞춤형 API"라고 밝혔습니다. 그 이면에는 더 나은 문서화(19%), '코드 없음' 통합 템플릿(19%), 필요하고 사용하는 API에 대한 SDK 래퍼(13%)가 있었습니다.

이 모든 것은 단순화에 대한 호소로 요약될 수 있습니다. 그리고 기술에서 단순화는 추상화를 의미합니다.

이제 이 글의 요점에 대해 이야기하겠습니다. 즉, 선언적 인터페이스는 그러한 추상화라는 것입니다. 오늘날 인프라를 프로비저닝, 구성, 관리 및 통합하는 데 사용되는 인터페이스를 단순화함으로써 선언적 인터페이스는 인프라를 민주화하고 기회를 열어줍니다. 

선언적 대 명령적

일반적으로 선언형과 명령형은 모두 API 유형으로 볼 수 있습니다. 명령형 API는 누군가가 API라고 말할 때 떠오르는 API입니다. 대상 시스템에 정확히 어떻게 해야 할지 알려줍니다. 가상 서버를 추가하려면 5~10회 또는 그 이상의 별도 API 호출이 필요하더라도 해당 작업을 수행하는 방법을 정확하게 지정해야 합니다.

즉, 적절한 속성을 가진 특정 객체(예: IP 주소가 있는 노드)를 생성하도록 지시하는 것입니다. 그런 다음 시스템에 별도로 할당할 풀과 이름을 생성하도록 지시해야 합니다. 그럼 당신은 ... 글쎄요, 이제 요점을 알았겠죠. 명령형 API는 사용자에게 시스템과 객체 모델을 이해해야 하는 부담뿐만 아니라 의도한 결과를 달성하는 데 필요한 단계도 이해해야 하는 부담을 줍니다.

그건 필수적으로 내야 하는 API 세금이에요.

물론, 명령형 API는 전반적으로 나쁜 것은 아닙니다. GUI를 구축하거나 명령형 API에서 얻을 수 있는 종류의 세분성이 필요한 다른 시스템과 통합할 때 매우 중요합니다. 명령형 API도 필요하지만 자동화와 통합에 직면한 NetOps와 DevOps에는 필요하지 않습니다.

하지만 우리 대부분은 그 수준의 세부 사항을 알 필요가 없습니다. 실제로 그렇게 심도 있는 지식을 요구하는 것은 기분 나쁘게 만들 수도 있고 자동화 및 오케스트레이션 작업을 지연시킬 수도 있습니다. 이는 DevOps 및 개발자를 위한 셀프 서비스 모델을 활성화하고 인프라를 민주화하는 데 전혀 적합하지 않으며, 특정 인프라 도메인 외부의 NetOps에는 더더욱 적합하지 않습니다.

여기서 선언적 API가 등장하게 됩니다.

선언적 인터페이스는 사용자가 무엇을 하려는지 구체적으로 지정하고, 논리와 작업 흐름은 시스템에 맡깁니다. 따라서 시스템에 노드와 풀을 생성하고 필요한 모든 로직을 수행하라고 구체적으로 지시하는 대신, 해당 객체와 객체 간의 관계를 설명합니다 .

일부 선언적 인터페이스는 JSON을 사용하고, 다른 인터페이스는 XML을 사용하고, 일부는 여전히 간단한 양식 데이터를 사용합니다. 이 모든 이론에서 공통적으로 발견되는 점은 데이터가 객체 모델과 시스템 계층 구조에 대한 이해가 거의 필요 없는 간단하고 직관적인 방식으로 객체를 설명한다는 것입니다.

예를 들어, 이 선언문은 사람이 읽기에 꽤 쉽습니다. 이는 객체 모델에 대한 기본 수준의 이해를 가정하지만 선언문을 작성하기 위해 특정 제품에 대한 인증을 요구할 정도는 아닙니다. 

"웹 풀": {
"클래스": "풀",
"모니터": [
"http"
],
"멤버": [
{
"servicePort": 80,
"서버 주소": [
"192.0.1.10",
"192.0.1.11"
]
}
]
}

선언적 인터페이스의 가치가 드러나는 부분은 바로 도메인 지식이 줄어들고 인프라 프로비저닝과 구성의 복잡성이 줄어든다는 점입니다. 필요한 전문성 수준을 낮추면 NetOps가 더 빠르고 효율적으로 작업할 수 있을 뿐만 아니라 DevOps 및 개발자가 해당 기능을 활용하도록 독려할 수도 있습니다.

인프라를 관리하는 표준 방법으로 선언적 인터페이스를 채택하면 셀프 서비스와 고급 자동화 기능을 제공하기 위해 활용할 수 있는 인재 풀이 즉시 확대됩니다. 위의 선언적 인터페이스는 DevOps와 개발자가 이해하고 사용할 수 있도록 하는 데 거의 설명이 필요하지 않습니다. 반면, 필수 인터페이스의 경우 결과를 기대하기 전에 인프라별 모델과 워크플로를 배우는 데 훨씬 더 많은 주의가 필요합니다.

선언적 인터페이스는 배포 파이프라인을 자동화하고 시스템을 다른 인프라 서비스와 통합하는 데 필요한 프로비저닝, 구성 및 관리를 단순화하여 인프라를 민주화합니다. 인프라를 민주화하면 더 빠르고 스마트한 자동화가 가능해지고, NetOps와 DevOps 운동의 이점을 실현하는 데 필요한 운영 도메인 전반의 협업과 협조를 장려할 수 있는 능력이 향상됩니다.