Микросервисная архитектура использует совершенно новый подход к инфраструктуре

Благодаря таким сервисам, как Netflix, Uber, YouTube и Facebook, большинство людей привыкли к приложениям, которые быстро реагируют, работают эффективно и регулярно обновляются. Терпение больше не является добродетелью, и благодаря приложениям, подобным упомянутым выше, когда люди используют приложения, они ожидают невероятной скорости и бесперебойного обслуживания. Если вы этого не сделаете, у пользователей не будет выбора; на удаление приложения и загрузку другого в качестве замены уходит меньше минуты.

Быстрый или мертвый

С микросервисной архитектурой, какой она является сегодня, разрыв между хорошим, плохим и уродливым теперь огромен с точки зрения возможности предоставления высококачественного программного обеспечения со скоростью и эффективностью. На самом деле, сейчас разница настолько огромна, что ее продемонстрировал Боб Уайз, технический директор группы облачных вычислений Samsung, в своем докладе, который показал, что высокопроизводительные организации развертываются в 200 раз чаще, восстановление после сбоя в 24 раза быстрее, в три раза меньше частота отказов изменений и в 2555 раз меньшее время выполнения заказов, чем у низкоэффективных организаций. Это огромная разница, если не сказать больше, и если ваша организация находится в нижней части этого спектра, время для паники было вчера.

Что такое микросервисная архитектура и почему она дает этим первопроходцам такое преимущество перед всеми остальными? Микросервисная архитектура заключается в том, чтобы разбить ее на части и распространить. У Uber, по-видимому, в любой момент времени работает от 2000 до 3000 микросервисов. Микросервис — это, по сути, код, написанный таким образом, чтобы его можно было повторно использовать во всем спектре организации или, по крайней мере, абстрагироваться, чтобы упростить разработчикам создание новых функций или сервисов без необходимости начинать с нуля. Это в значительной степени означает абстрагирование от всей «сантехники» и переход к делу гораздо более дешевым и эффективным способом.

Микросервисная архитектура и традиционные API

В качестве примера давайте рассмотрим, что отдел «А» организации создал сервис, который позволяет пользователям общаться в видеочате, а отдел «Б» позволяет им играть друг с другом в онлайн-игры. При традиционном подходе API оба этих отдела будут иметь свои собственные серверные процессы для выставления счетов, управления пользователями, планирования и контента, среди прочего. Однако теперь все эти процессы хорошо работают вместе внутри определенного отдела, все они настроены для конкретного решения, поэтому A не может использовать процесс выставления счетов B или B не может использовать поставщиков контента A и так далее. К чему это сводится, так это к дублированию усилий, что является большим запретом в сегодняшней среде пользователей с высокими ожиданиями.

Напротив, если бы описанный выше сценарий существовал в среде микрослужб, все, кроме фактического кода, который запускает приложение, было бы абстрагировано в отдельные микрослужбы, которые являются универсальными и могут использоваться во всех отделах и службах. По правде говоря, если убрать весь «вспомогательный персонал», останется только сама бизнес-функция. Это не только дает разработчикам свободу не беспокоиться о зависимостях и бэкэнд-функциях и сосредоточиться на коде, но также значительно упрощает создание тестовых сред, поскольку теперь все бэкенды дублируют друг друга в организации.

Контейнеры — это только вершина айсберга.

Вот почему высокоэффективные организации намного опережают низкоэффективные организации, и причина, по которой мы используем здесь слово «организации», заключается в том, что именно организационные изменения приводят вас к цели, а не технологические изменения. Хотя этот подход позволяет создавать, тестировать и развертывать новые функции и сервисы, не влияя на весь продукт, на самом деле это не так просто, как взять монолит и поместить его в контейнеры. Многие люди говорят о контейнерах и микросервисах и о том, как они сочетаются друг с другом, но контейнеры — это просто основная единица развертывания. Чтобы по-настоящему внедрить микросервисную архитектуру и оставаться актуальными, компаниям придется изменить не только то, что они развертывают, но и людей, которые занимаются развертыванием.

