Esta reflexión de dos partes refleja las conversaciones que he tenido con algunos buenos amigos y ex compañeros de equipo, así como reflexiones sobre algunas de mis propias observaciones en los últimos años mientras me preparo para unirme a una de las pocas empresas emergentes respaldadas por VC del Área de la Bahía. usando .NET en el backend.

Nota al margen: uno de los comentarios que recibí en la primera parte es que el uso de "boomer" solo sirve para perpetuar la discriminación por edad en la industria del software. Si bien soy sensible a esto, lo veo como una mentalidad y no como un rasgo físico. La frase “boomer” se refiere a alguien que tiene un fuerte apego al statu quo, o una sensación de estar atrasado, o incluso preferiría regresar a “los buenos viejos tiempos”. Muy a menudo, es el resultado de trabajar en un entorno, equipo o estilo de gestión en particular, más que un rasgo del individuo.

En la Parte 1, hablé sobre cuánto ha cambiado el panorama de la pila tecnológica desde los días de heno de .NET Framework . En la Parte 2, quiero centrarme en el entorno de desarrollo y las herramientas.

Hay mucho que desempaquetar, pero la clave es que .NET moderno no es una pila solo de Windows y, a menudo, ni siquiera es Windows primero. Gran parte de esto se debe al aumento de la contenedorización y las cargas de trabajo sin servidor en sus diversos modos.

Adaptarse a este cambio significa que los desarrolladores deben estar familiarizados con los sistemas operativos similares a Unix.

Aquí les presento los aprendizajes de un desarrollador boomer .NET, Parte 2:

Parte 1

1. Adopte .NET 6
2. Aprende TypeScript y Python o Go
3. React apesta, pero tienes que aprenderlo
4. Póngase manos a la obra con las modernas herramientas de front-end
5. Envuelva su mente alrededor de los paradigmas de NoSQL

1. código macOS y VS
2. Conocimiento práctico de Linux
3. Póngase cómodo con la línea de comandos (vi, git, npm, yarn y más)
4. Docker, Docker, Docker
5. Sin servidor y en la nube

Antes del comienzo de 2021, yo, como la mayoría de los desarrolladores de .NET, trabajé dentro de los cómodos límites de Visual Studio Professional en Windows y todo estaba bien con el mundo. Pero a principios de 2021, me comprometí a cambiar a VS Code que, poco sabía, me pondría en el camino hacia macOS.

Este no fue un cambio parcial, fue una confirmación completa y firme. De ahora en adelante, escribiría cada línea de código en VS Code.

Parte de ello era que quería ver si era posible. Parte de ello fue que ya estaba haciendo la mayor parte de mi trabajo de front-end Vue SPA en VS Code, que tiene excelentes herramientas para JavaScript, TypeScript y desarrollo de front-end en general.

Me encontré trabajando mucho más íntimamente con la interfaz de línea de comandos y la dotnetCLI. La buena noticia es que la CLI ha recorrido un largo camino y hoy en día es fácil trabajar rápidamente en .NET desde la CLI.

Hubo algunas dificultades iniciales para aprender las peculiaridades de OmniSharp y C# en VS Code. Pero el resultado clave de este período fue que ya no dependía de VS para nada ; Podía hacer casi todo lo que necesitaba desde la línea de comandos y VS Code (su experiencia puede variar).

Atrás quedaron los días de la msbuildinterfaz torpe

No me malinterpreten: uno realmente no puede comparar VS Code con un IDE completamente equipado como Visual Studio, pero la pregunta es cuánto de ese conjunto completo de funciones se usa en el día a día.

Ese desacoplamiento de Visual Studio y Windows fue un salto crítico, ya que la principal plataforma de desarrollo para todas las empresas emergentes con las que entrevisté era macOS, no Windows. No tener que estar sujeto a Visual Studio significaba que ya no estaba sujeto a Windows; Me comprometí totalmente a cambiar a macOS.

He escrito sobre mis experiencias trabajando en el hardware Apple M1 y, si su carga de trabajo lo permite, lo recomiendo absolutamente por el rendimiento, la duración de la batería y el funcionamiento absolutamente silencioso. Aunque prefiero Windows como sistema operativo de uso diario, el hardware de Apple es mucho mejor.

Pero lo que es más importante, me preparó para trabajar con .NET ejecutándose en contenedores de Linux.

(Nota al margen: JetBrains Rider también es un gran IDE si no quiere lidiar con las peculiaridades de OmniSharp)

2. Conocimiento práctico de Linux

La razón por la que esto es fundamental es que la forma en que el mundo implementa y escala el software se ha desplazado considerablemente hacia las cargas de trabajo en contenedores. Para esas cargas de trabajo, Linux es significativamente más económico y rentable que Windows.

