ДевОпс Інженер 🇺🇦

Deprecation plan Поділюсь сьогодні з вами подією, яка пройшла дуже тихо в середині літа, але для декого стала досить неприємною. 31-го липня, у своєму твіттері X, Jeff Barr повідомив ось таку новину на широкий загал:

After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit. While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today, including keeping them secure and reliable.

Тут варто сказати, що цей AWS CodeCommit в цілому і був не дуже хорошим рішенням, тому дивного тут нічого не було. Проблема полягає в тому, що Jeff Barr зробив це до офіційної комунікації AWS, і клієнти цього чудового сервісу почали у своїх компаніях, у лічках, пересилати посилання на твіттер (а він, повірте, використовується, особливо в тих випадках, коли регулятор забороняє будь-який third-party сервіс поза межами AWS). Чи це нормально? Звісно, ні, бо мали б пересилати посилання на блог або імейл, в якому було б сказано: “сорі, так і так — ось вам купа часу і промо на Х грошей, ми цю штуку прибираємо зі свого портфоліо. Хто користується — користуйтеся, але нові репозиторії вже не створюйте, будь ласка”. Далі за хронологією полетіло багато чого по трубам, і AWS вирішив додати в статтю, яка називалась “How to migrate your AWS CodeCommit repository to another Git provider” і в якій спочатку нічого не було про “we made the decision”, ось такий хідер:

After careful consideration, we have made the decision to close new customer access to AWS CodeCommit, effective July 25, 2024. AWS CodeCommit existing customers can continue to use the service as normal. AWS continues to invest in security, availability, and performance improvements for AWS CodeCommit, but we do not plan to introduce new features.

Ну, і в принципі на цьому вся комунікація від AWS і закінчилася. Ось ви це прочитали, чи залишились у вас питання? Наприклад: скільки ще він буде працювати для існуючих клієнтів — місяць, рік чи ще 5 років? Чи можна додатково заплатити і розблокувати можливість створення репозів? Який альтернативний solution є всередині самого AWS? А що з цим прекрасним CI/CD тулсетом — він теж депрекейтиться чи він strong enough? (CodeBuild / CodePipeline / CodeStart і т.д.) Як бачите, таким чином комунікувати неефективно, і комунікувати не рекомендується, якщо ви хочете, щоб клієнти були задоволені. Тому, шановні DevOps / SRE / Infra / Platform Engineers, ви, як представники сервісів, тулів, платформ, які працюють неефективно, не робіть так, як це було зроблено з AWS CodeCommit. Трохи подумавши, це можна було б пофіксити ось так: 1. За рік до події, зловивши тренд, розіслати кастомерам survey: “ми думаємо, що сервіс не вдався, і ви теж даєте нам такий фідбек. Ми хотіли б його задепрекейтити. Що ви думаєте?” 2. Цей фідбек ніхто не бачить, тож тут можемо діяти як завгодно. Наприклад, комунікуємо за півроку: “ми отримали результати опитувань, які свідчать, що цей сервіс не вдався, і ми не хочемо його розвивати. Починаючи з dd/mm/yyyy, він переходить на deprecation path, але до цієї дати він працюватиме як завжди. Це стосується виключно цього сервісу. Ось comprehensive guide, як з нього мігрувати”. 3. Фінальний нотіф: “Як ми повідомляли раніше, сьогодні dd/mm/yyyy ми припиняємо можливість створювати нові репозиторії. Так як сервіс на deprecation path, ми займаємось тільки його безпекою, і до кінця yyyy року ви змушені з нього зʼїхати, бо буде повний sunset. Команда AWS доступна для ваших запитів.” Використовуйте цей патерн для депрекейшну старих, нових, потрібних і непотрібних сервісів, які є у ваших системах. Ключ до ефективності — ранній нотіф клієнтам (офіційна, формальна комунікація). Для збереження відносин — comprehensive guide. І ще бажано мігронути клієнта на нову систему, можливо навіть смузлі. Тоді буде win-win. Пропрацьовуйте ваші депрекейшн плани "in upfront". Будьте здорові.