Флант corporate blog
DevOps
Google Cloud Platform
Server Administration
System administration
Comments 9
-2
bullshit
Смысл, как всегда один — думай своей головой, никому не верь и всё проверяй.

Одно ясно по колоссальному инфо шуму и рекламе, а также из финансовых отчетов Cloud провайдеров, что дело это очень прибыльное для них — Клондайк, и если грубо «ламповые»:
  • server room (вместе с админами)
  • enterprise service bus (вместе с админами)
  • message queue(RabbitMQ/WMQ)… etc (вместе с админами)
  • application server/java containers (вместе с админами)
  • oracle/ms sql server/db2 (вместе с админами и отчасти разработчиками)
  • c#/java

всеми правдами и неправдами, будут вытесняться и взамен будут «продвигаться» Cloud Lock решения:
  • Google, Amazon, Azure… etc Cloud (Работа будет не для всех и не во всех странах)
  • Google Kubernetes Engine/fleet/mesos/в части оркестровки, мониторинга зоопарка (переименовываем админа в свитере с оленями в devOps, отправляем изучать язык программирования python/Go/ruby?, инструменты Opaensource, и вуаля — спец готов)
  • Amazon SQS/Cloud Pub/Sub service (плохая новость — работы нет, если только не у Cloud провайдера работаете)
  • Container Level OS (работы нет, немного для Ops, если только не у Cloud провайдера работаете)
  • DO Spaces Object Storage, Cloud Storage, Persistent Disks, Redis, Cloud SQL, S3… etc (для админов работы нет, немного для Ops, если только не у Cloud провайдера работаете, для разрабов работы будет меньше т.к. перестанут пихать логи в реляционные БД и прочие непотребности)
  • python/Go/kotlin/php/js и разноцветные Кубики


Хорошая новость — весь этот Opaensource требует жутких костылей в работе, знаний магии, умения программировать и постоянно подпирать чтобы не развалилось. В тренде будут миграции от одного Vendor Lock Cloud в другой. Переписывания с нуля microservice при добавлении новой фичи, выпиливание vendor lock привязок и впиливание новых, настройка cross cloud взаимодействий, разборов какой из XXX взаимосвязанных сервисов участвующих в процессе виноват в отказе и.т.д.
Интеграция, интеграция, интеграция, ещё раз интеграция со всевозможными сервисами.
Приложения будут жрать в разы больше ресурсов процессора, диска, трафика, но все так и задумано.
Кстати в процессах SDLC — Ops становится таким «полубогом».

Вот как-то так, примерно, как развитие крупных сетей аля Магнит/X5… etc. Которые сжирают всех мелких.
Главное загнать в свои сараи, а дальше достаточно шерсть состригать вовремя.

+1

Вас это беспокоит, вы хотите поговорить об этом?


Кому надо — строят собственные облачные решения, вот там работы достаточно и предполагается ещё больше. Кому не надо — считают деньги, реальные физические ресурсы пока ещё в разы дешевле, да и эффективнее в некоторых вопросах. В процессе подсчёта денег все понимают, что фокус давно уже ушёл в разработку от администрирования, и само владение каким-то вычислительным ресурсом должно становиться дешевле и проще. Это нормально, за создание нового всегда готовы платить больше, чем за поддержку старого (да, щас начнётся, конечно… но факт остаётся фактом).


Переписывания с нуля microservice при добавлении новой фичи, выпиливание vendor lock привязок и впиливание новых, настройка cross cloud взаимодействий, разборов какой из XXX взаимосвязанных сервисов участвующих в процессе виноват в отказе и.т.д.
Интеграция, интеграция, интеграция, ещё раз интеграция со всевозможными сервисами.

Так оно и есть, а вы разве не для этого в ИТ шли?

+1
Для каждой задачи должно быть своё разумное решение. А не городить бесконечный спор о том, что лучше (on-premise или облако). Надо разбирать конкретные кейсы. К примеру, разместить 10 Тб важных данных для нечастого доступа. Имхо, дешевле в S3 или его аналоге, чем городить свою СХД. А что касается статьи, то спасибо автору и переводчику!
0
python/Go/kotlin/php/js

Мне одному странно видеть «Cloud Lock» решениях эту группу языков?
Мне больше здесь видятся C#/Java, предложенные вами выше.
+1
всеми правдами и неправдами, будут вытесняться и взамен будут «продвигаться» Cloud Lock решения

Kubernetes как раз избавляет от lock'ов — вы можете его установить как в облако AWS/Google/OpenStack так и на свои dedicated-сервера.
Приложения внутри Kubernetes, будучи корректно написанными — не заметят разницы.

Google Kubernetes Engine/fleet/mesos/в части оркестровки, мониторинга зоопарка

Вам все равно понадобится для серьезного проекта и мониторинг и деплой и планировщики и пр. Можно написать самому или воспользоваться уже готовыми решениями, в которых уже сотни человеко-лет. Написать нечто серьезное в этой области самому — одобрит ли ваше руководство эти затраты? Напишите ли вы в разумные сроки качественное решение?
А ведь речь не только о том, что мониторинг, к примеру, уже есть в Kubernetes, а и то, что уже есть дополнительный развитый качественный софт для анализа, интегрирующийся в Kubernetes как родной.

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


Собственные велосипеды требуют того же самого.
Но, полагаясь на более-менее стандартизованные решения — можно сэкономить время себе. И не заниматься задачами общего характера. И заняться уже решением конкретных уникальных проблем бизнеса.
Или не сэкономить себе время. Зависит от конкретной задачи.
Мне кажется, что человек, способный написать близкий к Kubernetes аналог, а не наколенную поделку — понимает и сам, плюсы-минусы и своего решения и решения на базе универсальных Mesos/Kubernetes и пр. И сам правильно выберет — писать или использовать готовое.
И если не способен понять принципы Kubernetes, разжеванные в куче статей/best practics/в документации — то вряд ли способен написать свое качественное решение.
Исключение: крайне просто решение крайне простой задачи, для которой Kubernetes будет излишним.

0
Вас это беспокоит

Давно активно «кручусь» в этой сфере, в том числе подготавливаю инфраструктуры для перехода в так называемую buzzword word microservices architecture, а по факту если отбросить маркетинговый bullshit — подготовка к миграции в Cloud, причем с сохранением возможности переезда в другой (с этим всё печально, каждый провайдер активно расставляет минное поле из Cloud Vendor Lock-in).

Цель одна «перепилить» надёжные, дорогие enterprise решения(которые даже купить стала проблемой ) монолиты (мир сошел с ума назвать кластер Java EE серверов с поддержкой OSGi — монолитом, но почему то платформу Google/Amazon Cloud Platform никто монолитом не называет) с классических «нормальных» сервисов на всякое непотребство от Cloud провайдеров, часто в виде спонсируемых ими OpaenSource проектов.
Уже несколько лет наблюдаю за инициативами Cloud провайдеров, вылавливая перспективные для решения задач в моей сфере.
Как свое личное развитие мне интересен соответствующий technology stack — знать который(в реале, а не по bullshit) мои прямые обязанности.


0
причем с сохранением возможности переезда в другой (с этим всё печально, каждый провайдер активно расставляет минное поле из Cloud Vendor Lock-in).

Вот конкретно Kubernetes и решает эту проблему. Разумеется, решение останется завязанным на Kubernetes.
Но при этом сам Kubernetes может жить как на своем железе так и в облаках различных вендоров.
При грамотном подходе приложение внутри не заметит разницу — значит, vendor lock не произойдет.
Only logged in users are able to leave comments. , please.