Могу ли я найти небольшую компанию на DevOps?

Предположим, я являюсь предпринимателем с небольшими начальными деньгами за мою Великую идею (ТМ), и я начинаю компанию, изначально планировавшую реализовать мою Великую идею (ТМ) самостоятельно, и нанимаю дополнительную помощь на основании, определяемом темпами роста компании.

Часто ответы на этом сайте сосредоточены вокруг идеи, что DevOps - это не роль, а новый способ работы с новой философией работы, которая позволяет команде ролей фактически выполнять DevOps. Это предотвращает выгорание, и люди чувствуют себя одинокими волками

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

DevOps состоит из трех частей: Инструменты / Автоматизация, Организационная и Культурная.

Вы основываете свою организационную структуру и процесс «на зрелости своего бизнеса». Который умный. Мой опыт работы в стартапе и с компанией из списка Fortune 1000 позволил мне отметить, что начинать с DevOps лучше для роста компании. Это эффективно и хорошо сочетается с гибкой.

механическая обработка

Поскольку ваша зрелость действительно молода, вы должны покупать процесс DevOps в качестве продуктов saas, чтобы сократить время выхода на рынок. Вместо Jenkins используйте circleCI или аналогичный продукт. Вместо ВМ и докера используйте Heroku. Попробуйте включить набор инструментов, но сделайте это так, чтобы это соответствовало масштабам вашего бизнеса. Если развертывание кода вручную занимает 4 часа в неделю, а его автоматизация за 1 час - это экономит. Сделай это.

организационный

Также с организационной точки зрения вы, естественно, начнете со всех разработчиков как ответственных сторон за операции / функции и даже разработку продукта. Посмотрите на http://web.devopstopologies.com/ для организационных структур. Наш стартап начался с типа 2, и по мере взросления мы будем двигаться к типу 7.

культурный

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

Короче говоря, да, преследуйте DevOps, но делайте это на уровне, соответствующем зрелости вашего бизнеса.

Один (основание небольшой компании из 1-2 человек и рост по мере поступления денег) не имеет ничего общего с другим (используя философию DevOps).

Даже бизнес с одним человеком может быть основан на DevOps. Вы можете приступить к реализации Великой Идеи (tm) с функционирующим полностью контейнерным конвейером CI / CD, на самом деле нет лучшего времени, чем в начале, когда еще нет необходимости заниматься заботой и до того, как вы достигнете значительного Количество пользователей. Это не собирается занимать месяцы работы; вы можете взломать базовый конвейер Jenkins / Docker за несколько часов (если вы уже много знаете) или, может быть, за несколько дней (но тогда дни будут потрачены на то, чтобы изучить эти вещи по ходу дела).

Начать с CD-части в новом проекте гораздо проще, чем добавить CD в существующее приложение, которое ранее использовалось вручную.

Вы можете начать с полного охвата тестированием с самого начала (по понятным причинам нет лучшего времени), включая инструменты, которые проверяют охват тестированием как часть CI / CD.

Вы можете легко начать с некоторых небольших мер безопасности, таких как проверка вашего набора тестов на наличие лишних открытых портов или что-то еще.

Вы можете и должны сразу начать с крупного рогатого скота, а не домашнего животного (имеется в виду IaC, IaaS, PaaS и все эти хорошие вещи, размещенные у одного из довольно обтекаемых поставщиков услуг «большой тройки»). Начните с малого, масштабируйте необходимое.

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

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

Я обнаружил, что разработка нового предприятия действительно может быть проще, если принять философию и практику DevOps. В конце концов, небольшая (1-2) человек компания не имеет ресурсов (или роскоши), чтобы нанять разработчика, QA, операций и даже обслуживания клиентов.

Таким образом, почти по необходимости ранним игрокам придется охватить несколько ролей, разработка и операции (функции и выпуски) могут быть привязаны непосредственно к бизнесу в стиле «DevOps».

То, что я сделал с моим предыдущим микроагентством, мы в конечном итоге стали 2 полными рабочими днями (я в основном разработчик, мой партнер в основном имеет опыт работы, но мы начали перекрестное опыление, чтобы гибридизировать себя :) и 3-4 постоянных подрядчика, которые будут называться как необходимо. В конце концов мы начали также управлять (управлять) некоторыми проектами для клиентов в дополнение к добавлению функций.

Хотя мы не использовали термин «DevOps» (я не думаю, что я знал, что он существовал в то время), мы были сосредоточены на улучшении функциональности до сроков развертывания и обеспечении максимально безболезненного взаимодействия с клиентом.

Кроме того, модель DevOps может облегчить людям отпуск, поскольку их роль может выполнять кто-то другой!

Я только сейчас начинаю предприятие (предоставление услуг DevOps) для малого бизнеса.

Таким образом, в двух словах, я не только думаю, что это возможно , но я верю, что это ЛУЧШИЙ способ начать!

Удачи!

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