Не пишите ваш микросервис как монолит, оставляйте его поддерживаемым и не избыточным.

Вы будете использовать ружьё для того  чтобы застрелить муху? Разумеется нет. Тот же принцип следует использовать когда вы пишете приложение микросервиса, размер которого не будет превышать 10К строк кода. Не делайте код избыточным. Допустим у вас есть большой код который вы поддерживаете. Это может быть 100К+ строк кода, но вам следует изменить вашим привычкам и начать думать по-другому. Эта публикация позволит вам приобщится к магии написания простого кода для микросервисов, который легко поддерживать. Предложения могут оказаться самоуверенными, но на практике это происходит в бизенесе за миллионы доларов.

TL;DR

Микросервисы это маленькие системы. Вы можете легко избавиться от MVC. Скажите нет ORM и пожалуйста не используйте все ваши знания о паттернах проектирования в микросервисах. Сконцентрируйтесь на производительности, читабельности кода и поддерживаемости, чего нет в старых правилах и паттернах. Паттерны были придуманы не для микросервисов.

Зачем писать микросервисы в первую очередь

Архитектура микросервисов, по моему мнению, призвана разбить один или несколько монолитов на множество небольших систем. Они более гибки в поддержке, разрабатываются независимо и в строгом соответствии с со своим предназначением. Эти маленькие системы ( поэтому из и называют «микро») должны фокусироваться только на своей бизнес задаче и делать это хорошо. Ключевым моментом здесь является «микро» - код не должен превышать 10К строк.

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

Теперь давайте посмотрим на то, как вы создавали код раньше и почему в этом теперь мало смысла в эпоху микросервисов.

Вам нужен MVC?

С паттерном Модель-Представление-Контроллер (MVC) я познакомился в 2007 или может чуть раньше. С тех пор я думал что это серебрянная пуля для любой архитектуры программного обеспечения. Но больше я не придерживаюсь такого мнения. Да вы привыкли работать с Java или PHP и там любой фреймворк построен на MVC. Но теперь вам не обязательно думать что иначе не может быть. Сфокусируйтесь на чистоте и том, что бы все работало.

Используйте контроллеры если вы хотите и это уместно в вашем случае. Думайте о задаче в духе: мое приложение получает HTTP запрос и после возвращает HTTP ответ. Не думайте о том, что у вас есть бэкенд с API и фронтенд, который его использует. Посмотрите на этот код, это точно не MVC:

	async function get(params) {
	const today = new Date().toISOString().split('T')[0];
	const {fromCurrency='AUD', toCurrency='USD', onDate=today} = params;
	let exchangeRates = await db.query(
	`SELECT rate, created_at FROM exchange_rates WHERE from_currency = ? AND to_currency = ? AND on_date = ?`,
	[fromCurrency, toCurrency, onDate]
	);
	if (exchangeRates.length) {
	const rate = Number(exchangeRates[0].rate);
	console.log(`Found exchange rate of ${rate} for ${fromCurrency} to ${toCurrency} of ${onDate} in the db`);
	return {fromCurrency, toCurrency, onDate, rate};
	}
	return getExternal(fromCurrency, toCurrency, onDate);
	}
	module.exports = {
	get
	}

Вы можете посмотреть полное приложение здесь, и обратите внимание, это точно не MVC.

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

Не переусердствуйте с ORM

Когда я впервые познакомился с ORM (Object Relation Mapping), я сказал сам себе что это самая крутая штука для программистов которую я видел. Спустя более чем 10 лет, я бы остерегался предлагать использовать ORM для любых случаев. Недавно я занимался рефакторингом и заменял реализацию полной ORM в чистыми вызовами SQL запросов. В результате я получил 20% прироста производительности. В дополнение к этому я начал непосредственно использовать транзакции и сделал код намного чище и понятней.

Маппер данных или Активная запись – каждая из них привностит свои особенности в реализации и тяжеловестноти решения. Это влияет не только на производительность, но также и на читабельность кода. Вот например возмем пре и пост хуки для Doctrine, они как то магически работают, и понять эту магию весьма не просто.

Вот просто попробуйте объяснить молодому специалисту как ORM добавляет данные и как данные добавляются с помощью INSERT SQL. Вы уже пожалели что используете ORM. И особенно в контексте микросервисов ORM выглядит чрезмерной. Микросервисы должны быть не более 10К строк кода, и использовать как максимум с десяток таблиц, поэтому не используйте ORM. Точка.

Паттерны проектирования могут быть обузой

Я ни в коем случае не говорю не изучать паттерны проектирования. Вы должы знать о SOLID, закона Деметры, паттерне фабрики, стратегии, синглтона, адаптера и прочих. Все это полезно если вы имеете дело с объектно –ориентированным программированием, верно? А что если вы пишете микросервис с помощью Node.js когда 1К сток кода разбиты на 7 файлов. Код просто решает некую бизнес задачу. Все эти паттерны для данного случая становятся не более чем полезной ерундой.

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

Выводы

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

Источник: https://hackernoon.com/dont-code-your-microservice-like-a-monolith-keep-it-maintainable-not-over-engineered-19f9d5d70f79

Успешный переход к микросервисам: зачем, когда и как

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

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

