API 동향: 플랫폼 엔지니어링, 분리 및 AI의 역할

오픈소스 중국 커뮤니티 팀이 공유라는 이름으로 오픈소스 중국 커뮤니티의 뒷이야기를 전하는 첫 생방송을 진행했습니다."

업계 전문가 패널이 최근 몇 달간 API 환경을 형성하는 주요 동향을 살펴봅니다.

Lori Marshall이 쓴 API Trends: Platform Engineering, the Unbundling and AI's Role 에서 번역되었습니다 .

마케팅 과대 광고의 소음 속에서 개발자에게 정말로 중요한 것이 무엇인지 찾는 것은 어려울 수 있습니다. 최근 Ambassador에서는 API 개발 세계를 다루는 업계 전문가 패널을 구성하여 최근 몇 달간 API 환경을 형성하는 주요 동향을 살펴보았습니다. 이제 정말로 주의를 기울일 가치가 있는 것이 무엇인지, 배경 소음이 무엇인지 생각해 봅시다.

대디커플링(Great Decoupling)에 대한 일반적인 합의는 없습니다.

Gartner, Kong 및 기타 업계 전문가들이 지난 6개월 동안 업계에서 떠들썩한 소문에도 불구하고 API 관리의 위대한 분리 이론은 여전히 논란의 여지가 있는 주제입니다. " 대형 디커플링 "이라는 아이디어는 단일 전체 도구 모음에서 동종 최고의 틈새 솔루션으로 이동하는 데 중점을 둡니다. 일부 전문가는 이를 보다 부정적인 입장으로 보고 협력하는 대부분의 기업이 다양한 API 관리 도구를 제공 파이프라인에 통합하는 데 시간, 리소스 및 예산을 투자하고 싶어하지 않는다고 설명합니다 .

Launch Any의 업계 패널리스트이자 API 컨설턴트인 James Higginbotham은 " 많은 고객이 이러한 도구를 모두 통합하는 쉬운 방법이 없다는 점에 매우 실망하고 있습니다. 따라서 일부 사람들이 생각하는 것만큼 쉽지 않습니다."라고 말했습니다. "

그러나 또 다른 패널리스트인 키스 케이시(Keith Casey)는 디커플링이 수년 동안 무대 뒤에서 진행되고 있는 일에 대한 고개를 끄덕이는 것이라고 믿습니다. 이제서야 공개됩니다. 그는 많은 기업이 도구 세트를 표준화했다고 주장하지만 실제로는 마이크로 게이트웨이 등이 조직 전체에 배포되고 있다고 지적했습니다. 개발자가 어떤 경로를 선택하든 더 나은 도구 통합 및 패키징이 작업을 더 쉽게 만들어준다는 데 모두가 동의합니다. 간단히 말해서, API 개발 프로세스에 적용하는 전략은 기술 스택에 추가하는 도구의 수나 부족보다 더 중요합니다.

"개발자에게는 인생에서 두 가지 목표가 있습니다. 유용한 것을 만들고 집에 가는 것입니다. 지금은 유용한 것을 만드는 데 방해가 되는 것들이 너무 많아서 집에 갈 수 없고 답답합니다."

– Keith Casey, [Pangea] 수석 제품 관리자

AI는 API 보안의 양날의 검이다

AI 시스템이 일상적인 애플리케이션 및 프로세스에 더욱 통합됨에 따라 API를 통해 교환되는 데이터는 점점 더 민감해지고 잠재적으로 노출되며 가치가 높아집니다. 이러한 API를 보호하는 것은 잠재적인 위반, 데이터 유출 및 무단 액세스를 방지하는 데 중요합니다. AI 시대에 보안 위반의 잠재적 결과가 더욱 심각해짐에 따라 패널 토론에서 한 가지 분명한 결론은 API 인프라와 여기에서 처리하는 민감한 데이터를 보호하기 위해 엄격한 보안 프로토콜 구현을 우선시해야 한다는 것이었습니다.

Casey는 다음과 같이 말했습니다. “'아무도 우리 API로 그렇게 하지 않을 거야'라고 생각할 때마다 누군가가 우리 API로 그렇게 할 것이라고 가정해야 합니다. 그 사람이 인간이 아닐 수도 있다는 걸 깨닫는 거죠."

패널리스트인 APIsec University 설립자인 Dan Barahona 는 API와 AI 사이의 지속적인 얽힘 관계와 이 관계가 API 보안에 미치는 영향을 강조했습니다. AI가 공격 벡터로 사용될 수 있다는 우려가 심각하다. 매우 정교한 공격을 실행하는 것이 점점 더 쉬워지고 있습니다. 반면 AI는 국방이나 보안 분야에도 활용될 가능성이 매우 높다.

Barahona는 "방어를 위해 AI를 어떻게 활용할 수 있는지, AI 보안 공격을 어떻게 사전에 방어할 수 있는지 질문해야 합니다"라고 말했습니다. "우리는 보안 코인의 양면을 모두 평가해야 합니다. 모든 API 실무자는 '우리는 어떻게 해야 할까요?' AI를 보안 도구에 통합하시겠습니까?'

