"좋은" 플랫폼 엔지니어링이란 무엇입니까?

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

플랫폼 엔지니어링 접근 방식은 개발자의 시간을 절약하고 팀은 개발자의 일상적인 요청의 전체 범주를 제거할 수 있습니다.

플랫폼 엔지니어링: '좋은' 모습은 무엇입니까? (저자 Dormain Drewitz) 에서 번역되었습니다 .

개발자 경험을 개선하기 위해 점점 더 많은 조직이 지루한 작업을 줄이고 수익 창출 기능과 혁신에 집중하기 위해 플랫폼 엔지니어링을 찾고 있습니다.

플랫폼 엔지니어링은 두 가지 주요 이점을 제공합니다. 첫 번째는 조직 내 사람들이 새로운 소프트웨어를 시험해 볼 수 있도록 하는 셀프 서비스 기능의 도입입니다. 두 번째는 잘 관리되는 환경에서 실험이 수행되도록 자동화된 인프라 운영을 통합하는 것입니다.

Gartner는 2026년까지 대규모 소프트웨어 엔지니어링 조직의 80%가 플랫폼 엔지니어링 팀을 보유하게 될 것으로 예상할 정도로 이점이 매우 큽니다 . 하지만 과대 광고 뒤에는 무엇이 있습니까?

플랫폼 엔지니어링이란 무엇입니까?

플랫폼 엔지니어링 접근 방식은 DevOps를 보완합니다 . "플랫폼"은 개발자가 안전하고 규정을 준수하는 환경에서 소프트웨어(예: 애플리케이션, 도구, 워크플로)를 구축하고 실행할 수 있도록 만들어진 내부 환경입니다.

플랫폼 엔지니어링의 주요 목적은 보안 및 가용성 위험을 완화하면서 개발자의 작업을 효율적으로 확장하는 것입니다. 개발자 플랫폼은 대규모 개발에 따른 막대한 비용과 복잡성을 해결합니다. 이러한 비용이 발생하는 가장 일반적인 이유는 개발자가 각 프로젝트(또는 프로젝트 내의 개별 테스트 사례)에 대해 별도의 환경을 가동하기 때문입니다. 또 다른 이점은 통합 플랫폼 내에서 작동하는 운영 프로세스를 자동화하는 기능으로 인해 대규모로 작업할 수 있는 가능성이 높아진다는 것입니다.

이 접근 방식이 성공하려면 소프트웨어가 동일한 플랫폼 내에 배포되어야 합니다. 표면적으로 이는 플랫폼 엔지니어링 접근 방식이 생산성 제약처럼 보일 수 있지만 실제로는 개발자의 창의성을 발휘하고 일상적인 지루한 작업을 크게 줄일 수 있습니다.

구축 vs. 구매: 조직에서는 이를 어떻게 구현합니까?

플랫폼 프로젝트가 성공하려면 플랫폼이 올바르게 구현되어야 합니다. 조직에서는 플랫폼에 대한 사용자 정의가 필요하기 때문에 단순히 기성 제품을 구매하는 것은 불가능합니다. 동시에 프로덕션에서 소프트웨어를 배포하고 실행할 때 발생하는 수많은 인프라, CI/CD, 보안 및 기타 "수행해야 할 작업"을 처리하는 데 사용할 수 있는 수많은 포인트 제품과 오픈 소스 프로젝트가 있습니다.

이는 조직이 구매하는 제품이나 채택한 오픈 소스 소프트웨어에 대해 일부 엔지니어링 작업을 수행해야 함을 의미합니다. 하지만 문제는: 자신의 디자인 중 어느 정도가 적절한가 하는 것입니다. 플랫폼 엔지니어링은 이러한 조직을 차별화하는 요소를 추진하기보다는 비즈니스 목표를 방해할 수 있습니다.

이 문제에 대한 해결책은 조직이 가능한 가장 효율적인 플랫폼을 구축하는 것입니다. 플랫폼 엔지니어링 팀은 처음부터 구축해서는 안 됩니다. 플랫폼은 다른 플랫폼 위에 구축되어야 합니다. 조직에서는 소프트웨어 팀이 서버 연결부터 제품 제공까지 모든 작업을 수행할 것으로 기대하지 않으며, 플랫폼 엔지니어링 팀이 처음부터 플랫폼을 완전히 구현할 것이라고 기대해서는 안 됩니다.

대신, 이들 팀은 거인의 어깨 위에 구축해야 합니다. 이러한 접근 방식을 추진하려면 조직은 가능한 한 많은 PaaS(Platform-as-a-Service) 및 SaaS(Software-as-a-Service) 도구를 구매하고 이를 함께 묶어 완성되고 실행 가능한 플랫폼을 구축해야 합니다. 가장 기본적인 플랫폼 경험을 유지 관리, 통합 및 업데이트하는 작업은 충분합니다. 여기에는 내부 엔지니어가 사용할 건물 인터페이스와 API가 포함되어 공급업체 종속을 완화할 수 있습니다.