Desde una perspectiva de desarrollo, es menos importante pensar en él como un sistema operativo que como un contenedor de tiempo de ejecución liviano y de bajo costo para su aplicación.

Debido a que macOS es en sí mismo un sistema operativo basado en Unix, las secuencias de comandos de shell entre macOS y Linux son más o menos portátiles, lo que hace que sea un poco más fácil trabajar en macOS que trabajar con WSL en Windows.

El simple hecho de crear scripts de shell y trabajar con la línea de comandos en macOS lo preparará para la interacción básica de Linux al configurar y trabajar con contenedores de Linux. De lo contrario, los contenedores .NET Runtime Linux de Microsoft ya están configurados para .NET y, por lo general, requieren un conocimiento mínimo de Linux.

Y eso es todo . En realidad.

3. Póngase cómodo con la línea de comandos (vi, git, npm, yarn, ¡y más!)

Eso nos lleva de vuelta a la línea de comandos y es absolutamente fundamental sentirse cómodo con ella.

Parte de esto es que todas las herramientas para construir interfaces modernas se basan en la línea de comandos. Ya sea que esté usando npmo yarn, terminará siendo bastante íntimo con la línea de comandos.

Parte de esto es que muchos de los mismos comandos usados ​​durante el desarrollo son necesarios para empaquetar e implementar en integración continua, ya sea GitHub Actions o GitLab CI o Azure Pipelines.

Parte de esto es que la forma más productiva de interactuar con los servicios en la nube suele ser a través de la CLI.

Parte de esto es que ocasionalmente tendrá que solucionar un contenedor erróneo y su único modo de interacción es a través de la línea de comandos. Ese contenedor no tiene GUI, por lo que deberá sentirse cómodo con cualquiera de los editores de texto de consola disponibles como vio vim. Si necesita verificar o actualizar un archivo de configuración en el contenedor, necesitará un funcionamiento básico vi(no todas las distribuciones vienen con vim , pero no he encontrado ninguna sin vi ).

En su mayoría, puede arreglárselas sabiendo cómo:

• abrir un archivo
• hacer una edición
• Encontrar y reemplazar
• Guarda el archivo y cierra
• Salir sin guardar

¡Eso es todo! En su mayor parte, la única razón para interactuar con Linux es solucionar problemas y, ocasionalmente, modificar un archivo, por lo que es realmente fundamental sentirse cómodo con algunas herramientas clave de la línea de comandos. Con la maduración de los contenedores sin servidor como un servicio que puede extraer código directamente de GitHub e implementarlo en su nombre, ahora puede implementar cargas de trabajo en contenedores en Linux sin siquiera interactuar con Linux en muchos casos .

4. Docker, Docker, Docker

“Millones de desarrolladores de todo el mundo utilizan Docker para crear, ejecutar y compartir aplicaciones en contenedores. Actualmente, el 55 % de los desarrolladores profesionales utilizan Docker en el trabajo” — TechRepublic

Los cambios recientes en las licencias de Docker han hecho que algunas personas busquen alternativas , pero Docker sigue siendo una de las herramientas más utilizadas y accesibles para trabajar con contenedores.

Entonces quizás el encabezado correcto debería ser “ contenedores, contenedores, contenedores ”, ya que es la realidad actual de implementar aplicaciones en la nube. Incluso las funciones sin servidor no son más que código insertado en contenedores especializados y lanzados en su nombre.

Mi punto de entrada para trabajar con Docker fue en realidad Dapr , con el que comencé a jugar a fines de junio de 2021 mientras lo evaluaba para una aplicación en la que estaba trabajando. El equipo de Dapr publica una aplicación eShopOnDapr de referencia:

Encontré que la aplicación de referencia de eShopOnDapr de muestra estaba demasiado "agitada con la varita" y decidí que quería desglosar cada capa de cómo configurar una aplicación Dapr completa desde cero y terminé escribiendo una serie de publicaciones de blog en el transcurso de un semana (la de GKE llegó mucho más tarde):

1. Funciones de Dapr y Azure: Parte 1 — Hello World
2. Dapr y Azure Functions: Parte 2: Contenedorización de Azure Functions en Docker
3. Funciones de Dapr y Azure: Parte 3: creación de contenedores con Dapr
4. Funciones de Dapr y Azure: Parte 4: implementación a través de Kubernetes
5. Funciones de Dapr y Azure: Parte 5a: implementación en AWS con ECR y EKS Fargate
6. Funciones de Dapr y Azure: Parte 5b : Implementación en Azure con ACR y AKS
7. Funciones de Dapr y Azure: Parte 5c : implementación en Google con GKE

