Эффективный выбор и локальный облачный разработчик
Облачные приложения создаются локально, в радикально отличных от того, где они попадают, Средах. Итак, как мы можем использовать эффективные методы, чтобы сделать это предприятие максимально безболезненным? Я хочу обсудить, как мы делаем выбор в целом, и применить это к проблеме.
Проблема
Мы ясно видим, что шаг от локального к облаку больше, чем у любого облака от m до m + 1.
Невероятно важно, чтобы все работало локально. Это основа проекта. Но с точки зрения критериев приемки, контрактов и, в конечном итоге, запуска в эксплуатацию - успех облака - это все, что имеет значение. Итак, это всегда должно быть видное место.
Эффективный выбор в целом
Предполагая любую действительную цель. Затем нам нужно реализовать метод для его получения. Мы создаем метод, используя наши умственные и коммуникативные способности. Затем это становится реальностью с помощью инструментов и процессов.
Инструменты: некоторые материальные технологии.
Процессы: какой-то структурированный подход.
Метод выбора действительно можно использовать для оценки самих целей. Это потому, что цели часто служат для достижения более высоких целей. Но для простоты мы предполагаем, что цель действительная.
Эффективный выбор состоит из трех основных областей:
(1) Решает ли это проблему?
(2), (3) Это Лучшее с учетом контекста?
Лучшее: балансирование переменных, которое может сделать решение сравнительно предпочтительным. Обычно вокруг дополнительных приятных функций или эффективности в каком-то смысле.
например,
цена; качество; представление; простота использования; простота; меньше зависимостей; более поверхностная кривая обучения; повышенная отказоустойчивость; многоразовость; расширяемость и т. д. и т. д.
Контекст: существующие ограничения и перспективы.
например,
Время: решение, подлежащее выполнению через день, будет отличаться от решения, подлежащего выполнению через неделю, и поэтому на.
Бюджет: по понятным причинам.
С точки зрения пользователей: можно ли протестировать решение? Безопасный? обслуживается командой Ops? (DevOps).
Снижение
Учитывая контекст, выбор должен приносить больше пользы, чем создаваемая им сложность. И не должно быть альтернативных вариантов с предпочтительным соотношением "Ценность: Сложность".
Это не значит «избегать сложностей». Многие проблемы по своей сути требуют сложных решений. Но даже в этом случае следует выбрать самый простой кандидат (бритву Оккама).
Это мысленно анализируется с помощью базового анализа затрат и выгод. Сравните компромиссы; Найдите коммунальное предприятие и выберите место с наименьшей альтернативной стоимостью.
Вот почему я называю этот метод «эффективным», а не «оптимальным». Я считаю, что оптимальность предполагает наличие объективно лучшего результата, тогда как этот метод учитывает максимально возможное субъективное суждение, когда компромиссы кажутся примерно равными.
Локальный облачный разработчик
Когда намерение состоит в том, чтобы предоставить какой-либо действующий программный продукт, тогда цель должна состоять в том, чтобы довести функции программного обеспечения до производства как можно быстрее и безопаснее. Таким образом, каждая часть повседневных задач, составляющих проект, должна непосредственно служить этой цели. Для этого нам нужно делать эффективный выбор так же, как и в любой другой части нашей жизни.
Этот пост вдохновлен зарождающимися проблемами, с которыми недавно столкнулась моя команда, стремясь обеспечить, чтобы наша деятельность всегда служила этой цели. Часто на первый взгляд вещи могут выглядеть как разумные меры качества. Но по некоторым соображениям они могут быть довольно расточительными (из-за упущенной выгоды) или даже полностью излишними! Мы хотим заранее отодвинуть такие осознания влево, заранее задумываясь о цели.
Предполагая, что мы создаем микросервисы и уже выбрали эффективный технический стек для создания наших приложений - давайте оценим, какие инструменты мы должны использовать локально в некоторых случаях.
Положительная полезность
(Спасибо Майклу Хунгеру за сообщение о таблицах в Medium: https://medium.com/@mesirii/5-tips-for-embedding-tables-in-your-medium-posts- 8722f3fc5bf5 )
Пружина: стандарт Defacto. Неизбежное использование на местах.
Maven: На самом деле все упрощает.
Параметризация: Значительное сокращение дублирования.
Относительные пути: Неизбежно.
Модульное тестирование: Отличная мера контроля качества.
Отрицательная полезность
Модульное тестирование (100% покрытие): часто низкая отдача и неэффективность. Docker: может быть полезно для тестирования файла докера, а иногда может быть зависимостью. Но обычно добавляет ненужное время и сложность к локальному тестированию.
Дженкинс: Опять же, может быть полезно с точки зрения DevOps. Было бы чрезвычайно сложно с точки зрения тестирования локальной функциональности.
~ «Если у вас есть молоток, все может выглядеть как гвоздь».
Молот Маслоу
Даже отличные инструменты могут быть излишними по сравнению с требованиями или неправильно соответствовать. Интуитивно мы знаем, что Aston Martin - это удивительный инженерный подвиг, но ужасный выбор в качестве обычного такси. Часто неэффективность выбора более тонкая. Независимо от того, скрыты они или очевидны, лучший выбор можно сделать, выполнив этот простой шаг анализа.
Будем надеяться, что, активно осознавая этот фундаментальный вопрос - размышляя о целях и задавая вопросы о том, что мы делаем, - мы сможем достичь некоторых хороших результатов, избежать некоторых плохих и действовать более эффективно.
Спасибо за чтение,
Ник.
Атрибуты
Рисунок 1, Пример конвейера CI микросервиса -
Значок тестирования: сделано https://www.flaticon.com/authors/freepik с сайта www.flaticon. com
Иконка пользователя: сделана https://www.flaticon.com/authors/freepik с www.flaticon.com
Иконка сборки: сделана https: // www. flaticon.com/authors/smashicons с www.flaticon.com
Изменения
№1, [примерно до даты после публикации], исправленная опечатка.
№2, [08.09.2018], исправленная опечатка. Исправление для перечисления среды в статье, чтобы мое «m» было представлено как «N», уже определенное как верхний предел Env на диаграмме. Поблагодарил за материал для создания таблиц, который я использовал. Добавлены «эффективные» и «оптимальные» маржиналии.
# 3, [07.09.2018], добавлен явный раздел о необходимости внесения изменений в производственную среду.
