Украинские события опять разделили нашу историю на периоды «До» и «После». IT все сегодняшние пертурбации коснулось нисколько не меньше, чем другие отрасли. И если в тучные годы компании могли себе позволить некоторые послабления, то сейчас проблемы оплаты, разрыв устоявшихся связей, снижение платежеспособности заказчиков и прочие последствия вынуждают их задуматься над оптимизацией расходов на разработку.

Я в компании отвечаю за работу команды разработчиков. Команда небольшая -  всего 6 разрабов, но за последний год с небольшим мы с нуля разработали и внедрили пять проектов. Причем это были не детские проектики, а вполне промышленные проекты, которые сейчас начинают свою работу на металлургическом заводе и интегрированы со сталеплавильными установками. Много это или мало? Чаще всего, от запуска проекта до его внедрения проходит примерно год-два. А тут средняя скорость разработки получается примерно проект за два-три месяца.

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

Наверное многие помнят скандальное заявление Грефа о том, что Сбербанку программисты не нужны: "У нас огромное количество программистов, с которыми мы боремся". Давайте проанализируем откуда такие заявления взялись и чем все это закончилось.

В настоящее время, задача разбивки монолита на микросервисы приобрела поистине огромную популярность в бизнес среде. Как будто все корпорации России вдруг осознали все перспективы “новой” архитектуры, получили при этом пинок от начальства и бросились брать под козырек.

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

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

Disclaimer: Я не имею никакого отношения к JetBrains, не получаю денег от продвижения Kotlin или от написания данной статьи. Весь материал — это лишь отражение моего личного опыта.

Выбор того или иного языка (и вообще любого инструмента) как правило продиктован как объективными, так и субъективными факторами. В каждом проекте могут быть свои особенности, влияющие на выбор. Я далек от того, чтоб устраивать очередной холивар на тему какой язык круче — языков много и у каждого своя ниша. Однако, на мой взгляд выбор между Kotlin и Java более определенный, поскольку Kotlin покрывает все возможности Java и добавляет много дополнительного функционала и сахара.

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

В этой публикации я собираюсь объяснить свою позицию, а заодно опишу некоторые особенности перехода с Java на Kotlin как в условиях стартапа, так и в условиях крупного энтерпрайз-проекта.