Вот, например, Kubernetes, который вы свободно скачиваете и устанавливаете — это проект. Вы никому ничего не должны. Вам, впрочем, тоже никто ничего не должен и не несет никаких обязательств перед вами.
Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.
Это больше похоже на «хотелось вот такое написать, но не знал, к чему бы…».
Да вы не стесняйтесь, переходите сразу к оскорблениям, чего уж там.
«Продукты» бывают только для «enterprise» (и что конкретно вы называете этим термином, он довольно расплывчат)?
Эмм, да. Продукт — это только для энтерпраза. В этом смысл слова «продукт». Вендор предлагает заплатить ему деньги за экспертизу, от пресейла и проектирования архитектуры до проактивного сопровождения решения на всем жизненном цикле. Ваши истории успеха очень успешны, но заказчики настолько большие, богатые и компетентные, что это скорее аргумент использовать вендорские решения, т.к. далеко не каждый ООО «Вектор» может себе позволить тратить существенные деньги и время на внутреннюю экспертизу, ведь сделать Kubernetes правильно — это непросто, кому как не вам это знать. Однако, каждый сможет получить преимущества использование Kubernetes в бизнесе. https://en.wikipedia.org/wiki/Product_(business)
Перед вами живой пример — компания «Флант», которая обслуживает upstream-дистрибутив Kubernetes для production у многих компаний. Что не так?
Я озвучил один простой тезис — upstream это не продукт, это проект. Я не знаю, что с этим утверждением не так. И почему это так вас задевает. У меня встречный вопрос, почему истории успеха сферические в вакууме, а не ваши?
в новой версии этого замечательного Open Source-продукта.
Это замечательный Open Source-проект, а не продукт. Продуктом он становится когда появляется саппорт, road map, product life cycle и SLA. L3 саппорт возможен только, если ты контрибьютишь в проект или если ты предлагаешь свой форк проекта, что как бы тупик. Нет L3 — нет возможности предоставить пользователю патчи, значит ты сам просто продвинутый пользователь, но никак не вендор с продуктом. Про остальное и говорить не имеет смысла. Есть over 9000 дистрибутивов кубера, есть огромное количество людей, которые утверждают, что могут саппортить кубер, но это неправда. Они не могут. Они могут установить, настроить, может быть даже придумать костыль. Это не энтерпрайз. Такие дела. Не вводите людей в заблуждение, пожалуйста.
Еще можно вынести критические сервисы в виртуалки, тем самым решить вопрос ограничения ресурсов и попутно хоть как-то попробовать закрыть тему HA и DR.
Еще можно вынести критические сервисы в виртуалки, тем самым решить вопрос ограничения ресурсов и попутно хоть как-то попробовать закрыть тему HA и DR.
Если я вас правильно понял, то мы же сейчас теплое с мягким сравниваем. В статье речь идет исключительно про ограничения потребления памяти процессом, а не ограничения по shared memory. Алсо, контейнеры могут в shared memory, но должна быть веская причина и производственная необходимость это делать, по крайней мере с позиции обеспечения безопасности. С другой стороны, делить память между контейнерами всяко безопасней, чем делить память на хосте.
В OpenShfit маршрут во внешний мир представлен сервисом с именем узла. Например, myapp.example.com. «Внутри» платформы у каждого пода свое уникальное имя и свой ip. Таким образом, DNS resolution для имени хоста происходит независимо от роутинга. Хотя, вам никто не запрещает штатными средствами сплитить трафик на два пода (A/B testing), которые имеют одно имя хоста на двоих. Порты тут особого значения уже не имеют.
А это не моя терминология, это как раз первоисточники. Прошу ознакомиться.
https://opensource.com/resources/what-open-source
Есть опенсорс проекты, продукты и инициативы.
Вот, например, Kubernetes, который вы свободно скачиваете и устанавливаете — это проект. Вы никому ничего не должны. Вам, впрочем, тоже никто ничего не должен и не несет никаких обязательств перед вами.
kubernetes.io/docs/concepts/overview/what-is-kubernetes
Но есть коммерческие предложения, например от того же Google — Kubernetes Engine. Это продукт.
Есть цена, есть понимание что покупатель получит за эту цену, есть права и обязанности сторон.
cloud.google.com/kubernetes-engine
cloud.google.com/kubernetes-engine/pricing
И есть инициативы. Например.
en.wikipedia.org/wiki/Open_Source_Initiative
Да вы не стесняйтесь, переходите сразу к оскорблениям, чего уж там.
Эмм, да. Продукт — это только для энтерпраза. В этом смысл слова «продукт». Вендор предлагает заплатить ему деньги за экспертизу, от пресейла и проектирования архитектуры до проактивного сопровождения решения на всем жизненном цикле. Ваши истории успеха очень успешны, но заказчики настолько большие, богатые и компетентные, что это скорее аргумент использовать вендорские решения, т.к. далеко не каждый ООО «Вектор» может себе позволить тратить существенные деньги и время на внутреннюю экспертизу, ведь сделать Kubernetes правильно — это непросто, кому как не вам это знать. Однако, каждый сможет получить преимущества использование Kubernetes в бизнесе.
https://en.wikipedia.org/wiki/Product_(business)
Я озвучил один простой тезис — upstream это не продукт, это проект. Я не знаю, что с этим утверждением не так. И почему это так вас задевает. У меня встречный вопрос, почему истории успеха сферические в вакууме, а не ваши?
Это замечательный Open Source-проект, а не продукт. Продуктом он становится когда появляется саппорт, road map, product life cycle и SLA. L3 саппорт возможен только, если ты контрибьютишь в проект или если ты предлагаешь свой форк проекта, что как бы тупик. Нет L3 — нет возможности предоставить пользователю патчи, значит ты сам просто продвинутый пользователь, но никак не вендор с продуктом. Про остальное и говорить не имеет смысла. Есть over 9000 дистрибутивов кубера, есть огромное количество людей, которые утверждают, что могут саппортить кубер, но это неправда. Они не могут. Они могут установить, настроить, может быть даже придумать костыль. Это не энтерпрайз. Такие дела. Не вводите людей в заблуждение, пожалуйста.
Если я правильно вас понял, логика победы в вашем сценариибудет абсолютно такая же как и в статье. Например…
Еще можно вынести критические сервисы в виртуалки, тем самым решить вопрос ограничения ресурсов и попутно хоть как-то попробовать закрыть тему HA и DR.
Еще можно вынести критические сервисы в виртуалки, тем самым решить вопрос ограничения ресурсов и попутно хоть как-то попробовать закрыть тему HA и DR.