какая разница ?

выбери любые 10

Мне кажется, что я себе нашёл жену.

выбери любые 10

тогда я не понимаю, почему используя докер/ovz и монолитное приложение, я не могу просто поставить тридцать инстансов своего монолита

Мне кажется, что я себе нашёл жену.

мы за вас рады, но если Вы имеете ввиду меня, сорри, я уже замужем, и вообще эмигрировала из РФ

погоди. Это к тебе вопрос, ты сказала нахер докер, agile это решает

я и говорю, расскажи как.

я и говорю, расскажи как.

а я всё ещё не понимаю задачу

мы за вас рады, но если Вы имеете ввиду меня, сорри, я уже замужем, и вообще эмигрировала из РФ

Ну второе не проблема, вывезем )) А первое - очевидность.

как agile решает задачу запуска 30 сервисов на одном хосте и каждый в 4х разных версиях ?

вот это

чем тебя не устраивают 30/90 контейнеров (ovz или докер не важно)?

версию кода определяем по гит тагу

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

Раз началось обсуждения контейнеров, то не могли бы Вы кратко разъяснить суть "хайпа" вокруг докера и ovz?

ну вот саппортишь 4 ветки по AGILE приложения

Раз началось обсуждения контейнеров, то не могли бы Вы кратко разъяснить суть "хайпа" вокруг докера и ovz?

погоди.

Раз началось обсуждения контейнеров, то не могли бы Вы кратко разъяснить суть "хайпа" вокруг докера и ovz?

нет никакого хайпа вокруг ovz

ну вот саппортишь 4 ветки по AGILE приложения

мы говорим про размещение на хосте, а не про то как это вести

ну вот у меня есть запускалка контенеров и деплоилка. Она так же лежит в гите. Она их и запустит. В качестве аргумента (одного из) она принимает версию приложения

я её запущу 30/90 раз

нет никакого хайпа вокруг ovz

Хорошо, тогда вокруг докера. Я не могу понять разницу между LXC и докером. На мой взгляд LXC умеет достаточно, чтобы конкрурировать с докером. А всё, что умеет докер "из коробки" - можно сделать вручную.

ещё и обновит приложение, если паппет или ансибл-пулл

в пределах ветки

если будет найден баг, и команда это поправит

Хорошо, тогда вокруг докера. Я не могу понять разницу между LXC и докером. На мой взгляд LXC умеет достаточно, чтобы конкрурировать с докером. А всё, что умеет докер "из коробки" - можно сделать вручную.

хайп вокруг докера связан с хайпом микросервисности

ну вот у меня есть запускалка контенеров и деплоилка. Она так же лежит в гите. Она их и запустит. В качестве аргумента (одного из) она принимает версию приложения

погоди, это какие то скрипты решают а не agile расскажи как agile

погоди, это какие то скрипты решают а не agile расскажи как agile

AGILE он и про скрипты. Они тоже разрабатываются по AGILE, а микросервисы нет. Они вообще часто оказываются несопровождаемыми блек боксами

Хорошо, тогда вокруг докера. Я не могу понять разницу между LXC и докером. На мой взгляд LXC умеет достаточно, чтобы конкрурировать с докером. А всё, что умеет докер "из коробки" - можно сделать вручную.

а ты знаешь как работает lxc ?

я не слышала о том, что бы два человека делали микросервис

это всегда тайное знание, которое само по себе разделение приложения на микросервисы не гарантирует, что внутри не окажется магии

т.е. мы тут верим разработчику микросервиса, что у него есть совесть

AGILE он и про скрипты. Они тоже разрабатываются по AGILE, а микросервисы нет. Они вообще часто оказываются несопровождаемыми блек боксами

мы не про разработку. ты сказала что методология разработки каким то образом решает вопросы дистрибуции и менеджмента сервиса. Расскажи как.

но проконтролировать это никак не можем

а в AGILE/монолите всё контролируется, и ревьювится

всей командой

а в AGILE/монолите всё контролируется, и ревьювится

дичь. если у тебя 20 человек девелопят монолит всё равно всех отвечают за свой кусок. conways law никто не отменял

мы не про разработку. ты сказала что методология разработки каким то образом решает вопросы дистрибуции и менеджмента сервиса. Расскажи как.

конечно решает. Релизы каждые две недели, и быстрое попадание фич в продакшен, а так же то, что нет блекбоксов в коде нравятся менеджменту. Всегда команда компетентна в своём приложении и быстро вставляет новые фичи в прод

дичь. если у тебя 20 человек девелопят монолит всё равно всех отвечают за свой кусок. conways law никто не отменял

