Dlaczego przestaliśmy być sklepem .NET

Przez większość naszej historii byliśmy sklepem .NET. Nadal dużo .NET dostarczamy — to dojrzały, wydajny, głęboko zdolny ekosystem i właściwe narzędzie dla wielu zastosowań enterprise. Ale gdzieś przy trzecim kliencie, którego problem naprawdę chciał Go, a dostał .NET, bo to sprzedajemy, przestaliśmy się tak opisywać.

Bodziec jednego stosu

Agencje jednego stosu mają strukturalny konflikt interesów z klientami. Doradzasz w kwestii architektury; dostajesz też wynagrodzenie tylko wtedy, gdy architektura używa stosu, który sprzedajesz. Rada będzie się wyginać. Wygina się cicho, z brzmiącymi rozsądnie uzasadnieniami, ale wygina się.

Zespół robiący tylko .NET znajdzie odpowiedź .NET dla każdego problemu. Tak samo jak zespół robiący tylko Node albo tylko Python. Żaden z nich nie myli się celowo. Mylą się z powodu bodźca.

Co stack-agnostic faktycznie oznacza

Nie oznacza to, że znamy każdy stos równie dobrze. Nikt nie zna. Oznacza to, że nasi senior inżynierowie dostarczyli systemy produkcyjne na wielu stosach i mają osąd, żeby zarekomendować właściwy dla problemu — w tym zarekomendowanie, żebyś nas nie zatrudniał, gdy właściwa odpowiedź to coś, czego nie robimy.

Ta ostatnia część to test. Agencja gotowa powiedzieć „to powinno być Elixir i my nie robimy Elixira" jest uczciwa. Agencja, która znajduje sposób, żeby każdy problem pasował do jej stosu, sprzedaje, a nie doradza.

Jak wybór faktycznie jest dokonywany

Wybór stosu leży w dużej mierze poniżej czterech rzeczy, w mniej więcej tej kolejności:

Zespół, który masz lub zatrudnisz, ma większe znaczenie niż puryzm. Teoretycznie lepszy stos, którego nie możesz obsadzić, jest gorszy niż nieco gorszy, który możesz. Najpierw rozmawiamy o rynku zatrudnienia.

Ograniczenia compliance i danych szybko zawężają pole. Obciążenia usług finansowych na określonych regionalnych chmurach zawężają opcje do dwóch lub trzech. Ochrona zdrowia zawęża je jeszcze bardziej. Te ograniczenia są niezbywalne; wszystko inne to preferencja.

Powierzchnia integracji z tym, co już masz. Przepisywanie świata dla marginalnie lepszego runtime rzadko się opłaca. Optymalizujemy pod to, co możesz dostarczyć w przyszłym kwartale, a nie pod teoretyczną elegancję.

Profil wydajności — dopiero po powyższych trzech. Większość oprogramowania enterprise jest ograniczona przez I/O, sieć i projekt bazy danych, a nie przez wybór języka. Wybieranie Go nad Node „dla wydajności" bez wiedzy, czy bottleneck leży w języku, to w dziewięćdziesięciu procentach przypadków przedwczesna optymalizacja.

Czym nadal jesteśmy

Jesteśmy senior inżynierami, którym bardzo dobrze idzie w .NET, JVM, Node, Python i Go, na Azure, AWS i GCP. Mamy opinie o wszystkich z nich i powiemy Ci, który pasuje do Twojej sytuacji.

Nie jesteśmy już sklepem z jedną odpowiedzią.