Сложно ли внедрение Serverless?
Является ли внедрение Serverless сложным процессом?
Понимайте простые меры, чтобы сделать вашу адаптацию серверного решения успешной
Более года назад, поднимаясь на определенную высоту в сентябрьском пейзаже Семмеринга, Австрия, мы потерялись на развилке на нашем пути. Так как указатели были неоднозначными, я обратился к мобильному телефону за подсказками. Среди нескольких уведомлений в Twitter (X) пролетела ссылка на статью Пола Джонстона Обучение без серверов (и почему это сложно).
В обычный день я бы прочитал это сразу. Но, находясь в местности и несущую ответственность за вывод моей семьи из леса, я не был готов пожертвовать живописным утром в Семмеринге ради обработки серверной части.
Я прочитал ее по возвращении, и в своей статье Пол смело ударил многие гвозди прямо в цель! Я хотел поделиться своими мыслями раньше, но с обязательством завершить книгу Разработка без серверов на AWS. Создание масштабируемых серверных решений для предприятий (O’Reilly, 2024), я здесь год спустя, чтобы одолжить молоток и нанести свои удары, рассмотреть проблему с общего ракурса, а не только с точки зрения обучения.
В этой статье я расскажу вам о некоторых основных факторах, чтобы достичь успеха при разработке приложений с использованием серверной технологии – будь это коммерческое производство, создание данных, ИИ или машинного обучения.
- Как работают искусственные интеллекты для обнаружения контента?
- Категориальные признаки что не так с кодированием меток?
- CSV в PDF Подсказка GPT-4 для автоматического создания отчета по визуализации данных
Книга о сервере
Разработка без серверов на AWS: Создание масштабируемых серверных решений
sbrisals.medium.com
Трудно ли водить автомобиль?
- Трудно ли водить автомобиль с механической коробкой передач?
- Трудно ли научиться водить автомобиль с механической коробкой передач?
Ответ зависит от вас. Если вы водите уже несколько лет, ваш ответ на первый вопрос будет отрицательным нет. Потому что за годы вы овладели всеми маневрами, и они приходят к вам естественно, без необходимости думать о них.
Однако, когда вы были водителем-новичком, ваш ответ на второй вопрос был бы однозначным да. Когда вы учитесь водить, есть множество вещей, которые нужно учитывать – действия, требующие координации, действия, происходящие последовательно, и наблюдения, которые нужно выполнять одновременно. При этом вы находитесь в движении с автомобилем.
Ваша способность только поворачивать руль не сделает вас водителем.
Если вы рассмотрите автомобиль с автоматической трансмиссией, то ваши действия водителя будут частично упрощены, так как механизмы автомобиля заботятся о некоторых действиях (как облачный провайдер заботится о выполнении некоторой тяжелой работы в серверных решениях).
Многие вещи в нашей повседневной жизни сложны, но мы изучаем навыки и следуем зарекомендовавшим себя путям, чтобы стать в них лучше. Разработка без серверов – не исключение. Это может показаться простым (как автомобиль с автоматической трансмиссией), но это не заставит вас мгновенно запустить двигатель и устремиться в путь.
Существует множество способов сделать что-то неправильно в технологии, особенно в серверных решениях. Построение запутанной архитектуры, основанной на событиях, с использованием серверных сервисов легко и не требует много времени. Однако, разработка модульного, наблюдаемого и устойчивого решения требует знаний и правильных навыков. Это не означает, что серверная разработка сложна.
В технологиях много способов делать вещи неправильно, особенно в безсерверной среде.
Безсерверный подход сложен, если вы не понимаете его экосистему.
Автомобиль состоит из множества частей, от общего представления до подробных деталей. Двигатель автомобиля в основном представляет собой одну единицу, но состоит из нескольких компонентов. Работающий автомобиль нуждается в водителе (если не учитывать автомобили без водителя) и перевозит пассажиров. В некотором смысле все они вместе составляют экосистему автомобиля.
Слишком часто многие описывают безсерверный подход как архитектурный чертеж, функцию как сервис (FaaS) или фреймворк. Для меня он выходит за рамки всего этого и больше, чем то, чем мы обычно его представляем. Безсерверность, в некотором смысле, представляет собой технологическую экосистему. Когда вы и я работаем с безсерверностью, мы также становимся ее частью – подобно тому, как водитель и пассажиры являются частью автомобильной экосистемы.
Как показано на картинке, экосистема безсерверного подхода имеет несколько факторов. Безсерверная технология имеет свои уникальные характеристики. Облачная платформа и управляемые сервисы образуют основу. Разработческие практики, инструменты и фреймворки позволяют создавать ценность быстрее. Заинтересованные стороны бизнеса сотрудничают с инженерами, чтобы создавать современные возможности в безсерверной среде для клиентов. Все это и многое другое является частью этой экосистемы.
Целью вышеописанного описания является заставить вас задуматься не только о написании функций или спорах о выборе инструментов инфраструктуры. Подумайте о разнообразии, которое безсерверность приносит вашей организации, вашей команде и вам самим, так как вам придется одновременно выполнять несколько ролей при работе с безсерверным подходом. Мы все чаще сталкиваемся с мыслями, подобными приведенным ниже, из высказывания Ли Гилмора. Постепенно развиваясь, мы становимся частью экосистемы безсерверного подхода.
Безсерверный подход сложен, если вы начинаете с неправильного менталитета.
Несколько лет назад один инженер обратился с просьбой о помощи в своем безсерверном путешествии. Несколько минут во время разговора стало ясно, что он хотел реализовать логику своих функций Lambda таким образом, чтобы его безсерверные приложения могли быть легко развернуты в другом облачном провайдере в случае необходимости, если принимающие решения в его организации захотят сменить провайдера.
Поняв его намерения, я спросил его о его подходе к не-FaaS-сервисам и о том, как он сделает их безразличными к облачным платформам. Его объяснение было своего рода грандиозной реализацией гексагональной архитектуры!
Под конец разговора я понял, что он еще не развернул ни одной безсерверной рабочей нагрузки в производстве!
Хотя такие мысли и подходы радуют руководство, оцена вызовов и ценности для бизнеса не проводится. Компании принимают технологии, такие как безсерверность, чтобы увеличить скорость разработки, повысить эффективность и создать конкурентное преимущество. Подход к безсерверности с таким мышлением, как описано выше, подобен гонке за миражом, в результате которой ничего не удается достичь и ничего не удается доставить в ближайшее время.
Инженеры часто указывают на возможности использования многоклаудовых конфигураций, предлагаемых фреймворками, как пример (или оправдание). Факт в том, что инструменты предоставляют такие возможности, чтобы каждый мог ими пользоваться, и вы не принимаете решение о многоклауде на основе того, что предлагает фреймворк. Когда такие неправильные стратегии не приносят ценности, мы слышим вопли – переход на безсерверность сложен, запутанный и противоречивый, как упоминает Пол в своей статье.
Инструменты разработки часто поддерживают возможности многоклауда, но вы не принимаете решение о многоклауде на основе того, что предлагает фреймворк.
Безсерверный подход сложен, если вы думаете, что он слишком прост.
Меня пригласили на встречу, чтобы прослушать и утвердить предложение о безсерверной архитектуре. Инженер представил хорошо подготовленную электронную доску и рассказал о своей архитектуре. Функции Lambda были основным элементом решения, с несколькими таблицами DynamoDB. Я начал чувствовать дискомфорт, и извиняясь прервал разговор и задал вопрос –
Ранее вы разрабатывали безсерверные решения?
И инженер ответил, Да!
После нескольких «Почему» в отношении некоторых выборов, сделанных в дизайне, инженер признался, что ранее они писали лямбда-функции для простых функциональностей, но не работали с микросервисами, основанными на событиях.
Моя цель здесь – не умалять инженера, но подчеркнуть важную фазу, через которую мы все проходим при освоении и работы с новой технологией. Умение писать и использовать лямбда-функции – это безусловно правильный старт, но в то же время не следует думать, что все слишком просто в безсерверной среде. Именно такое отношение делает вашу реализацию запутанными безсерверными приложениями.
Я согласен, что для новичка в безсерверной среде знание разделения проблемы на микросервисы, определение синхронных и асинхронных частей приложения, мышление в терминах событий или проектирование для обозримости является сложным. Факт в том, что многие из этих аспектов не являются новыми и не связаны специально с безсерверными решениями. Разница заключается в том, что в прошлом, с ограничениями команд, вам, как программисту, никогда не давали такой опыт или возможности участвовать в этом процессе.
Когда вы учитесь водить машину, вы проходите несколько занятий, прежде чем почувствуете уверенность для практического экзамена. Аналогично важно оценить свои навыки в безсерверной среде и пройти необходимое обучение (обсуждается в следующем разделе) вместе со своей работой в качестве безсерверного инженера.
Безсерверность сложна, если вы исключаете инженеров из архитектурных дискуссий.
Подход, который я использую при работе с командами, заключается в назначении ответственности за разработку сервиса или функциональности одному или нескольким инженерам – от идеи до внедрения. Они становятся частью пути, начиная с ранних разговоров с командами продукта, заинтересованными сторонами и техническими экспертами для сбора знаний о разрабатываемом решении. Они участвуют в необходимых сессиях идеи и анализа проблемы, начинают разрабатывать архитектуру под руководством старших коллег и экспертов, прежде чем создать Документ архитектуры решения для общего обзора. Отсюда создаются билеты на реализацию и проходит итеративная разработка и доставка.
Значимость проектирования решения в разработке безсерверных приложений – часть I
Что это дает и зачем нам это нужно?
sbrisals.medium.com
Вышеупомянутый подход является целенаправленным. Несмотря на наличие недостатков и критики, он приносит множество пользы команде и профессиональному росту инженеров. Чтобы обучить инженеров и внедрить их в экосистему безсерверных технологий, вам нужно перестать подавать им готовые архитектурные решения. Вместо этого вы развиваете архитектуру вместе с ними, предоставляя идеи и ресурсы для их обучения, развития и доставки.
Не стройте свои безсерверные архитектуры в башне архитекторов, а создавайте их в командной комнате.
Однажды в организации было сотрудничество между командами для внедрения новой функции. Было несколько сессий идеи с группой людей, прежде чем согласовать общую концепцию, которая была достаточно хороша, чтобы подробно описать ее в документе архитектуры решения. Позже нескольким инженерам был назначен билет для реализации их части решения. Однако эти инженеры никогда не участвовали в предыдущих сессиях, не получили инструкцию и не видели виртуальную доску, на которой были запечатлены все записи, рисунки и мысли из прежних разговоров.
Как вы можете себе представить, эти инженеры оказались в сложной ситуации. Независимо от их способностей и тривиальности проблемы, убедитесь, что ваша работа в безсерверной среде не начинается с Visual Studio (VS) Code. Если вы так сделаете, нет гарантии, что ваш опыт работы с безсерверностью будет гораздо проще.
Независимо от способностей инженеров и тривиальности проблемы, ваша работа в безсерверной среде не начинается с VS Code.
Безсерверность сложна, если вы требуете совершенства, отдавая предпочтение прагматизму.
В моих докладах о том, как развивать команды безсерверных технологий, я демонстрирую слайд, который показывает, как команда с практическим мышлением может ускориться с безсерверностью, в то время как команда, ориентированная на совершенство и стремящаяся к идеальному решению с пессимистическими взглядами, остается позади.
Часто информационное перенасыщение и стремление идеалистов-архитекторов знатоков, не имеющих практического опыта работы с двигателем, могут сделать ваше переход на безсерверную архитектуру сложным и ваш опыт плохим.
Однажды я услышал историю про две команды, работающие в безсерверном режиме, во время общего разговора в сообществе. Обе команды имели общие черты. Они работали в пределах своих территорий – ограниченных контекстов, разрабатывали событийно-ориентированные микросервисы и имели четко определенные API.
Одна команда владела и управляла своими микросервисами в одном производственном AWS-аккаунте (с отдельными аккаунтами для тестирования, QA, предпродакшена и т. д.), держала свои функции Lambda вне пользовательских VPC (Виртуальных Частных Облаков) и настраивала VPC только там, где это необходимо, и размещала свои API на Amazon API Gateway с необходимыми планами использования. Их сервисы координировались пользовательской системой шины событий Amazon EventBridge. Для этой команды разработка, развертывание и эксплуатация нового микросервиса казались легкими.
Однако вторая команда, руководимая идеалистической школой мысли, выбрала размещение каждого микросервиса в отдельном AWS-аккаунте и развертывание функций Lambda в пользовательских VPC. Кроме того, все их API размещались на другой платформе для входных ворот. С двадцатью и растущим числом микросервисов они боролись с возникающей сложностью.
Конечно, бывают ситуации, когда мы делаем отличные выборы и принимаем решения, но мы должны оценивать и корректировать курс, чтобы избежать попадания в неуправляемую и негативную ситуацию, из которой нельзя вернуться.
Одна из основных мотиваций для перехода на безсерверную архитектуру – это переложение рутинной работы на облачного провайдера, но если мы идем в разрез с преимуществами безсервера в своих стратегиях, безсерверный подход становится только сложнее.
Безсерверно сложно, если нарушены границы команды.
Когда речь идет о границах команды, каждый думает о Ограниченном Контексте (как в концепции ООД). Однако, помимо этого, существуют и другие границы, важные для автономных команд, занимающихся безсерверными сервисами и состоящими из двух-пицц-команд.
- Граница ограниченного контекста
- Граница ответственности команды
- Граница владения командой
- Граница репозитория исходного кода
- Граница облачного аккаунта
Первые три границы зависимы и пересекаются. Если ваша команда является хранителем ограниченного контекста организационного домена, вы находитесь в отличном положении. В этом случае ваша команда отвечает за все, что находится внутри этой границы, и владеет всеми функциями, сервисами и артефактами реализации.
Весь код вашей команды хранится в репозитории, к которому вносят свой вклад и делится друг с другом члены команды.
Граница облачного аккаунта AWS определяет операционную границу в пределах которой вы развертываете и работаете со своими облачными и безсерверными активами.
В идеальном мире у вас будет один-к-одному соответствие между вашей командой и этими границами, как показано ниже.
- Ваша команда существует из-за ограниченного контекста.
- Ваша команда отвечает за все, что находится внутри ограниченного контекста.
- Ваша команда использует репозиторий, в котором вносят свой вклад только члены вашей команды.
- Ваша команда эксплуатирует все, что принадлежит ей, в пределах своего выделенного облачного аккаунта.
Ваша жизнь как инженера безсерверной архитектуры становится простой и приятной!
Теперь давайте начнем расширять эти границы и представим, что может произойти.
Предположим, из-за приоритетов бизнеса и необходимости выполнить ожидания поставки, вы привлекаете инженеров из другой команды в качестве совместного ответственного за внесение вклада в границы вашей команды, что заставляет сфокусироваться вашу команду на новых областях.
- Как вы гарантируете, что команды знают друг о друге и знакомы с их рабочими методами?
- Как вы гарантируете, что качество кода остается однородным?
- Как вы гарантируете согласованность выбора сервисов AWS и архитектурных шаблонов?
- Как вы гарантируете, что нет пробелов в операционной ответственности?
Эти команды могут сотрудничать, чтобы решить и облегчить ситуацию. Но сотрудничество означает больше общения, парное программирование, обзоры кода, обсуждения, совещания и т. д., и все это повлияет на фокус и эффективность обеих команд.
Открытые границы команды и совместная ответственность без должной проработки могут негативно сказаться на организации. Разработка на безсерверной архитектуре может стать сложнее и вызывать разочарование у разработчиков.
Безсерверно сложно, если вы не инвестируете в развитие сотрудников.
Мир вокруг нас полон коротких путей. Несколько быстрых способов научат вас писать функции Lambda. Такой “фаст-фуд” подход к обучению хорош только пока еда не закончится. Чтобы сохранять аппетит, вам нужно продолжать заказывать.
Чтобы быть успешным в безсерверном программировании, вам необходимо продолжать обучаться.
Статья Пола фокусируется в основном на обучении и том, как люди, которые вступают в безсерверный мир, часто борются с осознанием технологии и ее экосистемы. Как описывает Пол, для новичка в безсерверном программировании даже понятие функций одного назначения Lambda требует времени для усвоения.
Для успеха в безсерверном программировании вам нужно сделать много шагов, как только вы освоитесь с функциями одного назначения Lambda. Несколько областей выступают в качестве ступеней, чтобы вы прогрессировали к успешному достижению, которое требует множества прыжков, и вы приобретаете множество навыков по пути.
Я часто подчеркиваю, как безсерверное программирование приносит разнообразие в команды разработчиков. Это осознание важно, если вы хотите сделать безсерверное программирование легким.
Инженеров следует направлять, развивать, наставлять, обучать (или каково было бы наиболее подходящее терминологии вашей организации), чтобы они понимали требования заинтересованных сторон, могли предлагать архитектуры, осознали преимущества функций одного назначения и микросервисов, знали, как внедрять безопасность, обучились основам управления наблюдаемостью, позволили им развертывать в продакшн и назначали их ответственными за свои сервисы. Это нельзя освоить за одну ночь или просмотром нескольких видео на YouTube. В этом случае оцените качественную подготовку и стратегию долгосрочного развития персонала.
Постарайтесь не ограничивать инженеров корпоративной бюрократией. Позвольте им свободно учиться новому, посещать конференции и участвовать в технических семинарах и совместных мероприятиях.
Я беседовал с менеджером по инженерии на конференции. Она высказала мнение, что семинары, такие как EventStorming и Architecture Katas, продолжительностью несколько часов или более, являются пустой тратой времени и влияют на продуктивность команды. Тогда я спросил ее, как она будет обеспечивать продуктивность, если пара отрицающих возможности и недовольных инженеров заболеют на день или два. У нее не было ответа!
Буткемпы по безсерверному программированию – простой способ донести основы технологии безсерверности до инженеров. Некоторые организации успешно внедрили такие программы. Мэтт Коултер, один из AWS Hero, однажды упомянул удачную программу для новых сотрудников, используемую в Liberty Mutual. Часто компании отдают малое значение таким инициативам, ссылаясь на ограничения бюджета, даже не оценивая преимуществ, которые они приносят.
Одной из проблем в области обучения безсерверному программированию является качество и охват технических, разработочных, архитектурных и операционных аспектов в учебном плане. Среди множества курсов я слышал отличные отзывы о тренировочном семинаре Яна Куи Production-Ready Serverless. Ян является серверным героем AWS и одним из ключевых экспертов в области безсерверного программирования.
Production-Ready Serverless
Изучите ЛУЧШИЕ ПРАКТИКИ для создания безопасных приложений безсерверного программирования.
productionreadyserverless.com
Помогите инженерам понять требования заинтересованных сторон, позвольте им предлагать архитектуры, осознайте для них преимущества функций одного назначения и микросервисов, покажите им, как внедрять безопасность, обучите их принципам наблюдаемости, позвольте им развертывать в продакшн и назначите их ответственными за свои сервисы.
Безсерверное программирование станет проще…
Как и вождение, безсерверное программирование становится продуктивным и приятным по мере накопления опыта и комфорта в его экосистеме.
Американские горки – это не для всех. Самый распространенный совет, который любители адреналина дают другим, – ты просто должен научиться отпускать!
Вы должны научиться доверять технологии безсерверного программирования, чтобы использовать преимущества, которые она предлагает в виде автоматического выполнения задач. Если Amazon Web Services предлагает управляемые решения, воспользуйтесь ими, чтобы увеличить бизнес-значимость. Зачем создавать сложные решения, которые никогда не понадобятся?
Получайте вдохновение от тех, кто уже успешно внедрил безсерверное программирование.
<!–Чтобы закрыть, я не мог найти лучшей фразы, чем тема Momento’s AWS re: Invent 2023 Комьюнити-вечеринка–
Верьте в Serverless!
Да, верьте в serverless и научитесь отпускать!!
