В отделах разработки только и разговоров, что о микросервисах, но на деле технология нужна не всем. В карточках кратко рассказываем, на какие критерии стоит ориентироваться, принимая решение о переходе на микросервисы, почитать подробнее можно по ссылке.
В Mail.ru Cloud Solutions помогли «Тендертех» сократить расходы на администрирование инфраструктуры
«Тендертех» — площадка, которая помогает компаниям получать банковские гарантии для участия в тендерах. Чтобы повысить управляемость и надежность инфраструктуры и подключить автомасштабирование, в компании перешли на Kubernetes как сервис от MCS. В кейсе — что из этого получилось.
«Тендертех» — площадка, которая помогает компаниям получать банковские гарантии для участия в тендерах. Чтобы повысить управляемость и надежность инфраструктуры и подключить автомасштабирование, в компании перешли на Kubernetes как сервис от MCS. В кейсе — что из этого получилось.
mcs.mail.ru
Тендертех: как Kubernetes в облаке помог вырасти финтех-проекту
Как построить надежную инфраструктуру и сократить расходы на ее обслуживание с помощью Kubernetes aaS.
Чек-лист: как начать работу с микросервисами
✅ Определите бизнес-потребности или функции, которым будут соответствовать будущие сервисы. На одну задачу — один микросервис.
✅ Назначьте ответственную команду для каждой бизнес-функции. Каждая команда станет экспертом в конкретной области.
✅ Подберите технологический стек. Набор технологий может отличаться у разных микросервисов, но лучше не использовать в одном приложении более 2-3 языков программирования без серьезных причин.
✅ Проработайте связи между микросервисами. Это важно, поскольку в дальнейшем изменить взаимодействие сервисов будет очень сложно.
✅ Настройте автоматическую сборку и развертывание микросервисов. Используйте конвейеры CI/CD на базе любой доступной системы: Jenkins, TeamCity, Go и так далее.
✅ Предусмотрите обработку сбоев. Существуют различные способы изоляции от сбоев, например, переборка (Bulkhead) и предохранитель (Circuits Breaker).
✅ Используйте мониторинг. Отслеживайте не только технические параметры хостов и время отклика сервисов, но и бизнес-показатели, изменение которых может указывать на сбои.
✅ Придерживайтесь принципа открытого исходного кода, используя системы контроля версий. Подход позволит вносить своевременные изменения в код даже без его автора.
✅ Утвердите стандарты в отношении ведения кода, оформления API, обработки ошибок и придерживайтесь их — это повысит эффективность совместной работы разных команд.
Подробнее
✅ Определите бизнес-потребности или функции, которым будут соответствовать будущие сервисы. На одну задачу — один микросервис.
✅ Назначьте ответственную команду для каждой бизнес-функции. Каждая команда станет экспертом в конкретной области.
✅ Подберите технологический стек. Набор технологий может отличаться у разных микросервисов, но лучше не использовать в одном приложении более 2-3 языков программирования без серьезных причин.
✅ Проработайте связи между микросервисами. Это важно, поскольку в дальнейшем изменить взаимодействие сервисов будет очень сложно.
✅ Настройте автоматическую сборку и развертывание микросервисов. Используйте конвейеры CI/CD на базе любой доступной системы: Jenkins, TeamCity, Go и так далее.
✅ Предусмотрите обработку сбоев. Существуют различные способы изоляции от сбоев, например, переборка (Bulkhead) и предохранитель (Circuits Breaker).
✅ Используйте мониторинг. Отслеживайте не только технические параметры хостов и время отклика сервисов, но и бизнес-показатели, изменение которых может указывать на сбои.
✅ Придерживайтесь принципа открытого исходного кода, используя системы контроля версий. Подход позволит вносить своевременные изменения в код даже без его автора.
✅ Утвердите стандарты в отношении ведения кода, оформления API, обработки ошибок и придерживайтесь их — это повысит эффективность совместной работы разных команд.
Подробнее
Облачные итоги-2020: рост российских облаков продолжается, рынок ждет от провайдеров комплексных услуг и новых сервисов
Независимый эксперт RCCPA подвел итоги состояния облачного рынка на конец 2020 года. Мы увидели несколько интересных тенденций:
⛅️ Российские облачные провайдеры, в том числе Mail.ru Cloud Solutions, выросли за прошедший год и активно внедряют новые сервисы, спрос на которые возник еще в начале года и продолжает расти. Это в частности произошло потому, что в облака активно переносили свои цифровые продукты довольно крупные компании. Они подключали не только IaaS, но и контейнеры, и элементы PaaS.
🏭 Компании-клиенты облачных провайдеров оказались лучше подготовлены к пандемии, а некоторые даже нарастили масштабы бизнеса и соответственно — потребление облачных ресурсов. Это также положительно сказалось на рынке российских облаков.
📉 На рынке классического хостинга наблюдается упадок — спрос на домены вырос, но компании, которые не смогли пережить кризис, перестали платить даже за сайт. Отсюда плачевное состояние тех хостеров, которые специализировались на неэластичной инфраструктуре, доменах и прочих классических хостинговых услугах. Облачные провайдеры, которые гораздо лучше умеют готовить высоконагруженные сценарии и могут оказать клиентам экспертную помощь в DevOps, у них выигрывают.
🏦 Спрос на облака может вырасти в финансовом секторе. Это связано с поправками в Налоговый кодекс, отменяющими льготы по НДС на лицензии иностранного программного обеспечения. Из-за этого любое ПО от глобальных компаний для банков фактически подорожает на 20% — в том числе софт для виртуализации, который они активно используют. Это может сподвигнуть их сменить лицензионные платформы виртуализации на облачные.
☁️ Ожидается, что в 2021 году отрыв лидеров облачного рынка от остальных игроков увеличится. Это связано с тем, что у крупных российских провайдеров больше компетентных специалистов и возможностей предоставить клиентам качественный сервис и техподдержку — это становится все важнее для компаний. При этом рост спроса усилит конкуренцию между провайдерами.
Все облачные итоги ушедшего года и прогнозы на будущий
Независимый эксперт RCCPA подвел итоги состояния облачного рынка на конец 2020 года. Мы увидели несколько интересных тенденций:
⛅️ Российские облачные провайдеры, в том числе Mail.ru Cloud Solutions, выросли за прошедший год и активно внедряют новые сервисы, спрос на которые возник еще в начале года и продолжает расти. Это в частности произошло потому, что в облака активно переносили свои цифровые продукты довольно крупные компании. Они подключали не только IaaS, но и контейнеры, и элементы PaaS.
🏭 Компании-клиенты облачных провайдеров оказались лучше подготовлены к пандемии, а некоторые даже нарастили масштабы бизнеса и соответственно — потребление облачных ресурсов. Это также положительно сказалось на рынке российских облаков.
📉 На рынке классического хостинга наблюдается упадок — спрос на домены вырос, но компании, которые не смогли пережить кризис, перестали платить даже за сайт. Отсюда плачевное состояние тех хостеров, которые специализировались на неэластичной инфраструктуре, доменах и прочих классических хостинговых услугах. Облачные провайдеры, которые гораздо лучше умеют готовить высоконагруженные сценарии и могут оказать клиентам экспертную помощь в DevOps, у них выигрывают.
🏦 Спрос на облака может вырасти в финансовом секторе. Это связано с поправками в Налоговый кодекс, отменяющими льготы по НДС на лицензии иностранного программного обеспечения. Из-за этого любое ПО от глобальных компаний для банков фактически подорожает на 20% — в том числе софт для виртуализации, который они активно используют. Это может сподвигнуть их сменить лицензионные платформы виртуализации на облачные.
☁️ Ожидается, что в 2021 году отрыв лидеров облачного рынка от остальных игроков увеличится. Это связано с тем, что у крупных российских провайдеров больше компетентных специалистов и возможностей предоставить клиентам качественный сервис и техподдержку — это становится все важнее для компаний. При этом рост спроса усилит конкуренцию между провайдерами.
Все облачные итоги ушедшего года и прогнозы на будущий
5 антипаттернов деплоя в Kubernetes
Собрали пять распространенных практик развертывания Kubernetes, для которых есть другие решения.
✅ Размещение файлов конфигурации внутри или рядом с образом Docker. Лучшая практика — хранить конфигурации общего назначения в ConfigMaps, а конфиденциальную информацию (например, ключи и секреты API) — в ресурсе Secrets.
✅ Работа без Helm или других шаблонизаторов. Так вы создаете много возможностей для ошибок. Шаблоны помогают упростить установку приложений Kubernetes и управление ими. Поскольку Kubernetes не предоставляет собственный механизм шаблонов, стоит использовать сторонние шаблонизаторы типа Helm.
✅ Смешивание производственной и непроизводственной нагрузок в одном кластере. Вместо того чтобы смешивать эти нагрузки в одном кластере, используйте отдельные кластеры для разработки/тестирования/продакшен — так вы улучшите изоляцию и повысите безопасность. Вы также должны максимально автоматизировать CI/CD, чтобы снизить вероятность человеческой ошибки.
✅ Развертывание модулей без установленных ограничений на память и/или CPU. Ограничение памяти и CPU для контейнеров в кластере позволяет эффективно использовать ресурсы, доступные на узлах кластера. Это помогает планировщику Kubernetes определить, на каком узле должен располагаться под для наиболее эффективного использования оборудования.
✅ Использование тега latest в продакшене. Использование тега latest считается плохой практикой, особенно в производственной среде. Модули неожиданно аварийно завершают работу по разным причинам, поэтому они могут в любой момент удалить докер-образы.
Еще больше антипаттернов деплоя в Kubernetes — в статье.
Собрали пять распространенных практик развертывания Kubernetes, для которых есть другие решения.
✅ Размещение файлов конфигурации внутри или рядом с образом Docker. Лучшая практика — хранить конфигурации общего назначения в ConfigMaps, а конфиденциальную информацию (например, ключи и секреты API) — в ресурсе Secrets.
✅ Работа без Helm или других шаблонизаторов. Так вы создаете много возможностей для ошибок. Шаблоны помогают упростить установку приложений Kubernetes и управление ими. Поскольку Kubernetes не предоставляет собственный механизм шаблонов, стоит использовать сторонние шаблонизаторы типа Helm.
✅ Смешивание производственной и непроизводственной нагрузок в одном кластере. Вместо того чтобы смешивать эти нагрузки в одном кластере, используйте отдельные кластеры для разработки/тестирования/продакшен — так вы улучшите изоляцию и повысите безопасность. Вы также должны максимально автоматизировать CI/CD, чтобы снизить вероятность человеческой ошибки.
✅ Развертывание модулей без установленных ограничений на память и/или CPU. Ограничение памяти и CPU для контейнеров в кластере позволяет эффективно использовать ресурсы, доступные на узлах кластера. Это помогает планировщику Kubernetes определить, на каком узле должен располагаться под для наиболее эффективного использования оборудования.
✅ Использование тега latest в продакшене. Использование тега latest считается плохой практикой, особенно в производственной среде. Модули неожиданно аварийно завершают работу по разным причинам, поэтому они могут в любой момент удалить докер-образы.
Еще больше антипаттернов деплоя в Kubernetes — в статье.
SRE-инженер или системный администратор: кто нужен вашей компании?
Компании все чаще ищут SRE-инженеров, и требования к ним похожи на те, что предъявляют к системным администраторам. В статье разбираемся, действительно ли SRE-инженер — отдельная профессия или это все тот же админ, но под новым названием.
Компании все чаще ищут SRE-инженеров, и требования к ним похожи на те, что предъявляют к системным администраторам. В статье разбираемся, действительно ли SRE-инженер — отдельная профессия или это все тот же админ, но под новым названием.
mcs.mail.ru
В чем разница между SRE-инженером и системным администратором: ищем отличия | Блог Mail.Ru Cloud Solutions
Расскажем, чем занимается SRE-инженер, что он должен уметь, чем отличается от системного администратора и что меняется в компании, когда в нее приходит SRE-инженер.
В промышленности и энергетике задействовано дорогое и сложное оборудование. Чтобы избежать его поломок и простоев, применяют методы предиктивной аналитики — предсказания различных событий. Примеры использования технологии — в карточках, еще больше кейсов — по ссылке.
В 2021 году компании сосредоточатся на cloud-native-приложениях
Компания Capgemini опубликовала прогнозы развития облачных технологий на 2021 год. Судя по ним, в этом году облака ждет еще большее развитие.
🌤 Компании поймут, что без облаков не обойтись. Зависимость от старых решений тормозит развитие компаний, в долгосрочной перспективе это дорого обойдется. В 2021 году еще больше компаний будут переходить в облака, потому что хотят идти в ногу со временем.
🤝 Вендоры будут больше сотрудничать. Для компаний все важнее становится независимость от конкретного поставщика. Они стараются выбирать независимые решения, потому что хотят быть уверены, что используемые технологии можно легко заменить. Поэтому многие поставщики будут сотрудничать и интегрировать свои решения друг с другом.
📦 Компании сосредоточатся на cloud-native-приложениях. Многие компании поняли, что cloud-native-приложения раскрывают все преимущества облаков, и стараются создавать как можно больше таких приложений.
💰 Компании будут серьезнее подходить к внедрению облачных технологий. В 2020 году многие компании переходили в облака, но не всегда могли соблюсти баланс между затратами и эффективностью. Но теперь, когда все немного успокоилось, компании будут применять более взвешенный подход к внедрению облаков. Они пересмотрят свои решения о том, какие технологии использовать и в каком объеме.
Подробнее
Компания Capgemini опубликовала прогнозы развития облачных технологий на 2021 год. Судя по ним, в этом году облака ждет еще большее развитие.
🌤 Компании поймут, что без облаков не обойтись. Зависимость от старых решений тормозит развитие компаний, в долгосрочной перспективе это дорого обойдется. В 2021 году еще больше компаний будут переходить в облака, потому что хотят идти в ногу со временем.
🤝 Вендоры будут больше сотрудничать. Для компаний все важнее становится независимость от конкретного поставщика. Они стараются выбирать независимые решения, потому что хотят быть уверены, что используемые технологии можно легко заменить. Поэтому многие поставщики будут сотрудничать и интегрировать свои решения друг с другом.
📦 Компании сосредоточатся на cloud-native-приложениях. Многие компании поняли, что cloud-native-приложения раскрывают все преимущества облаков, и стараются создавать как можно больше таких приложений.
💰 Компании будут серьезнее подходить к внедрению облачных технологий. В 2020 году многие компании переходили в облака, но не всегда могли соблюсти баланс между затратами и эффективностью. Но теперь, когда все немного успокоилось, компании будут применять более взвешенный подход к внедрению облаков. Они пересмотрят свои решения о том, какие технологии использовать и в каком объеме.
Подробнее
На удаленке сотрудники часто используют личные компьютеры — это усложняет установку софта, управление настройками и обеспечение информационной безопасности, в том числе защиту корпоративных данных. В карточках выше — три способа решить эту проблему, а все подробности — здесь.
ZFS: особенности и отличия от других файловых систем
Георгий Меликов, контрибьютор проектов OpenZFS и ZFS on Linux и разработчик IaaS в команде Mail.ru Cloud Solutions рассказал об особенностях ZFS. Вот основные моменты:
📁 ZFS — симбиоз файловой системы и менеджера томов, которая предоставляет инструменты для простого управления дисковым массивом. Плюсы ZFS в том, что он знает, что и где лежит, группирует это и дает некоторые другие фишки, в частности безопасное хранение данных.
📝Это copy-on-write файловая система, которая никогда не перезаписывает данные. Система всегда оперирует новым блоком, для обеспечения консистентности данных не нужен журнал, как в большинстве других файловых систем.
🏪 ZFS — локальное хранилище с большим спектром применения. Система подходит для домашнего использования, в NFS-хранилище, а также в качестве крупного хранилища.
Подробнее об особенностях и архитектуре ZFS
Георгий Меликов, контрибьютор проектов OpenZFS и ZFS on Linux и разработчик IaaS в команде Mail.ru Cloud Solutions рассказал об особенностях ZFS. Вот основные моменты:
📁 ZFS — симбиоз файловой системы и менеджера томов, которая предоставляет инструменты для простого управления дисковым массивом. Плюсы ZFS в том, что он знает, что и где лежит, группирует это и дает некоторые другие фишки, в частности безопасное хранение данных.
📝Это copy-on-write файловая система, которая никогда не перезаписывает данные. Система всегда оперирует новым блоком, для обеспечения консистентности данных не нужен журнал, как в большинстве других файловых систем.
🏪 ZFS — локальное хранилище с большим спектром применения. Система подходит для домашнего использования, в NFS-хранилище, а также в качестве крупного хранилища.
Подробнее об особенностях и архитектуре ZFS
RabbitMQ vs Apache Kafka: что выбрать для проекта?
В системе с объемными вычислительными задачами и потоками событий необходимо наладить коммуникацию между ее компонентами. Чаще всего для этого используют одно из двух решений: RabbitMQ или Apache Kafka — почитайте, чем они отличаются.
В системе с объемными вычислительными задачами и потоками событий необходимо наладить коммуникацию между ее компонентами. Чаще всего для этого используют одно из двух решений: RabbitMQ или Apache Kafka — почитайте, чем они отличаются.
mcs.mail.ru
RabbitMQ или Apache Kafka: в чем отличие и что выбрать для проекта | Блог VK Cloud Solutions
RabbitMQ и Apache Kafka — популярные решения для организации распределенной архитектуры. Разбираемся, чем они отличаются и как выбрать подходящее решение.
Запись выступления «Базы данных в современной IIoT-платформе»
Как известно, универсальной базы данных не существует. Особенно когда нужно построить платформу интернета вещей, способную обрабатывать миллионы событий от датчиков в режиме near real-time.
На @Databases Meetup Андрей Сергеев, руководитель группы разработки IoT-решений в Mail.ru Cloud Solutions, рассказал, как выбирали СУБД для Mail.ru IoT Platform: с чего все начиналось, с какими проблемами столкнулись, как их решали и что в итоге получилось. Посмотрите запись его выступления.
Как известно, универсальной базы данных не существует. Особенно когда нужно построить платформу интернета вещей, способную обрабатывать миллионы событий от датчиков в режиме near real-time.
На @Databases Meetup Андрей Сергеев, руководитель группы разработки IoT-решений в Mail.ru Cloud Solutions, рассказал, как выбирали СУБД для Mail.ru IoT Platform: с чего все начиналось, с какими проблемами столкнулись, как их решали и что в итоге получилось. Посмотрите запись его выступления.
