Контейнерные технологии надоедают — и это хорошо

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

Дьявол, которого ты знаешь

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

На KubeCon 2018, который недавно прошел в Сиэтле, присутствовало необычно большое количество поставщиков, таких как CouchBase, YugaByte, CockroachDB и MongoDB, и все они объявили о своей поддержке SQL. Несмотря на то, что существует множество разновидностей SQL, основным фактором, способствующим внедрению SQL в современные распределенные базы данных, является совместимость с инструментами бизнес-аналитики. Это означает, что удобнее писать инструменты BI для нескольких баз данных, когда все они используют SQL, а не проприетарные языки запросов. MongoDB, в частности, заявила, что их реализация SQL была специально разработана для поддержки инструментов BI.

Контейнерная технология: просто назовите это инфраструктурой

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

AWS и ее доминирующее поглощение облака ясно показали, что большинство людей скорее предпочтут использовать облачную платформу, чем покупать проприетарную инфраструктуру. И 2018 год показал, что помимо работы над своими функциями, большинство людей предпочли бы, чтобы за них делали и все остальное. Вероятно, поэтому в настоящее время существуют платформы внутри платформ, которые заботятся практически обо всем, включая возможность использовать готовый конвейер в виде службы CI/CD, такой как Jenkins X или Weaveworks. AWS Lambda, GKE и AWS Fargate — хорошие примеры платформ, которые практически не требуют опыта работы с Kubernetes и практически готовы к использованию «из коробки».

Обслуживание ваших микросервисов

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

Istio стал лидером в этом сегменте и представляет собой инструмент управления сеткой сервисов с открытым исходным кодом, который позволяет вам подключать, защищать, контролировать и наблюдать за вашими сервисами. Это означает, что теперь поставщики либо переходят на Istio, либо используют Istio, а не пишут свои собственные проприетарные инструменты. В экосистеме Istio появляется множество стартапов, и хотя конкурирующая компания Linkerd только что претерпела значительные изменения с новым пользовательским интерфейсом, показателями маршрутов и профилями услуг, в 2019 году Istio будет принята еще активнее. Коммуникация между службами, хотя и бесконечно более сложная, гораздо более мощная и, без сомнения, за ней будущее.

Это не означает, что Linkerd не имеет значения или что-то в этом роде, и сообщество Linkerd глубоко копнуло и практически полностью переписало свою кодовую базу с последним обновлением. По словам Уильяма Моргана, генерального директора Buoyant, это было сделано для того, чтобы плоскость управления можно было перенести с JVM на язык программирования Go, что сделало ее меньше и быстрее, чем в предыдущих итерациях. Кроме того, Linkerd 2.0 по своей сути является «дополнительной услугой», работающей на одной службе и не требующей установки в масштабе всего кластера. Это означает, что если у вас нет доступа ко всему кластеру Kubernetes, вы все равно можете запустить Linkerd в своем сервисе и использовать множество функций.

Монополизация облака

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

В частности, что касается безопасности, KubeCon Seattle увидел, что вендоры в целом ответили на призыв предыдущего KubeCon в Копенгагене, который звучал так: «В этом году все дело в безопасности». Aqua Security, ведущий поставщик платформ для защиты контейнерных и облачных приложений, объявил об интеграции своей платформы с платформой облачного мониторинга и аналитики Datadog. Это партнерство означает, что пользователи Datadog видят состояние безопасности облачных приложений в режиме реального времени. Сюда входит информация об уязвимых образах, ненадежных запущенных контейнерах и аномалиях безопасности.

Контейнерная безопасность

Google также рассказал об улучшениях безопасности контейнеров, а Майя Качоровски, менеджер по продуктам, безопасности и конфиденциальности, написала информативный блог о проблемах безопасности Kubernetes, в котором говорится: «В этом году Kubernetes добился огромных успехов в области безопасности и гигантских успехов в Google Cloud». Кроме того, чтобы решить проблемы с сетью и безопасностью в средах Kubernetes, Arista объединилась с Red Hat и Tigera для демонстрации интегрированного сервиса, который будет доступен в 2019 году. Предполагается, что сервис обеспечит модель безопасности с нулевым доверием для контейнеров и функций Kubernetes. возможность отслеживать журналы потоков данных на предмет нарушений политики безопасности, а также других аномалий.

Смещение фокуса контейнерных технологий

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