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

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

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

Прим. перев.: Service mesh'и определённо стали актуальным решением в современной инфраструктуре для приложений, следующих микросервисной архитектуре. Хотя Istio может быть на слуху у многих DevOps-инженеров, это довольно новый продукт, который, будучи комплексным в смысле предоставляемых возможностей, может потребовать значительного времени для знакомства. Немецкий инженер Rinor Maloku, отвечающий за облачные вычисления для крупных клиентов в телекоммуникационной компании Orange Networks, написал замечательный цикл материалов, что позволяют достаточно быстро и глубоко погрузиться в Istio. Начинает же он свой рассказ с того, что вообще умеет Istio и как на это можно быстро посмотреть собственными глазами.

Istio — Open Source-проект, разработанный при сотрудничестве команд из Google, IBM и Lyft. Он решает сложности, возникающие в приложениях, основанных на микросервисах, например, такие как:

Привет, Хаброжители! Год от года обретая новых сторонников, облачно-ориентированные и микросервисные архитектуры стали основой современного IT. Такой переход значительно повлиял и на структуру коммуникаций. Теперь приложения часто подключаются друг к другу по сети, и это происходит с помощью технологий межпроцессной коммуникации. Одной из наиболее популярных и эффективных технологий такого рода является gRPC, но информации о ней не хватает. Так было, пока не вышла эта книга!

Наконец архитекторы и разработчики смогут подробно разобраться, как технология gRPC устроена «под капотом», и для этого не придется разгребать десятки устаревших ссылок в поисковике.

Поняв основы gRPC и изучив паттерны коммуникации, вы научитесь создавать приложения gRPC на Go и Java, запускать их в продакшене, а также разберетесь, как gRPC взаимодействует с экосистемой Kubernetes.

В последнее время такие объявления заполонили интернет. Несмотря на приятную зарплату, не может не смущать, что внутри написана дикая ересь. Вначале предполагается, что «DevOps» и «инженер» можно каким-то образом склеить вместе в одно слово, а далее идет рандомный список требований, часть которых явно скопирована из вакансии сисадмина.

В этом посте хочется немного поговорить, как мы дошли до жизни такой, что такое DevOps на самом деле и что теперь с этим делать.

Такие вакансии можно всячески порицать, но факт остается фактом: их много, и так устроен рынок на данный момент. Мы сделали девопс-конференцию и открыто заявляем: «DevOops — не для DevOps-инженеров». Тут многим покажется странным и диким: почему люди, делающие совершенно коммерческое мероприятие, идут против рынка. Сейчас всё объясним.

Ведущие инструменты для управления конфигурацией по разному подходят к автоматизации серверов

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

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

В этот момент средства управления конфигурациями и вступают в игру. Во многих случаях, мы управляем группами одинаковых серверов, на которых запущены одинаковые приложения и сервисы. Они размещаются на системах виртуализации внутри организации, или же запускаются как «облачные» и гостевые в удаленных ЦОД. В некоторых случаях, мы можем говорить о большом количестве оборудования, которое существует только для поддержки очень больших приложений или об оборудовании, обслуживающем мириады небольших сервисов. В любом случае, возможность «взмахнуть волшебной палочкой» и заставить их всех выполнить волю системного администратора не может быть обесценена. Это единственный путь управлять огромными и растущими инфраструктурами.

Puppet, Chef, Ansible и Salt были задуманы чтобы упростить настройку и обслуживание десятков, сотен и джае тысяч серверов. Это не значит, что маленькие компании не получат выгоды от этих инструментов, так как автоматизация обычно делает жизнь проще в инфраструктуре любого размера.
Я пристально взглянул на каждый из этих четырех инструментов, исследовал их дизайн и функциональность, и убежден, что несмотря на то, что некоторые оценены выше, чем другие, для каждого есть свое место, в зависимости от целей внедрения. Здесь я подвожу итоги моих находок.

От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

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

Надеюсь, этот текст вам понравится.

Салют, Хабр! Сегодня мы разберем достаточно специфичную область — потоковая обработка данных, с помощью Spring Integration фреймворка и как сделать эти потоки в runtime без предварительной инициализации в контексте приложения. Полный пример приложения лежит в Гите.

Введение

Spring Integration — фреймворк корпоративной интеграции (EIP), использующий под капотом механизмы обмена сообщениями между адаптерами различных протоколов/систем интеграции на основе каналов сообщений (условные очереди). Известными аналогами являются — Camel, Mule, Nifi.

