Чи можу я знайти маленьку компанію на DevOps?

Припустимо, я є підприємцем з невеликими грошовими коштами для своєї великої ідеї (TM), і я запускаю компанію, яка спочатку планує самостійно реалізувати свою Велику ідею (TM) і наймаю додаткову допомогу на основі диктування темпів зростання компанії.

Часто відповіді на цьому веб-сайті зосереджуються на думці, що DevOps - це не роль, а новий спосіб роботи з новою філософією роботи, яка дозволяє команді ролей насправді робити DevOps. Це запобігає вигорянню і люди не відчувають себе вовком-одиноким

Як компанія, що розвивається та починає працювати, чи варто мені навіть намагатися переслідувати DevOps як філософію, чи це підходить лише для більш зрілої операції, здатної мати достатньою величиною команду розвитку?

DevOps складається з трьох частин: Інструментальний / автоматичний, Організаційний та Культурний.

Ви базуєте свою організаційну структуру та процес "на основі зрілості вашого бізнесу". Який розумний. Мій досвід роботи зі стартапом і з компанією Fortune 1000 дозволив мені зазначити, що починати з DevOps краще для зростання компанії. Це ефективно і добре поєднується з спритним.

Інструментальне обладнання

Оскільки ваша зрілість дуже молода, вам слід купувати процес DevOps як Saas продукти, щоб скоротити час на ринок. Замість Дженкінса використовуйте circleCI або подібний продукт. Замість VM та докера використовуйте Heroku. Спробуйте ввімкнути набір інструментів, але робіть це таким чином, що відповідає розміру вашого бізнесу. Якщо розгортання коду вручну займає 4 години на тиждень, а автоматизація його за 1 годину заощаджує це. Зроби це.

Організаційні

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

Культурні

DevOps - це просто командна робота. Працюйте разом, і все стає простіше. Зазвичай це проблема, оскільки керівництво цього не має на увазі, так як ви починаєте, переконайтесь, що всі є окремо від бізнесу. Це також відбивається на спритному.

Отже, коротше, так, слідкуйте за DevOps, але робіть це на рівні, який відповідає зрілості вашого бізнесу.

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

Навіть бізнес на 1 людину може бути заснований на DevOps. Ви можете почати реалізовувати свою Велику ідею (tm) за допомогою функціонуючого повністю контейнерного конвеєра CI / CD, адже насправді немає кращого часу, ніж на початку, коли немає жодної сукупності, про яку слід подбати, та ще до того, як ви потрапите на значне кількість користувачів. Місяці роботи це не займе; ви можете зламати основний трубопровід Дженкінса / Докера за кілька годин (якщо ви вже багато чого знаєте) або, можливо, днів (але тоді дні будуть продуктивно витрачені на вивчення цих речей, як ви йдете).

Почати з CD частини в проекті Greenfield набагато простіше, ніж додати компакт-диск до існуючої програми, яка раніше використовувала ручні розгортання.

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

Ви можете легко почати з деяких невеликих заходів безпеки, наприклад, перевірити свій тестовий набір на зайві відкриті порти чи що завгодно.

Ви можете, і потрібно починати з худоби, яка не є домашньою твариною (мається на увазі IaC, IaaS, PaaS та всі ті добрі речі, розміщені на одному з досить впорядкованих "великих трьох" постачальників). Почніть з малого, необхідного масштабу.

Коли ви додасте більше personel, вони почнуть діяти прямо у цій плідній атмосфері, і, сподіваємось, багато їх дешевших помилок негайно потраплять на CI / CD.

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

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

Тому майже за необхідності раннім гравцям доведеться охоплювати декілька ролей, розробку та операції (функції та випуски) можна перенести безпосередньо на бізнес "DevOps".

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

Хоча ми не використовували термін "DevOps" (я не думаю, що я знав, що він існував у той час), ми були зосереджені на вдосконаленні функцій до часових рамків розгортання та зробивши клієнтський досвід максимально безболісним.

Крім того, модель DevOps може полегшити людям дозвілля, оскільки їхню роль може охопити хтось інший!

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

Таким чином, не тільки я думаю, що це можливо , але я вважаю, що це найкращий спосіб почати!

Щасти!

Так, тому що ви можете використовувати просунуту автоматику для створення цінності та створення підстав для багаторазового використання майбутньої більшої компанії. Звичайно, залежить від того, як часто ви збираєтесь оновлювати свої цифрові продукти. Але ви будете цінувати можливість стільки ручної роботи, скільки потрібно на повторюваних вправах.