이 모델에서 각 조직의 플랫폼은 맞춤형으로 구축되지만 기존의 지원되고 구매 가능한 도구 위에 위치합니다. 이 접근 방식을 통해 조직은 구축 대 구매 딜레마에서 벗어나 조직의 요구 사항을 충족하도록 플랫폼을 미세 조정하는 데 집중할 수 있습니다.

그것이 표준이 되려면 어떻게 해야 합니까?

많은 조직이 DevOps를 채택할 때 역할과 책임이 부담스러워 보일 수 있기 때문에 어려움을 겪습니다. 개발자가 매일 생산 과정에서 스택의 모든 것을 책임진다면 비즈니스 가치를 제공하지 않는 지루한 작업에 갇힐 수 있습니다. 그러나 기존 아키텍처 및 운영 팀은 개발자 효율성을 측정하지 않는 경우가 많으므로 개발자는 티켓을 제출하고 기다리기만 하면 됩니다.

플랫폼 엔지니어링이 성공하려면 조직의 전적인 지원이 필요합니다. 내부 사용자를 위한 더 나은 경험을 구축하려면 사일로를 제거해야 합니다. 플랫폼 엔지니어링이 성공하려면 자체 팀이 필요합니다. 이를 단순히 IT의 확장으로 볼 수는 없습니다.

운영 변경 외에도 플랫폼 엔지니어링에서는 개별 기능 외에도 유용성, 보안 등 비기능적 요구 사항을 우선시하기 위해 개발 팀의 문화적 변화가 필요합니다. 플랫폼은 올바른 일을 쉽게 할 수 있도록 도와야 하지만 책임은 린 플랫폼 팀과 사용자(소프트웨어 개발 팀) 간에 공유되어야 합니다.

조직이 업무 프로세스를 전면적으로 점검할 때 항상 그렇듯, 일을 중간에 진행하는 것만으로는 충분하지 않습니다. 기업은 조직 내 모든 개발자의 전폭적인 지원과 고위 팀원의 승인 없이는 플랫폼 엔지니어링을 성공적으로 구현할 수 없습니다.

개발자가 왜 관심을 가져야 합니까?

대규모 소프트웨어 엔지니어링 조직은 크고 복잡한 기술 스택을 보유하기 쉽습니다. 이로 인해 유지 관리가 악몽이 되고 길고 느린 릴리스 주기와 스트레스가 많은 중단이 발생할 수 있습니다. 플랫폼 엔지니어링을 채택하면 훨씬 더 간결한 스택을 위해 복잡성을 교환하고 중요하지 않거나 성가신 부분을 제거합니다. 의사 결정자는 필요하지 않은 도구를 폐기하거나 환경을 종료하는 것을 두려워해서는 안 됩니다. 심지어 개발자가 사용 중인 플랫폼을 신뢰하면 이 프로세스를 자동화하는 것도 필요합니다. 실제로 자동화는 폐기를 플랫폼 수명주기의 일부로 만들어 이를 기존 프로세스에 통합하여 시간과 비용을 절약할 수 있습니다.

플랫폼 엔지니어링 접근 방식은 개발자는 물론 인프라 및 운영 팀의 시간도 크게 절약할 수 있습니다. 이러한 팀은 개발자의 일상적인 요청 범주 전체를 제거할 수 있습니다. 플랫폼 팀은 새로운 환경 시작, 인프라 관리, 리포지토리 생성 및 구성, CI/CD 파이프라인 처리 등 일상적이고 반복적인 작업을 자동화하여 개발 주기를 원활하게 하고 지루한 작업을 줄입니다.

개발자는 작업을 플랫폼으로 오프로드하여 시간과 노력을 절약할 수 있으며, 이는 기존 애플리케이션을 플랫폼으로 마이그레이션하는 데 큰 인센티브를 제공할 수 있습니다. 이러한 이점은 개발자의 생산성이 향상되어 서비스를 확대하기 위해 추가 계약자와 직원이 필요하지 않음으로써 기업에 상당한 비용 절감으로 이어질 수도 있습니다.

미래를 위한 플랫폼 엔지니어링

궁극적으로 플랫폼 엔지니어링의 목표는 개발자가 팀이나 기능에 관계없이 플랫폼 외부를 실험하기보다는 플랫폼을 사용하도록 장려하는 것입니다. 완전히 구현된 툴체인과 워크플로를 사용하여 이 설정의 프레임워크 내에서 작업할 때 개발자는 인프라에 대해 걱정하지 않고 코딩에 집중할 수 있습니다. 이를 통해 일일 작업량이 크게 줄어들어 단순히 생존하는 것이 아니라 번영할 수 있습니다.

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