Микросервисы *

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

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

Опытные программисты обычно имеют свои правила, соблюдая которые, понимают, следует ли выделять код в повторно используемый. Например, если такой(или сильно похожий) код используется в трех местах или более. Тем не менее, все, с кем мне довелось говорить на этот счет, соглашаются с тем, что такой повторно используемый код должен существовать, его создание является благом, и на это стоит тратить свое время.

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

Всем привет. В этой статье я расскажу, почему мы в Авито девять месяцев назад выбрали Kafka, и что она из себя представляет. Поделюсь одним из кейсов использования — брокер сообщений. И напоследок поговорим о том, какие плюсы мы получили от применения подхода Kafka as a Service.

Сравниение различных инструментов (RabbitMQ, Crossbar.io, Nats.io, Nginx и др.) для организации RPC между микросервисами.

Тема монорепозитория обсуждалась уже не раз и, как правило, вызывает весьма активные споры. Создавая werf как Open Source-инструмент, призванный улучшить процессы сборки кода приложений из Git в Docker-образы (и их последующей доставки в Kubernetes), мы мало размышляем на тему того, какой выбор лучше. Для нас первично обеспечить всё необходимое для сторонников разных мнений (если это не противоречит здравому смыслу, конечно).

Появившаяся недавно поддержка mono-repo в werf — хороший тому пример. Но для начала давайте разберёмся, как эта поддержка вообще связана с использованием werf и при чём здесь Docker Registry…

Привет, Хабр!

Выступление Себастьяна Дашнера на java meetup в московском офисе IBM (нашел запись похожего выступления) подтолкнуло меня начать свое знакомство с легковесными серверами приложений, в частности, с OpenLiberty. И тогда я задумался:

1. Какие преимущества дают легковесные сервера приложений?
2. Как меняется специфика работы при их использовании?
3. Зачем упаковывать сервер приложений в контейнер?

Отвечая на эти вопросы, я заметил, что информации по этой теме в открытом доступе мало, потому решил собрать и систематизировать её здесь.

Результаты выкладываю под катом.

Это история в двух частях — о новом витке развития automotive. Эта «серия» посвящена собственной разработке EPAM – Aos Connected Vehicle Platform. Алекс Агизим, CTO, Automotive & Embedded Systems, объясняет, чем она отличается от традиционного облачного решения и как дает software-разработчикам доступ в автомобиль. Ознакомиться с первой частью можно здесь.



В первой части я рассказывал, как наши разработки XEN Hypervisor позволяют изолировать сервисную часть автомобильного ПО от safety required software. Это один из барьеров перед широким применением в индустрии. Впервые опенсорсный гипервизор станет полноценным конкурентом закрытым коммерческим решениям.

Но это только первая ступенька. Чтобы вывести автомобильные сервисы на новый уровень, нужно «пустить» в него сервис-компании и разработчиков, далеких от embedded и automotive. Для этого требуется следующий уровень абстракции. Чтобы разработчик пользующийся современными фреймворками в разработке программного обеспечения мог, не переучиваясь, дизайнить свои сервисы для автомобилей.

Возможно, после прочтения вы захотите сказать: «Зачем такие сложности? Я, к примеру, купил Android-планшет для автомобиля, настроил нужные сервисы и вполне счастлив». Это классический инженерный подход, очень поддерживаю. Но давайте посмотрим шире. Автомобильная индустрия с точки зрения software как раз таки давно застряла в классических подходах. Я расскажу, каким ее будущее видим мы и что для этого делаем. А в конце пройдемся по основным сложностям.

Итак.

Современный подход к эксплуатации решает множество насущных проблем бизнеса. Контейнеры и оркестраторы позволяют легко масштабировать проекты любой сложности, упрощают релизы новых версий, делают их более надежными, но вместе с тем создают и дополнительные проблемы для разработчиков. Программиста, в первую очередь, заботит его код: архитектура, качество, производительность, элегантность, — а не то, как он поедет в Kubernetes и как его тестировать и отлаживать после внесения даже минимальных правок. Посему весьма закономерно и то, что активно развиваются инструменты для Kubernetes, помогающие решать проблемы даже самых «архаичных» разработчиков и позволяя им сосредоточиться на главном.

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

Gonkey тестирует наши микросервисы в Lamoda, и мы подумали, что он может протестировать и ваши, поэтому выложили его в open source. Если функциональность ваших сервисов реализована преимущественно через API, и используется JSON для обмена данными, то почти наверняка Gonkey подойдет и вам.

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

Прим. перев.: Автор этого материала — Cindy Sridharan, инженер из компании imgix, занимающаяся вопросами разработки API и, в частности, тестирования микросервисов. В этом материале она делится своим развёрнутым видением актуальных проблем в области распределённой трассировки, где, по её мнению, наблюдается недостаток по-настоящему эффективных инструментов для решения насущных задач.


[Иллюстрация заимствована из другого материала про распределенную трассировку.]

Считается, что распределенную трассировку сложно внедрять, да и отдача от нее в лучшем случае сомнительная. «Проблемность» трассировки объясняют множеством причин, при этом часто ссылаются на трудоемкость настройки каждого компонента системы для передачи соответствующих заголовков вместе с каждым запросом. Хотя эта проблема действительно имеет место, ее вовсе нельзя назвать непреодолимой. Она, кстати, не объясняет, почему разработчики не очень любят трассировку (даже уже функционирующую).

