Нашият подход да купуваме срещу изграждане

Балансиране на прилягането и усилията, като същевременно поддържате топката подвижна

Ако бяхте помолени да опишете вашата идеална системна архитектура, колко от нея ще бъде извън рафта?

Признавам, че за известно време отговорът ми беше ... много малко.

Преди да ме съдиш, аз съм на трийсет години; Израснах далеч преди интернет, софтуер с отворен код и архитектура, базирана на микросервизи. Софтуерът като цяло беше скъп и обемист ...

... и винаги съм обичал строителни неща.

Защо да се задоволяваме с по-малко от шивашки? - Аргументирах се ...

Но е 2018 г. и няма недостиг на приложения - просто хвърлете втори поглед върху технологичния пейзаж по-долу.

Трудно е да се повярва, че няма нещо, което да тиктака всички кутии, дори когато се обмисля ценообразуване. Също така е вярно, че в днешно време персонализираните решения могат да се изграждат по-бързо и по-ефективно от всякога.

За да закупите или изградите, това е въпросът ...

По наш опит, както купуването, така и изграждането може да предизвика обратна реакция по всяко време. Затова когато се събрахме да изградим архитектурата на Nirovision, поехме ангажимент да прегледаме критично софтуерните решения въз основа на няколко насоки, които сме спазили досега.

Ресурсен прагматизъм

В един урок от всеки мениджърски курс се споменава факта, че ресурсите са ограничени. Нищо ново там.

Но дори и ако някой не е напълно назначен да притежава или поддържа услуга или приложение, това не означава, че той косвено няма да прекара време в работа:

  • Колко време отнема да намерите и отстраните грешка?
  • Колко хора в крайна сметка участват в отстраняване на проблеми?
  • Дали езикът, използван за изграждането му, все още играе добре с останалата част от архитектурата?
  • Колко добре документирано е решението?
  • Колко удобно се чувства екипът около него?
Помощ, ! http://www.monkeyuser.com/2017/technically-not-a-bug/

Само след като разгледате всички тези предупреждения, стигате до разпределеното реално време и усилия. Обикновено рисува мрачна картина.

Ние стигнахме до тази реализация, когато преценявахме как да се справим с автентификацията и оторизацията на потребителите въз основа на предишния ни опит с напълно персонализирано решение. Сигнал за спойлер: най-накрая отидохме с Auth0 - ще оставя подробностите за друга публикация.

Само защото системата не е работа на някого на пълен работен ден, това не означава, че включва малко работа.

Модулност като принцип на проектиране

След като заковаете това упражнение, лесно е логично да стигнете до модулен подход за изграждане. Ако решим, че ни трябват решения, които не се предлагат, ние също трябва да приемем възможността да не изберем правилния инструмент при първия кадър. И дори и да го направим, е възможно да надраснем системи или в по-драстични случаи да променим посоката.

Трябва да можем да въртим бързо, ако искаме да правим иновации.

Позволете ми да представя прекалено рецитирано, но рядко отразено върху цитата на Безос:

Някои решения са последващи и необратими или почти необратими - еднопосочни врати - и тези решения трябва да се вземат методично, внимателно, бавно, с голямо обмисляне и консултация. (...)
Но повечето решения не са такива - те са сменяеми, обратими - те са двупосочни врати. Ако сте взели неоптимално решение от тип 2, не е нужно да живеете с последствията толкова дълго. Можете да отворите отново вратата и да се върнете през нея.
- Джеф Безос

Ако архитектурата е изградена с модулен начин на мислене, всеки компонент трябва да бъде бързо заменяем, което означава, че те стават решения от тип 2.

Да, дори и бази данни - ясно помня външния вид на нашия DevOps Engineer, когато го изразихме.

Да, дори основните системи.

- https://xkcd.com/1801/

Лично за мен това е едно от най-големите ми познания и това, което вярвам, е най-голямото предимство на стартъпите: способността да експериментирам, да се проваля и да се възстановява бързо. Вместо да отделяме много време за преглед на решенията на хартия и да вървим напред-назад, ние ги тестваме. Единственият начин да постигнете това, като запазвате топката, е с модулна, гъвкава архитектура.

Модулността прави повечето архитектурни решения обратими и съответно намалява риска от изпробване.

Една последна мисъл ...

Ние направихме този начин на мислене „Купете срещу изграждане“ част от нашата култура: всеки код, който напишем или закупим, е готов за дебат и актуализация. Ето защо поддържаме твърдението, че приложението Niro винаги се развива.

Имайки достатъчно време и пари, вашите конкуренти могат да дублират почти всичко, което работите за вас. Те могат да наемат някои от най-добрите ви хора. Те могат да обърнат инженеринг на вашите процеси. Единственото нещо, което не могат да дублират, е вашата култура.
- Билка Келехер

Бих искал да чуя за опита на другия екип. Какво открихте, че се възстановявате постоянно? Какво прекъснахте веднага? Какви насоки използвате за вземане на тези решения?