net·devs
← Всі статті
File insight
2 хв читанняАвтор: Kyrylo Osadchukpositioningengineering

Чому ми перестали бути .NET-магазином

Ми виросли на .NET. Ми все ще багато його відвантажуємо. Але називати себе .NET-магазином означало казати клієнтам неправильне про те, чим ми насправді займаємося.

Більшу частину своєї історії ми були .NET-магазином. Ми досі відвантажуємо багато .NET — це зріла, продуктивна, глибоко спроможна екосистема і правильний інструмент для чималої кількості корпоративної роботи. Але десь на третьому клієнті, чия проблема справді хотіла Go і отримала .NET, бо саме це ми продавали, — ми перестали так себе описувати.

Стимул єдиного стеку

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

Команда, яка займається лише .NET, знайде .NET-відповідь на будь-яку проблему. Так само команда, яка займається лише Node, або лише Python. Жодна з них не помиляється навмисно. Вони помиляються через стимул.

Що насправді означає незалежність від стеку

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

Остання частина — тест. Агентство, готове сказати "це має бути Elixir, а ми Elixir не робимо" — чесне. Агентство, що знаходить спосіб підігнати кожну проблему під свій стек — продає, а не консультує.

Як реально приймається рішення про стек

Вибір стеку здебільшого є downstream від чотирьох речей, приблизно в такому порядку:

Команда, яка у вас є або яку ви найматимете — важливіша за чистоту. Теоретично кращий стек, який ви не можете укомплектувати персоналом, гірший за дещо гірший, який можете. Ми говоримо про ринок найму в першу чергу.

Обмеження відповідності та даних звужують поле швидко. Навантаження фінансових послуг на певних регіональних хмарах звужують варіанти до двох-трьох. Healthcare звужує ще більше. Ці обмеження є непереговорними; все інше — перевага.

Поверхня інтеграції з тим, що у вас вже є. Переписувати все заради дещо кращого рантайму рідко варте того. Ми оптимізуємо під те, що ви можете відвантажити наступного кварталу, а не заради теоретичної елегантності.

Профіль продуктивності — тільки після трьох перших. Більшість корпоративного ПЗ обмежено I/O, мережею та дизайном бази даних, а не вибором мови. Обирати Go замість Node "заради продуктивності" до того, як ви знаєте, чи вузьке місце — мова, у дев'яноста відсотках випадків є передчасним.

Чим ми все ще є

Ми — сеньйор-інженери, яким дуже комфортно з .NET, JVM, Node, Python та Go, на Azure, AWS і GCP. Ми маємо думки щодо кожного з них і скажемо вам, який підходить вашій ситуації.

Ми більше не є магазином з однією відповіддю.

Хочемо почути ваші думки.

наш CTO Кирило Осадчук відповість протягом 24 годин. Без воронки продажів.