Прим. перев.: Тот восторг, что испытали наши тимлиды, увидев в блоге IBM Cloud этот материал — своеобразное «расширение» легендарного Twelve-Factor App, — говорит сам за себя. Поднятые автором вопросы не просто на слуху, а по-настоящему жизненны, т.е. актуальны в повседневной жизни. Их понимание полезно не только для DevOps-инженеров, но и разработчиков, создающих современные приложения, запускаемые в Kubernetes.

Известная методология «12 factor application» представляет собой свод четко определенных правил для разработки микросервисов. Они широко используются для запуска, масштабирования и деплоя приложений. В облачной платформе IBM Cloud Private мы следуем тем же 12 принципам при разработке контейнеризированных приложений. В статье «Kubernetes & 12-factor apps» обсуждается специфика применения этих 12 факторов (они поддерживаются моделью оркестровки контейнеров Kubernetes).

Размышляя о принципах разработки контейнеризированных микросервисов, работающих под контролем Kubernetes, мы пришли к следующему выводу: вышеуказанные 12 факторов совершенно справедливы, однако для организации production-среды крайне важны и другие, а в частности:

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

Наш клиент — это федеральная компания-производитель. Её мерчендайзеры отвечают за наличие товаров в магазинах, представленность на полках, POSM материалы (реклама), знания продавца о продукции и др. Супервайзеры занимаются обучением, оценкой и контролем полевых сотрудников. Для этого есть корпоративные стандарты и четко регламентированный процесс.

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



Мы в True Engineering создали технологичный инструмент, который помогает супервайзерам спланировать развитие своей команды, зафиксировать результат и подвести итоги. В этой статье расскажем подробности.

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

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

Предлагаем ознакомиться с отрывком «Управление транзакциями в микросервисной архитектуре»

Вступление

Сегодня геолокация и геопозиционирование превратились в государство, о котором мы не мечтали около 60 лет назад, в период первых мыслей о создании Интернет-сети.

Исследуйте геолокацию и API бесплатно вместе с сервисом геолокации IPGeolocation.io

Картография превратилась в чудо — из безумно больших листов бумаги в то, что умещается на ладони.

На сегодня, карты используются не только для поиска культурного центра в Париже, но чтобы иметь возможность найти все:

• ближайший отель
• аптеку или больницу
• продуктовый магазин
• университет или школу
• место проведения концерта Pink в Сан-Франциско

Трансформация технологии на этом не остановится. Это станет лучше и точнее, как никогда.

Эволюция во времени

Давайте посмотрим, как началась эволюция геолокации. Путешествие этого явления начинается с давнейших времен.

Экскурс в прошлое

Привет, Хабр! представляю вашему вниманию перевод статьи «Go, gRPC and Docker» автора Mat Evans.

Существует множество статей о совместном использовании Go и Docker. Создавать контейнеры, способные взаимодействовать с клиентами и между собой, очень легко. Далее следует небольшой пример того, как это делается на базовом уровне.

Сегодня, команда Micronaut в Object Computing Inc (OCI) представила Predator, новый проект с открытым исходным кодом, цель которого — значительно улучшить время выполнения и производительность (по памяти) доступа к данным для микросервисов и serverless-приложений, при этом не потеряв в продуктивности по сравнению с такими инструментами, как GORM и Spring Data.

Все эти годы вы, frontend-разработчик, писали монолиты, хотя и понимали, что это дурная привычка. Вы делили свой код на компоненты, использовали require или import и определяли npm-пакеты в package.json или плодили гит-репозитории в вашем проекте, но все равно писали монолит.
Пришло время изменить положение.

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

В этой статье я расскажу о том, как проект, в котором я работаю, превращался из большого монолита в набор микросервисов.

Проект начал свою историю довольно давно, в начале 2000. Первые версии были написаны на Visual Basic 6. С течением времени стало понятно, что разработку на этом языке в будущем будет сложно поддерживать, так как IDE и сам язык развиваются слабо. В конце 2000-х было решено переходить на более перспективный C#. Новая версия писалась параллельно с доработкой старой, постепенно все больше кода было на .NET. Backend на C# изначально ориентировался на сервисную архитектуру, однако при разработке использовались общие библиотеки с логикой, да и запускались сервисы в едином процессе. Получилось приложение, которое мы называли «сервисный монолит».

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

Свою работу по декомпозиции мы начали примерно в 2015 году. Пока еще мы не достигли идеального состояния — остались части большого проекта, которые уже трудно назвать монолитами, но и на микросервисы они не похожи. Тем не менее, прогресс существенный.
О нем я и расскажу в статье.

Привет, Хаброжители! Мы недавно сдали в типографию книгу Криса Ричардсона, цель которой — научить успешно разрабатывать приложения с использованием микросервисной архитектуры. В книге обсуждаются не только преимущества, но и недостатки микросервисов. Вы узнаете, в каких ситуациях имеет смысл применять их, а когда лучше подумать о монолитном подходе.

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

Ниже представлен отрывок из книги «Использование асинхронного обмена сообщениями»