не-не, всегда код ревью

а ты знаешь как работает lxc ?

Сложно ответить на данный вопрос. Но пусть ответом будет - да.

ещё и голосования за то, сколько очков дать фиче

ты не можешь голосовать,

если ты не смотрел исходники

конечно решает. Релизы каждые две недели, и быстрое попадание фич в продакшен, а так же то, что нет блекбоксов в коде нравятся менеджменту. Всегда команда компетентна в своём приложении и быстро вставляет новые фичи в прод

ты опять не отвечаешь как решает agile вопрос того, как версионировать конфиги и библиотеки 30 приложенек.

и не компетентен в том, что делает сосед

Сложно ответить на данный вопрос. Но пусть ответом будет - да.

ну расскажи тогда в 2х словах, чо ты.

ты опять не отвечаешь как решает agile вопрос того, как версионировать конфиги и библиотеки 30 приложенек.

зачем вообще нужно 30 приложений?

я не видела ни одного стартапа, в котором было бы столько

обычно одна команда = ну, максимум 10 проектов

а вообще 2-4

собственно, если у тебя большая контора, то там просто много команд\

и они на одном аккаунте AWS или в корпоративном опенстеке и запускают, каждая команда, свои жалкие несколько приложений

зачем вообще нужно 30 приложений?

погоди. есть задача, её нужно решить, ты сказала что она решается agile'ом. Рассказывай. я уже замучался.

часть приложений для других команд

Или скажи уже "я тут дичь всякую несу, и иногда не читаю что вы пишите, а просто пишу что думаю" ))

погоди. есть задача, её нужно решить, ты сказала что она решается agile'ом. Рассказывай. я уже замучался.

да, она позволяет уменьшить количество приложений, и не плодить сущности. Вот конкретно, выкинуть микросервисы из приложения, и свести 30 микросервисов к 2-3 монолитам. И саппортить той же командой без увеличения числа факапов

ну расскажи тогда в 2х словах, чо ты.

Виртуализация на уровне оси, служит для запуска изолированных экземпляров linux. LXC и виртуальная машина разные вещи. LXC использует один экземпляр ядра операционной системы. На мой взгляд докер и есть "тот же LXC", но уже с сервисами "из коробки".

Виртуализация на уровне оси, служит для запуска изолированных экземпляров linux. LXC и виртуальная машина разные вещи. LXC использует один экземпляр ядра операционной системы. На мой взгляд докер и есть "тот же LXC", но уже с сервисами "из коробки".

докер раньше юзал LXC, сейчас использует свои утилиты

да, она позволяет уменьшить количество приложений, и не плодить сущности. Вот конкретно, выкинуть микросервисы из приложения, и свести 30 микросервисов к 2-3 монолитам. И саппортить той же командой без увеличения числа факапов

как она решает задачу деплоя и управления этими сущностями когда они уже есть

как она решает задачу деплоя и управления этими сущностями когда они уже есть

опять сферические сущности в вакууме. Я помогу тебе, давай из тридцати сферических микросервисов сделаем 10?

перечисли

Виртуализация на уровне оси, служит для запуска изолированных экземпляров linux. LXC и виртуальная машина разные вещи. LXC использует один экземпляр ядра операционной системы. На мой взгляд докер и есть "тот же LXC", но уже с сервисами "из коробки".

расскажи, зачем cgroups namespace придумали ?

вот конкретно библиотеки и что они делают

опять сферические сущности в вакууме. Я помогу тебе, давай из тридцати сферических микросервисов сделаем 10?

у нас нет задачи переделывать код, у нас есть задача деплоить его и управлять им.

у нас нет задачи переделывать код, у нас есть задача деплоить его и управлять им.

почему нет такой задачи?

и не компетентен в том, что делает сосед

Мне кажется, что вы фантазируете, уж простите. 1. Не надо нанимать людей по объявлениям в газете, если не хотите, чтобы они выдавали говнокод. Если выдают — надо объяснять/увольнять. 2. Код ревью никто не отменяет. Не понимаю, почему та же команда не может быть в курсе того, кто что внутри неё делает. Вне зависимости от архитектуры. 3. Выбор архитектуры — это сознательный шаг. Это не жалание левой пятки разработчика Василия. Ну, по-хорошему :) Микросервисы дают одно главное преимущество, вытекающее из определения: слабую связанность компонентов. Легче модифицировать, легче хранить, легче мыть. Бизнесу это нравится.

не нужно подгонять задачи под удобные себе подходы.

Мне кажется, что вы фантазируете, уж простите. 1. Не надо нанимать людей по объявлениям в газете, если не хотите, чтобы они выдавали говнокод. Если выдают — надо объяснять/увольнять. 2. Код ревью никто не отменяет. Не понимаю, почему та же команда не может быть в курсе того, кто что внутри неё делает. Вне зависимости от архитектуры. 3. Выбор архитектуры — это сознательный шаг. Это не жалание левой пятки разработчика Василия. Ну, по-хорошему :) Микросервисы дают одно главное преимущество, вытекающее из определения: слабую связанность компонентов. Легче модифицировать, легче хранить, легче мыть. Бизнесу это нравится.

никто не помнит, что внутри микросервиса уже через полгода. Ну правда. Иногда сам разработчик

а текучку никто не отменял

она всегда большая в ит компаниях, если вы не гугл, увы

Ну разобраться в одном сервисе, который говорит по стандартизированному протоколу, который написан на 500 строчках всё же проще, чем в монстре, в котором всё может быть перепутанно и завалено лесами костылей.

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

монолитный код может занимать в десятки и сотни раз меньше

это ещё и технический долг

расскажи, зачем cgroups namespace придумали ?

Неймспейс - изолированные процессы. А вот cgroups ещё "не тыкал" и даже не читал толком.

никто не помнит, что внутри микросервиса уже через полгода. Ну правда. Иногда сам разработчик

основная проблема монолита в том, что он идеологически несет внутри себя доменную модель. всего его библиотеки и компоненты, в 99% случаев "реализуют" конкретный кусочек её. По этой причине чтобы понять почему здесь так и вот так вам нужно понимать доменную область. Микросервисы идеолгически, реализуя лабую связность, "выпиливают" из себя все занания о домене, таким образом чтобы понять как работает сервис нам не нужно ничего знать о предметной области. Исключением являются glue-services которые как раз реализуют бизнеслогику и "склеивают" разные сервисы. Однако, очень часто доменная область вымывается в "связи" между сервисами и их api.

основная проблема монолита в том, что он идеологически несет внутри себя доменную модель. всего его библиотеки и компоненты, в 99% случаев "реализуют" конкретный кусочек её. По этой причине чтобы понять почему здесь так и вот так вам нужно понимать доменную область. Микросервисы идеолгически, реализуя лабую связность, "выпиливают" из себя все занания о домене, таким образом чтобы понять как работает сервис нам не нужно ничего знать о предметной области. Исключением являются glue-services которые как раз реализуют бизнеслогику и "склеивают" разные сервисы. Однако, очень часто доменная область вымывается в "связи" между сервисами и их api.

а AGILE помогает понимать

это очень важно сохранять компетенции

Неймспейс - изолированные процессы. А вот cgroups ещё "не тыкал" и даже не читал толком.

а говорите понимаете. разберитесь что такое lxc чуть глубже и поймёте что такое docker и что за задачу он решает.

хотя бы с точки зрения секьюрити проблем

это очень важно сохранять компетенции

наоборот.

вот необновляемый, в принципе, микросервис, как и сам дырявый докер (ну все же знают, что он дырявый тут, правда? Сами разработчики не рекомендуют пускать демоны внутри под рутом),

никто не знает, как он сделан

чувак, который его пилил, давно уволился

а говорите понимаете. разберитесь что такое lxc чуть глубже и поймёте что такое docker и что за задачу он решает.

Хорошо. Спасибо за желание помогать. Обязательно разберусь с namespace и cgroups

"сохранение" это снижение bus factor. "упрощение" это увеличение его.

никто не знает в конторе, нужно ли обновлять микросервис

по тому, что нет документации

нет компетенции всей команды

которую даёт AGILE для монолита

Хорошо. Спасибо за желание помогать. Обязательно разберусь с namespace и cgroups

найдите в компании человека котоырй потратит час времени и расскажет вам всё. Я сам внутри компании делал доклад пару недель назад. За час уложился и с namespace/cgroup/capabilities/плюсы/минусы/причины успеха/мифы

вот необновляемый, в принципе, микросервис, как и сам дырявый докер (ну все же знают, что он дырявый тут, правда? Сами разработчики не рекомендуют пускать демоны внутри под рутом),

ты реально такое в слух говоришь ?

есть суммарно куча говнокода, который при микросервисной архитектуре, будем откровенны, так и подбивает не ревьювить (можно ревьювить, но ведь один разработчик, а не два делают микросервис!)

человек несовершенен

зато группа людей совершенна

я не говорю, что микросервисы неприминимы всегда

я говорю, что попытки их навязать всем зло

как и попытки похоронить монолиты

да дичь это всё

группа людей ещё более несовершенна