기술 리더는 개발자가 이미 탐색 및 테스트 도구로 AI를 많이 사용하고 있으며 이러한 사용은 기술이 발전함에 따라 증가할 것이라는 점을 가정해야 합니다. 지금 AI 정책과 모범 사례를 수립하고 어떤 도구도 강력한 개발자를 완전히 대체할 수 없다는 점을 인식하면서 AI 도구의 기능을 극대화하는 방법을 깊이 이해하고 있는 개발자를 고용하십시오.

또한, 패널리스트들은 수동적인 보안 조치를 취하는 데 중점을 두는 논란의 여지가 있는 "Shield Right"와 달리 보안 분야에서 "Shift Security Left"를 강력히 추진하는 것으로 보인다는 점에 주목했습니다. 배포된 시스템을 잠재적인 위협으로부터 보호하기 위해 Shift Left를 사용합니다. , 반면, API 게이트웨이( https://www.getambassador.io/products/edge-stack/api-gateway/security) 와 같은 도구의 조기 통합과 같은 취약점을 방지하기 위해 개발 프로세스 초기에 사전에 보안을 통합하는 것을 우선시합니다. -인증) 이러한 초기 통합을 통해 보안 문제를 조기에 해결한다는 "왼쪽 이동" 철학에 따라 보안 기능을 개발 프로세스에 구축할 수 있습니다.

우수성 센터에서 역량 강화 센터로

플랫폼 엔지니어링이 전 세계를 휩쓸고 있는 동안 우리는 먼저 브레이크를 밟고 기본 사항을 바로잡아야 합니다. 때때로 플랫폼 팀이나 COE(Center of Excellence)에 대한 신화는 그들이 DevOps 과제에 대한 솔루션의 필수적인 부분이 되기보다는 상아탑에서 성명을 발표하고 있다는 것입니다. 패널리스트들은 초점이 "이 플랫폼을 어떻게 관리합니까?"에서 "사람들의 생산성을 높이도록 어떻게 도울 수 있습니까?"로 발전해야 한다는 데 동의했습니다.

“조금 뒤로 물러나 플랫폼 엔지니어링 열풍에서 벗어나면, 플랫폼 엔지니어링은 현재 내부적으로 매우 집중적이고 방대하며, 플랫폼에 대해 이야기하기 전에 개발자를 위한 자동화 활성화 작업을 많이 해야 합니다. ” Higginbotham 공유 도로. "API 활성화에 초점을 맞추고 활성화 센터 또는 우수 센터를 살펴보도록 대화를 옮겨보겠습니다."

Casey는 C4E(지원 센터)로의 이동이 성공적인 실제 플랫폼 엔지니어링의 핵심이라고 말하면서 Higginbotham의 의견을 반영했습니다. 그는 사람들에게 봉사하고 생산성을 높이도록 돕는 사고 방식을 높은 수준의 성명을 발표하고 개발자가 이를 맹목적으로 따르기를 기대하는 전통적인 접근 방식을 대조했습니다.

Higginbotham은 "COE는 API를 구현하고 제공하는 코드에 중점을 두기보다는 API 디자이너, 프로비저닝 팀 및 소비자를 활성화하는 데 중점을 두고 있습니다."라고 말했습니다.

예를 들어, API를 구축하는 팀이 있다면 조직 내에서 이를 사용하는 150개의 서로 다른 팀이 있을 수 있습니다. 즉, 린 플랫폼 팀이 없으면 매번 똑같은 대화를 할 때마다 150명의 이해관계자와 협력하게 될 수 있습니다.

COE 접근 방식을 취하는 탄탄한 플랫폼 팀에 투자한다는 것은 이러한 대화를 완전히 줄이거나 없앨 수 있는 적절한 문서, 지원, 코드 샘플 및 기타 리소스에 투자한다는 것을 의미합니다. 또한 이러한 리소스를 통해 소비자는 API 사용을 더 효과적으로 시작할 수 있습니다.

따라서 결론은 다음과 같습니다. 제공 지원 및 개발자 지원에 먼저 초점을 맞추는 한 플랫폼 엔지니어링은 API 개발에서 점점 더 중요해지고 있습니다. 진정한 API 성공을 달성하려면 플랫폼 전략과 COE가 함께 협력해야 합니다.

마침내

이는 새로운 개념은 아니지만 API 개발 리더가 이러한 추세에 대해 취하는 접근 방식과 실사는 개발자가 긍정적으로 대응할 수 있는지 여부에 큰 변화를 가져올 것입니다. 자세한 내용은 YouTube 채널 에서 API 관리 팀의 전체 기술 토론을 확인하세요 .

이 기사는 Yunyunzhongsheng ( https://yylives.cc/ ) 에 처음 게재되었습니다 . 누구나 방문하실 수 있습니다.