A diferencia de la transición anterior e igualmente revolucionaria de bare metal a máquinas virtuales, los contenedores reducen drásticamente la redundancia de la pila de software y cambian la naturaleza misma de la gestión de sistemas operativos en la empresa.
Muchos eligen acelerar su migración a contenedores con Red Hat OpenShift Container Platform, la plataforma de Kubernetes líder en la industria para el sector empresarial. Esta solución asume automáticamente muchas de las tareas del primer día y ofrece el mejor ecosistema de Kubernetes en una plataforma única, rigurosamente probada y altamente segura. Esta es la solución más completa y funcional para empresas, que contiene todo lo que necesita para comenzar y elimina muchas barreras técnicas y complejidades al construir una plataforma Kubernetes.
Sin embargo, OpenShift no es una varita mágica que resuelva todos los problemas por sí solo. Sí, gracias a sus capacidades, esta plataforma es capaz de brindar, y lo hace a sus clientes, muchos beneficios y se amortiza rápidamente, siempre que en el momento de su lanzamiento tenga un plan bien pensado. Para tener éxito, hay siete áreas que deben resolverse a fondo antes de mover cualquier carga de trabajo a OpenShift.
1. Estandarización de reglas de denominación y metadatos
Solo hay dos cosas difíciles en informática: invalidar la caché y nombrar entidades.
- Phil Karlton
Cada entidad en OpenShift y Kubernetes tiene su propio nombre. Y cada servicio debe tener su propio nombre DNS , la única limitación aquí son las reglas de nombres DNS. Ahora imagine que una aplicación monolítica se ha descompuesto en 100,500 microservicios separados, cada uno con su propia base de datos. Y sí, en OpenShift, todo es jerárquico, relacionado o debe seguir un patrón. Por tanto, habrá que nombrar la masa y la masa de todo. Y si no prepara los estándares de antemano, será un verdadero salvaje oeste.
¿Ya planificó el esquema de implementación del servicio? Digamos que será un gran espacio de nombres, por ejemplo, "bases de datos", en el que todos alojarán sus bases de datos. De acuerdo, e incluso supongamos que todos lo hacen, pero luego comienzan a alojar sus clústeres de Kafka en sus propios espacios de nombres. Sí, pero ¿necesita crear un espacio de nombres "middleware"? ¿O es mejor llamarlo "mensajería"? Y como de costumbre, en algún momento hay tipos que siempre siguen su propio camino y se consideran especiales, y dicen que necesitan sus propios espacios de nombres. Y escuche, tenemos 17 departamentos en la organización, ¿tal vez necesitemos adjuntar nuestros prefijos de departamento estándar a todos los espacios de nombres?
Considere los estándares de nomenclatura y clasificación antes de poner cualquier cosa en producción; ahorrará mucho tiempo y esfuerzo si hace esto de antemano. Establece estándares para todo. Además, no es tanto su calidad lo que importa aquí, sino su disponibilidad, integridad e implementación.
Otra cosa muy útil son los metadatos . Estandarice qué activos desea rastrear y asegúrese de que los metadatos correctos estén escritos en los recursos correctos. Comience con etiquetas recomendadas... Por ejemplo, anotar "support_email" en los metadatos del espacio de nombres puede ahorrarle un tiempo valioso al comunicarse con el soporte de nivel 2 en caso de una falla importante. Además, los metadatos se pueden utilizar para acortar los nombres de los recursos a una longitud significativa en lugar de separar toda la información necesaria con guiones. Involucre a todos, desde arquitectos de aplicaciones hasta operadores de TI, realice una lluvia de ideas y descubra lo que se necesitaría para tener estándares sólidos cuando se lance OpenShift.
2. Estandarización de imágenes de base corporativa
Una de las características clave de los contenedores es la capacidad de mezclar y combinar todas las piezas de la pila de software. Por supuesto, puede tomar su tipo de sistema operativo favorito y construir todo sobre él, pero al actuar de esta manera, la organización está perdiendo grandes oportunidades. Después de todo, ¿qué tienen de bueno las imágenes de contenedores? Capas. Puede eliminar muchas tareas críticas de los desarrolladores y resolverlas estandarizando imágenes.
Tome una aplicación básica de Java, por ejemplo. Es poco probable que sus desarrolladores se equivoquen con OpenJDK, pero con la gestión de vulnerabilidades, la actualización de bibliotecas y otros problemas de higiene de TI, pueden hacerlo. Todos sabemos que los problemas comerciales a menudo se resuelven a costa de compromisos técnicos, como el uso deliberado de versiones anteriores de Java. Afortunadamente, estas tareas se automatizan y gestionan fácilmente a nivel empresarial. Puede seguir utilizando las imágenes base del proveedor , pero al mismo tiempo establecer y controlar sus ciclos de actualización creando sus propias imágenes base.
Volviendo al ejemplo anterior, digamos que los desarrolladores quieren Java 11 y usted quiere que siempre usen la última versión de Java 11. Luego, crea una imagen base corporativa (registration.yourcompany.io/java11) usando como punto de partida imagen base del proveedor del sistema operativo (registro.redhat.io/ubi8/openjdk-11). Y cuando se actualiza esta imagen base, automáticamente ayuda a los desarrolladores a utilizar las últimas actualizaciones. Además, esto proporciona una capa de abstracción que le permite extender sin problemas la imagen estándar con las bibliotecas o paquetes de Linux necesarios.
3. Estandarización de los controles de estado y preparación
Monitoreo de la capacidad de servicio, se necesita en casi todas partes. Se cree que un examen médico anual es suficiente para una persona. El estado de las aplicaciones debe verificarse, por supuesto, mucho más a menudo, y deben monitorearse dos cosas clave:
- Si la aplicación se está ejecutando (verificación de estado).
- Si la aplicación está lista (verificación de disponibilidad).
Hay toneladas de otras métricas para facilitar el monitoreo de aplicaciones, pero estos dos son la base no solo del monitoreo sino también del escalado. El estado suele estar determinado por la disponibilidad de conectividad de red y la capacidad del host que ejecuta la aplicación para responder a una solicitud. En lo que respecta a la preparación, aquí cada aplicación debe responder a las solicitudes de acuerdo con sus propios estándares. Por ejemplo, el lanzamiento de una aplicación con una latencia muy baja puede resultar en una actualización de caché prolongada o en un calentamiento de la JVM . Y en consecuencia, la pausa entre las respuestas "Comenzado" y "Listo" puede durar varios minutos. Pero, por ejemplo, para una API REST sin estado con una base de datos relacional, estas respuestas llegarán simultáneamente.
Lo más importante en estas comprobaciones es no desviarse de la lógica puramente binaria. Lanzado significa lanzado, sin ningún "tipo de lanzamiento" allí. Hecho significa listo, y no hay gradaciones, como "listo para responder a esas solicitudes, pero no a esas solicitudes". El principio es simple: todo o nada.
El segundo aspecto de estos controles es la estandarización. ¿Cómo comprobar la preparación? Si no tiene estándares, incluso una pregunta tan simple puede ser una verdadera pesadilla de monitoreo. Simplemente compare cómo los estándares de Quarkus y los estándares de Spring Boot han divergido . Pero nadie quería eso, pero los estándares siempre son el caso. La única diferencia es que su organización ahora tiene el poder de desarrollar y hacer cumplir los estándares.
Nota en el margen. No invente sus propios estándares. Simplemente busque y use uno ya hecho .
4. Estandarización de registros
Continuando con el tema del monitoreo, observamos que la combinación de almacenamientos económicos y soluciones de big data ha dado lugar a un nuevo monstruo en las empresas: la tala total. Anteriormente, estos eran registros de consola arcaicos y no estructurados que no duraban mucho y se creaban de vez en cuando. Ahora se esfuerzan por registrar todo y construir ciencia de datos con aprendizaje automático para optimizar las operaciones y el monitoreo de la manera más revolucionaria. Por desgracia, debemos admitir lo obvio: cualquier intento de comenzar a recopilar registros de cientos de aplicaciones sin tener absolutamente ningún estándar y sin siquiera pensar en ellos, invariablemente conduce a gastos inútiles y exorbitantes en herramientas para administrar registros y transformación de datos solo para comenzar. trabajo. Es decir, incluso antes de que entiendasque es poco probable que los mensajes "Transición completada" o "Este bloque se haya activado" tengan algo que ver con sus operaciones.
La estructura debe estandarizarse. Nuevamente, la integridad de los estándares es más importante que su corrección. Debería poder escribir un analizador de registro independiente para cada aplicación que se encuentre en la empresa. Sí, estos serán puramente piezas, no cosas replicadas. Sí, tendrá un montón de excepciones que no se pueden controlar, especialmente para aplicaciones en caja. Pero no tire al bebé con el agua, preste atención a los detalles: por ejemplo, la marca de tiempo en cada registro debe cumplir con el estándar ISO apropiado ; la salida en sí debe estar en UTC con una precisión del quinto lugar decimal en microsegundos (2018-11-07T00: 25: 00.07387Z). Los niveles de registro deben emitirse con CAPS y debe haber elementos TRACE, DEBUG, INFO, WARN, ERROR. En general, configure la estructura y solo luego entre en los detalles.
La estandarización de la estructura obligará a todos a ceñirse a las mismas reglas y utilizar los mismos patrones arquitectónicos. Esto es cierto tanto para los registros de la aplicación como de la plataforma. Y no se desvíe de una solución ya preparada a menos que sea absolutamente necesario. La pila EFK (Elasticsearch, Fluentd y Kibana) de la plataforma OpenShift debería poder manejar todos sus scripts. Después de todo, ingresó a la plataforma por una razón, y cuando se actualiza, esto es otra cosa de la que no debes preocuparte.
5. Cambiar a GitOps
Una de las mejores cosas de OpenShift es que todo aquí, literalmente: todo, es en última instancia configuración o código, lo que significa que se puede controlar a través del control de código fuente. Esto le permite revolucionar los métodos de entrega y deshacerse de la burocracia al iniciar la producción.
En particular, el esquema tradicional basado en tickets se puede reemplazar por completo con un modelo con solicitudes de extracción de git.... Digamos que el propietario de la aplicación quiere ajustar los recursos asignados a la aplicación después de implementar nuevas funciones en ella, por ejemplo, aumentar la memoria de 8 GB a 16 GB. En el esquema tradicional, un desarrollador necesita crear un ticket y esperar a que alguien más complete la tarea correspondiente. Esta otra persona suele ser un operador de TI que solo introduce un retraso tangible en el proceso de implementación de cambios, sin aumentar el valor de este proceso o, lo que es peor, colgar ciclos adicionales adicionales en este proceso. De hecho, el operador tiene dos opciones. Primero, revisa la aplicación y decide ejecutarla, para lo cual ingresa al ambiente de producción, realiza los cambios solicitados manualmente y reinicia la aplicación.
Además del tiempo para realizar el trabajo en sí, hay un retraso adicional aquí, ya que el operador, por regla general, siempre tiene una cola completa de solicitudes de ejecución. Además, existe el riesgo de error humano, como una entrada de 160 GB en lugar de 16 GB. La segunda opción: el operador pone en duda la aplicación y con ello lanza una reacción en cadena para conocer los motivos y consecuencias de los cambios solicitados, tanto es así que en ocasiones las autoridades tienen que intervenir.
Ahora veamos cómo se hace esto en GitOps. La solicitud de cambio va al repositorio de git y se convierte en una solicitud de extracción. Después de eso, el desarrollador puede enviar esta solicitud de extracción (especialmente si se trata de cambios en el entorno de producción) para la aprobación de las partes involucradas. De esta manera, los profesionales de la seguridad pueden involucrarse en una etapa temprana y siempre existe la oportunidad de rastrear la secuencia de cambios. Los estándares en esta área se pueden implementar de manera programática utilizando las herramientas adecuadas en la cadena de herramientas de CI / CD. Una vez aprobada, la solicitud de extracción se versiona y audita fácilmente. Además, se puede probar en un entorno de preproducción como parte de un proceso estándar , eliminando por completo el riesgo de error humano.
Como puede ver, los cambios son radicales. Pero serán nuevos no tanto para los desarrolladores que no son ajenos a los sistemas de control de versiones, como para los administradores de sistemas y los especialistas en seguridad. Pero tan pronto como profundicen en el nuevo paradigma y aprecien su fuerza y simplicidad, la idea estallará con fuerza.
6. Planos
Pasar de aplicaciones monolíticas a microservicios mejora el papel de los patrones de diseño de aplicaciones (patrones). De hecho, la aplicación monolítica típica no es muy clasificable. Por lo general, hay API REST, procesamiento por lotes y controlado por eventos. HTTP, FTP, kafka, JMS e Infinispan ? Sí, por favor, y también funciona con tres bases de datos diferentes al mismo tiempo. ¿Y cómo se ordena crear un diagrama cuando aquí se mezclan un montón de patrones de integración de aplicaciones empresariales? De ninguna manera.
Pero si descompone una aplicación tan monolítica en partes separadas, las plantillas se distinguen mucho más y más fácilmente. Digamos que ahora hay cuatro aplicaciones independientes y utilizan las siguientes plantillas:
- API REST para la gestión de datos en un DBMS.
- Procesamiento por lotes que comprobará si hay actualizaciones en el servidor FTP y lo enviará al tema de kafka.
- Camel es un adaptador que toma datos de este tema de kafka y los envía a la API REST
- API REST que exponen información agregada recopilada de Data Grid que actúa como una máquina de estado.
Así que ahora tenemos esquemas y los esquemas se pueden estandarizar. Las API REST deben cumplir con los estándares de API abiertas . Los trabajos por lotes se gestionarán como trabajos por lotes de OpenShift . Las integraciones usarán Camel... Puede crear esquemas para API, para trabajos por lotes, para AI / ML, para aplicaciones de multidifusión o lo que sea. Y luego puede determinar cómo implementar estos esquemas, cómo configurarlos, qué plantillas usar. Con estos estándares implementados, no tiene que reinventar la rueda cada vez y puede concentrarse mejor en las tareas realmente importantes, como crear nuevas funciones comerciales. Desarrollar los esquemas puede parecer una pérdida de tiempo, pero el esfuerzo invertido se multiplicará por cien en el futuro.
7. Prepárese para la API
Las API vienen junto con la arquitectura de microservicios. También tendrán que ser gestionados y mejor preparados para esto de antemano.
Primero, aquí se necesitan estándares nuevamente. Puedes tomar los estándares de la API abierta como punto de partida , pero debes adentrarte más en la jungla. Aunque es importante lograr un equilibrio aquí y no caer en una sobrerregulación excesiva con un montón de restricciones. Mire estas preguntas: Cuando se crea una nueva entidad usando POST, ¿deberíamos devolver 201 o 200? ¿Está permitido actualizar entidades usando POST y no PUT? ¿Cuál es la diferencia entre 400 y 500 respuestas? - aproximadamente el mismo nivel de detalle que necesita.
En segundo lugar, necesita una malla de servicios... Esto es algo realmente fuerte y con el tiempo se convertirá en una parte integral de Kubernetes. ¿Por qué? Debido a que el tráfico tarde o temprano se convertirá en un problema, y querrá administrarlo tanto dentro del centro de datos (el llamado tráfico "este-oeste") como entre el centro de datos y el mundo exterior ("norte- sur"). Querrá extraer la autenticación y la autorización de las aplicaciones y llevarlas al nivel de plataforma. Necesitará las capacidades de Kiali para visualizar el tráfico dentro de la malla de servicios, así como esquemas de implementación de aplicaciones azul-verde y canarias, o, por ejemplo, control de tráfico dinámico. En general, la malla de servicios entra sin duda en la categoría de tareas del primer día.
En tercer lugar, necesitará una solución de gestión de API centralizada.... Querrá tener una "ventana única" para buscar y reutilizar API. Los desarrolladores deberán poder ir a la tienda de API, encontrar la API que desean y obtener documentación sobre cómo usarla. Querrá administrar de manera consistente las versiones y las obsoletas. Si está creando una API para consumidores externos, puede ser un punto final norte-sur para la seguridad y la gestión de carga. 3Scale incluso puede ayudar con la monetización de API. Bueno, tarde o temprano su administración querrá recibir un informe que responda a la pregunta "¿Qué API tenemos?"
En conclusión, observamos que, si bien identificar áreas para la estandarización y documentar los estándares corporativos puede ser abrumador en sí mismo, la mayor parte del esfuerzo no se dedica a esto, sino a monitorear y hacer cumplir los estándares. Poderosa mezcla de entropía organizacionaly una renuencia completamente natural a entrar en conflicto con los colegas desde el principio a trabajar contra los estándares. La pelea se divide en innumerables batallas diminutas y, a veces, invisibles: aquí falta la etiqueta requerida, y este nombre, aunque no del todo, todavía cumple con el estándar lo suficiente. Los estándares generalmente mueren a causa de mil recortes, y pocos, si es que hay alguno, en la organización lo saben. En cierto sentido, los estándares son como el ejercicio: nadie quiere sudar y esforzarse, pero todos saben que una vida larga y saludable es imposible sin ellos.
Sin embargo, hay esperanza y radica en la automatización. Cualquiera de los estándares anteriores se puede implementar mediante la automatización. El proceso de GitOps puede verificar que todas las etiquetas y anotaciones requeridas estén presentes en todos los archivos yaml correspondientes. El proceso CI / CD puede hacer cumplir los estándares para imágenes corporativas. Todo se puede codificar, probar y armonizar. Además, la automatización se puede mejorar cuando introduce nuevos estándares o cambia los existentes. La indudable ventaja de la estandarización a través de la automatización es que la computadora no evita los conflictos, simplemente expone los hechos. Por lo tanto, con suficiente sofisticación e inversión en automatización, la plataforma en la que está invirtiendo tanto hoy espuede generar un retorno de la inversión mucho mayor en el futuro en forma de rendimiento y estabilidad mejorados.