Google Cloud님께, 이전 버전과 호환되지 않으면 목숨을 잃을 수 있습니다.

빌어먹을 구글, 난 다시는 블로그를 하고 싶지 않았다. 할 일이 너무 많아요. 블로깅에는 시간, 에너지, 창의성이 필요하며 이를 잘 활용할 수 있습니다. музыка, 내 게임 등등. 하지만 당신은 내가 이 글을 써야 할 정도로 나를 화나게 했습니다.

그럼 이것으로 끝내겠습니다.

제가 처음 Google에서 일하기 시작했을 때의 짧지만 유익한 이야기부터 시작하겠습니다. 최근에 Google에 대해 나쁜 말을 많이 했다는 것을 알고 있지만, 우리 회사가 정기적으로 무능한 비즈니스 결정을 내리는 것을 보면 속상합니다. 동시에 우리는 이에 대한 정당성을 부여해야 합니다. Google의 내부 인프라는 정말 탁월하며 오늘날 이보다 더 좋은 것은 없다고 해도 무방합니다. Google의 창립자들은 나보다 훨씬 뛰어난 엔지니어들이었으며, 이 이야기는 그 사실을 확인해 줄 뿐입니다.

첫째, 약간의 배경 지식: Google에는 다음과 같은 데이터 저장 기술이 있습니다. 빅테이블. 이는 최초의 (최초는 아니지만) "무한 확장 가능한" 키-값 저장소(K/V) 중 하나인 놀라운 기술적 성과였으며, 본질적으로 NoSQL의 시작이었습니다. 요즘 빅테이블은 다소 혼잡한 K/V 스토리지 공간에서 여전히 잘나가고 있지만, 당시(2005년)에는 놀라울 정도로 멋졌다.

Bigtable의 한 가지 재미있는 점은 대규모 인덱스가 있는 태블릿 서버라는 내부 제어 평면 개체(구현의 일부로)가 있었고 어느 ​​시점에서 시스템을 확장할 때 병목 현상이 발생했다는 것입니다. Bigtable 엔지니어들은 확장성을 어떻게 구현해야 할지 고민하던 중 갑자기 태블릿 서버를 다른 Bigtable 스토리지로 교체할 수 있다는 사실을 깨달았습니다. 따라서 Bigtable은 Bigtable 구현의 일부입니다. 이러한 저장 시설은 모든 수준에 있습니다.

또 다른 흥미로운 세부정보는 Bigtable이 한동안 Google 내에서 널리 사용되고 각 팀이 자체 저장소를 갖게 되었다는 것입니다. 그래서 금요일 회의 중 하나에서 Larry Page는 우연히 지나가면서 이렇게 물었습니다. “왜 우리는 Bigtable을 두 개 이상 가지고 있나요? 왜 한 개만 안 됩니까?” 이론적으로는 하나의 저장 공간으로 Google의 모든 저장 공간 요구사항을 충족할 수 있습니다. 물론 실제적인 개발 이유(예: 잠재적인 실패의 결과)로 인해 단 하나의 방법만 사용하지는 않았지만 이론은 흥미로웠습니다. 전체 우주를 위한 하나의 저장소(그건 그렇고, Amazon이 Sable을 사용하여 이 작업을 수행했는지 아는 사람이 있습니까?)

어쨌든, 여기 내 이야기가 있습니다.

당시 저는 Google에서 근무한 지 XNUMX년 남짓이었는데 어느 날 Bigtable 엔지니어링 팀으로부터 다음과 같은 이메일을 받았습니다.

친애하는 스티브,

안녕하세요, 빅테이블 팀입니다. [데이터 센터 이름]에서 매우 오래된 Bigtable 바이너리를 사용하고 있음을 알려드립니다. 이 버전은 더 이상 지원되지 않으며 최신 버전으로 업그레이드할 수 있도록 도와드리고 싶습니다.

이 문제에 대해 함께 작업할 시간을 계획할 수 있는지 알려 주시기 바랍니다.

모두 제일 좋다,
빅테이블 팀

Google에서는 많은 메일을 받기 때문에 언뜻 보면 다음과 같은 내용을 읽었습니다.

수신자님께,

안녕하세요, 어떤 팀에서 왔습니다. 우리는 저쩌고 저쩌고 저쩌고 전하고 싶습니다. 어쩌고 저쩌고 저쩌고 저쩌고, 그리고 어쩌고 저쩌고 즉시.

어쩌고 저쩌고 소중한 시간을 계획할 수 있는지 알려주세요.

모두 제일 좋다,
일종의 명령

바로 지울 뻔했는데, 의식의 가장자리에서 괴로운 잔소리가 느껴졌다. 별로 공식적인 편지처럼 보이지만 분명히, 제가 ​​Bigtable을 사용하지 않았기 때문에 수신자가 착각했다고 합니다.

그러나 그것은 이상했다.

나는 하루 종일 일과 작은 부엌에서 어떤 종류의 상어 고기를 먹을까를 번갈아 생각하면서 보냈는데, 그 중 적어도 세 마리는 내 자리에서 비스킷을 잘 던져 맞힐 만큼 가까웠지만, 글을 쓴다고 생각하면 가벼운 불안이 커지는 느낌이 들지 않았습니다.

그들은 내 이름을 분명히 말했어요. 그리고 그 이메일은 다른 사람의 이메일 주소가 아닌 내 이메일 주소로 전송되었으며, 참조:나 숨은 참조:도 아닙니다. 톤은 매우 개인적이고 명확합니다. 어쩌면 이것은 일종의 실수일까요?

마침내 호기심이 더욱 커져서 그들이 언급한 데이터 센터에 있는 Borg 콘솔을 보러갔습니다.