Архитектура микросервисов (MSA) – это ответ на проблемы связанные с традиционным монолитом, когд его сложность начинает порождать проблемы но требует дальнейшего масштабирования.

Большие IT компании, такие как Netflix, Amazon и Uber показывают как миграцию к микросервисам влияет на из бизнесс. Нетехнические компании также получают бонусы. Случай Walmart, который восстановил свое online присутствие с помощью микросервисов может послужить примером трансформативного потенциала подобной архитектуры для традиционных предприятий.

Согласно недавним опросам, 80% компаний расчитывают на микросервисы и двигаются в направлении к полностью микросервисовой архитектуре. 9% уже при создании своего  программного обеспечения используют распределенную структуру, 38% совместно используют микросервисы и традиционный монолит, а 33% планируют переключится в ближайшем будущем.

Почему: Роль микросервисов в разработке корпоративных систем

Корпоративные приложения как правило рождаются в виде монолита, например MVC. Это обычная практика выглядит привычной и правильной пока поддержка не так важна и система работает хорошо в небольшом масштабе. Поэтому компаниям нету никакой необходимости что то менять.

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

Преимущества и сложности микросервисов

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

Преимущества:

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

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

 - Гибкость. Если вам необходимо применить или попробовать новую технологию, микросервисы позволят вам добится этого с меньшими трудозатратами.

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

 Недостатки:

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

 - Тестирование. Архитектура монолита использует сторонний WAR. QA специалисту нужно лишь запустить файл и подтвержить соединение монолита и базы данных. В микросервисах необходимо выполнять подобную проверку для каждого микросервиса.

Когда: Правильное время для перехода к архитектуре микросервисов

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

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

Переход к микросервисам нее всегда бывает простым. Но эти затраты окупятся со временем.

Как: Способы перехода к микросервисам

Как интегрировать микросервисы в монолитное приложение? Есть два фундаментальных подхода:

1. Разбить монолит на микросервисы

Это сложый и дорогой вариант. Полная переделка приложения потребует до года изнурительной работы. Такой проект требует талантливых и опытных специалистов поскольку микросервисы – это не простая архитектура и MSA экпертиза сложна сама по себе.

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

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

2. Сохранить монолит и строить микросервисы вокруг него

Поскольку ваша изначальная архитектура работает хорошо, то зачем ее ломать?

Когда ваша команда становиться слишком большая для того что бы поддерживать монолит и добавлять новую функциональность, возможный вариант дальнейшего развития продукта – это микросервисы. Таким образом, новые сотрудники работают как подкоманды, в то время как основные ~25 разработчиков продолжают трудится над монолитом. Монолит становится большим макросервисом, и собирает вокруг себя прочие микросервисы.

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

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

Завершение

Реальные ситуации всегда отличаются от теории, и ситуация с микросервисами не исключение. Корпорации должны учитвать свои собственные нужды, потенциальные угрозы и возможности перед тем как принимать решение по переходу к микросервисам. Этим два подхода создания микросервисов – просто ориентры для руководства по самому процессу. Ваша ситуация всегда уникальна и требует оригинального решения. Однако, изменения неизбежны и вы долны принять это.

Источник: https://dzone.com/articles/successful-migration-to-microservices-why-when-and

Шахматы и программирование: Разрушаем миф, что все программисты - хорошие шахматисты

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

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

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

Может ли игра в шахматы сделать тебя лучшим программистом?

Шахматы помогают достичь феноменального фокусированя

В современной мире легко отвлечься изза наличия множества микрозадач, социальных сетей и чатов с коллегами. Программисту требуется 15–45 минут, чтобы после отвлечения внимания вернуться в режим производительности. Игра в шахматы тренирует тот тип фокусирования, который нужен для игры в матчах, которая может длиться часами и довести ее до конца.

Адаптация к утомительной работе

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

Навыки, необходимые для достижения долгосрочных целей

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

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

Тренировки разума

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

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

Недостатки игры в шахматы

Шахматы могут быть просто потраченным временем. Лучше вместо них сделать упражнения.

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

Недостаток социализации и сильного общества

Помимо работы, есть много мероприятий, которые помогают строить карьеру и сеть. Вы можете отправиться в поход, поиграть в компьютерные игры с коллегами во время перерыва или покататься на велосипеде в парке. Шахматное сообщество слишком мало - его даже меньше, чем во вселенной «Warhammer 40,000».

Первое место уже занято

В 1996 году, чемпион мира по шахматам Гарри Каспаров проиграл игру Deep Blue, компьютеру IBM который способен вычислить 200 миллионов ходов в секунду. Это значит, что чемпион уже был предопределен – человек не может выиграть машину в шахматы, пока в него не вживят какой-нибудь более современных имплант мозга. Вопрос в том, готовы ли вы посвятить годы овладению шахматами, чтобы иметь возможность побороться за второе место?

Невозможно зарабатывать игрой в шахматы.

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

Финальные мысли

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

И самый лучший способ стать программистом – попытаться написать свою программу игры в шахматы.

Источник: https://hackernoon.com/andrii-ryzhenko-chess-and-programming-busting-the-myth-that-all-programmers-are-good-chess-players-5ad6c6b8bb57