워크플로우 대 API

오늘은 당신을 위한 일을 가져왔습니다. 제가 원하는 건 당신이 – 그래요, 바로 당신이 그 자리에 있죠 – 은행에 수표를 입금하는 거예요. 차에 타서 은행으로 가서 안으로 들어가서 직원과 그 일을 한 다음 집으로 돌아와야 합니다.

짜증나? 특히, 추가 단계 없이 모바일 뱅킹 앱만으로 할 수 있으니 더욱 그렇습니다.

여러분, 이것이 바로 워크플로(프로세스)와 API의 차이입니다.

API 세금 이라는 아주 실제적인 것이 있습니다(이름은 제가 지었지만 실제로 존재하는 것은 아닙니다). 이는 개별 API 호출을 사용하여 복잡한 프로세스를 실행하는 데 발생하는 시간과 기술적 부채입니다. 모바일 앱을 사용하여 입금하는 대신 실제로 은행에 가는 것과 같습니다.

이 세금은 프로세스가 확장됨에 따라 증가합니다. 10~20개의 서로 다른 API 호출이 필요한 긴 프로세스가 있는 경우 코드(스크립트도 코드임)가 점점 더 복잡해져 문제 해결에 영향을 미치고 나중에 변경하기가 더 어려워집니다. 개별 API 호출을 통해 프로세스를 골화하는 것은 민첩성의 반대입니다. 최적화를 통해 효율성을 개선할 수 있는 기회를 막는 것은 취약성입니다.

워크플로는 기본적으로 일반적으로 실행되는 작업에 대해 미리 정의된 프로세스입니다. 대부분의 비즈니스(운영) 프로세스가 이 범주에 속합니다. 이는 로그인하고, 시스템의 오른쪽 부분으로 이동하고, 포트의 액세스 제어를 변경한 다음 변경 사항을 커밋하는 데 사용하는 명령입니다. 이 작업을 할 때마다 똑같은 일이 일어납니다. 이는 쉽게 체계화될 수 있는 흔히 실행되는 프로세스입니다. 운영에는 이와 같은 프로세스가 많이 있으며, 이를 워크플로로 묶으면 API 세금을 없앨 수 있을 뿐만 아니라 이를 호출하는 스크립트의 품질과 지속 가능성을 개선할 수 있습니다.

API 대신 워크플로를 사용하면 코드가 덜 복잡해지고 관리 및 변경이 더 쉬워지기 때문입니다. 그들은 더 민첩하고 덜 취약합니다.

완전히 날조된 예를 생각해 보겠습니다. 첫 번째는 API 기반 접근 방식입니다. 해당 과정의 각 단계는 API 호출을 나타냅니다. 즉, 거의 20개의 서로 다른 호출이 포함된 스크립트를 시간이 지남에 따라 개발, 테스트 및 유지 관리해야 한다는 뜻입니다. 그것이 기술적 부채입니다. 이 기능은 작성 당시 사용하던 시스템의 API 버전에 연결되어 있습니다. 해당 통화 중 하나가 변경되면 스크립트도 변경해야 합니다.

오른쪽에는 워크플로 기반 접근 방식이 있습니다. API 호출을 통해 프로세스를 시작할 수도 있지만(많은 조직에서 선호할 가능성이 높음) 프로세스의 실제 단계는 초기 호출과 함께 전송된 매개변수(변수)를 기반으로 실행됩니다. 정리하고 커밋해야 할 수도 있지만, 그래도 필요한 코드를 두 번 이하의 상호 작용으로 줄였습니다.

하지만 API와 템플릿을 사용하는 것이 나쁘다는 것은 아닙니다. 그렇지 않아요. 하지만 특히 네트워크 분야에서는 API를 사용하려면 시스템과 네트워킹 전반에 대한 지식이 필요한 경우가 많습니다. 이로 인해 DevOps나 개발자가 API를 사용하기가 어려워집니다. 워크플로우 방식은 지식이나 전문성에 대한 가정을 없애므로 DevOps가 이를 편안하게 사용할 수 있고 NetOps는 직무 안정성을 유지할 수 있습니다.  

자동화가 확산되고 있는(심지어 인수까지 진행 중인) 환경에서 워크플로 기반 접근 방식은 DevOps가 특정 분야에 대한 지식이 크게 필요 없이 작업을 호출할 수 있도록 하여 NetOps에 실질적인 도움을 줄 수 있습니다.

그리고 귀찮은 API 세금도 피할 수 있습니다. 세금을 피하는 것을 싫어하는 사람이 어디 있겠어요?