Post Top Ad

Your Ad Spot

martes, 5 de mayo de 2020

El desarrollador moderno, parte 5: aprovisionamiento, implementación y mantenimiento

En la publicación de hoy, analizaremos las etapas de un producto de software posterior a la etapa de garantía de calidad (QA), específicamente el aprovisionamiento, la implementación y el mantenimiento.
Esta es la publicación final de la serie, un gran agradecimiento a todos los que se han quedado conmigo durante los últimos meses. Espero que hayas disfrutado el viaje.
Cuando comencé en el desarrollo de software, pensé que una vez que se lanzó el software, el trabajo estaba hecho. Chico, oh chico, estaba equivocado. A menudo, es solo el comienzo.
Antes de lanzar algo, debe asegurarse de tener la infraestructura necesaria para hacerlo. Aquí es donde entra en juego el aprovisionamiento.

Aprovisionamiento: obtención de infraestructura y licencias

A pesar de estar en la publicación final, el aprovisionamiento se puede realizar en cualquier momento después del diseño. En pocas palabras, el aprovisionamiento es obtener toda la infraestructura y las licencias que necesitará al lanzar algo a producción.
Las dos opciones principales para el aprovisionamiento son poseer o alquilar.
¿Cuál deberías elegir?
Algunos proyectos requieren que tengas tu propia infraestructura. El almacenamiento en la nube y el software bancario son ejemplos clave. Por lo general, este tipo de requisito está dictado por diferentes legislaciones en el dominio específico. La legislación difiere según el país, por lo que es algo en lo que quiere comenzar. Otro ejemplo de una situación en la que necesitará ser dueño de su infraestructura es para contratos gubernamentales.
Puede obtener un acuerdo especial con algunos proveedores sobre la seguridad de los datos, pero la regla general es que si no posee la infraestructura, no tiene el control completo. No todo es malo: hay beneficios, como veremos más adelante.
¿Qué sucede si no tiene restricciones de seguridad u obligaciones contractuales para ser propietario de su infraestructura? ¿Aún deberías tenerlo?
Lo primero a considerar es el costo. Ser propietario de un servidor cuesta miles de dólares, y tener la infraestructura necesaria en términos de gestión del calor, electricidad, internet, etc., también es muy costoso. Aunque puede colocar su servidor en un centro de datos, su mantenimiento cuesta mucho dinero cada mes.
Por el contrario, la infraestructura alquilada (por ejemplo, DigitalOcean, Amazon, Google Cloud, etc.) factura por minuto. Además, suelen ofrecer herramientas para gestionar mejor todo. Puede iniciar, detener, clonar, destruir o crear máquinas con unos pocos clics, y aparecen casi al instante.
Esta es una solución mucho más flexible. Si desea esta flexibilidad para la infraestructura de su propiedad, necesitará uno o más administradores de sistemas, y la velocidad probablemente faltará en comparación.
Otra ventaja de la infraestructura alquilada es que puede reemplazar muchos de los servicios que está utilizando con soluciones prefabricadas. Por ejemplo, en lugar de configurar su propio servidor de base de datos, puede usar una base de datos como servicio. En lugar de alojar su código, puede usar funciones en la nube, etc.
Por otro lado, una ventaja para el hardware propio es que tiene un control completo sobre todo. ¿Necesita una combinación RAID específica? ¡Por supuesto! ¿Necesita tener un almacenamiento conectado a la red específico para satisfacer las necesidades de esta aplicación específica? No hay problema. El rendimiento potencial no puede ser igualado por ningún hardware alquilado. El control del hardware que construye su servidor no tiene paralelo.
La ventaja clave de la infraestructura de propiedad es que tiene un control completo del hardware y las máquinas virtuales. Puede cambiarlo y modificarlo como desee. Esto puede ofrecer importantes beneficios de rendimiento que no puede obtener del hardware alquilado. La desventaja clave es que el costo es alto y es posible que necesite personas adicionales para monitorearlo y mantenerlo.
La ventaja clave de la infraestructura alquilada es que todo se automatiza y factura por minutos. Los costos iniciales son muy bajos y puede escalar según lo necesite. Muchos proveedores ofrecen copias de seguridad automatizadas y recuperación ante desastres. La desventaja clave es que no tienes un control completo. Aunque esto no debería ser un problema para la mayoría de los proyectos, puede ser un factor decisivo para algunos.
En mi trabajo, he tratado con ambos tipos de aprovisionamiento. Personalmente, uso infraestructura alquilada para mis proyectos personales, ya que puedo crear y destruir infraestructura cuando la necesite.
Si tuviera que elegir uno, elegiría la infraestructura alquilada para proyectos de computación pesada con carga inconsistente. De esa manera, puedo hacer que la aplicación agregue más servidores cuando la carga es alta y los destruya cuando no sean necesarios. Para proyectos de alta inversión y mucho almacenamiento, elegiría hardware propio, ya que los pequeños cambios de configuración y configuración pueden tener un gran efecto en el rendimiento y el rendimiento de un sistema.
Además del hardware, esto es lo que debe considerar al aprovisionar la infraestructura:
  • ¿Se compran todos los dominios y tiene certificados https para todos ellos?
  • ¿Ha configurado la red interna entre sus servidores? ¿Está asegurado?
  • ¿Has comprado licencias que se adaptan a tus necesidades? (Por lo general, la licencia de los servicios durante el desarrollo es barata pero requiere una actualización para la producción).