물론 BigTable 스토리지도 관리하고 있었습니다. 미안해요, 뭐라고요? 내용을 살펴보니 와! 2005년 XNUMX월 Google에서 근무한 첫 주 동안 제가 참여했던 Codelab 인큐베이터에서 나온 내용이었습니다. Codelab에서는 거기에 일부 값을 작성하기 위해 Bigtable을 실행하도록 강요했고, 그 이후에는 저장소를 닫지 않은 것 같습니다. XNUMX년 이상이 지났음에도 여전히 작동하고 있었습니다.

이 이야기에는 몇 가지 주목할만한 측면이 있습니다. 첫째, Bigtable의 작업은 Google 규모에서 너무 중요하지 않았기 때문에 불과 XNUMX년 후에 누구나 추가 저장 공간을 알아차렸는데, 이는 바이너리 버전이 오래되었기 때문입니다. 비교를 위해 한때 사용을 고려했습니다. Google Cloud의 Bigtable 내 온라인 게임을 위해. 당시 이 서비스 비용은 연간 약 $16였습니다. 비어 있는 GCP의 빅테이블. 그들이 당신을 속이고 있다는 말은 아니지만, 내 개인적인 생각으로는 빈 데이터베이스에 돈이 너무 많이 드는 것 같아요.

또 한 가지 주목할만한 점은 저장 공간이 있다는 것입니다. XNUMX년이 지나도 여전히 일을 하고 있다. 뭐야? 데이터 센터는 왔다 갔다 합니다. 가동 중단이 발생하고, 예정된 유지 관리가 진행되며, 항상 변경됩니다. 하드웨어가 업데이트되고, 스위치가 교체되며, 모든 것이 지속적으로 개선되고 있습니다. 도대체 어떻게 이 모든 변화에도 불구하고 내 프로그램을 2020년 동안 계속 실행할 수 있었습니까? 2005년에는 작은 성과처럼 보일 수도 있지만, 2007~XNUMX년에는 상당히 인상적이었습니다.

그리고 가장 멋진 점은 다른 주에 있는 외부 엔지니어링 팀이 작고 거의 비어 있는 Bigtable 인스턴스의 소유자인 나에게 접근했다는 것입니다. 트래픽 제로 지난 XNUMX년 동안 업데이트할 수 있도록 지원을 제공하고 있습니다.

나는 그들에게 감사를 표하고 저장 공간을 삭제했으며 삶은 평소와 같이 계속되었습니다. 하지만 XNUMX년이 지난 지금도 나는 아직도 그 편지를 생각합니다. 가끔 Google Cloud로부터 비슷한 이메일을 받기 때문입니다. 그것들은 다음과 같습니다:

Google Cloud 사용자님께,

참고로, 2020년 XNUMX월부터 [사용하는 필수 서비스] 서비스가 중단되며, 이후에는 인스턴스를 업그레이드할 수 없습니다. 베타 테스트 중이고 문서도 없고 마이그레이션 경로도 없으며 친절한 도움을 받아 이전에 구식이었던 최신 버전으로 업그레이드하는 것이 좋습니다.

우리는 이번 변경사항이 Google Cloud 플랫폼의 모든 사용자에게 최소한의 영향을 미치도록 최선을 다하고 있습니다.

영원히 가장 친한 친구,
구글 클라우드 플랫폼

그러나 나는 그런 편지를 거의 읽지 않습니다. 왜냐하면 그들이 실제로 말하는 내용은 다음과 같기 때문입니다.

수신자님께,

지옥 에나 가라. 엿 먹어, 엿 먹어, 엿 먹어. 중요하지 않기 때문에 당신이하는 모든 일을 중단하십시오. 중요한 것은 우리의 시간입니다. 우리는 쓰레기를 유지하는 데 시간과 돈을 낭비하고 그것에 지쳐서 더 이상 지원하지 않을 것입니다. 그러니 빌어먹을 계획을 그만두고 우리의 엉뚱한 문서를 파헤치기 시작하고 포럼에서 스크랩을 구걸하세요. 그런데 우리의 새로운 것은 이전의 것과 완전히 다릅니다. 왜냐하면 우리가 이 디자인을 꽤 나쁘게 망쳤기 때문입니다. 문제는 우리가 아닙니다.

우리는 귀하의 모든 개발이 XNUMX년 이내에 사용할 수 없게 되도록 계속 노력하고 있습니다.

제발 꺼져
구글 클라우드 플랫폼

그리고 사실 저는 한 달에 한 번 정도 그런 편지를 받습니다. 이런 일이 너무 자주, 지속적으로 일어나서 필연적으로 밀려나다 GCP에서 클라우드 방지 캠프로 이동했습니다. 나는 더 이상 그들의 독점 개발에 의존하는 데 동의하지 않습니다. 왜냐하면 실제로 데브옵스는 "오래된" 제품을 폐쇄하려는 Google의 정책을 따라잡으려고 노력하는 것보다 베어 가상 머신에서 오픈 소스 시스템을 유지하는 것이 더 쉽기 때문입니다.

Google Cloud로 돌아가기 전에 심지어 가까이 그들을 비판하는 데 그치지 말고 다른 분야에서 회사의 성과를 살펴보겠습니다. Google 엔지니어들은 소프트웨어 엔지니어링 분야에 자부심을 갖고 있으며 이것이 실제로 문제를 일으키는 원인입니다. 자부심은 부주의한 사람들을 위한 함정이며, 이로 인해 많은 Google 직원은 자신의 결정이 항상 옳고 (모호한 모호한 정의에 따르면) 옳은 것이 고객을 배려하는 것보다 더 중요하다고 생각하게 되었습니다.

Google 외부의 다른 대규모 프로젝트에서 무작위로 몇 가지 예를 들겠지만, 이 패턴을 모든 곳에서 볼 수 있기를 바랍니다. 다음과 같습니다: 이전 버전과의 호환성을 통해 수십 년 동안 시스템을 최신 상태로 유지합니다..

이전 버전과의 호환성은 다음을 위해 설계된 모든 성공적인 시스템의 설계 목표입니다. 열린 즉, 오픈 소스 코드 및/또는 공개 표준으로 구현됩니다. 너무 당연한 말을 해서 모두가 불편하기까지 한 것 같지만 그렇지 않습니다. 이는 정치적인 문제이므로 사례가 필요합니다.

제가 선택할 첫 번째 시스템은 가장 오래된 시스템입니다. GNU Emacs는 Windows 메모장, OS 커널 및 국제 우주 정거장을 혼합한 것입니다. 설명하기가 조금 어렵지만 간단히 말해서 Emacs는 생산성을 높이기 위한 프로그래밍을 위해 1976년(예, 거의 반세기 전)에 만들어진 플랫폼이지만 텍스트 편집기로 가장합니다.

나는 매일 Emacs를 사용합니다. 예, 저는 IntelliJ도 매일 사용하고 있으며 그 자체로 강력한 도구 플랫폼으로 성장했습니다. 그러나 IntelliJ용 확장 기능을 작성하는 것은 Emacs용 확장 기능을 작성하는 것보다 훨씬 더 야심 차고 복잡한 작업입니다. 그리고 더 중요한 것은 Emacs용으로 작성된 모든 내용이 보존된다는 것입니다. 영원히.

나는 1995년에 Emacs용으로 작성한 소프트웨어를 아직도 사용하고 있습니다. 그리고 나는 누군가가 80년대 중반에 Emacs용으로 작성된 모듈을 사용하고 있다고 확신합니다. 때때로 약간의 조정이 필요할 수 있지만 이는 실제로 매우 드뭅니다. 나는 Emacs용으로 재설계가 필요한 내용을 작성한 적이 없습니다(그리고 많은 내용을 작성했습니다).

Emacs에는 쓸모없는 엔터티에 대해 make-obsolete라는 기능이 있습니다. 기본적인 컴퓨터 개념(예: "창"이 무엇인지)에 대한 Emacs 용어는 Emacs가 오래 전에 도입했기 때문에 업계 관례와 종종 다릅니다. 이는 시대를 앞서가는 사람들에게 전형적인 위험입니다. 모든 용어가 정확하지 않습니다. 그러나 Emacs에는 비추천(deprecation)이라는 개념이 있습니다. 스러져 감.

그러나 Emacs 세계에서는 다른 작업 정의가 있는 것 같습니다. 원한다면 다른 기본 철학이 있습니다.

Emacs의 세계(그리고 아래에서 다룰 다른 많은 영역)에서 더 이상 사용되지 않는 API 상태는 기본적으로 다음을 의미합니다. 여기에 나열하세요. 하지만 결국 선택은 당신의 몫입니다."

Google 세계에서 구식이라는 것은 "우리가 귀하에 대한 약속을 위반했습니다"를 의미합니다. 이것은 사실이다. 이것이 본질적으로 의미하는 바입니다. 이는 그들이 당신에게 강요할 것임을 의미합니다. 정기적으로 일을 좀 해라, 어쩌면 많은 일을 해라, 그것을 믿은 것에 대한 벌로. 다채로운 광고: 우리는 최고의 소프트웨어를 보유하고 있습니다. 가장 빠른! 지침에 따라 모든 작업을 수행하고 애플리케이션이나 서비스를 시작한 다음 XNUMX~XNUMX년 후에는 중단됩니다.

1500km 지나면 반드시 고장날 중고차를 파는 것과 같습니다.

이것은 "노후화"에 대한 완전히 다른 두 가지 철학적 정의입니다. 구글의 냄새 정의 계획된 노후화. 나는 이것을 믿지 않는다 사실 Apple과 같은 의미에서 계획된 노후화. 하지만 Google은 확실히 우회적인 방식으로 귀하의 프로그램을 중단시킬 계획을 가지고 있습니다. 저는 그곳에서 12년 넘게 소프트웨어 엔지니어로 일했기 때문에 이것을 알고 있습니다. 이전 버전과의 호환성을 어느 정도 따라야 하는지에 대한 모호한 내부 지침이 있지만 이는 궁극적으로 각 개별 팀이나 서비스에 달려 있습니다. 엔터프라이즈 또는 엔지니어링 수준의 권장 사항은 없으며 노후화 주기 측면에서 가장 과감한 권장 사항은 "전체 시스템을 중단하기 전에 고객에게 업그레이드할 수 있는 6~12개월의 시간을 제공하는 것"입니다.

문제는 그들이 생각하는 것보다 훨씬 더 크고, 고객 관리가 그들의 DNA에 없기 때문에 앞으로도 수년 동안 지속될 것입니다. 이에 대한 자세한 내용은 아래에서 확인하세요.

이 시점에서 나는 Emacs가 대체로 성공적이라는 대담한 말을 하려고 합니다. 기본적으로 왜냐하면 그들은 이전 버전과의 호환성을 매우 중요하게 여기기 때문입니다. 사실 이것이 우리 기사의 주제입니다. 성공적이고 오래 지속되는 개방형 시스템의 성공은 수십 년 동안 주변에 살아온 소규모 커뮤니티 덕분입니다. 확장/플러그인. 이것이 생태계입니다. 저는 이미 플랫폼의 본질과 그것이 얼마나 중요한지, 그리고 Google이 회사 역사상 Android나 Chrome 외부에서 성공적인 개방형 플랫폼을 만드는 데 무엇이 필요한지 결코 이해하지 못했다는 점에 대해 이야기했습니다.

사실 안드로이드에 대해 간단히 언급해야 할 이유는 아마도 여러분이 안드로이드에 대해 생각하고 계실 것이기 때문입니다.

첫째, 안드로이드는 구글이 아니다. 그들은 서로 공통점이 거의 없습니다. 안드로이드는 2005년 XNUMX월 구글이 인수한 회사로, 회사는 어느 정도 자율적으로 운영될 수 있도록 허용되었으며 실제로 그 사이 몇 년 동안 거의 그대로 유지되었습니다. Android는 악명 높은 기술 스택이자 마찬가지로 악명 높은 까다로운 조직입니다. 한 Google 직원은 "Android에 로그인만 할 수는 없습니다."라고 말했습니다.

이전 기사에서 나는 Android의 초기 디자인 결정 중 일부가 얼마나 나빴는지 논의했습니다. 도대체 내가 그 기사를 썼을 때 그들은 "인스턴트 앱"이라는 쓰레기를 출시하고 있었는데 지금은 (놀랍게도!) 시대에 뒤진, 그리고 Google의 말을 듣고 콘텐츠를 이러한 인스턴트 앱으로 옮길 만큼 어리석었다면 동정합니다.

그러나 여기에는 차이점이 있습니다. 중요한 차이점은 Android 사용자가 플랫폼이 얼마나 중요한지 실제로 이해하고 있으며 오래된 Android 앱이 계속 작동하도록 최선을 다한다는 것입니다. 사실, 이전 버전과의 호환성을 유지하려는 그들의 노력은 너무 극단적이어서 나조차도 몇 년 전 안드로이드 사업부에서 잠시 근무하는 동안 일부 오래된 장치와 API에 대한 지원을 중단하도록 설득하려고 노력했습니다. 과거와 현재의 다른 많은 일들과 마찬가지로 죄송합니다. 안드로이드 여러분! 이제 인도네시아에 가봤으니 안드로이드가 필요한 이유를 이해합니다.

Android 사용자는 이전 버전과의 호환성을 거의 상상할 수 없을 정도로 극한까지 밀어붙이며 시스템과 도구 체인에 막대한 양의 레거시 기술 부채를 쌓습니다. 맙소사, 호환성이라는 이름으로 빌드 시스템에서 수행해야 하는 미친 일 중 일부를 확인해야 합니다.

이를 위해 저는 Android에 모두가 탐내는 'You're Not Google' 상을 수여합니다. 그들은 지속 가능한 플랫폼을 만드는 방법을 모르는 Google이되고 싶지 않지만 Android는 알고있다, 어떻게 해야 할까요? 그래서 Google은 한 가지 측면에서 매우 똑똑합니다. 사람들이 Android에서 자신만의 방식으로 작업을 수행할 수 있도록 허용하는 것입니다.

하지만 안드로이드용 인스턴트 앱은 꽤 멍청한 아이디어였습니다. 왜 그런지 아시나요? 그들이 요구했기 때문에 애플리케이션을 다시 작성하고 다시 디자인하세요.! 이는 마치 사람들이 XNUMX만 개의 애플리케이션을 간단히 다시 작성하는 것과 같습니다. 인스턴트 앱은 Google 직원의 아이디어인 것 같아요.

그러나 차이점이 있습니다. 이전 버전과의 호환성에는 비용이 많이 듭니다. 이러한 비용은 안드로이드 자체가 부담하는 반면, 구글은 부담을 주장한다. 너는 ~이다., 지불 클라이언트.

API에서 이전 버전과의 호환성에 대한 Android의 약속을 확인할 수 있습니다. 말 그대로 동일한 작업을 수행하는 XNUMX~XNUMX개의 서로 다른 하위 시스템이 있다면 이는 핵심에서 이전 버전과의 호환성을 보장한다는 확실한 신호입니다. 플랫폼 세계에서 이는 고객과 시장에 대한 헌신과 동의어입니다.

여기서 Google의 주요 문제는 엔지니어링 위생에 대한 자부심입니다. 그들은 같은 일을 하는 데 여러 가지 다른 방법이 있고, 오래되고 덜 바람직한 방법이 새롭고 더 멋진 방법 옆에 있는 것을 좋아하지 않습니다. 시스템을 처음 접하는 사람들의 학습 곡선을 높이고 레거시 API 유지 관리 부담을 늘리며 새로운 기능의 속도를 늦추고 가장 큰 죄는 아름답지 않다는 것입니다. Google - Tim Burton의 이상한 나라의 앨리스에 나오는 Lady Ascot처럼:

레이디 애스콧:
- 앨리스, 내가 가장 두려워하는 것이 무엇인지 아세요?
- 귀족의 쇠퇴?
- 그럴까봐 두려웠어요 못생긴 손자.

아름다운 것과 실용적인 것 사이의 균형을 이해하기 위해 Emacs와 Android에 이어 세 번째로 성공한 플랫폼인 Java 자체를 살펴보고 그것이 어떻게 작동하는지 살펴보겠습니다.

Java에는 오래된 API가 많이 있습니다. 지원 중단은 Java 프로그래머들 사이에서 매우 인기가 있으며 대부분의 프로그래밍 언어보다 훨씬 더 인기가 있습니다. Java 자체, 핵심 언어 및 라이브러리는 지속적으로 API를 더 이상 사용하지 않습니다.

수천가지 사례 중 하나만 꼽자면, 스레드 닫기 쓸모없는 것으로 간주됩니다. 1.2년 1998월 Java 22 출시 이후 더 이상 사용되지 않습니다. 이 기능이 지원 중단된 지 XNUMX년이 되었습니다.

하지만 실제 프로덕션 코드에서는 여전히 스레드가 종료되고 있습니다. 매일. 정말 그게 좋다고 생각하시나요? 전적으로! 물론, 오늘 코드를 다시 작성한다면 다르게 구현하겠다는 뜻입니다. 그런데 지난 XNUMX년 동안 수십만 명의 사람들을 행복하게 만든 내 게임의 코드에는 너무 오래 걸리는 스레드를 닫는 기능이 포함되어 있는데, 한번도 바꿀 필요가 없었어. 나는 누구보다 내 시스템을 더 잘 알고 있으며, 말 그대로 25년 동안 프로덕션 환경에서 작업한 경험이 있으며 확실히 말할 수 있습니다. 내 경우에는 이러한 특정 작업자 스레드를 완전히 닫는 것이 해가없는. 이 코드를 다시 작성하는 데 시간과 노력을 들일 가치가 없으며 Oracle이 코드를 다시 작성하도록 강요하지 않은 Larry Ellison(아마도)에게 감사드립니다.

오라클은 아마도 플랫폼도 이해하고 있을 것입니다. 누가 알아.

협곡의 빙하 선처럼 노후화의 물결로 가득 찬 핵심 Java API 전체에서 증거를 찾을 수 있습니다. Java Swing 라이브러리에서 XNUMX~XNUMX개의 키보드 탐색 관리자(KeyboardFocusManager)를 쉽게 찾을 수 있습니다. 실제로 더 이상 사용되지 않는 Java API를 찾는 것은 어렵습니다. 하지만 그들은 여전히 ​​작동합니다! 나는 인터페이스가 눈에 띄는 보안 문제를 야기하는 경우에만 Java 팀이 API를 실제로 제거할 것이라고 생각합니다.

문제는 다음과 같습니다. 우리 소프트웨어 개발자는 모두 매우 바쁘고 소프트웨어의 모든 영역에서 경쟁적인 대안에 직면해 있습니다. 언제든지 언어 X를 사용하는 프로그래머는 언어 Y를 가능한 대체 언어로 고려하고 있습니다. 아, 내 말을 못 믿으시나요? 스위프트라고 부르고 싶나요? 예를 들어, 모두가 Swift로 마이그레이션하고 있고 누구도 이를 버리지 않습니다. 그렇죠? 와, 당신이 아는 게 얼마나 적은지. 회사는 이중 모바일 개발 팀(iOS 및 Android)의 비용을 계산하고 있으며 Flutter 및 React Native와 같은 재미있는 이름을 가진 크로스 플랫폼 개발 시스템이 실제로 작동하고 규모를 줄이는 데 사용될 수 있다는 것을 깨닫기 시작했습니다. 모바일 팀은 생산성을 두 배로 높이거나 반대로 생산성을 두 배로 높입니다. 진짜 돈이 걸려 있습니다. 예, 타협이 있지만 반면에 돈이 있습니다.

Apple이 어리석게도 Guido van Rossum의 지시를 받아 Python 6.0이 Python 5.0와 호환되지 않는 것처럼 Swift 3이 Swift 2과 하위 호환되지 않는다고 선언했다고 가정해 보겠습니다.

아마도 3000년 전쯤에 이 이야기를 했을 것입니다. 그러나 XNUMX년 전쯤 저는 Guido와 함께 O'Reilly의 Foo Camp에 갔고, Paul Graham과 거물들과 함께 텐트에 앉아 있었습니다. 우리는 무더위 속에서 래리 페이지가 개인 헬리콥터를 타고 이륙하기를 기다리고 있었고, 귀도는 모든 사람이 그곳으로 이주하는 데 걸리는 시간을 따서 이름을 붙인 "Python XNUMX"에 관해 드론을 날렸습니다. 우리는 그에게 왜 호환성을 깨뜨리고 있는지 계속 물었고 그는 "유니코드"라고 대답했습니다. 그리고 우리는 코드를 다시 작성해야 한다면 어떤 다른 이점을 얻을 수 있는지 물었습니다. 그리고 그는 "Yooooooooooooouuuuuuuniiiiiiicoooooooode"라고 대답했습니다.

Google Cloud Platform SDK('gcloud')를 설치하면 다음 알림을 받게 됩니다.

수신자님께,

Python 2에 대한 지원이 더 이상 사용되지 않는다는 점을 알려드리고 싶습니다.

… 등등. 삶의 순환.

그러나 요점은 모든 개발자에게 선택권이 있다는 것입니다. 그리고 코드를 충분히 자주 다시 작성하도록 강요한다면 그들은 다음과 같이 생각할 수도 있습니다. 다른 옵션. 당신이 아무리 원하더라도 그들은 당신의 인질이 아닙니다. 그들은 당신의 손님입니다. Python은 여전히 ​​매우 인기 있는 프로그래밍 언어이지만, 젠장, Python 3(000)은 커뮤니티와 커뮤니티 사용자 사이에서 그 자체로 혼란을 야기하여 그 결과가 XNUMX년 동안 해결되지 않았습니다.

이러한 이전 버전과의 비호환성으로 인해 얼마나 많은 Python 프로그램이 Go(또는 Ruby 또는 다른 대안)로 다시 작성되었습니까? 파이썬이 아닌 다른 언어로 작성된 새로운 소프트웨어는 얼마나 됩니까? 될 수있다. 귀도가 마을 전체를 불태우지 않았다면 파이썬으로 작성되었을까요? 말하기는 어렵지만 Python은 분명히 어려움을 겪었습니다. 그것은 엄청난 혼란이고 모두가 잃습니다.

Apple이 Guido의 신호를 받아 호환성을 깨뜨렸다고 가정해 보겠습니다. 다음에 무슨 일이 일어날 것이라고 생각합니까? 글쎄, 아마도 개발자의 80-90%는 가능하다면 소프트웨어를 다시 작성할 것입니다. 즉, 사용자 기반의 10-20%가 자동으로 Flutter와 같은 일부 경쟁 언어로 이동합니다.

이 작업을 여러 번 수행하면 사용자 기반의 절반이 손실됩니다. 스포츠와 마찬가지로 프로그래밍의 세계에서도 현재의 형태도 중요합니다. всё. XNUMX년 안에 사용자의 절반을 잃는 사람은 Big Fat Loser로 간주됩니다. 당신은 플랫폼 세계에서 트렌디해야 합니다. 그러나 이전 버전을 지원하지 않으면 시간이 지남에 따라 망가질 수 있습니다. 왜냐하면 당신이 일부 개발자를 제거할 때마다 당신은 (a) 계약을 위반한 것에 대해 화가 나서 그들을 영원히 잃게 되고, (b) 그들을 경쟁사에게 넘겨주기 때문입니다.

아이러니하게도 저는 코드 자체를 쉽게 자동화하고 계측할 수 있게 해주는 소스 코드 분석 및 이해 시스템인 Grok을 만들 때 Google이 이전 버전과의 호환성을 무시하는 프리마돈나가 되도록 도왔습니다. IDE와 유사하지만 여기서는 클라우드 서비스가 저장합니다. 대규모 데이터 웨어하우스에 수십억 줄의 Google 소스 코드를 모두 구체화했습니다.

Grok은 Google 직원에게 전체 코드베이스(말 그대로 Google 전체)에 걸쳐 자동화된 리팩토링을 수행할 수 있는 강력한 프레임워크를 제공했습니다. 시스템은 귀하의 업스트림 종속성(귀하가 의존하는)뿐만 아니라 하류 (그것은 당신에게 달려 있습니다) 따라서 API를 변경하면 당신이 깨뜨린 모든 사람을 알 수 있습니다! 이렇게 하면 변경 시 API의 모든 소비자가 새 버전으로 업데이트되었는지 확인할 수 있으며 실제로는 그들이 작성한 Rosie 도구를 사용하여 프로세스를 완전히 자동화할 수 있는 경우가 많습니다.

이를 통해 Google의 코드베이스는 내부적으로 거의 초자연적으로 깨끗할 수 있습니다. 로봇 하인이 집 안을 돌아다니며 SomeDespicouslyLongFunctionName을 SomeDespicouslyLongMethodName으로 이름을 바꾸면 자동으로 모든 것을 정리하기 때문입니다. 왜냐하면 누군가가 그것이 못생긴 손자이고 그를 잠들게 해야 한다고 결정했기 때문입니다.

그리고 솔직히 말해서 Google 내부적으로는 꽤 잘 작동합니다. 네, Google의 Go 커뮤니티는 지속적인 리팩토링 습관 때문에 Google의 Java 커뮤니티와 함께 ​​크게 웃었습니다. 어떤 것을 N번 다시 시작한다면, 이는 N-1번을 망쳤을 뿐만 아니라, 시간이 지나면 아마 N번째 시도에서도 망쳤다는 것이 꽤 분명해진다는 뜻입니다. 그러나 전반적으로 그들은 이 모든 소란을 넘어 코드를 "깨끗하게" 유지합니다.

문제는 클라우드 클라이언트와 다른 API 사용자에게 이러한 태도를 강요하려고 할 때 시작됩니다.

저는 여러분에게 Emacs, Android, Java에 대해 조금 소개했습니다. 최근에 성공하고 오래 지속된 플랫폼인 웹 자체를 살펴보겠습니다. 플래싱 태그를 사용한 1995년 이후 HTTP가 얼마나 많은 반복을 겪었는지 상상할 수 있습니까? 웹 페이지의 "공사중" 아이콘.

하지만 여전히 작동합니다! 그리고 이 페이지들은 여전히 ​​작동하고 있습니다! 그렇습니다. 브라우저는 이전 버전과의 호환성 측면에서 세계 챔피언입니다. Chrome은 제대로 작동하는 희귀한 Google 플랫폼의 또 다른 예입니다. 짐작하셨겠지만 Chrome은 Google의 나머지 부분과 별개로 샌드박스 회사로 효과적으로 운영됩니다.

또한 성공적인 플랫폼에서 이전 버전과의 호환성을 훌륭하게 수행한 Windows, Linux, APPLE이 아닌 Linux, FreeBSD 등의 운영 체제 개발자에게 감사의 말씀을 전하고 싶습니다. 단점은 정당한 이유 없이 항상 모든 것을 망가뜨린다는 것입니다. 하지만 어떻게든 커뮤니티는 모든 릴리스에서 문제를 해결하고 있으며 OS X 컨테이너는 아직 완전히 쓸모없지는 않습니다...아직).

하지만 잠깐만요. 우리는 사과를 오렌지와 비교하고 있지 않습니까? Emacs/JDK/Android/Chrome과 같은 단일 시스템의 독립형 소프트웨어 시스템과 클라우드 서비스와 같은 다중 서버 시스템 및 API를 비교하고 있지 않습니까?

글쎄, 나는 어제 이것에 대해 트윗했지만 Larry Wall (프로그래밍 언어 Perl의 창시자 - 대략 per.)의 스타일로 "sucks/rules"의 원칙에 따라 단어를 찾았습니다. 사용되지 않는 Google 및 Amazon 개발자 사이트에서. AWS에는 수백 GCP보다 제공되는 서비스가 몇 배나 많기 때문에 Google 개발자 문서에서는 지원 중단을 약 XNUMX배 더 자주 언급합니다.

Google의 누군가가 이 글을 읽고 있다면, 그들은 아마도 자신이 실제로 모든 일을 제대로 하고 있음을 보여주는 도널드 트럼프 스타일의 차트를 꺼낼 준비가 되어 있을 것이며, "더 이상 사용되지 않는 단어에 대한 언급 횟수와 서비스 수" "

하지만 수년이 지난 후에도 Google Cloud는 여전히 3위 서비스입니다(2위가 되려는 시도가 실패했다는 기사를 쓴 적이 없습니다). 하지만 내부자라면 곧 하락할 수 있다는 우려가 있습니다. 4번.

나는 내 논문을 "증명"하기 위한 설득력 있는 주장을 가지고 있지 않습니다. 내가 가진 건 개발자로서 30년 넘게 쌓아온 다채로운 사례들뿐이다. 나는 이미 이 문제의 심오한 철학적 성격을 언급했습니다. 어떤 면에서는 개발자 커뮤니티에서 정치화되어 있습니다. 어떤 사람들은 그렇게 믿습니다. 크리에이터 플랫폼은 호환성에 신경을 써야 하지만 다른 사람들은 이것이 문제라고 생각합니다. 사용자 (개발자 자신). 둘 중 하나. 사실 공동의 문제에 대한 비용을 누가 부담할지 결정하는 것은 정치적인 문제가 아닌가?

그래서 이것이 정치입니다. 그리고 아마도 내 연설에 분노한 반응이 있을 것입니다.

방법 사용자 Google Cloud Platform을 사용하고 AWS 사용자로서 XNUMX년 동안(Grab에서 근무하면서) 우선순위에 있어서 Amazon과 Google의 철학에는 큰 차이가 있다고 말할 수 있습니다. 저는 AWS에서 적극적으로 개발하지 않기 때문에 오래된 API를 얼마나 자주 제거하는지 잘 모르겠습니다. 그러나 이것이 Google만큼 자주 발생하지는 않는다는 의혹이 있습니다. 그리고 저는 GCP에서 이러한 끊임없는 논란과 좌절의 원인이 플랫폼 개발을 방해하는 가장 큰 요인 중 하나라고 진심으로 믿습니다.

더 이상 지원되지 않는 GCP 시스템의 구체적인 예를 언급하지 않은 것으로 알고 있습니다. 네트워크(가장 오래된 것부터 VPC까지)부터 스토리지(Cloud SQL v1-v2), Firebase(현재는 완전히 다른 API를 갖춘 Firestore), App Engine(시작도 하지 말자)까지 제가 사용한 거의 모든 것이 있다고 말할 수 있습니다. , 클라우드 엔드포인트 Cloud 엔드포인트 및 최대... 모르겠습니다 - 절대적으로 이 모든 것 최대 2~3년 후에 코드를 다시 작성하도록 강요했으며 마이그레이션을 자동화하지 않았으며 종종 문서화된 마이그레이션 경로가 전혀 없었습니다.. 마치 그래야만 했던 것처럼.

그리고 AWS를 볼 때마다 나는 대체 왜 아직도 GCP를 사용하고 있는지 자문합니다. 그들은 분명히 고객이 필요하지 않습니다. 그들은 필요 구매자. 차이점을 이해하시나요? 설명하겠습니다.

구글 클라우드는 온라인마켓사람들이 소프트웨어 솔루션을 제안하는 곳에서 빈 식당 효과를 피하기 위해 몇 가지 제안으로 채워야 했기 때문에 Bitnami라는 회사와 계약을 맺고 "원 클릭"으로 배포되는 여러 솔루션을 만들었습니다. 나는 그것을 "해결책"이라고 씁니다. 왜냐하면 이것들은 망할 일을 해결하지 못하기 때문입니다. 그것들은 단순히 체크박스나 마케팅 필러로 존재하며 Google은 도구가 실제로 작동하는지 여부에 전혀 관심을 두지 않습니다. 나는 운전석에 있었던 제품 관리자를 알고 있으며, 이 사람들은 신경 쓰지 않는다는 것을 확신할 수 있습니다.

예를 들어 "원클릭" 배포 솔루션을 생각해 보겠습니다. 퍼 코나. 저는 Google Cloud SQL 헛소리에 지쳐서 대안으로 자체 Percona 클러스터를 구축하기 시작했습니다. 그리고 이번에는 Google이 일을 잘 해낸 것 같았습니다. 버튼 하나만 클릭하면 시간과 노력을 절약할 수 있을 것 같았습니다!

좋아요, 가자. 링크를 따라가서 이 버튼을 클릭해 보겠습니다. 모든 기본 설정에 동의하고 Google 클라우드 프로젝트에 클러스터를 배포하려면 '예'를 선택하세요. 하하, 작동하지 않습니다. 이 쓰레기 중 어느 것도 작동하지 않습니다. 이 도구는 테스트되지 않았으며 처음 XNUMX분부터 부패하기 시작했으며 "솔루션"의 절반 이상이 원클릭 배포인 경우에도 놀라지 않을 것입니다(이제 인용문이 붙은 이유를 이해합니다). 일반적으로 작동하지 않습니다. 이것은 절대적으로 절망적인 어둠입니다. 들어가지 않는 것이 더 좋습니다.

하지만 구글은 옳다 격려하다 당신은 그들을 사용합니다. 그들은 당신이 그러기를 원해요 샀다. 그들에게는 거래입니다. 그들은 아무것도 원하지 않는다 지원. 이는 Google DNA의 일부가 아닙니다. 예, Bigtable에 대한 저의 이야기에서 알 수 있듯이 엔지니어들은 서로를 지원합니다. 하지만 보통 사람들을 위한 제품이나 서비스에서는 항상 무자비했다 모든 서비스 종료, 이는 수백만 명의 사용자가 있어도 수익성 기준을 충족하지 못합니다.

이는 모든 클라우드 제품의 DNA이기 때문에 GCP에 대한 실질적인 과제를 제시합니다. 그들은 아무것도 지원하려고 하지 않습니다. 제XNUMX자 소프트웨어를 관리형 서비스로 호스팅하는 것을 거부한다는 것은 잘 알려져 있습니다. 그때까지, AWS가 동일한 작업을 수행하여 이를 중심으로 성공적인 비즈니스를 구축할 때까지, 그리고 고객이 문자 그대로 동일한 것을 요구할 때까지입니다. 그러나 Google이 무언가를 지원하도록 하려면 약간의 노력이 필요합니다.

이러한 지원 문화의 부족은 "더 아름답게 만들기 위해 부수자"라는 사고방식과 결합되어 개발자를 소외시킵니다.

그리고 오래 지속되는 플랫폼을 구축하려는 경우 이는 좋은 일이 아닙니다.

구글, 일어나, 젠장. 지금은 2020년입니다. 당신은 아직도지고 있습니다. 이제 거울을 자세히 들여다보고 정말로 클라우드 비즈니스를 계속하고 싶은지 답해 보아야 할 때입니다.

계속 머물고 싶다면 그때 모든 걸 그만 부숴버려. 여러분, 당신은 부자입니다. 우리 개발자들은 그렇지 않습니다. 따라서 호환성의 부담을 누가 짊어질지는 본인이 직접 짊어져야 합니다. 우리에게는 그렇지 않습니다.

정말 좋은 클라우드가 적어도 XNUMX개 이상 더 있기 때문입니다. 그들은 손짓한다.

이제 모든 손상된 시스템을 고치겠습니다. 뭐라고.

다음 시간까지!

이 기사에 대한 토론 중 일부를 읽은 후 PS 업데이트합니다(토론은 훌륭합니다. 그런데). Firebase 지원은 중단되지 않았으며 제가 알고 있는 계획도 없습니다. 그러나 Java 클라이언트가 App Engine에서 정지되는 불쾌한 스트리밍 버그가 있습니다. 엔지니어 중 한 명이 이 문제를 해결하는 데 도움을 주었습니다. 내가 구글에서 일했을 때, 그러나 그들은 실제로 버그를 수정하지 않았기 때문에 매일 GAE 앱을 다시 시작해야 하는 형편없는 해결 방법이 있습니다. 그래서 XNUMX년이 지났습니다! 이제 Firestore가 있습니다. 완전히 다른 시스템이고 Firebase 버그는 절대 수정되지 않기 때문에 마이그레이션하려면 많은 작업이 필요합니다. 어떤 결론을 내릴 수 있습니까? 도움을 받으실 수 있습니다 회사에서 일한다면. 나는 100% 네이티브 앱에서 100개 미만의 키를 기록하고 알려진 버그로 인해 이틀에 한 번씩 작동을 멈추기 때문에 아마도 GAE에서 Firebase를 사용하는 유일한 사람일 것입니다. 자신의 책임하에 사용하는 것 외에 무엇을 말할 수 있습니까? Redis로 전환 중입니다.

또한 경험이 많은 AWS 사용자 중 일부는 AWS가 일반적으로 서비스 지원을 중단하지 않는다고 말하는 것을 보았습니다. SimpleDB가 좋은 예입니다. AWS가 Google과 동일한 지원 종료 질병을 갖고 있지 않다는 나의 가정은 정당한 것 같습니다.

또한 20일 전에 Google App Engine 팀이 중요한 Go 라이브러리의 호스팅을 중단하고 핵심 Go 개발자 중 한 명의 GAE 애플리케이션을 종료했다는 사실을 발견했습니다. 정말 바보 같았어요.

마지막으로, Google 직원들이 이미 이 문제에 대해 논의하고 일반적으로 제 의견에 동의한다는 소식을 들었습니다(사랑합니다!). 하지만 그들은 구글의 문화가 올바른 인센티브 구조를 갖지 못했기 때문에 문제가 해결 불가능하다고 생각하는 것 같습니다. Grab에서 일하면서 AWS 엔지니어들과 함께 일했던 정말 놀라운 경험에 대해 잠시 이야기를 나누는 시간을 갖는 것이 좋겠다고 생각했습니다. 미래의 언젠가, 나는 희망한다!

그리고 네, 2005년에는 43번 빌딩의 대형 뷔페에서 다양한 종류의 상어 고기를 먹었는데 제가 가장 좋아하는 것은 귀상어 고기였습니다. 그러나 2006년까지 Larry와 Sergei는 건강에 해로운 간식을 모두 없앴습니다. 그래서 2007년 빅테이블 이야기에는 정말 상어가 없었고 제가 당신을 속였습니다.

XNUMX년 전 클라우드 빅테이블을 봤을 때(주거나 받거나) 비용은 이랬다. 지금은 약간 떨어진 것 같지만, 빈 데이터 웨어하우스의 경우 여전히 끔찍한 수준입니다. 특히 첫 번째 이야기에서 비어 있는 대형 테이블이 규모에 비해 얼마나 하찮은지 보여주었기 때문입니다.

Apple 커뮤니티에 불쾌감을 주었고 Microsoft 등에 대해 좋은 말을 하지 않아서 죄송합니다. 괜찮습니다. 이 기사에서 생성된 모든 토론에 정말 감사드립니다! 하지만 때로는 토론을 시작하기 위해 약간의 파도를 조성해야 할 때도 있습니다.

읽어 주셔서 감사합니다.

2년 19.08.2020월 XNUMX일 업데이트 XNUMX. 줄무늬 API를 올바르게 업데이트합니다.!

3년 31.08.2020월 2일 2 업데이트. 저는 Cloud Marketplace의 Google 엔지니어로부터 연락을 받았는데, 그 엔지니어는 저의 오랜 친구였습니다. 그는 CXNUMXD가 작동하지 않는 이유를 알고 싶었고, 결국 그 이유는 제가 몇 년 전에 네트워크를 구축했고 템플릿에 서브넷 매개변수가 누락되어 CXNUMXD가 기존 네트워크에서 작동하지 않았기 때문이라는 것을 알아냈습니다. 잠재적인 GCP 사용자가 Google의 엔지니어를 충분히 알고 있는지 확인하는 것이 가장 좋다고 생각합니다.

출처 : habr.com