Боб Уайз спросил, сколько людей слышало о законе Конвея, и был приятно удивлен, когда несколько человек подняли руки. Закон Конвея гласит, что системная архитектура следует организационной модели, поэтому, короче говоря, традиционной иерархической организации с централизованным управлением придется нелегко с микросервисной архитектурой. Что вам нужно, так это множество независимых команд, самостоятельно создающих независимые части.

Он также упомянул «оружие для прошлой войны», и это отличная аналогия, так как путь развития современных контртеррористических сил является прекрасным примером.

Новое оружие для новой войны

Чтобы противостоять партизанской войне, которую использует большинство террористических организаций, современные антитеррористические группы отказались от ортодоксальных операций в стиле взводных батальонов. Современный подход или подход после 11 сентября — это множество небольших, хорошо экипированных ударных групп, разбросанных по большим территориям, с постоянной поддержкой, связью и даже информацией с дронов и спутников. Там, где был один военный корабль, теперь сотни бронекатеров с радарами, спутниковыми телефонами и ракетными установками, вот что нужно делать со своим монолитом.

Если мы внимательно посмотрим на приведенную выше аналогию, то на самом деле изменилось не оружие, а подход. Этот подход в разбивке сводится к тому, насколько быстро вы способны адаптироваться к изменениям в вашей среде или насколько «быстра» ваша команда быстрого реагирования.

Принятие изменений с помощью автоматизации

Боб Уайз сказал, что высокопроизводительные организации принимают изменения, но действительно высокопроизводительные организации «быстро принимают изменения с помощью автоматизации». Это достигается за счет множества независимых команд, выполняющих независимые и простые части с непрерывной интеграцией и непрерывной доставкой (CI/CD), автоматизированным контролем качества и автоматизированной безопасностью. Он также упоминает, что в настоящее время DevOps быстро становится термином для перегруженных «универсалов», которые делают всего понемногу. Это потому, что они по-прежнему управляют своим бизнесом как централизованно управляемая иерархия, а не как «кластерные операции», которые представляют собой множество команд независимых операционных специалистов. Он также затрагивает тот факт, что люди так часто используют слово CI/CD, что многие начинают думать, что CI означает CD.

КИ это не компакт-диск

Тот факт, что у вас есть CI, не означает, что вы можете говорить, что у вас есть CI/CD, пока ваше развертывание не будет автоматизировано. Другими словами, CI с ручным развертыванием не только не в счет, но и ведет себя в противоположном направлении. Чтобы построить эту худощавую, подлую боевую машину, вам нужно начать с нуля, и основа — это Ops, а не Dev. У вас не может быть гибкой команды разработчиков без гибкой команды эксплуатации, и это делается путем контейнеризации существующих приложений в инструментах развертывания, чтобы это не повлияло на команду разработчиков.

Kubernetes, облачный Linux

Боб Уайз также входит в Cloud Native Computing Foundation, поэтому неудивительно, что он рекомендует Kubernetes как лучший способ развертывания новых контейнеров, и никто не стал бы с ним спорить по этому поводу прямо сейчас. У него даже был интересный слайд, показывающий, как Kubernetes является частью CNCF, которая является частью основы Linux, и как Kubernetes быстро становится облачным Linux.

Очевидно, что идеальной системой будет та, в которой артефакты развертывания могут обновляться и развертываться последовательно без ошибок. Именно тогда вы, наконец, запускаете небольшие добавочные обновления Dev и действительно начинаете путь DevOps к тому, чтобы стать высокопроизводительной организацией.

Строительство с нуля дает вам возможность обновлять часть за раз, не перегружая себя. Когда вы сразу понимаете, что внедрение микросервисной архитектуры, вероятно, станет самым важным, рискованным и техническим проектом, который когда-либо предпринимала ваша организация, возможно, стоит сделать это правильно с первого раза.