Comments 9
Общий смысл сводится к фразе «Нормально делай — нормально будет».
UFO just landed and posted this here
Вас это беспокоит, вы хотите поговорить об этом?
Кому надо — строят собственные облачные решения, вот там работы достаточно и предполагается ещё больше. Кому не надо — считают деньги, реальные физические ресурсы пока ещё в разы дешевле, да и эффективнее в некоторых вопросах. В процессе подсчёта денег все понимают, что фокус давно уже ушёл в разработку от администрирования, и само владение каким-то вычислительным ресурсом должно становиться дешевле и проще. Это нормально, за создание нового всегда готовы платить больше, чем за поддержку старого (да, щас начнётся, конечно… но факт остаётся фактом).
Переписывания с нуля microservice при добавлении новой фичи, выпиливание vendor lock привязок и впиливание новых, настройка cross cloud взаимодействий, разборов какой из XXX взаимосвязанных сервисов участвующих в процессе виноват в отказе и.т.д.
Интеграция, интеграция, интеграция, ещё раз интеграция со всевозможными сервисами.
Так оно и есть, а вы разве не для этого в ИТ шли?
Для каждой задачи должно быть своё разумное решение. А не городить бесконечный спор о том, что лучше (on-premise или облако). Надо разбирать конкретные кейсы. К примеру, разместить 10 Тб важных данных для нечастого доступа. Имхо, дешевле в S3 или его аналоге, чем городить свою СХД. А что касается статьи, то спасибо автору и переводчику!
UFO just landed and posted this here
всеми правдами и неправдами, будут вытесняться и взамен будут «продвигаться» Cloud Lock решения
Kubernetes как раз избавляет от lock'ов — вы можете его установить как в облако AWS/Google/OpenStack так и на свои dedicated-сервера.
Приложения внутри Kubernetes, будучи корректно написанными — не заметят разницы.
Google Kubernetes Engine/fleet/mesos/в части оркестровки, мониторинга зоопарка
Вам все равно понадобится для серьезного проекта и мониторинг и деплой и планировщики и пр. Можно написать самому или воспользоваться уже готовыми решениями, в которых уже сотни человеко-лет. Написать нечто серьезное в этой области самому — одобрит ли ваше руководство эти затраты? Напишите ли вы в разумные сроки качественное решение?
А ведь речь не только о том, что мониторинг, к примеру, уже есть в Kubernetes, а и то, что уже есть дополнительный развитый качественный софт для анализа, интегрирующийся в Kubernetes как родной.
Хорошая новость — весь этот Opaensource требует жутких костылей в работе, знаний магии, умения программировать и постоянно подпирать чтобы не развалилось.
Собственные велосипеды требуют того же самого.
Но, полагаясь на более-менее стандартизованные решения — можно сэкономить время себе. И не заниматься задачами общего характера. И заняться уже решением конкретных уникальных проблем бизнеса.
Или не сэкономить себе время. Зависит от конкретной задачи.
Мне кажется, что человек, способный написать близкий к Kubernetes аналог, а не наколенную поделку — понимает и сам, плюсы-минусы и своего решения и решения на базе универсальных Mesos/Kubernetes и пр. И сам правильно выберет — писать или использовать готовое.
И если не способен понять принципы Kubernetes, разжеванные в куче статей/best practics/в документации — то вряд ли способен написать свое качественное решение.
Исключение: крайне просто решение крайне простой задачи, для которой Kubernetes будет излишним.
UFO just landed and posted this here
причем с сохранением возможности переезда в другой (с этим всё печально, каждый провайдер активно расставляет минное поле из Cloud Vendor Lock-in).
Вот конкретно Kubernetes и решает эту проблему. Разумеется, решение останется завязанным на Kubernetes.
Но при этом сам Kubernetes может жить как на своем железе так и в облаках различных вендоров.
При грамотном подходе приложение внутри не заметит разницу — значит, vendor lock не произойдет.
Sign up to leave a comment.
7 лучших практик по эксплуатации контейнеров по версии Google