Cómo C# se convirtió en multiplataforma y en una opción real para backend

De raíces en Windows a objetivos multiplataforma

C# nació como un lenguaje muy “nativo de Microsoft”. A comienzos de los 2000 se desarrolló junto al .NET Framework y se diseñó para funcionar bien en Windows: Windows Server, IIS, Active Directory y el ecosistema de herramientas Microsoft. Para muchos equipos, elegir C# no era solo elegir un lenguaje: era optar por un modelo operativo con Windows como primera opción.

Qué significa realmente “multiplataforma”

Cuando la gente dice “multiplataforma” para trabajo backend, suele referirse a algunas cosas prácticas:

• Tu código puede ejecutarse en Windows, Linux y macOS sin reescrituras.
• El runtime y las librerías se comportan de forma consistente en esos sistemas.
• Puedes construir, probar y desplegar usando flujos comunes (CI, contenedores, hosting en la nube) independientemente del SO subyacente.

No se trata solo de “¿puede correr?” sino de si ejecutarlo fuera de Windows es una experiencia de primera clase.

Los hitos que nos trajeron hasta aquí

Esta publicación traza cómo C# pasó de sus raíces en Windows a ser una opción crédible y ampliamente usada en backend en distintos entornos:

• Mono, un primer esfuerzo para ejecutar aplicaciones .NET en sistemas no Windows.
• .NET Core, que repensó el runtime para servidores modernos y Linux.
• .NET unificado (5+), que redujo la fragmentación y facilitó la adopción y el mantenimiento de la plataforma.

Para quién es esto

Si estás evaluando stacks de backend—quizá comparando C# con Node.js, Java, Go o Python—esta guía está pensada para ti. El objetivo es explicar el “por qué” del cambio multiplataforma de C# y qué implica para decisiones reales del lado servidor hoy.

Por qué C# se veía como exclusivo de Windows

C# no nació como un lenguaje "que se ejecuta en cualquier lugar". A principios de los 2000, C# estaba fuertemente asociado con el .NET Framework, y el .NET Framework era, en la práctica, un producto de Windows. Se distribuía con APIs enfocadas a Windows, dependía de componentes de Windows y evolucionó junto al stack de desarrollo de Microsoft.

La era del .NET Framework: Windows por diseño

Para la mayoría de equipos, “desarrollar en C#” implicaba implícitamente “desarrollar para Windows”. El runtime y las librerías se empaquetaban y soportaban principalmente en Windows, y muchas de las funciones más utilizadas estaban profundamente integradas con tecnologías de Windows.

Eso no hacía a C# peor: lo hacía predecible. Sabías exactamente cómo sería tu entorno de producción: Windows Server, actualizaciones soportadas por Microsoft y un conjunto estándar de capacidades del sistema.

Qué solía significar “backend en C#”

Un backend en C# típicamente se veía así:

• ASP.NET en IIS (Internet Information Services)
• Hospedaje en Windows Server en un centro de datos o en la sala de servidores de la empresa
• Integración estrecha con herramientas e infra de Microsoft (Active Directory, autenticación Windows, SQL Server en muchos casos)

Si ejecutabas una aplicación web, lo más probable era que tu runbook de despliegue fuera: “Provisiona una VM Windows Server, instala IIS, despliega el sitio”.

Los trade-offs que formaron la percepción

Esta realidad centrada en Windows generó un conjunto claro de pros y contras.

En lo positivo, los equipos obtenían excelente tooling—especialmente Visual Studio y un conjunto coherente de librerías. Los flujos de trabajo eran cómodos y productivos, y la plataforma se sentía consistente.

En lo negativo, las opciones de hosting eran limitadas. Los servidores Linux dominaban muchos entornos de producción (especialmente en startups y organizaciones sensibles al costo), y el ecosistema de hosting web tendía fuertemente a stacks basados en Linux. Si tu estándar de infraestructura era Linux, adoptar C# a menudo significaba nadar contra corriente—o añadir Windows solo para soportar una parte del sistema.

Por eso C# ganó la etiqueta de “solo Windows”: no porque no pudiera hacer backend, sino porque la ruta mayoritaria hacia producción pasaba por Windows.

Mono: el primer gran paso fuera de Windows

Antes de que “.NET multiplataforma” fuera una prioridad oficial, Mono fue la solución práctica: una implementación independiente y de código abierto que permitía a los desarrolladores ejecutar C# y aplicaciones estilo .NET en Linux y macOS.