El aprovisionamiento es clave para el éxito de un proyecto. Se puede hacer en paralelo con el desarrollo. A medida que cambien los requisitos de software, también lo harán los requisitos de aprovisionamiento. Al igual que en el software, es importante construir cosas con la mentalidad de que puedan cambiar.

Implementación: Obtenga el código, las bibliotecas y los servicios en línea

despliegueAnalicemos el producto de software típico:
  • Código fuente
  • Bibliotecas y marcos de terceros (archivos estáticos, binarios)
  • Servicios de terceros (procesos vivos)
Un despliegue puede ser cualquier combinación de los tres. La segunda y la tercera viñetas pueden tener subcategorías:
  • Agregar o eliminar una dependencia
  • Actualiza su versión
  • Cambiar la configuración
Cada escenario requerirá pasos ligeramente diferentes para la ejecución. Es primordial saber exactamente qué se debe hacer para que los cambios surtan efecto de inmediato; de lo contrario, puede encontrarse ejecutando una compilación rota.
En teoría, la implementación debería ser una de las cosas más fáciles, ya que se trata de mover el código fuente y reiniciar los servicios, pero en la práctica es difícil. Muy duro.
La razón principal es la cultura del desarrollo . Aunque ahora tenemos soluciones automatizadas, y la implementación se considera una prioridad de primera clase, este no siempre fue el caso.
Hasta el día de hoy, muchas empresas realizan implementaciones manuales o utilizan soluciones personalizadas de elaboración casera.
Pero, ¿por qué es esto ineficaz? ¿Qué tienen de malo las implementaciones manuales y las soluciones personalizadas?
Consideremos las consecuencias de un mal despliegue.
Puede tener tiempo de inactividad y perder dinero debido a eso. Peor aún, actualiza la mitad de sus servidores y tiene dos versiones en ejecución del mismo software, lo que puede generar errores realmente desagradables que a veces son imposibles de depurar. O puede perder todos sus datos y verse obligado a restaurar desde una copia de seguridad.
Hay muchas más razones por las que podría enumerar, pero conducen a la misma conclusión: los problemas durante la implementación deben evitarse a toda costa, ya que dañarán a los usuarios finales, lo que, a su vez, perjudicará a la organización.
El trabajo manual es propenso a errores. No solo eso, sino que tener que implementar la nueva versión del software en 50 o 100 máquinas llevará mucho más tiempo si se hace manualmente que si fuera automatizado. La posibilidad de error también es mucho menor cuando un programa ejecuta la implementación.
Las soluciones Homebrew son increíbles, ya que se adaptan a las necesidades del software específico. Mi principal problema con ellos es que, por lo general, no se prueban exhaustivamente y no son compatibles.
Los cambios se realizan cuando son necesarios porque la implementación no funcionará o hay un nuevo servicio que debe agregarse. Esto significa que nadie estará 100% seguro del código y puede introducir más errores al agregar la nueva característica pequeña. Sé que en un mundo perfecto, investigarías el código antes de editarlo, pero en realidad, este rara vez es el caso.
La última opción es usar una solución estandarizada . Una de las mejores opciones disponibles actualmente es Ansible. En Ansible, describe sus servidores, luego les agrega algunos metadatos y a qué grupos pertenecen los servidores, y finalmente ejecuta tareas en estos grupos / roles.
Las tareas en sí se dividen en dos categorías: por un lado, tenemos tareas estandarizadas como reiniciar un servicio, extraer código de un repositorio, instalar un paquete, crear y editar un archivo y rotar registros, y por otro lado tenemos tareas personalizadas, por ejemplo, cuando desea ejecutar un script de limpieza.
Eso es prácticamente todo lo que necesitará para la mayoría de las implementaciones. Tener el procedimiento de implementación en un script lo hace reproducible, rastreable, registrable y monitoreable, todo lo que desea incorporar eventualmente a su software para garantizar el máximo tiempo de actividad.
Como no está desarrollando la solución, la mayor parte del trabajo de mantenimiento de este software se realizará por usted. Además, la base de usuarios del producto que está utilizando a veces será de cientos de miles de usuarios, por lo que la mayoría de los errores se solucionarán durante las pruebas y tendrá una implementación general mucho más estable en comparación con una solución casera.