1. Estibador
2. Docker Compose (realmente útil)
3. Kubernetes (menos útil y probablemente un ejemplo atroz de YAGNI para la mayoría de los equipos y casos de uso)
4. Trabajar con los registros de contenedores y las ofertas de Kubernetes en cada uno de los proveedores de la nube

Nota al margen: contenedores != Kubernetes . Le recomiendo encarecidamente que conozca Kubernetes, pero en general evítelo a menos que sea necesario para la arquitectura de su aplicación (por ejemplo, necesita ejecutar un servidor que maneje sockets web). Todos los proveedores de la nube ahora tienen mecanismos para ejecutar cargas de trabajo de contenedores sin la sobrecarga de Kubernetes. Azure Container Apps abstrae la orquestación subyacente y todavía permite una arquitectura sidecar de Dapr .

También te pondrás realmente manos a la obra con las CLI de cada uno de los proveedores de la nube y te familiarizarás con las plataformas (me ha llegado a gustar mucho GCP).

Al final, la conclusión clave para mí es lo increíble que puede ser trabajar con contenedores para empaquetar, enviar y ejecutar aplicaciones. Las ofertas actuales de contenedores sin servidor ( Google Cloud Run , AWS App Runner y Azure Container Apps ) simplifican mucho la implementación de código en la nube y mitigan muchas de las deficiencias y restricciones de trabajar con funciones sin servidor al tiempo que ofrecen muchos de los beneficios como escalado automático y escala a cero.

5. Sin servidor y en la nube

No hay duda ahora de que la nube es el presente y el futuro; es simplemente una cuestión de tiempo y cada desarrollador debe tener experiencia práctica trabajando con la nube.

Personalmente, creo que uno de los mayores cambios en los últimos dos años es el aumento de los contenedores como servicio (a diferencia de Kubernetes como servicio), ya que brinda la capacidad de ejecutar cargas de trabajo sin servidor que escalan a cero. sin tener que hacer mucho más que escuchar las solicitudes entrantes en un puerto conocido. Escriba código en cualquier lenguaje de programación, en cualquier servidor de aplicaciones; siempre que pueda empaquetarlo en un contenedor, ¡puede ejecutarlo sin servidor en la nube!

Implemente su front-end React o Vue como un conjunto de activos estáticos en cualquiera de los servicios de almacenamiento de blobs y ¡bum! ¡Aplicación web instantánea!

La buena noticia es que las tres plataformas ofrecen abundantes créditos para empezar. Pero para ser honesto, incluso ejecutar aplicaciones a tiempo completo en estas plataformas cuesta menos de $ 1 / mes si elige las tecnologías adecuadas con precios basados ​​​​en el consumo. CosmosDB es un gran ejemplo con una oferta sin servidor y un nivel gratuito.

Ejecuto una aplicación Google Cloud Run ( la instancia en vivo de mi repositorio dn6-mongo-react-valtio de muestra ) con un backend MongoDB de nivel gratuito que maneja al menos una solicitud cada 2 horas (reinicio programado) por $ 0.02 / mes.

Después de haber trabajado con los tres proveedores de la nube ahora, creo que Google Cloud es quizás el más fácil de usar y lo recomiendo como punto de entrada (AWS es el más complicado y menos ergonómico, en mi opinión). En particular, Google Cloud Run hace que sea realmente fácil tomar las habilidades existentes con .NET y crear aplicaciones para contenedores sin servidor sin mucho alboroto; literalmente, simplemente agregue una Dockerfilea su API web existente y tendrá una API web sin servidor súper escalable.

Me gusta pensar en esto como El fin del principio :

Avon el caracol y Edward la hormiga están de regreso para otra divertida aventura. Y la aventura, según ha oído, es la clave para una vida feliz. Entonces, con su nuevo amigo Edward, la hormiga, Avon emprende un viaje para encontrar la emoción que le faltaba a su vida.

Para mí, ciertamente ha sido una aventura pasar de .NET Framework e incluso .NET Core a .NET 6, Node, Docker, sin servidor y en la nube.

En verdad, siento que apenas he arañado la superficie con estos dos artículos y ciertamente hay muchos temas que he dejado fuera ( Next.js, Nuxt.js, Nest.js, SSR, SSG, WebAssembly, GitHub Actions y CI/CD en general, dispositivos móviles, Electron, Cypress, Playwright, Jest, WebSockets, gRPC, GraphQL y más ), pero traté de concentrarme en el conjunto central real de aprendizajes de mi propio viaje.

¡Espero que estos dos artículos le hayan brindado una perspectiva y las líneas generales de una hoja de ruta para que pueda comenzar sus propias aventuras y viajes hacia el futuro de .NET y el desarrollo de aplicaciones!

Si le gustaron estos dos artículos, suscríbase para obtener más información sobre .NET, sin servidor e ingeniería de software.