Микросервисы для Java программистов. Практическое введение во фреймворки и контейнеры
10 навыков, которые помогут в карьере Java-программисту
Сокращенный перевод статьи «10 Skills Java Programmer can Learn to Accelerate their Career».
Я часто получаю письма от моих читателей, в которых они спрашивают, как стать лучшим Java-программистом, что нужно изучить, над какими вещами поработать.
Я отвечал на подобные письма в индивидуальном порядке последние несколько лет, а теперь, наконец, решил собрать воедино несколько советов для Java-программистов и разработчиков приложений.
Прежде чем перейти к самим советам, я хотел бы отметить, что, становясь лучшим программистом вообще, вы становитесь и лучшим Java-программистом в частности. Но советы общего характера я давал в другой своей статье.
Статья, которую вы читаете, полностью посвящена Java-разработке. Подбирая советы для нее, я исходил из того, что читатель уже имеет хорошие навыки кодинга, разбирается в алгоритмах и структурах данных, знаком с такими концепциями как сети, протоколы, объектно-ориентированное программирование и т. п.
Советы из этой статьи будут в равной степени полезны и Java-разработчикам, пишущим серверные приложения и не нуждающимся в знании JSP, Servlet и JEE, и веб-разработчикам, чья основная работа — создавать веб-приложения с использованием Java.
Если вы хотите улучшить свой набор навыков, ускорить карьерный рост и стать лучшим Java-программистом, обратите внимание на следующие навыки — их наличие выделит вас на фоне других разработчиков.
1. Изучайте проектирование и архитектуру программного обеспечения
Проектирование и архитектура это, пожалуй, самые важные стадии процесса разработки ПО. Умение при решении конкретных проблем видеть картину крупным планом, а также умение выбирать подходящую архитектуру и технологический стек для реализации приложения это очень важные навыки для любого разработчика программного обеспечения, не только для Java-разработчика.
В общем, если вы хотите продвинуться по карьерной лестнице и стать разработчиком-сеньором, одним из тех, за которыми охотятся компании, я советую вам изучать архитектуру ПО.
2. Изучайте контейнеры и DevOps-инструменты (Jenkins, Docker, Kubernetes)
Для современного Java-разработчика знание DevOps обязательно. Он должен быть как минимум знаком с непрерывной интеграцией и непрерывным развертыванием, а также знать, какова роль Jenkins в том и другом.
Эти знания становятся еще более важны для разработчиков-сеньоров, в чьи обязанности часто входит внедрение лучших практик программирования, создание окружений и сценариев, составление руководств.
Я советую вам уделить некоторое время более тщательному изучению DevOps в целом, а также изучению таких инструментов как Docker, Chef, Kubernetes и т. п., плюс Maven и Jenkins.
3. Изучите фреймворк Spring (Spring Boot)
Для современного Java-разработчика изучение фреймворка Spring является практически обязательным. Это связано с тем, что многие компании предпочитают вести разработку с применением именно Spring-фреймворков (Spring MVC, Spring Boot и Spring Cloud).
Также использование этих фреймворков предполагает применение лучших практик, таких как dependency injection, и делает ваши приложения более тестируемыми, а это одно из основных требований к современному ПО.
Если вы начинающий разработчик, я советую начать с руководств по Spring — чтобы хотя бы познакомиться с этим прекрасным фреймворком. А если вы уже с ним знакомы, можете исследовать Spring Boot и Spring Cloud — это вам пригодится для разработки Java-приложений следующего поколения.
4. Освойте модульное тестирование (JUnit и Mockito)
Хороших Java-разработчиков от посредственных часто отличает одна общая черта: навык модульного тестирования.
Хороший, профессиональный Java-разработчик практически всегда пишет модульные тесты для своего кода. А по-настоящему выдающегося разработчика всегда видно по его коду и его тестам.
Сейчас Java-разработчикам доступны многие инструменты модульного, интеграционного и автоматизированного тестирования.
На оттачивание навыков тестирования может уйти довольно много времени. Но начинающим разработчикам лучше всего начать этот путь с изучения библиотеки JUnit. Последняя версия JUnit 5 отличается и мощью, и гибкостью. С ней должен познакомиться каждый Java-разработчик!
5. Изучайте API и библиотеки
Если вам случалось работать с хорошими Java-разработчиками, вы наверняка замечали, как здорово они ориентируются в экосистеме Java и как хорошо знают формы API для большей ее части.
Java это один из самых популярных и развитых языков программирования в мире. В его экосистеме можно найти библиотеки и API практически для чего угодно.
Конечно, никто не ждет, что вы изучите их все. Но вы должны знать некоторые ключевые API (JSON), обрабатывающие API (Jackson и Gson), API для обработки XML (JAXB и Xerces), библиотеки модульного тестирования (Mockito и JUnit).
Если для вас все это внове, начать можно с моего обзора «20 библиотек Java, обязательных для каждого Java-разработчика». В этой статье я рассказал об основных библиотеках в ключевых областях.
6. Изучите, как работает виртуальная машина Java
Если вы серьезно настроены стать выдающимся Java-разработчиком, вы просто обязаны уделить время изучению работы JVM. То есть, вы должны знать, из каких частей она состоит и как эти части работают.
Хорошо зная JVM, вы сможете писать надежные и одновременно высокопроизводительные Java-приложения. То есть, делать то, что делают все выдающиеся разработчики.
В рамках этого вы также должны научиться профилировать свои Java-приложения и находить узкие места в производительности (например, находить, какие объекты занимают большую часть вашей памяти и съедают CPU).
По этой теме могу посоветовать книгу «The Definitive Guide to Java Performance» Скотта Оакса, это отличный источник знаний по работе JVM и сборке мусора.
7. Изучайте шаблоны проектирования
Если вы пишете Java-приложение с нуля, это означает, что большую часть времени вы пишете объектно-ориентированный код. А шаблоны проектирования в такой ситуации — испытанное и проверенное решение для распространенных проблем.
Зная шаблоны и применяя их в своем коде, вы делаете свое приложение более гибким, а его изменение в будущем — более простым.
Также применение шаблонов улучшает качество кода и документации в целом, потому что другие Java-разработчики тоже знакомы с этими шаблонами, а значит, смогут быстрее разобраться в вашем решении.
Но не следует сосредотачиваться на конкретном коде. Вместо этого постарайтесь понять сам дух шаблона и будьте креативны. Используйте такие свойства Java 8 как lambdas и Streams для переписывания шаблонов вроде «Стратегии».
8. Изучите Kotlin
Пару лет назад я прочел книгу «The Well-Grounded Java Developer», в которой подчеркивалось преимущество знания нескольких языков для программиста. Это вдохновило меня изучить Scala, а позже я также попробовал взяться за Groovy, потому что его использование в написании скриптов сборки и модульном тестировании заметно растет.
Этот опыт очень мне помог, так что я призываю Java-разработчиков изучить новый JVM-язык. О JVM-языках я говорил отдельно, но если вы спешите, просто изучите Kotlin.
Это отличный язык от JetBrains — компании, стоящей за IntelliJ IDEA, а кроме того, это официальный язык Android. То есть, изучение Kotlin поможет вам не только улучшить свою производительность, но и войти в сферу Android-разработки.
9. Изучите микросервисы
Архитектура меняется постоянно. Многие компании переходят от монолитных приложений к микросервисам.
Так что для Java-разработчиков сейчас самое время осваивать микросервисную архитектуру и учиться создавать микросервисы на Java, чтобы использовать все преимущества существующего тренда.
К счастью, фреймворк Spring предлагает Spring Cloud и Spring Boot, очень сильно упрощающие разработку микросервисов на Java.
Из книг по данной теме я советую «Cloud Native Java» Джоша Лонга. Это доступное руководство по созданию облачных Java-приложений.
10. Получше познакомьтесь со своей IDE
Одна из отличительных черт лучших Java-разработчиков — они очень хорошо владеют своими инструментами. То есть, они не просто знают больше инструментов, чем средний разработчик, они также гораздо лучше знают каждый из этих инструментов.
Поскольку самым важным инструментом для любого Java-программиста является его IDE (Eclipse, NetBeans, IntelliJ IDEA), имеет смысл уделить время более глубокому ее изучению.
Можно познакомиться с полезными плагинами, облегчающими работу, можно изучить сокращения клавиш для ускорения навигации. При достаточно частом использовании даже какие-нибудь мелочи могут играть большую роль.
11. Глубже изучите Java
Это, безусловно, самое главное для любого Java-разработчика. Язык Java постоянно обновляется. С учетом того, что новая версия выходит каждые 6 месяцев, довольно сложно уследить за всеми нововведениями. Я изучал особенности Java 10, но при этом знаю многих программистов, не написавших ни единой строки кода с использованием таких функций Java 8 как lambdas и Stream API.
К сожалению, многие из этих программистов — опытные разработчики, у них за плечами по 7-10 лет стажа. Я понимаю, что на каком-то этапе карьеры скорость учебы снижается, но если не шевелиться, можно очень скоро остаться на обочине.
Сейчас почти все вакансии в Java-разработке требуют знания Java 8+. Если у вас таких знаний нет, вам придется туго на собеседованиях.
Это все, что я хотел посоветовать Java-разработчикам. Знаю, что следовать всем этим советам непросто, но вам не обязательно браться за все сразу, это слишком непрактично. Можно сфокусироваться для начала на самом важном, например, на изучении Java 8 и фреймворка Spring (если вы с ним еще не знакомы). А если с этими темами у вас все в порядке, можно выбрать другие, например, модульное тестирование, работу JVM и DevOps.
Если вы не настроены на большие свершения, но все равно хотите приобрести какие-то новые полезные навыки, лучшим выбором будет глубокое освоение вашей IDE. Это позволит вам достаточно быстро улучшить продуктивность вашей работы.
Soft, интернет, безопасность: новости, статьи, советы, работа
Избранное сообщение
Фетісов В. С. Комп’ютерні технології в тестуванні. Навчально-методичний посібник. 2-ге видання, перероблене та доповнене / Мои публикации
В 10-х годах я принимал участие в программе Европейского Союза Tempus “Освітні вимірювання, адаптовані до стандартів ЄС”. В рамк.
вторник, 31 октября 2017 г.
Микросервисы для Java программистов. Практическое введение во фреймворки и контейнеры. (Часть 3) / Программирование на Java
Перевод книги Кристиана Посты (Christian Posta) Microservices for Java Developers. A Hands-On Introduction to Frameworks & Containers. Продолжение. Предыдущая публикация.
ГЛАВА 1. Микросервисы для Java программистов
(Продолжение)
Проектирование с учетом обязательств
В среде микросервисов с автономными командами и сервисами очень важно иметь в виду взаимоотношения между поставщиком и потребителем сервиса. Как автономная команда обслуживающая сервис, Вы не можете предъявлять какие-либо требования к другим командам и сервисам потому, что Вы не владеете ими, они автономны по определению. Всё, что Вы можете сделать — это выбрать, будете ли Вы принимать или не принимать их обязательства функциональности или поведения. А как поставщик сервиса для других, всё, что Вы можете сделать — это пообещать им определенное поведение. Они вольны в выборе — доверять Вам или нет. Модель теории обязательств впервые предложена Марком Берджессом (Mark Burgess) в 2004 году и описана в его книге «В поисках определенности» (In Search of Certainty, O’Reilly, 2015). Это исследование автономных систем включая человеческие и компьютерные, оказывающие услуги друг другу.
С точки зрения распределенных систем «обязательство» помогает сформулировать, какие услуги предоставляются и какие предположения на их счет могут или не могут быть сделаны. Например, команда владеет сервисом, который рекомендует книги. Мы обещаем персонифицированный набор книг, рекомендуемый для конкретного произвольного пользователя. Что произойдет, если при обращении к этому сервису один из бэкендов (база данных, хранящая текущий профиль рекомендаций для пользователей) вдруг недоступен? Мы могли бы сгенерировать исключение и отправить обратно трассировку стека, но это было бы не очень приятно для потребителя и может потенциально развалить другие части системы. Мы дали обещание и мы попытаемся сделать всё возможное, чтобы выполнить его. В том числе вернув некий стандартный набор рекомендаций книг или подмножество, состоящее из любой книги. Бывают случаи, когда обещания невозможно выполнить и наилучшее поведение в таком случае будет определяться уровнем сервиса или результатом для пользователей, который мы хотели бы сохранить. Ключевым здесь является акцент на обещании сервиса (выдать рекомендации), даже если сервис от которого мы зависим, не может выполнить своё обещание (база данных отказала). Попытки сдержать обещание помогают сохранить остальные части системы и удержать уровень качества обслуживания.
Другой взгляд на «обязательство» — это согласованное взаимное понимание его ценности для обеих сторон (как производителя, так и потребителя). Но как же нам выбрать из двух поставщиков, что ценнее и на какие обязательства нам стоит соглашаться? Если никто не обращается к сервису или не получает результат от обещаний, чем полезен такой сервис? Один из способов сформулировать обязательства между потребителями и поставщиками — это задаваемый потребителем контракт (consumer-driven contract). В задаваемом потребителем контракте мы можем зафиксировать объем обещаний кодом или утверждениями, а в качестве поставщика мы можем использовать эти знания, чтобы проверить, действительно ли мы держим свои обещания.
Управление распределенными системами
В конце концов управление отдельной системой проще, чем распределенной. Если есть только одна машина, один сервер приложений и в системе случились проблемы, мы знаем где искать. Если нужно изменить конфигурацию, обновить до определенной версии или обезопасить его — это всё равно одно физическое и логическое расположение. Выполнять управление, отладку и изменения в таком случае достаточно просто. Единая система может работать для некоторых приложений, но там, где требуется масштабирование, следует обратить внимание на микросервисы. Как мы уже упоминали ранее, микросервисы не даются бесплатно — плата за гибкость и масштабируемость — более сложная система управления.
Вот некоторые вопросы управляемости развертывания микросервисов:
- Как запускать и останавливать весь «флот» сервисов?
- Как собирать и консолидировать логи/метрики/параметры качества со всех микросервисов?
- Как обнаруживать сервисы в изменяющемся окружении, если они могут появляться, исчезать, перемещаться и т.п.?
- Как осуществлять балансировку нагрузки?
- Как мы получим состояние кластера или отдельных микросервисов?
- Как перезапустить «упавшие» сервисы?
- Как организовать настраиваемую маршрутизацию запросов API?
- Как обеспечить безопасность сервисов?
- Как придержать/разогнать или отключить части кластера если он начал «разваливаться» или вести себя непредсказуемо?
- Как развернуть несколько версий сервиса и корректно маршрутизировать к ним запросы?
- Как провести изменения конфигурации во всем «флоте» сервисов?
- Как организовать изменение кода приложения и его конфигурации безопасным, проверяемым и повторяемым способом?
И это не самые легкие для решения проблемы. Остальная часть книги будет посвящена введению Java-разработчиков в мир микросервисов и в способы решения некоторых из перечисленных выше проблем. Полный, всеобъемлющий перечень инструкций и ответов на перечисленные вопросы (и многие другие) появится во втором издании этой книги.
Технологические решения
На протяжении остальной книги мы познакомим Вас с некоторыми популярными компонентами технологий и как они решают некоторые проблемы разработки и внедрения программного обеспечения с использованием архитектуры микросервисов. Как говорилось ранее, микросервисы — это не только технологическая проблема, первостепенными являются правильная организационная структура и соответствующие команды. Переход от SOAP к REST не создает микросервисную архитектуру.
Первым шагом для команды Java разработчиков разрабатывающей микросервисы, является получение работающего результата на своей локальной машине! Эта книга познакомит Вас с тремя фреймворками Java для работы с микросервисами: Spring Boot, Dropwizard и WildFly Swarm. Каждый из них имеет свои плюсы для разных команд, организаций и подходов к микросервисам. Так же как и для любой другой технологии то, что некоторые инструменты лучше подходят для той или иной работы или команды — это норма. Перечисленные инструменты не единственные в своем роде. Есть еще пара, которые исповедуют реактивный подход к микросервисам — это Vert.x и Lagom. Переход к событийной модели разработки слегка отличается и требует несколько другого набора знаний, так что в этой книге мы будет придерживаться модели, которую большинство Java программистов найдут вполне комфортной.
Цель этой книги — подготовить Вас к использованию основных возможностей каждого из фреймворков. Мы погрузимся в пару «продвинутых» концепций в последней главе, но для первых шагов с каждым из фреймворков мы будем использовать микросервисное приложение «hello-world». Эта книга не является всеобъемлющим справочником по разработке микросервисов. В каждом разделе есть ссылки на справочные материалы, которые Вы сможете изучить по мере необходимости. Мы будем постепенно развивать приложение «hello-world», создав несколько сервисов и демонстрируя различные простые схемы взаимодействия.
Заключительный этюд для каждого из фреймворков затронет такие концепции как «переборки» (bulkheading) и «теория обязательств», чтобы сделать сервисы более устойчивыми перед лицом отказов. Мы покопаемся в таких частях стека NetflixOSS как Hystrix, что поможет облегчить реализацию этого функционала. Мы обсудим плюсы и минусы такого подхода и исследуем другие существующие варианты.
По мере продвижения по примерам мы обсудим значение Linux-контейнеров для развертывания, управления и изоляции микросервисов равно как и их значение для локальной разработки. Docker и Kubernetes внесли неоценимый вклад в упрощение работы с распределенными масштабируемыми системами, поэтому мы обсудим некоторые полезные практики связанные с контейнерами и микросервисами.
В последнем разделе, мы дадим Вам несколько мыслей на тему управления распределенными конфигурациями, логированием, мониторингу и непрерывной поставки.
Подготовка среды разработки
Для примеров мы будем использовать Java 1.8 и собирать их с помощью Maven. Пожалуйста, убедитесь, что у Вас установлены соответствующие программы и выполнены следующие условия:
- JDK 1.8
- Maven 3.2+
- Есть доступ к командной строке (bash, PowerShell, cmd, Cygwin, и т.д.)
Экосистема Spring имеет несколько отличных инструментов, которые можно использовать либо в командной строке, либо в IDE. Большинство примеров будет придерживаться командной строки, чтобы оставаться независимыми от IDE потому, что каждая IDE определяет свой собственный способ работы с проектами. Для Spring Boot, мы будем использовать Spring Boot CLI 1.3.3.
Альтернативные IDE и инструментарий для Spring:
IDE на базе Eclipse: Spring Tool Suite.
Spring Initializr web interface.
И для Dropwizard, и для WildFly Swarm мы будем использовать JBoss Forge CLI и некоторые расширения, чтобы создавать и управлять проектами: JBoss Forge 3.0+.
Альтернативные IDE и инструментарий для проектов Spring, Dropwizard или WildFly Swarm (которые отлично работают с JBoss Forge):
- IDE на базе Eclipse: JBoss Developer Studio.
- Netbeans.
- IntelliJ IDEA.
И наконец, для сборки и запуска микросервисов в виде Docker-контейнеров внутри Kubernetes нам понадобятся следующие инструменты для развертывания среды контейнеров:
- Vagrant 1.8.1.
- VirtualBox 5.0.x.
- Container Development Kit 2.x.
- Kubernetes/Openshift CLI.
- Docker CLI (опционально).
H Микросервисы для Java программистов. Практическое введение во фреймворки и контейнеры в черновиках Tutorial
.collapse”>Содержание
Перевод книги Кристиана Посты (Christian Posta) Microservices for Java Developers. A Hands-On Introduction to Frameworks & Containers. Продолжение см. здесь
ГЛАВА 1. Микросервисы для Java программистов
Чего Вы можете ожидать от этой книги?
Эта книга ориентирована на программистов и архитекторов Java, интересующихся разработкой микросервисов. Мы начнем книгу с высокоуровнего обзора общих принципов и фундаментальных требований, которые должны быть выполнены для успешной реализации микросервисной архитектуры. К сожалению, простое применение современных технологий не решает магическим образом всех проблем присущих распределенным системам. Мы рассмотрим основных игроков и то, что успешные компании сделали, чтобы микросервисы на них работали, включая культуру, организационную структуру и факторы рынка. Затем мы совершим глубокое погружение в несколько Java-фреймворков, используемых в реализации микросервисов. Репозиторий примеров исходных кодов из данной книги расположен на GitHub. Испачкав руки в коде, мы вернемся на воздух и обсудим проблемы развертывания, кластеризации, отказоустойчивости и то, какие решения предлагают Docker и Kubernetes в этих областях. Затем мы снова вернемся к деталям нескольких практических примеров с применением Docker, Kubernetes и NetflixOSS для демонстрации возможностей, которые они придают облачной микросервисной архитектуре. Закончим мы некоторыми положениями, которые мы не можем раскрыть в такой небольшой книге, но которые от этого не становятся менее важными: конфигурирование, протоколирование и непрерывная поставка (CD).
Микросервисы — это не только вопрос технологий. Реализация микросервисов уходит корнями в теорию саморегулирующихся систем, проектирование сервисов, эволюцию, проблемно-ориентированное проектирование, анализ зависимостей, теорию обязательств и другие источники. Собранные вместе, они позволяют нам организовать действительно технологически гибкие, отзывчивые, обучаемые системы, позволяющие оставаться конкурентными в быстроменяющемся мире бизнеса. Давайте рассмотрим поближе.
Вы работаете на компанию-разработчика ПО
Программное обеспечение действительно «поедает» весь мир. Бизнес понемногу начинает это понимать. Существует два основных двигателя этого феномена: удовлетворение потребностей посредством высококачественных сервисов и быстрая коммодизация технологий. Эта книга имеет, в основном, формат практического руководства с примерами, но прежде чем мы погрузимся в технологии, нам необходимо правильно расставить декорации и понять, кто участвует и какую роль исполняет. В последние годы мы «до тошноты» обсуждали, как сделать бизнес более гибким, однако мы должны полностью разобраться, что это значит. Иначе мы получим очередную банальность, с которой и так все вокруг носятся.
Ценность услуги
На протяжении более чем 100 лет бизнес был сосредоточен на создании продуктов и убеждении покупателей в необходимости потребления этих продуктов: столы, микроволновки, автомобили, обувь, да всё что угодно. Идея, стоящая за всей этой «ведомой производителем» экономикой, происходит из сформулированного Генри Фордом тезиса — «если Вы можете произвести большое количество продукции при малых издержках, то рынок будет практически бесконечным». Для того, чтобы это работало, Вам потребуется несколько односторонних каналов прямого маркетинга в массы, чтобы убедить их в том, что они нуждаются в вашей продукции и их жизнь с ними станет значительно лучше. Практически весь 20-й век эти однонаправленные каналы существовали в форме рекламы на телевидении, в газетах, журналах и на рекламных щитах. Однако, такая ведомая производителем экономика «сложилась» потому, что рынки полностью насытились продукцией (сколько телефонов/автомобилей/телевизоров Вам нужно?). Более того, Интернет вместе с социальными сетями изменяет динамику взаимодействия производителей с потребителями (и что более важно то, как потребители взаимодействуют с производителями).
Социальные сети позволяют нам как потребителям свободнее обмениваться информацией друг с другом и с компаниями, с которыми мы имеем дело. Мы доверяем друзьям, семье и другим людям больше, чем маркетинговым отделам компаний. Вот почему мы прибегаем к помощи социальных сетей при выборе ресторанов, отелей и авиаперевозчиков.
Положительные отклики в виде обзоров, твитов, ссылок и т.п. могут положительно повлиять на бренд компании, а отрицательные отзывы также легко и непринужденно могут его разрушить. Это создает мощный, ранее не существовавший, двунаправленный поток информации между компаниями и потребителями, при котором бизнес старается удержаться и не уронить марку.
Постиндустриальные компании начинают понимать, что они должны пестовать свои взаимоотношения с потребителями (используя эти двунаправленные каналы коммуникаций), чтобы понимать, как создать и донести до них ценность как таковую. Для достижения этого компании организуют взаимодействие через службу сервиса, через постоянную оценку удовлетворенности покупателей и обратную связь. Потребители выбирают какой сервис использовать и за какой заплатить в зависимости от того, кто предоставляет большую ценность и удобство. Возмём, например Uber, у которого нет никакого склада или продаваемых продуктов как таковых. Я не получаю никакой пользы от сидения в чьём-либо автомобиле, но обычно я пытаюсь добраться куда-нибудь (на бизнес-встречу, например), что и представляет для меня ценность. В таком контексте Uber и я создаем ценность через моё использование их услуги. Развивая мысль — компании должны сосредоточиться на предоставлении полезных для потребителей услуг, а технологии будут обеспечивать процесс посредством цифровых сервисов.
Коммодизация технологий
Технологии развиваются по схожим с экономикой, биологией и юриспруденцией циклам взрывного роста и стагнации. Это привело к великим новациям таким, как паровой двигатель, телефон и компьютер. Тем не менее, на конкурентных рынках ключевые новации требуют больших инвестиций и скорого внедрения для быстрой капитализации на соответствующем рынке. Это создает еще большую конкуренцию, большие объемы производства и ведет к падению цен, что в конце концов делает ранее инновационную технологию общеупотребительной. По мере коммодизации мы продолжаем развивать инновации и видоизменяться — цикл повторяется. Коммодизация привела нас от мэйнфреймов к персональному компьютеру и к тому, что мы сейчас называем «облачными вычислениями», которые по сути представляют собой общедоступную услугу с практически нулевыми капитальными затратами для потребителя. Поверх облачных вычислений мы теперь развиваем другую новацию в форме цифровых сервисов.
Существенную роль в технологических изменениях играет программное обеспечение (ПО) с открытым кодом. Следуя кривой коммодизации, сообщества ПО с открытым кодом это место, где разработчики могут бросить вызов коммерческим компаниям, создавая инновации в программном обеспечении в областях, где однажды был выбор только из «любого черного» (да еще без исходных кодов и с высокой стоимостью лицензии). Отсутствие выбора подталкивает сообщества к созданию таких вещей, как операционные системы (Linux), языки программирования (Go), менеджеры очередей (Apache ActiveMQ) и веб-сервера (httpd). Даже те компании, которые изначально отвергали ПО с открытым кодом начинают постепенно присоединяться, открывая исходные тексты своих технологий и внося свою лепту в существующие сообщества. По мере того, как ПО с открытым кодом и связанная с ним экосистема становятся нормой, мы начинаем наблюдать множество инноваций в программных технологиях, приходящие напрямую из мира открытого ПО (например Apache Spark, Docker и Kubernetes).
Разрушение
Совместное влияние сервисно-ориентированного проектирования и эволюции технологий снижают входной барьер начала экспериментов и создания нового сервиса для каждого с хорошей идеей. Вы можете обучиться программированию, использованию продвинутых фреймворков и при этом опираться на вычислительные мощности по запросу почти с нулевыми затратами. Вы можете публиковать в социальных сетях, блоге, организовывать диалог с потенциальными пользователями вашего сервиса совершенно бесплатно. С существующей степенью изменчивости бизнес-рынков любой из стартапов выходного дня может «выбить» традиционную компанию из бизнеса.
И этот факт пугает большинство исполнительных и ИТ-директоров. По мере того, как программное обеспечение быстро становится для компаний средством построения цифровых услуг, накопления опыта и приобретения преимущества над другими, многие понимают, что они должны стать разработчиками ПО в своих соответствующих «вертикальных» рынках. Прошли дни тотального ИТ-аутсорсинга и отношения к ИТ, как к общеупотребительной услуге и центру затрат. Чтобы оставаться конкурентоспособными, компаниям нужно принять программное обеспечение как конкурентное преимущество. А чтобы воспользоваться этим конкурентным преимуществом — они сами должны стать организационно гибкими.
10 навыков, которые помогут в карьере Java-программисту
Сокращенный перевод статьи «10 Skills Java Programmer can Learn to Accelerate their Career».
Я часто получаю письма от моих читателей, в которых они спрашивают, как стать лучшим Java-программистом, что нужно изучить, над какими вещами поработать.
Я отвечал на подобные письма в индивидуальном порядке последние несколько лет, а теперь, наконец, решил собрать воедино несколько советов для Java-программистов и разработчиков приложений.
Прежде чем перейти к самим советам, я хотел бы отметить, что, становясь лучшим программистом вообще, вы становитесь и лучшим Java-программистом в частности. Но советы общего характера я давал в другой своей статье.
Статья, которую вы читаете, полностью посвящена Java-разработке. Подбирая советы для нее, я исходил из того, что читатель уже имеет хорошие навыки кодинга, разбирается в алгоритмах и структурах данных, знаком с такими концепциями как сети, протоколы, объектно-ориентированное программирование и т. п.
Советы из этой статьи будут в равной степени полезны и Java-разработчикам, пишущим серверные приложения и не нуждающимся в знании JSP, Servlet и JEE, и веб-разработчикам, чья основная работа — создавать веб-приложения с использованием Java.
Если вы хотите улучшить свой набор навыков, ускорить карьерный рост и стать лучшим Java-программистом, обратите внимание на следующие навыки — их наличие выделит вас на фоне других разработчиков.
1. Изучайте проектирование и архитектуру программного обеспечения
Проектирование и архитектура это, пожалуй, самые важные стадии процесса разработки ПО. Умение при решении конкретных проблем видеть картину крупным планом, а также умение выбирать подходящую архитектуру и технологический стек для реализации приложения это очень важные навыки для любого разработчика программного обеспечения, не только для Java-разработчика.
В общем, если вы хотите продвинуться по карьерной лестнице и стать разработчиком-сеньором, одним из тех, за которыми охотятся компании, я советую вам изучать архитектуру ПО.
2. Изучайте контейнеры и DevOps-инструменты (Jenkins, Docker, Kubernetes)
Для современного Java-разработчика знание DevOps обязательно. Он должен быть как минимум знаком с непрерывной интеграцией и непрерывным развертыванием, а также знать, какова роль Jenkins в том и другом.
Эти знания становятся еще более важны для разработчиков-сеньоров, в чьи обязанности часто входит внедрение лучших практик программирования, создание окружений и сценариев, составление руководств.
Я советую вам уделить некоторое время более тщательному изучению DevOps в целом, а также изучению таких инструментов как Docker, Chef, Kubernetes и т. п., плюс Maven и Jenkins.
3. Изучите фреймворк Spring (Spring Boot)
Для современного Java-разработчика изучение фреймворка Spring является практически обязательным. Это связано с тем, что многие компании предпочитают вести разработку с применением именно Spring-фреймворков (Spring MVC, Spring Boot и Spring Cloud).
Также использование этих фреймворков предполагает применение лучших практик, таких как dependency injection, и делает ваши приложения более тестируемыми, а это одно из основных требований к современному ПО.
Если вы начинающий разработчик, я советую начать с руководств по Spring — чтобы хотя бы познакомиться с этим прекрасным фреймворком. А если вы уже с ним знакомы, можете исследовать Spring Boot и Spring Cloud — это вам пригодится для разработки Java-приложений следующего поколения.
4. Освойте модульное тестирование (JUnit и Mockito)
Хороших Java-разработчиков от посредственных часто отличает одна общая черта: навык модульного тестирования.
Хороший, профессиональный Java-разработчик практически всегда пишет модульные тесты для своего кода. А по-настоящему выдающегося разработчика всегда видно по его коду и его тестам.
Сейчас Java-разработчикам доступны многие инструменты модульного, интеграционного и автоматизированного тестирования.
На оттачивание навыков тестирования может уйти довольно много времени. Но начинающим разработчикам лучше всего начать этот путь с изучения библиотеки JUnit. Последняя версия JUnit 5 отличается и мощью, и гибкостью. С ней должен познакомиться каждый Java-разработчик!
5. Изучайте API и библиотеки
Если вам случалось работать с хорошими Java-разработчиками, вы наверняка замечали, как здорово они ориентируются в экосистеме Java и как хорошо знают формы API для большей ее части.
Java это один из самых популярных и развитых языков программирования в мире. В его экосистеме можно найти библиотеки и API практически для чего угодно.
Конечно, никто не ждет, что вы изучите их все. Но вы должны знать некоторые ключевые API (JSON), обрабатывающие API (Jackson и Gson), API для обработки XML (JAXB и Xerces), библиотеки модульного тестирования (Mockito и JUnit).
Если для вас все это внове, начать можно с моего обзора «20 библиотек Java, обязательных для каждого Java-разработчика». В этой статье я рассказал об основных библиотеках в ключевых областях.
6. Изучите, как работает виртуальная машина Java
Если вы серьезно настроены стать выдающимся Java-разработчиком, вы просто обязаны уделить время изучению работы JVM. То есть, вы должны знать, из каких частей она состоит и как эти части работают.
Хорошо зная JVM, вы сможете писать надежные и одновременно высокопроизводительные Java-приложения. То есть, делать то, что делают все выдающиеся разработчики.
В рамках этого вы также должны научиться профилировать свои Java-приложения и находить узкие места в производительности (например, находить, какие объекты занимают большую часть вашей памяти и съедают CPU).
По этой теме могу посоветовать книгу «The Definitive Guide to Java Performance» Скотта Оакса, это отличный источник знаний по работе JVM и сборке мусора.
7. Изучайте шаблоны проектирования
Если вы пишете Java-приложение с нуля, это означает, что большую часть времени вы пишете объектно-ориентированный код. А шаблоны проектирования в такой ситуации — испытанное и проверенное решение для распространенных проблем.
Зная шаблоны и применяя их в своем коде, вы делаете свое приложение более гибким, а его изменение в будущем — более простым.
Также применение шаблонов улучшает качество кода и документации в целом, потому что другие Java-разработчики тоже знакомы с этими шаблонами, а значит, смогут быстрее разобраться в вашем решении.
Но не следует сосредотачиваться на конкретном коде. Вместо этого постарайтесь понять сам дух шаблона и будьте креативны. Используйте такие свойства Java 8 как lambdas и Streams для переписывания шаблонов вроде «Стратегии».
8. Изучите Kotlin
Пару лет назад я прочел книгу «The Well-Grounded Java Developer», в которой подчеркивалось преимущество знания нескольких языков для программиста. Это вдохновило меня изучить Scala, а позже я также попробовал взяться за Groovy, потому что его использование в написании скриптов сборки и модульном тестировании заметно растет.
Этот опыт очень мне помог, так что я призываю Java-разработчиков изучить новый JVM-язык. О JVM-языках я говорил отдельно, но если вы спешите, просто изучите Kotlin.
Это отличный язык от JetBrains — компании, стоящей за IntelliJ IDEA, а кроме того, это официальный язык Android. То есть, изучение Kotlin поможет вам не только улучшить свою производительность, но и войти в сферу Android-разработки.
9. Изучите микросервисы
Архитектура меняется постоянно. Многие компании переходят от монолитных приложений к микросервисам.
Так что для Java-разработчиков сейчас самое время осваивать микросервисную архитектуру и учиться создавать микросервисы на Java, чтобы использовать все преимущества существующего тренда.
К счастью, фреймворк Spring предлагает Spring Cloud и Spring Boot, очень сильно упрощающие разработку микросервисов на Java.
Из книг по данной теме я советую «Cloud Native Java» Джоша Лонга. Это доступное руководство по созданию облачных Java-приложений.
10. Получше познакомьтесь со своей IDE
Одна из отличительных черт лучших Java-разработчиков — они очень хорошо владеют своими инструментами. То есть, они не просто знают больше инструментов, чем средний разработчик, они также гораздо лучше знают каждый из этих инструментов.
Поскольку самым важным инструментом для любого Java-программиста является его IDE (Eclipse, NetBeans, IntelliJ IDEA), имеет смысл уделить время более глубокому ее изучению.
Можно познакомиться с полезными плагинами, облегчающими работу, можно изучить сокращения клавиш для ускорения навигации. При достаточно частом использовании даже какие-нибудь мелочи могут играть большую роль.
11. Глубже изучите Java
Это, безусловно, самое главное для любого Java-разработчика. Язык Java постоянно обновляется. С учетом того, что новая версия выходит каждые 6 месяцев, довольно сложно уследить за всеми нововведениями. Я изучал особенности Java 10, но при этом знаю многих программистов, не написавших ни единой строки кода с использованием таких функций Java 8 как lambdas и Stream API.
К сожалению, многие из этих программистов — опытные разработчики, у них за плечами по 7-10 лет стажа. Я понимаю, что на каком-то этапе карьеры скорость учебы снижается, но если не шевелиться, можно очень скоро остаться на обочине.
Сейчас почти все вакансии в Java-разработке требуют знания Java 8+. Если у вас таких знаний нет, вам придется туго на собеседованиях.
Это все, что я хотел посоветовать Java-разработчикам. Знаю, что следовать всем этим советам непросто, но вам не обязательно браться за все сразу, это слишком непрактично. Можно сфокусироваться для начала на самом важном, например, на изучении Java 8 и фреймворка Spring (если вы с ним еще не знакомы). А если с этими темами у вас все в порядке, можно выбрать другие, например, модульное тестирование, работу JVM и DevOps.
Если вы не настроены на большие свершения, но все равно хотите приобрести какие-то новые полезные навыки, лучшим выбором будет глубокое освоение вашей IDE. Это позволит вам достаточно быстро улучшить продуктивность вашей работы.
Энтерпрайз головного мозга
Блог о разработке приложений на Java EE и Spring
четверг, 30 июля 2015 г.
Микросервисы глазами простого разработчика
Последние два-три года стало модно говорить о микросервисах. В твиттере и на профильных ресурсах слово “microservice” мелькает уж очень часто. Но.
— Arun Gupta (@arungupta) 26 июня 2015 В моём представлении микросервис по сути представляет собой самостоятельный компонент большой системы, выполняющий узкий круг задач. Кто-то превращает большие монолитные проекты в набор микросервисов, кто-то создаёт проекты сразу изначально в виде набора микросервисов. Наиболее важная на мой взгляд выгода в использовании микросервисов – достижение слабой связанности компонентов проекта. Плюс можно разделить микросервисы между командами разработчиков, что наверняка увеличит производительность труда.
Интересно, что микросервисы как подход к разработке можно было применять и пять лет назад и десять – этому ничего не мешало, просто не было такого тренда. Никто не мешал дробить крупные Java EE-проекты на большое количество маленьких WAR и JAR, разворачивать фермы Glassfish или JBoss и добиваться той же слабой связанности. Так же никто не мешал разрабатывать микросервисы в виде standalone-приложений. В целом этому способствовало и существование OSGi-контейнеров, которые, впрочем, в народе не особо прижились. Наиболее важной причиной увеличения популярности микросервисов на мой взгляд является популярность облачных сервисов: PaaS, IaaS и прочих XaaS.
Standalone или контейнеры?
Spring Boot и WildFly Swarm
На волне популярности микросервисов начали появляться фреймворки и проекты, упрощающие разработку микросервисов: к вышеупомянутым OSGi-контейнерам добавился Spring Boot, а так же ведётся разработка WildFly Swarm. Оба проекта предоставляют возможность разрабатывать микросервисы в виде standalone-приложений, минимизируя затрачиваемое время на конфигурирование компонента.
Стоит отметить, что Spring Boot уже является стабильным и достаточно успешным фреймворком, с помощью которого можно без лишней головной боли разрабатывать standalone-приложения, основанные на Spring Framework. Хотя далеко не все рекомендуют это делать, особенно приверженцы Java EE.
А вот с WildFly Swarm всё несколько хуже. Идея проекта заключается в интеграции Java EE в standalone-приложения. Смысл в этом есть, но сам проект ещё находится в разработке и до стабильного релиза, судя по всему, ещё очень далеко. Если при разработке простенького микросервиса с REST в случае со Spring Boot в итоге получается компактный jar на 5-10Мб, то в случае WildFly Swarm у вас в зависимостях будет добрая половина сервера приложений WildFly. Модульность Spring Framework взяла своё в данном случае.
Слово “микросервис” использовано в данном посте 20 раз.
Микросервисы. Руководство для начинающих
Вы наверняка слышали подобные высказывания: «Наши сервисы состоят из множества масштабируемых микросервисов», «Мы планируем перейти на архитектуру микросервисов». Но что такое микросервисы? Я постараюсь объяснить это на примерах из реального мира.
Монолит — машина по производству мороженого
Отвлечёмся на минуту от микросервисов и представим аппарат по производству мороженого. Он состоит из 4 отсеков: с мороженым, орехами, шоколадом и сиропом. В чашу можно добавить все ингредиенты, из которых только мороженое является обязательным, а остальные по желанию.
Открыв свой магазинчик мороженого, вы начнёте с одного небольшого аппарата, в который встроены все 4 компонента. По мере роста вашего бизнеса вы можете решить приобрести аппараты побольше, чтобы обслуживать больше клиентов за то же время. Такой подход приведёт к тому, что рано или поздно у вас будет самый большой аппарат из возможных. На этом развитие и закончится.
Так можно представить себе монолитную архитектуру, при которой все части приложения объединены в одном коде. Однажды вы достигните предела производительности.
Увеличение количества монолитов
А что, если внедрить множество таких аппаратов и обойти ограничения? И так вы решаете вместо покупки одного большого аппарата, приобрести несколько маленьких.
Это называется клонированием. Вы используете множество экземпляров приложения, чтобы обслуживать запросы пользователей.
Теперь всё отлично, ваше мороженое становится всё более популярным. В конечном итоге, вам всё равно придётся обновить все свои аппараты для мороженого до самых мощных версий.
Исправление ошибок
На первом этапе развития вы нанимаете одного специалиста, который решает все технические проблемы с аппаратом для мороженого. Пока всё идёт гладко. Но когда у вас появится множество аппаратов, вам понадобится больше специалистов, чтобы они успевали исправлять неполадки.
Однажды вы решаете, что было бы неплохо продавать ещё и шоколадное мороженое. Тогда вам необходимо добавить дополнительный отсек. Из-за того, что все части встроены в один аппарат и зависят друг от друга, вашим специалистам придётся постараться, чтобы внедрить новый компонент. Но после того, как работа сделана, оказывается, что аппарат перестал добавлять сироп. Такое может произойти из-за того, что компоненты взаимозависимы. Стукнешь здесь — треснет там.
Микросервис. Для каждой задачи — отдельный аппарат
Поняв ограничения масштабируемости, вы принимаете решение создать новую инфраструктуру. Вы обращаетесь к производителю аппаратов для мороженого с заказом на 4 раздельных компонента, каждый из которых выполняет свою задачу. Теперь вы можете распределить команду специалистов на независимые группы, которые будут обслуживать отдельные компоненты.
Это и есть суть архитектуры микросервисов — одно большое монолитное приложение разделяется на независимые модули. Каждый модуль сам по себе является приложением и решает определённые задачи.
Монолит или Микросервис
- Масштабируемость: как вы уже поняли, самый большой аппарат из возможных является пределом масштабируемости. В случае с микросервисами вы всегда можете добавлять новые компоненты к уже существующей системе.
- Обслуживание: добавление новых компонентов в монолитную архитектуру может привести к поломкам из-за взаимозависимости компонентов. Например, если один модуль приложения требует изменения в схеме базы данных, то оно может привести к ошибкам в других частях приложения. В случае с микросервисами за каждую часть приложения отвечает отдельная команда, что позволяет избежать конфликтов из-за зависимой архитектуры. Независимая архитектура позволяет выпускать новые фичи быстрее, потому что коммуникация внутри команды происходит быстрее, чем между командами, как в больших организациях.
- Стоимость: может показаться, что вопрос масштабируемости решится покупкой нескольких больших аппаратов, но что, если вам нужно увеличить производительность только одного компонента. С монолитной архитектурой вам придётся каждый раз покупать новый аппарат. Благодаря микросервисам вы просто добавляете нужный компонент. Это сократит ваши затраты, поскольку вы сможете масштабировать экземпляры для каждой независимой службы в зависимости от ее нагрузки.
- Время на установку: в монолитной архитектуре все компоненты интегрированы, вам нужно просто, не нарушая этой структуры, начать использование. Из-за того, что микросервисы необходимо подключать в одну систему, вам потребуется больше времени.
- Тестирование и развёртывание: взаимозависимость компонентов монолитной архитектуры создаёт определённые трудности для тестирования и развёртывания системы. С микросервисами всё проще, потому что вы можете сосредоточиться на отдельных компонентах.
Стоит ли сразу начинать с микросервисов
Коротко говоря — нет. Многие эксперты утверждают, что если у вас нет необходимости в такой архитектуре, то лучше этого не делать. Продолжайте использовать монолитную архитектуру, пока не начнутся трудности с обслуживанием и масштабируемостью системы. Когда это произойдёт, разделите сервис на отдельные части.
Микро не всегда означает — маленький
Если вы думаете, что микросервис это некий маленький компонент, то вы ошибаетесь. Микросервис может быть большим сам по себе, или он может иметь несколько клонов, параллельно обслуживающих запросы пользователей. Например, в аппарате может быть 20 отсеков с мороженым, если большинство клиентов предпочитают мороженое без наполнителей.
Также микросервисом может быть отдельное приложение, далеко не маленькое и требующее больших усилий для обслуживания и масштабирования.
Заключение
Некоторые крупные софтверные компании, которые используют архитектуру микросервисов, начинали с монолитных приложений. Столкнувшись с ограничениями, они разделили монолит на отдельные независимые компоненты.
Несомненно, архитектура микросервисов позволяет использовать разные технологии для разных сервисов, а также даёт больше возможностей масштабирования и обслуживания приложений. С другой стороны, это требует привлечения опытных специалистов. Поэтому лучше начать с хорошо структурированной монолитной архитектуры, а затем перейти на микросервисы.