Lo que Mono hizo posible

El mayor impacto de Mono fue simple: demostró que C# no tenía que estar atado a servidores Windows.

En el lado servidor, Mono habilitó despliegues tempranos de apps web en C# y servicios en background sobre Linux—frecuentemente para encajar con entornos de hosting existentes o restricciones de coste. También abrió puertas más allá de webs:

• Móvil: Mono sustentó MonoTouch y Mono para Android (caminos tempranos para usar C# en iOS y Android).
• Embebidos y dispositivos: algunos equipos usaron Mono donde un runtime más pequeño y manejable importaba.
• Librerías cross-platform: los desarrolladores pudieron compartir más código entre sistemas operativos que lo habitual en esa época.

Unity: C# se hace masivo fuera de Windows

Si Mono construyó el puente, Unity puso el tráfico. Unity adoptó Mono como su runtime de scripting, lo que introdujo a muchísimos desarrolladores a C# en macOS y en múltiples plataformas objetivo. Aunque esos proyectos no fueran trabajo de backend, normalizaron la idea de que C# podía vivir fuera del ecosistema Windows.

La desventaja honesta: fragmentación y huecos

Mono no era lo mismo que el .NET Framework de Microsoft, y esa diferencia importaba. Las APIs podían variar, la compatibilidad no estaba garantizada y los equipos a veces tenían que ajustar código o evitar ciertas librerías. También había múltiples “sabores” (desktop/server, perfiles móviles, el runtime de Unity), lo que hacía que el ecosistema se sintiera dividido comparado con la experiencia unificada que esperamos del .NET moderno.

Aun así, Mono fue la prueba de concepto que cambió expectativas y preparó el terreno para lo que vino después.

Open source y el giro estratégico hacia Linux

El movimiento de Microsoft hacia Linux y el open source no fue un ejercicio de marca: fue una respuesta a dónde se estaba ejecutando realmente el software backend. A mediados de la década de 2010, el objetivo por defecto para muchos equipos dejó de ser “un servidor Windows en el centro de datos” y pasó a ser Linux en la nube, a menudo empaquetado en contenedores y desplegado automáticamente.

Por qué cambió la estrategia

Tres fuerzas prácticas empujaron el cambio:

• Realidad cloud: Las grandes plataformas cloud hicieron de Linux el denominador común para cargas escalables y coste-eficientes.
• Momentum de contenedores: Docker y Kubernetes normalizaron imágenes basadas en Linux y herramientas operacionales.
• Expectativas de desarrolladores: Los equipos querían pipelines modernos, scriptables y despliegues predecibles entre entornos.

Soportar esos flujos requería que .NET encontrara a los desarrolladores donde estaban—en Linux y en setups cloud-native.

El open source cambió la confianza (y la adopción)

Históricamente, los equipos de backend dudaban en apostar por un stack que se sintiera controlado por un único proveedor con visibilidad limitada. Hacer open source partes clave de .NET abordó eso directamente: la gente podía inspeccionar la implementación, seguir decisiones, proponer cambios y ver discusiones de issues en público.

Esa transparencia importó para uso en producción. Redujo la sensación de “caja negra” y facilitó que empresas estandarizaran en .NET para servicios que debían correr 24/7 en Linux.

GitHub y un modelo de desarrollo más transparente

Mover el desarrollo a GitHub hizo el proceso legible: hojas de ruta, pull requests, notas de diseño y discusiones de releases pasaron a ser públicas. También bajó la barrera para contribuciones de la comunidad y para que mantenedores terceros se alinearan con los cambios de la plataforma.

El resultado: C# y .NET dejaron de sentirse “Windows-first” y empezaron a competir en igualdad con otros stacks de servidor—listos para servidores Linux, contenedores y flujos de despliegue cloud modernos.

.NET Core: una ruptura limpia para backends multiplataforma

.NET Core fue el momento en que Microsoft dejó de intentar “extender” el viejo .NET Framework y, en su lugar, construyó un runtime pensado para el trabajo de servidores modernos desde cero. En lugar de suponer un stack solo para Windows y un modelo de instalación a nivel máquina, .NET Core se rediseñó para ser modular, ligero y más amigable con la forma en que se despliegan servicios backend hoy.

Qué significaba realmente “ejecutar en cualquier lugar”

Con .NET Core, la misma base de código de backend en C# podía ejecutarse en:

• Servidores Windows
• Servidores Linux (un gran cambio para la mayoría de hosting de producción)
• macOS (útil para desarrollo local y algunos escenarios de despliegue)

En la práctica, esto permitió a los equipos estandarizar en C# sin tener que estandarizar en Windows.

Por qué encajó mejor con las necesidades de backend

Los servicios backend se benefician cuando los despliegues son pequeños, predecibles y rápidos de arrancar. .NET Core introdujo un modelo de empaquetado más flexible que facilitó enviar solo lo que la app necesita, reduciendo el tamaño del despliegue y mejorando el comportamiento de cold-start—particularmente relevante para microservicios y setups basados en contenedores.

Otro cambio clave fue alejarse de depender de un runtime compartido del sistema. Las apps pudieron llevar sus propias dependencias (o apuntar a un runtime específico), lo que redujo los problemas de “funciona en mi servidor”.

Instalaciones lado a lado y actualizaciones más sencillas

.NET Core también soportó instalaciones side-by-side de distintas versiones del runtime. Eso importa en organizaciones reales: un servicio puede quedarse en una versión antigua mientras otro actualiza, sin forzar cambios arriesgados a nivel de servidor. El resultado son despliegues más suaves, opciones de rollback más sencillas y menos coordinación de upgrades entre equipos.

ASP.NET Core hizo a C# práctico en cualquier servidor

ASP.NET Core fue el punto de inflexión donde “backend en C#” dejó de significar “se necesita Windows Server”. El ASP.NET clásico estaba fuertemente acoplado a componentes Windows como IIS y System.Web. Funcionaba bien en ese mundo, pero no estaba diseñado para ejecutarse limpiamente en Linux ni dentro de contenedores ligeros.

Cómo difiere ASP.NET Core del ASP.NET clásico

ASP.NET Core es un framework web re-arquitectado con una superficie más pequeña, modular y una pipeline de peticiones moderna. En lugar del modelo pesado y orientado a eventos de System.Web, usa middleware explícito y un modelo de hospedaje claro. Eso hace las apps más fáciles de razonar, probar y desplegar de forma consistente.

Hosting cross-platform: Kestrel + reverse proxies

ASP.NET Core incluye Kestrel, un servidor web rápido y multiplataforma que corre igual en Windows, Linux y macOS. En producción, los equipos suelen poner un reverse proxy delante (como Nginx, Apache o un balanceador de la nube) para terminación TLS, ruteo y temas de borde—mientras Kestrel atiende el tráfico de la aplicación.

Este enfoque de hosting encaja naturalmente con servidores Linux y orquestación de contenedores, sin configuraciones “solo para Windows”.

Patrones backend comunes que habilita

Con ASP.NET Core, los equipos en C# pueden implementar estilos de backend modernos:

• APIs REST para clientes web y móviles
• gRPC para comunicación eficiente entre servicios
• Workers en background para colas, tareas programadas y procesos de larga duración

Experiencia de desarrollo que acelera a los equipos

De serie obtienes plantillas de proyecto, inyección de dependencias integrada y una pipeline de middleware que fomenta un buen layering (auth, logging, routing, validación). El resultado es un framework de backend moderno que se despliega en cualquier lugar sin requerir una infraestructura con forma de Windows.

.NET unificado: una plataforma en lugar de muchas

Durante un tiempo, “.NET” significó un árbol confuso: .NET Framework clásico (mayormente Windows), .NET Core (multiplataforma) y las herramientas Xamarin/Mono para móvil. Esa fragmentación dificultaba responder preguntas simples como “¿sobre qué runtime deberíamos estandarizar?”

De .NET Core a “un solo .NET”

El gran cambio ocurrió cuando Microsoft pasó de la marca separada “.NET Core” a una línea unificada empezando con .NET 5 y continuando con .NET 6, 7, 8 y siguientes. El objetivo no fue solo renombrar: fue consolidar: un conjunto de fundamentos del runtime, una dirección única para la base de clases y una ruta de actualización más clara para apps servidor.

Qué significa “unificado” para los equipos

En términos prácticos de backend, .NET unificado reduce la fatiga de decisión:

• Menos plataformas competidoras que evaluar para APIs y servicios
• Plantillas y tooling más consistentes entre Windows, Linux y macOS
• Expectativa más clara de que tu código puede moverse entre máquinas de dev, CI y producción sin rework específico por plataforma

Aún puedes usar cargas de trabajo distintas (web, worker services, contenedores), pero no estarás apostando por “tipos” diferentes de .NET para cada caso.

Releases LTS y por qué importan

.NET unificado también facilitó la planificación de releases mediante versiones LTS (Long-Term Support). Para backends, LTS importa porque normalmente quieres actualizaciones previsibles, ventanas de soporte más largas y menos upgrades forzados—especialmente para APIs que deben mantenerse estables durante años.

Elegir una versión objetivo

Un valor por defecto seguro es apuntar a la última LTS para servicios nuevos en producción y planear las actualizaciones deliberadamente. Si necesitas una característica nueva o una mejora de rendimiento, considera la release más reciente, pero alinea esa elección con la tolerancia de tu organización a upgrades más frecuentes.

Rendimiento y escalabilidad: qué cambió con el tiempo

C# no se convirtió en una opción seria de backend solo porque corriese en Linux: también mejoró la eficiencia con que usa CPU y memoria en cargas reales de servidor. Con el tiempo, el runtime y las librerías han pasado de “suficientes” a “predecibles y rápidos” para patrones web y de API comunes.

Ejecución más rápida del runtime (JIT y más)

El .NET moderno usa un compilador JIT mucho más capaz que los runtimes de las primeras épocas. Características como la compilación por niveles (arranque rápido seguido de optimización en caminos calientes) y optimizaciones guiadas por perfil en releases más nuevos ayudan a que los servicios alcancen mayor throughput una vez que el tráfico se estabiliza.

Para equipos backend, el resultado práctico suele ser menos picos de CPU bajo carga y manejo de requests más consistente—sin reescribir la lógica de negocio en un lenguaje de bajo nivel.

Gestión de memoria más inteligente (GC, latencia y throughput)

La recolección de basura también evolucionó. Modos de GC para servidor, GC en background y mejor manejo de grandes asignaciones buscan reducir pausas largas y mejorar el throughput sostenido.

Por qué importa: el comportamiento del GC afecta la latencia de cola (esas requests ocasionalmente lentas que notan los usuarios) y el coste de infra (cuántas instancias necesitas para cumplir un SLO). Un runtime que evita pausas frecuentes puede ofrecer tiempos de respuesta más suaves, especialmente en APIs con tráfico variable.

Async/await: buena afinidad para backends I/O-heavy

El modelo async/await de C# es una gran ventaja para trabajo backend típico: peticiones web, llamadas a bases de datos, colas y I/O de red. Al no bloquear hilos mientras espera I/O, los servicios pueden manejar más concurrencia con el mismo pool de hilos.

El trade-off es que el código async requiere disciplina—un uso inadecuado puede añadir overhead o complejidad—pero aplicado en caminos I/O-bound normalmente mejora la escalabilidad y mantiene la latencia más estable bajo carga.

Cloud, contenedores y flujos de despliegue modernos

C# se volvió una opción de backend más natural una vez que despliegue dejó de significar "instalar IIS en una VM Windows". Las apps .NET modernas se empaquetan, envían y ejecutan igual que otras cargas de servidor: como procesos Linux, a menudo dentro de contenedores, con configuración predecible y ganchos operacionales estándar.

Amigable con contenedores por defecto

ASP.NET Core y el runtime moderno funcionan bien en Docker porque no dependen de instalaciones a nivel máquina. Construyes una imagen que incluye exactamente lo que la app necesita y luego la ejecutas en cualquier sitio.

Un patrón común es un multi-stage build que mantiene la imagen final pequeña:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApi.dll"]

Imágenes más pequeñas se descargan más rápido, arrancan antes y reducen la superficie de ataque—ganancias prácticas cuando escalas.

Hosting “Linux-first” como norma

La mayoría de plataformas cloud corren sobre Linux por defecto, y .NET encaja cómodamente allí: Azure App Service para Linux, AWS ECS/Fargate, Google Cloud Run y muchos servicios gestionados de contenedores.

Esto importa por coste y consistencia: la misma imagen basada en Linux puede ejecutarse en el portátil del desarrollador, en la pipeline de CI y en producción.

Kubernetes (sin el dolor de cabeza)

Kubernetes es un objetivo común cuando los equipos quieren autoscaling y operaciones estandarizadas. No necesitas código específico para Kubernetes; necesitas convenciones.

Usa variables de entorno para la configuración (connection strings, feature flags), expón un endpoint de salud simple (para readiness/liveness) y escribe logs estructurados a stdout/stderr para que la plataforma los recopile.

Si sigues esas bases, los servicios en C# se despliegan y operan como cualquier otro backend moderno—portables entre nubes y fáciles de automatizar.

Tooling y ecosistema: por qué los equipos avanzan más rápido

Una gran razón por la que C# se volvió una opción práctica de backend en Windows, Linux y macOS no es solo el runtime: es la experiencia diaria del desarrollador. Cuando las herramientas son coherentes y automáticas, los equipos pasan menos tiempo peleando con el entorno y más tiempo entregando valor.

Un flujo único en todas las máquinas con la CLI dotnet

La CLI dotnet hizo tareas comunes predecibles en cualquier SO: crear proyectos, restaurar dependencias, ejecutar tests, publicar builds y generar artefactos listos para despliegue con los mismos comandos.

Esa consistencia importa para onboarding y CI/CD. Un desarrollador nuevo puede clonar el repo y ejecutar los mismos scripts que usa el servidor de build—sin setups “solo Windows”.

Editores e IDEs para distintos equipos

El desarrollo en C# ya no está atado a una sola herramienta:

• VS Code funciona bien para edición ligera, desarrollo con contenedores y debugging rápido.
• Visual Studio sigue siendo la opción “todo en uno” que muchos equipos prefieren, especialmente para soluciones grandes.
• Rider es popular en macOS y Linux por su refactorización y navegación rápida.

La ventaja es la elección: los equipos pueden estandarizar en un entorno o dejar que los devs usen lo que les resulte cómodo sin fragmentar el build.

Debugging cross-platform y desarrollo local

El tooling moderno de .NET soporta debugging local en macOS y Linux de forma natural: ejecuta la API, conecta un debugger, pon breakpoints, inspecciona variables y avanza por el código. Eso elimina un embudo clásico donde el “debug real” solo ocurría en Windows.

La paridad local mejora además cuando ejecutas servicios en contenedores: puedes debuggear tu backend en C# mientras habla con las mismas versiones de Postgres/Redis/etc. que usa producción.

Dependencias, actualizaciones y el ecosistema NuGet

NuGet sigue siendo uno de los mayores aceleradores para equipos .NET. Es sencillo añadir librerías, fijar versiones y actualizar dependencias como parte del mantenimiento regular.

Igualmente importante, la gestión de dependencias funciona bien en automatización: restaurar paquetes y ejecutar chequeos de vulnerabilidades puede ser parte de cada build.

Librerías y plantillas comunitarias (con expectativas realistas)

El ecosistema ha crecido más allá de paquetes mantenidos por Microsoft. Hay opciones comunitarias sólidas para necesidades comunes de backend—logging, configuración, jobs en background, documentación de APIs, testing y más.

Las plantillas y proyectos iniciales aceleran la puesta en marcha, pero no son mágicas. Las mejores ahorran tiempo en el plumbing sin impedir que tu equipo mantenga decisiones de arquitectura explícitas y mantenibles.

Cuándo C# es una elección fuerte (y cuándo no lo es)

C# ya no es una "apuesta por Windows". Para muchos proyectos backend es una elección pragmática que combina buen rendimiento, librerías maduras y una experiencia de desarrollo productiva. Aun así, hay casos donde no es la herramienta más simple.

Casos en los que C# destaca

C# suele brillar cuando construyes sistemas que necesitan estructura clara, mantenimiento a largo plazo y una plataforma bien soportada.

• APIs y backends web: servicios REST/JSON, gateways GraphQL y BFFs son un buen encaje para ASP.NET Core.
• Sistemas empresariales: reglas de negocio complejas, integraciones y arquitecturas en capas se benefician del tipado y tooling de C#.
• Fintech y dominios regulados: comportamiento predecible, buenos patrones de testing y ecosistema para necesidades de seguridad y cumplimiento.
• Servicios de alto throughput: el rendimiento del .NET moderno lo hace competitivo para APIs concurridas, procesamiento en background y cargas orientadas a eventos.

Cuando puede ser menos ideal

C# puede ser “demasiado” cuando el objetivo es máxima simplicidad o un footprint operativo muy pequeño.

• Scripts serverless ultra-pequeños: si escribes funciones mínimas donde cold-start y tamaño del paquete dominan, runtimes más ligeros pueden ser más sencillos.
• Restricciones de hosting muy específicas: si tu entorno favorece fuertemente otro runtime o tiene soporte limitado para despliegues .NET, lucharás contra la plataforma.
• Equipos que buscan estructura mínima: para prototipos descartables, opciones dinámicas pueden sentirse más rápidas (a costa de mantenibilidad futura).

Factores de equipo y longevidad

Elegir C# suele ser tanto sobre personas como sobre tecnología: habilidades .NET existentes, mercado local de contratación y si esperas que la base de código viva durante años. Para productos de larga vida, la consistencia del ecosistema .NET es una ventaja considerable.

Una forma práctica de reducir riesgo es prototipar el mismo servicio en dos stacks y comparar velocidad de desarrollo, fricción de despliegue y claridad operacional. Por ejemplo, algunos equipos usan Koder.ai para generar rápidamente una base productiva (frontend React, backend Go, PostgreSQL, móvil opcional en Flutter), exportan el código y luego comparan ese flujo con una implementación equivalente en ASP.NET Core. Incluso si al final eliges .NET, disponer de una build de comparación rápida hace los trade-offs más concretos.

Lista de verificación rápida para evaluar

• ¿Necesitamos una base de código mantenible con contratos claros y buen tooling?
• ¿El despliegue en Linux/contenedores forma parte del plan?
• ¿Son importantes rendimiento y fiabilidad a escala?
• ¿Ya tenemos skills .NET o podemos contratarlos con confianza?
• ¿Este servicio se integrará fuertemente con otros sistemas empresariales?
• ¿Estamos construyendo algo “pequeño y descartable" (donde un runtime ligero podría ganar)?

Conclusiones clave y próximos pasos

C# no llegó a ser una historia multiplataforma creíble de la noche a la mañana: lo logró mediante una serie de hitos concretos que eliminaron las suposiciones de “solo Windows” y normalizaron el despliegue en Linux.

Hitos a recordar

El cambio ocurrió por etapas:

• Mono demostró el concepto: mostró que C# y .NET podían correr más allá de Windows y ayudó a generar confianza temprana en servidores.
• Microsoft abrazó el open source: al abrir partes importantes de .NET y participar públicamente, lo multiplataforma dejó de ser un proyecto secundario.
• .NET Core entregó un runtime moderno: diseñado para escenarios de servidor Linux-first, convirtió lo multiplataforma en algo práctico.
• ASP.NET Core modernizó el stack web: más rápido y modular, corre igual en Windows, Linux y macOS—ideal para servicios API-first.
• .NET unificado (5+) simplificó todo: menos dudas sobre “qué .NET” y una vía más clara para upgrades, tooling y soporte a largo plazo.

Próximos pasos prácticos que puedes dar

Si evalúas C# para backend, la ruta más directa es:

1. Comenzar con ASP.NET Core para APIs y servicios (los proyectos nuevos deberían apuntar a versiones modernas de .NET).
2. Desplegar en Linux desde temprano—incluso en staging—para validar comportamiento del runtime, logging y dependencias del sistema desde el primer día.
3. Usar contenedores cuando ayude: empaquetar un servicio ASP.NET Core en un contenedor puede facilitar la paridad dev/prod y reducir problemas de “funciona en mi máquina”.

Si vienes de apps antiguas en .NET Framework, trata la modernización como un esfuerzo por fases: aisla nuevos servicios detrás de APIs, actualiza librerías incrementalmente y migra cargas a .NET moderno cuando tenga sentido.

Si quieres avanzar más rápido en iteraciones tempranas, herramientas como Koder.ai pueden ayudarte a poner en marcha una app funcional vía chat (incluyendo backend + base de datos + despliegue), hacer snapshot y rollback de cambios, y exportar el código cuando estés listo para integrarlo en tu flujo de ingeniería estándar.

Lecturas sugeridas

Para más guías y ejemplos prácticos, consulta /blog. Si comparas opciones de hosting o soporte para despliegues en producción, mira /pricing.

Conclusión: C# ya no es una opción de nicho o atada a Windows—es una alternativa mainstream para backend que encaja con servidores Linux modernos, contenedores y flujos de despliegue en la nube.