Mantenimiento: corrección de errores, parches de seguridad y pruebas futuras

El proyecto finalmente se lanzó. Los usuarios finales están satisfechos. Cada vez que aparece un error, se soluciona y la solución se implementa en unos pocos días. Incluso si no hay solicitudes de cambio para un mayor desarrollo, hay varias cosas que deben ser monitoreadas y mantenidas.
Lo primero es el hardware en sí mismo: sin él no tendrá un sistema en funcionamiento. Esto no requiere trabajo constante; más bien, cuando algo se rompe, debe arreglarse rápidamente.
Luego, debemos asegurarnos de que a medida que el sistema crezca, pueda sostener su crecimiento. Esto significa que se deben agregar bases de datos y servidores de aplicaciones más potentes. O quizás se necesita una red de mayor ancho de banda. Independientemente de lo que sea necesario, el sistema debe admitir el hardware adicional que se agregará. La escalabilidad es una de las principales razones por las que la arquitectura de microservicios se ve favorecida en estos días.
Otra cosa a considerar es la salud del sistema operativo. Una de las cosas más importantes es estar actualizado con parches de seguridad. Además, algunas de las métricas centrales, como el espacio en disco, la memoria RAM, la CPU y el ancho de banda de la red, deben ser monitoreados. Mantener el sistema operativo saludable y el entorno seguro es un tema que abarca varios libros. Lo importante es tenerlo en cuenta y no ignorarlo.
corrección de erroresAl subir una capa, llegamos a los servicios y bibliotecas de soporte: bases de datos, servidores web y marcos. Deben estar actualizados con parches de seguridad y correcciones de errores. Este es el mínimo indispensable; La solución óptima es actualizar siempre a la versión más reciente.
Desafortunadamente, muchos proyectos tienen muchas dependencias, tantas que cuando se actualizan las dependencias, varias partes del software se rompen. Si ese es el caso, tener un conjunto de pruebas automatizadas es una manera fácil de identificar los problemas y solucionarlos sin introducir regresiones en la producción. La otra forma es usar el control de calidad manual para encontrar los errores, pero esto es más lento y hay una mayor posibilidad de fallas.
Por último, tenemos mantenimiento de software. Noventa y nueve por ciento de las veces, la corrección de errores es parte del trato inicial, al menos durante los primeros 12-24 meses. Las solicitudes de cambio y características son un poco más complicadas. Forman parte de la fase de mantenimiento a pesar de requerir desarrollo. Si el código no se puede mantener y sin pruebas , es poco lo que puede hacer después del lanzamiento sin gastar inmensos recursos. Es por eso que la calidad de escritura y el código mantenible son clave.
Muy a menudo, el equipo que escribe las solicitudes de cambio y las características después del lanzamiento no es el mismo equipo que escribió la versión inicial del software. Esto se debe principalmente a la alta rotación en las empresas de software. La documentación, los scripts de compilación y las pruebas son lo que reducirá los recursos de incorporación necesarios para los nuevos desarrolladores y ayudará a sacar las nuevas características en un tiempo razonable.

El software está cambiando constantemente

Los requisitos de hoy cambiarán inevitablemente. El trabajo en un producto de software nunca terminará a menos que toda la tecnología se congele, lo cual es muy poco probable. Cuando se trabaja con software, es crucial hacer que el código, los subsistemas y el hardware sean extensibles.
Tener un proceso de lanzamiento estable reduce en gran medida el riesgo al implementar correcciones de errores. Las pruebas y los altos estándares de calidad garantizan que el software tendrá el máximo tiempo de actividad posible.
Puede parecer desafiante y complicado, pero es una inversión de tiempo y esfuerzo que valdrá la pena a largo plazo y tendrá un efecto muy positivo en su carrera.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas