زیرشاخهها و تیمهای مهندسی گوگل نسبتا نامتمرکز و خودمختار کار میکنند، مانند مدل ایالتی آمریکا. تغییرات زیرساختی بزرگ در سطح کل شرکت را در نظر بگیرید، مثلا منسوخ کردن BigTable و رفتن به Spanner (دو تکنولوژی ذخیرهسازی داده، یکی در الگوی NoSQL و یکی در الگوی جدید NewSQL). چنین تغییراتی، نیازمند بازنویسیها و مهاجرت عمدهای از سوی تیمهای client مثلا maps و search و ads و الخ است، گاه یک برنامهی مهاجرت ۲ ۳ ساله که تیمها باید از منابع انسانیشان خرج آن کنند، و خوب نمیکنند مگر این که واقعا ضرورتش جا افتاده باشد.
مثلا در مثال بالا، تیمهای زیرساختی مسؤل BigTable و Spanner میروند و با تیمهای متاثر گفتگو میکنند و تخمینی از زحمت لازم به دست میآورند و همچنین دلایل این منسوخسازی را توجیه میکنند (مثلا پیچیدگی نگهداری از دو سیستم موازی) و اگر واقعا ضروری باشد، یک تصمیم فراتیمی گرفته شود.
یک مشکل اساسی که در این زمینه داریم، تعداد زیاد این تغییرات است؛ یک روز زیرساخت ذخیرهی فلان و یک روز سیستم مدیریت فلان و یک روز کتابخانهی فلان و ... اصلا جوک-واقعیت معروف در گوگل این است که سیستم قبلی منسوخ (deprecate) شده در حالی که سیستم جدید آماده نیست.
یک مشکل دیگر، افتادن هزینه به پای تیمهای client است و نهایتا بسیاری از مهاجرتها نصفه میمانند. مثلا از روزی که اینجا به یاد دارم (۹ سال پیش) قرار بوده تیمها برای پایش از سیستمی به نام Borgmon (معادل Prometheus) به سیستم جدید پیشرفتهتری به نام Monarch مهاجرت کنند، ولی هنوز برخی نکردهاند یا در حالت بینابینی ماندهاند.
یک قانون سرانگشتی برای حل این معضل این شده که در هنگام طراحی یک مهاجرت یا منسوخسازی، ۸۰٪ کار باید متمرکز قابل انجام باشد، مثلا آماده کردن ابزار خودکارسازی یا APIهای میانی، و تنها ۲۰٪ روی دوش تیمها.
بسیاری مهاجرتها هم با پیروزی انجام شده. ولی نهایتا هنوز در این زمینه اوضاعمان خراب است و در مواردی، برای سالها سیستمهای موازی داریم.
