저는 20년 전 소프트웨어 엔지니어로 커리어를 시작했습니다. 저뿐만 아니라 많은 사람들이 퍼블릭 클라우드의 전례 없는 성장을 목격해왔고, 지금도 그 성장세를 이어가고 있습니다.
클라우드 제공업체는 구축 방식에 대해 독단적인 견해를 가지고 있는 경우가 있습니다. 이러한 접근 방식을 플랫폼 네이티브라고 부릅니다. 이러한 공급업체는 자사 에코시스템 내에서 자사 서비스와 툴을 사용하는 방식으로 빌드하기를 원합니다. 하지만 클라우드 제공업체가 빌드 및 배포 방법을 지시해서는 안 됩니다. 대신, 워크로드에 가장 적합한 지역, 가격 또는 성능을 찾을 수 있는 곳이면 어디든 배포하고 이동할 수 있는 개방형 및 표준 기반 도구를 사용하여 워크로드를 이식할 수 있어야 합니다.
오늘날의 개발자 구매 여정
올바른 클라우드 제공업체를 선택할 때 실수를 한 적이 있습니다. 우리 중 많은 사람들이 그랬죠. 하지만 좋은 경험이든 나쁜 경험이든 이러한 경험을 통해 선택 과정의 패턴을 파악할 수 있었습니다. 그리고 개발자의 클라우드 구매 여정에서 5단계를 발견했습니다.
1. 발견하세요. 스택 오버플로나 Reddit 스레드를 읽다가, YouTube를 보다가, 이벤트에서 새로운 소식을 듣거나 어디서든 이전에 들어본 적이 없는 클라우드 서비스가 관심을 끌 수 있습니다. 그러다 갑자기 이게 뭐지? 이것이 나에게 어떻게 적용될 수 있을까? 어떻게 도움이 될까?
검색 과정에서 질문해야 할 사항은 무수히 많습니다. 목표는 클라우드 서비스를 독특하게 만드는 요소, 비슷한 제품과 차별화되는 요소, 고객에게 제공하는 구체적인 가치 제안에 대한 답을 얻는 것이어야 합니다. 서비스에 대한 약속이든 다른 것이든, "왜?"라는 질문을 던질 때 답을 찾을 수 있습니다.
2. 평가. 이 단계에서는 궁금증을 넘어 무언가를 발견했다고 확신할 수 있습니다. 이제 우리가 발견한 것을 실행하고 평가할 때입니다. 많은 시간을 투자할 계획은 세우지 마세요. 보통 문서를 작성하는 데는 15~20분 정도밖에 걸리지 않습니다. 하지만 서비스나 도구를 이해하고 이미 알고 있는 것과 어떤 차이가 있는지 평가하려면 더 깊이 들어가야 합니다.
평가하려는 서비스를 정확히 이해하는 것이 도움이 되지만, 다른 클라우드 제공업체에 대한 지식이 다소 부족하더라도 걱정하지 마세요. 예를 들어 관리형 Kubernetes 서비스를 생각해 보세요. 경쟁 서비스에 대해 잘 알고 있다면 이러한 서비스와 Linode Kubernetes Engine을 몇 가지 비교할 수 있습니다.
다음은 드론 제조업체인 스카이디오의 엔지니어링 디렉터인 엘리엇 그레이버트의 평가 사용 사례에서 발췌한 내용입니다.
"인터페이스가 상당히 동일해 보여서 어느 쪽이 더 낫다고 말할 수 없습니다. AWS 및 Azure에서 흔히 볼 수 있는 기능 부풀리기 없이 디자인이 깔끔 하고 깔끔합니다. 제 생각에는 이러한 단순함이 사용자가 들어가서 앱을 배포하고 다시 코드 작성으로 돌아가는 데 큰 도움이 됩니다." 그는 이렇게 덧붙입니다: "새로운 k8s 클러스터를 부팅하는 Linode의 놀라운 속도는 일부 사용자에게 어필할 수 있을 것이며, 전반적인 노드 배포 시간도 견고했습니다."
3. 학습. 이제 가장 중요한 단계로 넘어갈 준비가 되었습니다. 그 이유는 평가 단계에서 약간의 시간을 투자하게 되지만, 이 단계에 대부분의 시간을 투자해야 하기 때문입니다. 개발자로서 우리 머릿속에는 수많은 프로젝트가 있습니다. 이제 우리는 이 클라우드 서비스가 가치가 있는지 알아보기 위해 약간의 연습을 거치고 있습니다. 학습에 시간을 투자할 준비를 하세요. 가장 큰 질문은 다음과 같습니다: 이 클라우드 제공업체와 그 솔루션이 내 다음 프로젝트에 적합한가?
4. 빌드. 키보드에 손을 대는 것을 좋아하지 않는 엔지니어가 있을까요? 하지만 이 단계에서 종종 일이 잘못되는 경우가 있습니다. 우리는 "최소한의 사랑스러운 제품"인 MLP를 만들어야 할 때 MVP(최소 기능 제품)를 만들도록 스스로를 조절했습니다.
MVP는 최소한의 것이며, 반드시 마음에 들지는 않을 것입니다. 제가 커리어를 통해 구축한 모든 MVP 중에서 프로덕션에 적합한 MVP를 하나도 꼽을 수 없습니다. 현재 제 역할은 개발자에게 MLP를 만드는 방법을 보여주는 것입니다. 개발자가 MLP를 구축하는 데 들인 노력이 그만한 가치가 있는지 솔직하게 평가할 수 있기 때문입니다.
5. 규모. 이 단계에서는 많은 질문을 하게 될 것입니다. 규모를 이해할 때 재해 복구를 위해 한 지점에서 다른 지점으로 데이터를 복제할지, 아니면 둘 이상의 지역에 존재할지 등 여러 지역을 활용하는 방법을 알고 싶을 것입니다. 프로세스 관점뿐 아니라 인력 관점에서도 규모를 고려해야 합니다. 이 프로세스에 더 많은 인력을 투입해야 한다면 어떤 모습일까요?
또한 통합 프로세스를 이해하고 싶을 것입니다. 통합 프로세스는 CLI 또는 API를 통해 자동화에 도움이 될 수 있는 것이 무엇인지 알아보세요. 우리는 코드형 인프라(IAC) 가 주도하는 자동화의 물결 속에 있습니다. 프로세스는 확장되지만 사람은 확장되지 않는다는 사실을 잘 알고 있기 때문에 적은 자원으로 더 많은 일을 하고 있습니다. 인프라를 구축하고 확장하는 데 필요한 노력을 평가하세요.
플랫폼 네이티브 대 클라우드 네이티브
클라우드 선택은 계속 진화하는 여정이 될 것입니다. 좀 더 객관적으로 바라볼 필요가 있습니다. 제가 처음 클라우드에 뛰어들었을 때는 해당 플랫폼과 도구로만 구축했습니다. 당시 이용 가능한 모든 기술 문헌은 특정 플랫폼에 관한 것이었습니다. 하지만 엔지니어로서 성장하면서 워크로드를 선택하여 어디로든 이동할 수 있는 클라우드 네이티브 방식으로 빌드하기 시작했고, 빌드한 것을 더 잘 제어할 수 있게 되었습니다. 그리고 오픈 소스 도구의 도움으로 CI/CD, IaC, 컨테이너화와 같은 통합 표준을 채택할 수 있었습니다.
이 모든 것이 귀사의 사고 방식과 일치하고 클라우드 네이티브 방식으로 빌드하고 싶으시다면 언제든지 문의해 주세요. 저나 팀원에게 연락하여 클라우드 구매 여정에 대해 논의하세요.
내용