Перевод статьи Руслана Кусова, Senior Solutions Architect в SoftServe. Работа над ошибками помогает сформулировать выводы и избежать подобного в будущем. Надеюсь, наш опыт поможет еще кому-нибудь.
Как-то один мой сотрудник сказал: «Это не такая уж проблема. К счастью, мы не строим самолеты». Я бы здесь не был так уверен. Некоторые архитекторы, особенно начинающие, не отдают себе отчет в последствиях своих ошибок. Ошибки бывают более масштабными, чем кажется. Простейший пример – угроза похищения данных, которое может привести к значительным финансовым потерям и репутационным рискам.
В этой статье поделюсь с вами четырьмя историями из жизни. Это «изученные уроки», укрепившие фундамент архитектурного опыта моей команды.
Случай №1. Несогласованный план хуже, чем его отсутствие
Задача – перенести инфраструктуру крупной энтерпрайз-компании в AWS из другого облачного провайдера. Для нашей команды это стандартная вещь без очевидных вызовов. Ввиду большого количества данных, систем и компонентов у клиента важно было подготовить правильный фундамент — landing zone. Это не проблема, поскольку AWS имеет готовый концепт для этого.
Стейкхолдеры (спонсоры миграции) на стороне клиента хорошо понимали принципы AWS landing zone, они согласились со всеми нашими предложениями, отметив лишь то, что у них теоретически может быть VPN с дата-центром и есть SD-WAN, который желательно будет настроить в будущем, но сейчас это не важно, кроме того, этим будем заниматься не мы, а их инженерная команда. В общем, условия были привлекательными: свобода выбора, «правильные» стейкхолдеры и обещанная поддержка инженеров со стороны клиента.
Мы поняли, что оптимально будет использовать AWS CloudFormation для развертывания ресурсов, потому что он проще, в том числе и для централизованного управления AWS облака. Все должно быть хорошо, но…
Что пошло не по плану
Проблемы возникли уже на первой неделе. Мы построили landing zone и были готовы переходить к финальному этапу, когда оказалось, что нам все-таки нужно настроить SD-WAN и сделать так, чтобы через него можно было собирать данные из отдаленных центров. И это вообще главный критерий успеха проекта. Это стало первым тревожным звоночком.
Дальше – еще интереснее. По схеме, предложенной инженерами клиента, мы должны создать конфигурацию и предоставить им конфигурационные файлы, которые они загрузят на свои устройства — и все заработает. Да и эта SD-WAN команда оказалась не инженерами клиента, а специалистами двух разных внешних вендоров. С одним из них было сложно связаться и получить всю необходимую информацию.
Почти на каждом этапе работы мы сталкивались с необходимостью получать согласование от новых стейкхолдеров, с которыми вообще не контактировали и о чьем существовании даже не догадывались. Хотя нас уверяли, что все нужные стейкхолдеры присутствовали на первой встрече.
В конце концов, мы настроили SD-WAN, создали концепт централизованного сетевого аккаунта и VPC под каждого SD-WAN вендора и даже получили данные из удаленных дата-центров. В этом случае клиент сообщил о появлении очередных новых стейкхолдеров.
Выяснилось, что получение данных – критерий только операционной команды, а у нее есть еще внутренние клиенты, на базе ее продуктов разрабатывающие свои решения. И эти стейкхолдеры не могут пользоваться AWS-инфраструктурой и всей организацией в нынешнем виде, потому что, во-первых, структура аккаунтов не соответствует их модели, а во-вторых, они пользуются Terraform, а не AWS CloudFormation, и хотят передавать его операционной команде на поддержку. Это означало, что для нас проект значительно усложняется, потому что возникает еще один инструмент, под который нужно полностью подстроить продукт. В конце концов, нам пришлось создать дизайн AWS landing zone 2.0 — несовместимый с предыдущей версией — с многочисленными кардинальными изменениями и дополнительными рисками, связанными с миграцией на эту версию 2.0.
Чему мы научились
Вот какие выводы я сделал из этого непростого опыта:
- На первой же встрече нужно задавать как можно больше вопросов, чтобы максимально все прояснить и убедиться в том, что стейкхолдеры понимают, о чем идет речь.
- Важно выяснить все о своих стейкхолдерах и их конечных пользователях, а также убедиться, что вы задаете вопрос именно тем, кто должен на них отвечать. Определить проектных спонсоров, отвечающих за конечный результат и успех проекта.
- Надо проговаривать все до мельчайших деталей – то, что для вас очевидно, может быть не так ясно для клиента, особенно если он вовлечен не во все аспекты работы над продуктом.
- При малейших сомнениях следует аргументированно настаивать на дополнительных встречах и обсуждениях дизайна. Согласования все равно не избежать – это рабочий процесс, но таким образом вы спасете себя от излишней работы и стресса из-за проблем в коммуникации.
Случай №2. Everybody lies
На первый взгляд этот клиент казался настоящим экспертом: утверждал, что хорошо осведомлен с технологиями, которые мы внедряли, что имеет сертифицированных архитекторов AWS-cloud и AWS-девелоперов и использует best practices от Amazon Web Services, а также убеждал, что у него все на 100% правильно настроены. Все по AWS Well-Architected Framework.
Клиент обратился к нам, когда подсчитал, что много платит за использование инфраструктуры AWS (это было в мае 2020-го, когда большинство компаний были в режиме жесткой экономии и стали более тщательно контролировать расходы).
Заказчик утверждал, что его инфраструктура оптимизирована, в компании используют механизмы контроля расходов, reserved instances, утилизация есть. То есть все как следует, но при этом на поддержку инфраструктуры тратятся миллионы долларов в год.
На тот момент мы для них выполняли работу, связанную только с одним из их приложений, в AWS инфраструктуру доступа у нас не было и все, что оставалось — поверить им на слово.
В общем есть два пути решения такой проблемы:
- Cost cut — урезание затрат путем отказа от определенных сервисов, влияющих на характеристики качества системы (безопасность, масштабирование, отказоустойчивость и т.п.).
- Cost optimization – оптимизация имеющихся ресурсов, чтобы сохранить все желаемые характеристики качества системы.
Клиент решил выбрать третий – переехать на облако другого провайдера, предложившего привлекательные скидки на начальном этапе. Понимая, что это неправильный путь, который в долгосрочной перспективе только усугубит проблему, мы попросили провести небольшой анализ, чтобы понять, на что идут средства и ресурсы. Когда наша команда пообщалась с архитектором на стороне клиента, оказалось, что он не так уверен в правильной работе системы, как нам заявляли сначала. И не зря.
Вот список проблем, которые мы выявили:
- технический долг, возникший при переходе в AWS-облако из дата-центра по принципу lift&shift без адаптации инфраструктуры;
- отсутствие облачной модели расходов;
- отсутствие контроля над расходами в облаке и нормального планирования;
- отсутствие контроля за используемыми ресурсами и сервисами;
- не внедрены best practices и базовые конфигурации безопасности и ограничений — исследовав отчеты по использованию reserved instances, мы выяснили, что в начале они выбрали и приобрели предыдущее поколение виртуальных машин (EC4), но в какой-то момент команда разработчиков решила, что лучше подходит C5 поколение виртуальных машин (т.е. они дважды платили за одно и то же);
- плохая внутренняя коммуникация;
- плохая документация: банально не было документировано, какие ресурсы они купили, а какие используют по факту.
Однако топ менеджмент уже принял решение переходить на другое облако, даже несмотря на наши расчеты. Буквально в начале марта этого года мы получили от них запрос на оптимизацию, поскольку они увидели, что в новом облаке экономят только из-за скидки, которую им предоставил провайдер, и как только она закончится, все вернется к тому уровню, на котором и было.
Чему мы научились
Из этого кейса я извлек три основных урока:
- не стоит полностью полагаться на информацию, которую предоставляют клиенты — даже если они не имеют цели скрыть, они могут не понимать, какие данные для нас важны и нечаянно пропустить ключевые детали;
- начинать коммуникацию с клиентом и предлагать решение потенциальных или уже имеющихся проблем нужно как можно раньше, не ждать, пока клиент захочет мигрировать в другой cloud-сервис. А для этого важно своевременно оценить ситуацию;
- необходимо сразу же находить правильных стейкхолдеров, чтобы как можно быстрее и в полном объеме получать нужную информацию.
Случай №3. Kubernetes как серебряный шар
Среди некоторых инженеров есть тенденция любую проблему решать использованием самых трендовых технологий, таких как Kubernetes. Этот кейс о том, что подобный подход срабатывает не всегда.
Наш клиент – платежный сервис, работавший по модели классического телефонного контакт-центра. Они обратились к нам с запросом разработать совершенно новый сервис – интернет-платформу для онлайн-платежей. Они желали полноценно держать свою инфраструктуру в облаке AWS, но вместе с тем хотели сделать ее облачно независимой для будущих нужд (новые клиенты, региональные рынки и т.д.). Никаких ограничений в технологиях не было.
Клиент привык к использованию виртуальных машин с другими своими продуктами, но мы провели воркшоп для стейкхолдеров, чтобы объяснить преимущества микросервисной архитектуры и контейнеров и склонили клиента на их сторону. На этом этапе все было хорошо. Пока мы не пришли к выбору конкретной технологии.
Обычно более двух вариантов лучше не давать, поскольку клиенту будет сложно определиться. Поэтому мы провели и аргументированно предложили выбрать между Kubernetes и Amazon ECS . Нам изначально лучше казался второй вариант, поскольку он позволил бы за короткое время достичь конкретного результата (клиент смог бы продавать свой продукт конечным пользователям). Kubernetes является полноценной экосистемой с рядом дополнительных особенностей и возможностей. Все это добавляет функционалу, но этому клиенту он не был нужен. К тому же на тот момент в AWS не был полноценно доступен Kubernetes как managed service ( Amazon EKSработал только в нескольких регионах и с ограниченным функционалом). Это усложняло процесс менеджмента и поддержки этого решения. Однако клиент побоялся, что Amazon ECS сильно подвяжет их под AWS-облако (vendor lock), и остановился на Kubernetes.
Что пошло не так
Короче говоря, мы просто послушали клиента, а также внешних экспертов, утверждавших, что ECS не перспективная технология, развивать которую AWS не будет и начали делать проект на Kubernetes.
Среди первых трудностей, с которыми столкнулись, были:
- Решение должно было соответствовать PCI DSS (Payment Card Industry Data Security Standard). Это ограничивало использование некоторых managed-сервисов. Так, например, EKS тогда был доступен только в двух регионах и не имел этой сертификации. ECS, в отличие от него, подходил.
- Managed-сервисы поднимать не могли, но могли использовать Vanilla Kubernetes. Операционная команда на стороне клиента оказалась не столь квалифицированной, чтобы его полноценно поддерживать.
- К кластерам были особые требования, поскольку нужно было производить безопасную интеграцию сервисов основной платформы, не обрабатывающей платежные данные, с обрабатываемыми сервисами. С ECS это было бы гораздо проще.
Следующие этапы, когда клиент должен был адаптировать решение в соответствии с результатами маркетингового исследования, а затем трансформировать его в SaaS-решения, были чрезвычайно длинными и сложными, еще и нужно было постоянно обучать команду поддержки, которая оказалась не готова к такому сложному стеку.
Результат:
- Дополнительная сложность проекта.
- Затянутые сроки.
- Проблема с гибкостью решения в разрезе его жизненного цикла, то есть в процессе того, как он развивался бы дальше.
В конце концов, когда Amazon EKS сервис стал соответствовать PCI DSS в нужных нам регионах, мы перешли на него. Но, конечно, это было не так-то просто, учитывая, что нужно было переписывать под него все конфигурационные скрипты.
В общем, это решение обошлось клиенту слишком дорого (дополнительные затраты на тренировку операционной команды и на сам кластер), он рассматривал переход и на ECS, и в другие облака (надеясь, что это поможет сэкономить), но это было бы еще сложнее и дороже.
Чему научились
Главный урок – важно объективно оценивать уместность технологий. Не ко всему нужно и можно применить Kubernetes (есть достаточно альтернатив, например, Amazon ECS и HashiCorp Nomad ). Хотя у платформы и много возможностей, но они далеко не всем уместны, особенно когда речь идет о небольших проектах, нуждающихся в быстрых и максимально эффективных решениях. Не для всего нужны ракеты — для чего-то достаточно и воздушных шаров.
Случай № 4. «Новые фичи – наша цель»
Этому клиенту требовалась микросервисная архитектура с нуля, процесс CI/CD, и он соглашался с использованием IaC для развертывания менеджмента и инфраструктуры. Однако у клиента было ограниченное время на принятие решения и реализацию пилота (MVP) — ему сначала следовало показать решение MVP-интеграции и уже потом двигаться дальше. Получив широкое поле работы, мы навязали клиенту идею all-in-one-platform с большим количеством фич (представьте независимые компоненты с возможностью переиспользования, развертывания различных компонентов облачной инфраструктуры, использование различных типов сборки приложений, использование Golden Image и т.д.).
Что пошло не так
Проект оказался сложным, и в процессе имплементации произошло несколько ошибочных «потерь» разработочных оцеплений, что отняло у нас много усилий и времени, приводило к блокерам и срыву дедлайнов. В конце концов получилось много фич и воркераундов (это было связано с тем, что клиент еще не был готов менять все автоматизированно, как предполагалось).
Мы поняли, что проект слишком комплексный и сложен и для нас, и для клиента. Мы создавали лишние Proofs of Concept, которые не выполняли реальные функции, но отнимали время. В конце концов оказалось, что созданная платформа имела высокий порог вхождения — в ней было много фич и элементов, поэтому клиенту было трудно понять, как ею пользоваться.
Чему научились
Этот проект научил меня важным вещам о целесообразности и необходимости определенных сервисов и функционала:
- крайне важно понять, что именно нужно клиенту, и работать согласно этим потребностям, а не с собственными представлениями о проекте и интересными для нас вариантами его воплощения – наше мнение здесь далеко не на первом месте;
- следует руководствоваться техническими возможностями клиента и уровнем развития его команды при регулировании сложности проекта — какими бы крутыми ни были фичи, которые мы создаем, в них не будет никакого смысла, если они не будут выполнять свое предназначение и не будут эффективно приближать клиента к его цели;
- Proofs of Concept нужно делать только тогда, когда они доказывают value, иначе это бесполезная трата времени и усилий.
Вместо выводов
Ну и наконец несколько общих принципов, которые я для себя сформулировал:
- Здание начинается с архитектуры и фундамента, так же хорошо прописана архитектура – ключевой компонент для успешного технологического проекта.
- Внимание к деталям важно: при необходимости можно изменить решение, но уже в самом начале работы нужно правильно определить, сколько времени требуется для реализации, насколько производительна работа и скоординированы ли отдельные команды, работающие над проектом.
- Атрибуты качества зависят от архитектурных решений: каждый дизайн требует компромиссов (если самолет пассажирский – акцент на комфорт, если военный – на скорость и безопасность), поэтому поймите, что именно нужно вашему клиенту и как можно скорее обсудите приоритеты.
- AWS landing zone очень полезна во время миграции – не игнорируйте ее преимущества.
- У стейкхолдеров ключевая роль в том, чтобы проект был успешен, и каждый из них отвечает за отдельные сферы, поэтому для того, чтобы понять всю систему, нужно найти общий язык с ними всеми. Задавайте стейкхолдерам правильные вопросы и ограничивайте каждое обсуждение небольшим количеством тем, чтобы максимально эффективно прорабатывать информацию.
- За все нужно платить — сервисы и платформы не бесплатны, каждое решение требует идти на определенные компромиссы (часто связанные с ценой), и если клиент к этому не готов, то уметь объяснить возможные последствия.