Из тестового кейса у нас будет — сделать REST сервис, который умеет считывать полученные параметры запроса, ходить в нашу базу, к примеру, postgres, делать обновление и выборку из данных таблиц по параметрам, полученных от источника, и отдавать результат в очередь обратно (request/response), а также сделать несколько экземпляров с разными путями запроса.

Условно диаграмма data flow (потока) будет выглядеть так:



Далее я покажу, как это можно просто сделать без особых танцев с бубном, с помощью IntegrationFlowContext, с REST-управляющими эндепоинтами компонентов/потоков. Весь основной код проекта будет расположен в репозитории, здесь укажу лишь некоторые вырезки. Что ж, кто заинтересован, прошу под кат.

Привет, Хаброжители! Наконец-то у нас вышла книга Дженнифер Дэвис и Кэтрин Дэниелс — Философия DevOps.

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.

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

Прим. перев.: эта небольшая статья Lin Sun из IBM в блоге CNCF — занятная иллюстрация тех сложностей, над преодолением которых сейчас трудятся инженеры популярных реализаций service mesh. С ними становится понятным, почему порог вхождения у этих продуктов остаётся довольно большим.

В августе этого года на конференции ServiceMeshCon EU мы с William Morgan из Linkerd выступили с совместным докладом под названием «Service mesh is still hard». William рассказал об инновациях в Linkerd, в то время как я затронула нововведения в Istio. Оба проекта, очевидно, активно работают над тем, чтобы упростить переход обычных пользователей на service mesh.


Этот слайд (из видео с недавним выступлением William Morgan и Lin Sun) лаконично подытоживает актуальные плюсы и минусы сервисных сеток

Сегодня service mesh стали более зрелыми, чем были год или пару лет назад. Однако они по-прежнему сложны для понимания большинства пользователей.

Перевод статьи подготовлен в преддверии старта курса «Разработчик на Spring Framework».

---

Одна из причин популярности Spring и Spring Boot — это хорошая поддержка тестирования. Можно писать как юнит-тесты с Mockito без использования функциональности Spring’а, так и интеграционные с инициализацией Spring-контекста.

Для интеграционных тестов может потребоваться взаимодействие с внешними сервисами, такими как реляционные базы данных, NoSQL-базы данных, Kafka и другими. При тестировании удобно разворачивать эти сервисы в Docker-контейнерах.

Хотя недавно была выпущена Java 9 с новой модульной системой, многие еще продолжают пользоваться привычной восьмой версией, с лямбдами. В течение полугода я плотно работал с ней и всеми ее нововведениями. Если с новыми методами коллекций и Optional все понятно, то с лямбдами не все так очевидно. В частности, как они реализованы и как влияют на производительность. И главное — чем они отличаются от старых добрых анонимных классов.

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «The Origins of DevOps: What’s in a Name?» автора Steve Mezak.

В зависимости от вашей точки зрения, DevOps будет отмечать свою девятую или десятую годовщину в этом году. В 2016 в отчёте компании RightScales о состоянии облаков отмечалось, что 70 процентов малого и среднего бизнеса принимают на вооружение методы DevOps. Каждый составляющий эту оценку индикатор с тех пор увеличился. Пока DevOps готовится разменять второе десятилетие своего существования, было бы здорово прогуляться по закоулкам прошлого и вернуться к истокам DevOps — и даже к происхождению самого этого названия.

В статье опишу использование Spring Data.

Spring Data — дополнительный удобный механизм для взаимодействия с сущностями базы данных, организации их в репозитории, извлечение данных, изменение, в каких то случаях для этого будет достаточно объявить интерфейс и метод в нем, без имплементации.

Содержание:

1. Spring Repository
2. Методы запросов из имени метода
3. Конфигурация и настройка
4. Специальная обработка параметров
5. Пользовательские реализации для репозитория
6. Пользовательский Базовый Репозиторий
7. Методы запросов — Query

Движущая сила микросервисов

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

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

Однако, когда дело доходит до тестирования (или, чего похуже, разработки) микросервисов, выясняется, что большинство компаний по-прежнему испытывает привязанность к допотопному способу тестирования всех компонентов вместе. Создание сложной инфраструктуры считается обязательным условием для проведения сквозного (end-to-end) тестирования, при котором набор тестов для каждого сервиса обязательно должен быть выполнен — делается это для того, чтобы убедиться, что в сервисах не появилось регрессий или несовместимых изменений.