Warum wir aufgehört haben, ein .NET-Shop zu sein

Für den größten Teil unserer Geschichte waren wir ein .NET-Shop. Wir liefern immer noch viel .NET — es ist ein reifes, performantes, tiefgreifend fähiges Ökosystem und das richtige Werkzeug für viele Enterprise-Aufgaben. Aber irgendwo beim dritten Kunden, dessen Problem wirklich Go brauchte und .NET bekam, weil das war, was wir verkauften, hörten wir auf, uns so zu beschreiben.

Der Einzel-Stack-Anreiz

Einzel-Stack-Agenturen haben einen strukturellen Interessenkonflikt mit ihren Kunden. Ihr beratet zur Architektur; ihr werdet aber nur bezahlt, wenn die Architektur den Stack verwendet, den ihr verkauft. Der Rat wird sich verbiegen. Er verbiegt sich stillschweigend, mit vernünftig klingenden Begründungen, aber er verbiegt sich.

Ein Team, das nur .NET macht, wird eine .NET-Antwort auf jedes Problem finden. Dasselbe gilt für ein Team, das nur Node oder nur Python macht. Keines von ihnen liegt absichtlich falsch. Sie liegen durch Anreize falsch.

Was Stack-agnostisch wirklich bedeutet

Es bedeutet nicht, dass wir jeden Stack gleich gut kennen. Das tut niemand. Es bedeutet, dass unsere Senior-Ingenieure Produktionssysteme auf mehreren Stacks geliefert haben und das Urteilsvermögen haben, den richtigen für das Problem zu empfehlen — einschließlich zu empfehlen, uns nicht einzustellen, wenn die richtige Antwort etwas ist, das wir nicht tun.

Der letzte Teil ist der Test. Eine Agentur, die bereit ist zu sagen "das sollte Elixir sein und wir machen kein Elixir", ist ehrlich. Eine Agentur, die einen Weg findet, jedes Problem an ihren Stack anzupassen, verkauft — sie berät nicht.

Wie die Wahl tatsächlich getroffen wird

Die Stack-Auswahl ist hauptsächlich abhängig von vier Dingen, in etwa dieser Reihenfolge:

Das Team, das ihr habt oder einstellen werdet, ist wichtiger als Reinheit. Ein theoretisch besserer Stack, den ihr nicht besetzen könnt, ist schlechter als ein leicht schlechterer Stack, den ihr besetzen könnt. Wir reden zuerst über den Einstellungsmarkt.

Die Compliance- und Daten-Einschränkungen schränken das Feld schnell ein. Finanzdienstleistungs-Workloads auf bestimmten regionalen Clouds kollabieren die Optionen auf zwei oder drei. Healthcare kollabiert sie weiter. Diese Einschränkungen sind nicht verhandelbar; alles andere ist Präferenz.

Die Integrationsoberfläche mit dem, was ihr bereits habt. Die Welt für eine marginal bessere Laufzeit umzuschreiben lohnt sich selten. Wir optimieren für das, was ihr nächstes Quartal liefern könnt, nicht für theoretische Eleganz.

Das Performance-Profil — erst nach den obigen drei. Die meiste Enterprise-Software ist durch I/O, Netzwerk und Datenbankdesign gebunden, nicht durch die Sprachwahl. Go statt Node "für Performance" zu wählen, bevor man weiß, ob der Engpass die Sprache ist, ist in neunzig Prozent der Fälle verfrüht.

Was wir noch sind

Wir sind Senior-Ingenieure, die zufällig sehr vertraut mit .NET, der JVM, Node, Python und Go sind — auf Azure, AWS und GCP. Wir haben Meinungen zu allen und sagen euch, welcher zu eurer Situation passt.

Wir sind nicht mehr ein Shop, der eine einzige Antwort hat.