En este documento, se describe la popular metodología de apps de doce factores y cómo aplicarla cuando desarrollas apps que se ejecutan en Google Cloud. Si usas esta metodología, puedes crear apps escalables y resistentes que se puedan implementar de forma continua con una agilidad óptima.
Este documento está destinado a desarrolladores que estén familiarizados con Google Cloud, el control de versiones, la integración continua y la tecnología de contenedores.
Introducción
Los desarrolladores trasladan apps a la nube y, en este proceso, adquieren más experiencia en el diseño y la implementación de aplicaciones nativas de la nube. A partir de esa experiencia, surgió un conjunto de prácticas recomendadas que se conocen comúnmente como los doce factores. Si diseñas una app con estos factores en consideración, puedes implementar apps en la nube que serán más portátiles y resistentes que las apps implementadas en entornos locales en los que la provisión de recursos nuevos toma más tiempo.
Sin embargo, el diseño de aplicaciones modernas nativas de la nube requiere un cambio en tu forma de pensar sobre ingeniería, implementación y configuración de software, en comparación con el diseño de apps para entornos locales. Este documento te ayuda a entender cómo aplicar los doce factores en el diseño de tu app.
Ventajas de las apps de doce factores
El diseño de doce factores también te ayuda a separar los componentes de la app, de modo que cada uno pueda reemplazarse con facilidad, escalar verticalmente o reducirse sin problemas. Debido a que los factores son independientes de cualquier lenguaje de programación o pila de software, el diseño de doce factores se puede aplicar a una amplia variedad de apps.
Los doce factores
1. Base de código
Debes rastrear el código de tu app en un sistema de control de versiones como Git o Mercurial. Para trabajar en la app, descarga el código en tu entorno de desarrollo local. El almacenamiento del código en un sistema de control de versiones le permite a tu equipo trabajar en conjunto y proporciona un registro de auditoría de cambios en el código, una forma sistemática de resolver conflictos de fusión y la capacidad de revertir el código a una versión anterior. También proporciona un lugar desde el cual realizar la integración continua (IC) y la implementación continua (CD).
Si bien los desarrolladores pueden estar trabajando en diferentes versiones del código en sus entornos de desarrollo, la fuente de información verdadera siempre es el código en el sistema de control de versiones. El código en el repositorio es lo que se construye, se prueba y se implementa, y la cantidad de repositorios es independiente de la cantidad de entornos. El código en el repositorio se usa a fin de producir una única compilación, que se combina con una configuración específica del entorno para producir una versión inmutable, una versión en la que no se pueden realizar cambios, incluida la configuración, que luego se puede implementar en un entorno. Cualquier cambio necesario para la versión debería dar como resultado una nueva actualización.
Cloud Source Repositories te permite colaborar y administrar tu código en un repositorio de Git privado, escalable y con todas las funciones. Incluye la funcionalidad de búsqueda de código en todos los repositorios. También puedes conectarte a otros productos de Google Cloud, como Cloud Build, App Engine, Cloud Logging y Pub/Sub.
2. Dependencias
Cuando se trata de dependencias para apps de doce factores, hay dos consideraciones: declaración de dependencia y aislamiento de dependencia.
Las apps de doce factores nunca deberían tener dependencias implícitas. Debes declarar cualquier dependencia de manera explícita y marcarlas en el control de versiones. Esto te permite comenzar a usar el código de manera rápida y repetible, y facilita el seguimiento de los cambios de las dependencias. Muchos lenguajes de programación ofrecen una forma de declarar dependencias de forma explícita, como pip para Python y Bundler para Ruby.
También debes aislar una app y sus dependencias. Para ello, empaquétalas en un contenedor. Los contenedores te permiten aislar una app y sus dependencias de su entorno y asegurarte de que la app funcione de manera uniforme a pesar de las diferencias entre los entornos de etapa de pruebas y desarrollo.
Artifact Registry es un servicio privado de administración de artefactos completamente administrado que admite varios tipos de artefactos, como imágenes de contenedores, paquetes de lenguaje (como Maven y npm) y paquetes de SO. como RPM). Para ayudarte a administrar los resultados de tus compilaciones de CI/CD y sus dependencias, puedes usar Cloud IAM con Artifact Registry con un control de acceso detallado. Artifact Analysis detecta las vulnerabilidades en las imágenes de contenedor que se envían a Artifact Registry para garantizar que las imágenes de contenedor sean seguras para implementar.
Las integraciones existentes de IC/EC también te permiten configurar tuberías completamente automatizadas para obtener comentarios rápido. Puedes enviar imágenes a su registro y, luego, extraer imágenes con un extremo HTTP desde cualquier máquina, ya sea una instancia de Compute Engine o tu propio hardware.
3. Configuración
Cada app moderna requiere algún tipo de configuración. Por lo general, tienes diferentes opciones de configuración para cada entorno, como desarrollo, prueba y producción. Estas opciones suelen incluir credenciales de cuenta de servicio y controladores de recurso para servicios de copia de seguridad, como bases de datos.
Las opciones para cada entorno deben ser externas al código y no deben registrarse en el control de versiones. Todos trabajan en una sola versión del código, pero tú tienes varias opciones de configuraciones. El entorno de implementación determina qué configuración usar. Esto permite que una versión del objeto binario se implemente en cada entorno; la única diferencia es la configuración del entorno de ejecución. Una manera fácil de comprobar si la configuración se ha externalizado con éxito es ver si el código se puede hacer público sin revelar ninguna credencial.
Una forma de externalizar la configuración es crear archivos de configuración. Sin embargo, los archivos de configuración suelen ser específicos de un marco de trabajo de desarrollo o un lenguaje.
Un mejor enfoque es almacenar la configuración en variables de entorno. Estas son fáciles de cambiar para cada entorno en el entorno de ejecución, es probable que no se controlen en la versión de control y son independientes del lenguaje de programación y del marco de trabajo de desarrollo. En Google Kubernetes Engine (GKE), puedes usar ConfigMaps. Esto te permite vincular variables de entorno, números de puerto, archivos de configuración, argumentos de línea de comandos y otros artefactos de configuración a los componentes del sistema y contenedores de los pods en el entorno de ejecución.
Cloud Functions y Cloud Run admiten el uso de variables de entorno. Puedes externalizar las configuraciones y modificarlas desde la consola de Google Cloud o mediante el SDK de Google Cloud.
4. Servicios de copia de seguridad
Se debe acceder a todos los servicios que la app consume como parte de su funcionamiento normal, como los sistemas de archivos, bases de datos, sistemas de almacenamiento en caché y colas de mensajes, como un servicio y externalizarse en la configuración. Debes pensar en estos servicios de copia de seguridad como abstracciones para el recurso subyacente. Por ejemplo, cuando la app escribe datos a fin de almacenarlos, si tratas el almacenamiento como un servicio de copia de seguridad, podrás cambiar sin problemas el tipo de almacenamiento subyacente, ya que está separado de la app. Luego, puedes realizar un cambio, como cambiar de una base de datos local de PostgreSQL a Cloud SQL para PostgreSQL sin cambiar el código de la app.
5. Compila, libera, ejecuta
Es importante separar el proceso de implementación de software en tres etapas distintas: compilación, lanzamiento y ejecución. Cada etapa debe dar como resultado un artefacto que se pueda identificar de manera única. Cada implementación debe estar vinculada a una actualización específica que sea el resultado de combinar la configuración de un entorno con una compilación. Esto permite realizar reversiones fáciles y brinda un registro de auditoría visible del historial de cada implementación de producción.
Puedes activar de manera manual la etapa de compilación, pero en general, se activa de manera automática cuando confirmas el código que pasó por todas las pruebas requeridas. La etapa de compilación toma el código, recupera las bibliotecas y los activos necesarios, y los empaqueta en un contenedor o objeto binario autónomo. El resultado de la etapa de compilación es un artefacto de compilación.
Cuando se completa la etapa de compilación, la etapa de lanzamiento combina el artefacto de compilación con la configuración de un entorno específico. Esto produce un lanzamiento. La versión se puede implementar de manera automática en el entorno mediante una app de implementación continua. De forma alternativa, puedes activar el lanzamiento a través de la misma app de implementación continua.
Por último, la etapa de ejecución impulsa el lanzamiento y lo inicia. Por ejemplo, si implementas en GKE, con Cloud Build se puede pasar a la etapa de compilación gke-deploy para implementar en tu clúster de GKE. Cloud Build puede administrar y automatizar las etapas de compilación, lanzamiento y ejecución en varios lenguajes y entornos con archivos de configuración de compilación en formato YAML o JSON.
Además, puedes usar Cloud Deploy, que proporciona un servicio completamente administrado que proporciona entrega continua a GKE, Cloud Run y GKE Enterprise. Con Cloud Deploy, puedes crear una canalización de entrega que incluya pasos de aprobación y promoción sin interrupciones para varios entornos. Además, Cloud Deploy admite una reversión de un solo paso de una aplicación implementada en cualquier destino.
6. Procesos
Debes ejecutar apps de doce factores en el entorno como uno o más procesos. Estos procesos no deben tener ningún estado y no deben compartir datos entre sí. Esto permite que las apps escalen verticalmente mediante la replicación de sus procesos. La creación de apps sin estado también hace que los procesos sean portátiles en toda la infraestructura de procesamiento.
Si estás acostumbrado al concepto de sesiones “fijas”, esto requiere un cambio en la forma de pensar sobre el control y la persistencia de los datos. Debido a que los procesos pueden desaparecer en cualquier momento, no puedes confiar en que el contenido del almacenamiento local esté disponible o que cualquier solicitud posterior se maneje con el mismo proceso. Por lo tanto, debes conservar de manera explícita cualquier dato que se deba volver a usar en un servicio de copia de seguridad externo, como una base de datos.
Si necesitas conservar datos, puedes usar Memorystorey Filestore como un servicio de copia de seguridad para almacenar en caché el estado de las apps y compartir datos comunes entre procesos a fin de fomentar un acoplamiento bajo.
7. Vinculación de puerto
En entornos que no están en la nube, las aplicaciones web a menudo se escriben para ejecutarse en contenedores de app como GlassFish, Apache Tomcat y Apache HTTP Server. En cambio, las apps de doce factores no dependen de los contenedores de apps externos. En su lugar, agrupan la biblioteca del servidor web como parte de la app en sí.
Una práctica recomendada de arquitectura para los servicios es exponer un número de puerto, especificado por la variable de entorno PORT.
Las apps que exportan la vinculación de puertos pueden consumir información de vinculación de puertos de manera externa (como variables de entorno) cuando se usa el modelo de plataforma como servicio. En Google Cloud, puedes implementar apps en servicios de plataforma como Compute Engine, GKE, App Engine o Cloud Run.
En estos servicios, una capa de enrutamiento transfiere las solicitudes desde un nombre de host público hasta tus procesos web vinculados a un puerto. Por ejemplo, cuando implementas tus apps en App Engine, declaras dependencias para agregar una biblioteca de servidor web a la app, como Express (para Node.js), Flask y Gunicorn (para Python) o Jetty (para Java).
No debes integrar los números de puerto como parte de tu código. En su lugar, debes proporcionar los números de puerto en el entorno, como en una variable de entorno. Esto hace que tus apps sean portátiles cuando las ejecutas en Google Cloud.
Debido a que Kubernetes tiene un descubrimiento de servicios incorporado, en él puedes abstraer vínculos de puertos mediante la asignación de puertos de servicio a contenedores. El descubrimiento de servicios se lleva a cabo con nombres de DNS internos.
En lugar de codificar el puerto en el que escucha el servidor web, la configuración usa una variable de entorno. En el siguiente fragmento de código de una app de App Engine, se muestra cómo aceptar un valor de puerto que se pasa a una variable de entorno.
const express = require('express')
const request = require('got')
const app = express()
app.enable('trust proxy')
const PORT = process.env.PORT || 8080
app.listen(PORT, () => {
console.log('App listening on port ${PORT}')
console.log('Press Ctrl+C to quit.')
})
8. Simultaneidad
Debes descomponer tu app en procesos independientes basados en tipos de procesos, como procesos en segundo plano, web y trabajadores. Esto permite que tu app escale verticalmente o se reduzca según los requisitos de carga de trabajo individuales. La mayoría de las aplicaciones nativas de la nube te permiten escalar a pedido. Debes diseñar la app como múltiples procesos distribuidos que puedan ejecutar bloques de trabajo de forma independiente y escalar horizontalmente mediante el agregado de procesos.
En las siguientes secciones, se describen algunas construcciones para que las apps puedan escalar. Las apps que se compilan con principios de falta de estado y una capacidad de ser desechables en su núcleo están bien posicionadas para aprovechar estas construcciones de escalamiento horizontal.
con Cloud Run
Cloud Run es una plataforma de procesamiento que te permite ejecutar contenedores directamente sobre la infraestructura administrada por Google. Cloud Run admite dos formas de ejecutar tu código. Cloud Run services se ejecuta de forma continua como un servicio. Por lo general, se usa para responder a solicitudes o eventos web. Cloud Run jobs ejecuta código que realiza trabajos específicos y se cierra cuando el trabajo finaliza. Cloud Run también ofrece Cloud Scheduler para ejecutar trabajos por lotes. Esta estructura es adecuada para implementar simultaneidad y escalar posibles arquitecturas de servicio.
Para obtener más información sobre Cloud Run, consulta Qué es Cloud Run.
Usa Cloud Functions
Las funciones de Cloud Functions son funciones sin estado de un solo propósito que se ejecutan en Google Cloud. En Google se administra la arquitectura subyacente en la que se ejecutan. Con Cloud Functions se responden a activadores de eventos, como una carga en un bucket de Cloud Storage o un mensaje de Pub/Sub. Cada invocación de función responde a un solo evento o solicitud.
Cloud Functions maneja las solicitudes entrantes asignándolas a las instancias de tu función. Cuando el volumen de solicitudes entrante excede el número de instancias existentes, Cloud Functions puede iniciar nuevas instancias para controlar las solicitudes. Este comportamiento de ajuste de escala automático y completamente administrado permite que con Cloud Functions se manejen muchas solicitudes en paralelo, cada una a través de una instancia diferente de la función.
Usa App Engine
Puedes alojar tus apps en la infraestructura administrada de Google Cloud con App Engine. Las instancias son las unidades de computación que usa App Engine para el ajuste de escala automático en tu app. En cualquier momento, tu app puede ejecutarse en una instancia o en muchas instancias, y las solicitudes se distribuyen en todas ellas.
El programador de App Engine decide cómo entregar cada solicitud nueva. El programador puede usar una instancia existente (una que esté inactiva o que acepte solicitudes simultáneas), colocar la solicitud en una lista de solicitudes pendientes o iniciar una instancia nueva para esa solicitud. A fin de tomar esa decisión, se consideran la cantidad de instancias disponibles, la rapidez con la que tu app entrega las solicitudes (su latencia) y el tiempo que lleva iniciar una instancia nueva.
Si usas el ajuste de escala automático, puedes crear un equilibrio entre el rendimiento y el costo si estableces el uso objetivo de la CPU, la capacidad de rendimiento objetivo y las solicitudes simultáneas máximas.
Puedes especificar el tipo de escalamiento en el archivo app.yaml, que cargas para tu versión de servicio. Según esta entrada de configuración, la infraestructura de App Engine usa instancias dinámicas o residentes. Para obtener más información sobre los tipos de escalamiento, consulta Cómo se administran las instancias.
Usa el ajuste de escala automático de GKE
A continuación, se enumeran algunas construcciones clave de Kubernetes que se aplican a los procesos de escalamiento:
Ajuste de escala automático horizontal de pods (HPA). Kubernetes se puede configurar para escalar verticalmente o reducir la cantidad de pods que se ejecutan en el clúster según las métricas estándar o personalizadas. Esto resulta útil cuando necesitas responder a una carga variable en tu clúster de GKE.
Ajuste de escala automático de nodos. En tiempos de mayor demanda, puede que debas escalar tu clúster para incluir más pods. Con GKE, puedes configurar tu clúster de manera declarativa para el escalamiento. Con el ajuste de escala automático habilitado, GKE escala de manera automática los nodos cuando se necesitan programar pods adicionales y cuando los nodos existentes no pueden acomodarlos. GKE también reduce los nodos cuando la carga en el clúster disminuye, según los umbrales que hayas configurado.
Jobs. GKE es compatible con los trabajos de Kubernetes. Un trabajo se puede definir, en términos generales, como una tarea que necesita que uno o más pods se ejecuten para ejecutarse. El trabajo puede ejecutarse una vez o de manera programada. Los pods en los que se ejecuta el trabajo se borran cuando este se completa. El archivo YAML que configura el trabajo especifica detalles sobre el manejo de errores, el paralelismo, la forma en la que se manejan los reinicios, etcétera.
Usa Compute Engine
También puedes implementar y administrar las apps en Compute Engine. En ese caso, puedes escalar tu app para responder a cargas variables con grupos de instancias administrados (MIG) en función del uso de la CPU, de las solicitudes que se controlan o de otras señales de telemetría de tu app.
En la siguiente imagen, se ilustran las características clave que proporcionan los grupos de instancias administradas.
El uso de grupos de instancias administrados (MIG) permite a tu app escalar para satisfacer la demanda entrante y tener alta disponibilidad. Este concepto funciona inherentemente bien en apps sin estado, como frontends web y cargas de trabajo de alto rendimiento basadas en lotes.
9. Capacidad de ser desechable
En el caso de las apps que se ejecutan en la infraestructura de la nube, debes tratarlas a ellas y a la infraestructura subyacente como recursos desechables. Tus apps deberían poder manejar la pérdida temporal de la infraestructura subyacente y deberían poder cerrarse y reiniciarse de forma correcta.
Los principios clave a considerar incluyen los siguientes:
- Funcionalidad de separación, como la administración de estado y el almacenamiento de datos transaccionales mediante servicios de copia de seguridad. Para obtener más información, consulta la sección Servicios de copia de seguridad más arriba en este documento.
- Administra variables de entorno fuera de la app para que puedan usarse en el entorno de ejecución.
- Asegúrate de que el tiempo de inicio sea mínimo. Esto significa que debes decidir cuántas capas debes compilar en las imágenes cuando usas máquinas virtuales, como imágenes públicas en comparación con imágenes personalizadas. Esta decisión es específica para cada app y debe basarse en las tareas que realizan las secuencias de comandos de inicio. Por ejemplo, si descargas objetos binarios o varios paquetes, y los inicializas durante el arranque, una parte considerable de tu tiempo de inicio se dedicará a completar estas tareas.
- Usa características nativas de Google Cloud para realizar tareas de infraestructura. Por ejemplo, puedes usar actualizaciones progresivas en GKE y administrar tus llaves de seguridad mediante Cloud Key Management Service (Cloud KMS).
Use la señal SIGTERM (cuando esté disponible) para iniciar un cierre ordenado. Por ejemplo, cuando App Engine Flex cierra una instancia, suele enviar una señal STOP (SIGTERM) al contenedor de la app. Tu app puede usar esta señal para realizar cualquier acción de limpieza antes de que el contenedor se cierre. (Tu aplicación no necesita responder al evento SIGTERM). En condiciones normales, el sistema espera hasta 30 segundos para que la app se detenga y, luego, envía una señal KILL (SIGKILL).
En el siguiente fragmento de una app de App Engine, se muestra cómo puedes interceptar la señal SIGTERM para cerrar las conexiones abiertas de la base de datos.
const express = require('express') const dbConnection = require('./db') // Other business logic related code app.listen(PORT, () => { console.log('App listening on port ${PORT}') console.log('Press Ctrl+C to quit.') }) process.on('SIGTERM', () => { console.log('App Shutting down') dbConnection.close() // Other closing of database connection })
10. Paridad de entorno
Las apps empresariales se mueven a través de diferentes entornos durante su ciclo de vida de desarrollo. Por lo general, estos entornos son desarrollo, prueba y etapa de pruebas, y producción. Es recomendable mantener estos entornos lo más similares posible.
La paridad de entorno es una característica que la mayoría de los desarrolladores la dan por sentada. No obstante, a medida que las empresas crecen y sus ecosistemas de TI evolucionan, la paridad de entorno se vuelve más difícil de mantener.
Mantener la paridad del entorno se volvió más fácil en los últimos años porque los desarrolladores adoptaron el control de la fuente, la administración de configuración y los archivos de configuración de plantilla. Esto facilita la implementación de una app en varios entornos de manera coherente. Por ejemplo, con Docker y Docker Compose, puedes asegurarte de que la pila de apps conserve su forma y su instrumentación en todos los entornos.
En la siguiente tabla, se enumeran los servicios y herramientas de Google Cloud que puedes usar cuando diseñas apps para que se ejecuten en Google Cloud. Estos componentes tienen diferentes propósitos y juntos te ayudan a compilar flujos de trabajo que hacen que tus entornos sean más coherentes.
| Componente de Google Cloud | Purpose |
|---|---|
| Cloud Source Repositories | Un solo lugar para que tu equipo almacene, administre y realice un seguimiento del código. |
| Artifact Registry | Es un administrador de paquetes universal para todos tus artefactos de compilación y dependencias. |
| Cloud Build | Un servicio completamente administrado con el que se ejecutan tus compilaciones en la infraestructura de Google Cloud. |
| Cloud KMS | Almacena tus claves criptográficas en un servicio de nube central para que otras aplicaciones y recursos de la nube las usen directamente. |
| Cloud Storage | Almacena imágenes personalizadas que crees a partir de discos de origen, imágenes, instantáneas o imágenes almacenadas en Cloud Storage. Puedes usar estas imágenes para crear instancias de máquina virtual (VM) adaptadas a tus apps. |
| Cloud Deploy | Proporciona una entrega automatizada de tus aplicaciones a una serie de varios entornos de destino en una secuencia definida. |
11. Registros
Los registros te proporcionan conocimiento del estado de tus apps. Es importante separar la recopilación, el procesamiento y el análisis de registros de la lógica central de tus apps. El registro de separación es útil, en especial, cuando tus apps requieren escalamiento dinámico y se ejecutan en nubes públicas, ya que quita la sobrecarga de administrar la ubicación de almacenamiento para registros y la agregación de VM distribuidas (y, a menudo, efímeras).
Google Cloud ofrece un conjunto de herramientas que te ayudan con la recopilación, el procesamiento y el análisis estructurado de los registros. Se recomienda instalar el agente de Cloud Logging en las VM de Compute Engine. El agente está preinstalado en las imágenes de VM de App Engine y GKE de forma predeterminada. El agente supervisa un conjunto preconfigurado de ubicaciones de registro. Los registros que generaron las apps que se ejecutan en la VM se recopilan y se transmiten a Cloud Logging.
Cuando se habilita el registro para un clúster de GKE, se implementa un agente de Logging en cada nodo que sea parte del clúster. El agente recopila registros, los enriquece con metadatos relevantes y los guarda en el almacenamiento de datos. Estos registros están disponibles para revisión mediante Cloud Logging. Si necesitas más control sobre lo que se registra, puedes usar daemonsets de Fluentd.
Para obtener más información, consulta Configura el agente de Logging.
12. Procesos de administración
Los procesos administrativos, por lo general, consisten en tareas puntuales o tareas repetibles y cronometradas, como generar registros, ejecutar secuencias de comandos por lotes, iniciar copias de seguridad de bases de datos y migrar esquemas. El factor de procesos de administración en el manifiesto de doce factores se escribió con base en tareas únicas. En el caso de las aplicaciones nativas de la nube, este factor se vuelve más relevante cuando se crean tareas repetibles. Esta sección está orientada a tareas como esas.
Los activadores temporizados a menudo se crean como trabajos cron y se manejan inherentemente por las propias apps. Este modelo funciona, pero introduce una lógica que se relaciona de manera estrecha con la app y que requiere mantenimiento y coordinación, en especial si tus apps se distribuyen en distintas zonas horarias.
Por lo tanto, cuando diseñes para procesos administrativos, debes separar la administración de estas tareas de la app en sí misma. Según las herramientas y la infraestructura en la que se ejecuta tu app, ten en cuenta las siguientes sugerencias:
- Para ejecutar apps en GKE, inicia contenedores separados con tareas de administración. Puedes aprovechar CronJobs en GKE. Los CronJobs se ejecutan en contenedores efímeros y te permiten controlar el tiempo, la frecuencia de ejecución y los reintentos si los trabajos fallan o si toman demasiado en completarse.
- Para alojar apps en App Engine o Compute Engine, puedes externalizar el mecanismo de activación y crear un extremo para que el activador pueda invocar. Este enfoque ayuda a definir un límite en torno a la responsabilidad de las apps, en contraste con el enfoque de un solo propósito del extremo. Cloud Tasks es un servicio de ejecución de tareas completamente administrado y asíncrono que puedes usar para implementar este patrón con App Engine. También puedes usar Cloud Scheduler, un programador completamente administrado y de nivel empresarial en Google Cloud, para activar las operaciones programadas.
Ve más allá de los doce factores
Los doce factores que se describen en este documento ofrecen orientación sobre cómo debes abordar la compilación de aplicaciones nativas de la nube. Estas apps son los pilares fundamentales de una empresa.
Una empresa típica tiene muchas apps como estas, a menudo desarrolladas por varios equipos en colaboración para brindar capacidad comercial. Es importante establecer algunos principios adicionales durante el ciclo de vida de desarrollo de la app, y no como una ocurrencia tardía, para abordar cómo las apps se comunican entre sí, y cómo se protegen y se controla su acceso.
En las siguientes secciones, se describen algunas de las consideraciones adicionales que debes tener en cuenta durante el diseño y el desarrollo de apps.
Piensa primero en la API
Las apps se comunican mediante las API. Cuando crees apps, piensa en cómo su ecosistema la utilizará y comienza con el diseño de una estrategia de API. Un buen diseño de API hace que sea fácil de usar por los desarrolladores de apps y las partes interesadas externas. Se recomienda comenzar con la documentación de la API mediante el uso de la especificación OpenAPI antes de implementar cualquier código.
Las API abstraen la funcionalidad subyacente de la app Un extremo de API bien diseñado debe aislar y separar las aplicaciones que consumen de la infraestructura de la app que provee el servicio. Esta separación brinda la habilidad de cambiar el servicio subyacente y su infraestructura de forma independiente, sin generar un impacto en los consumidores de la app.
Es importante catalogar, documentar y publicar las API que desarrolles para que los consumidores puedan descubrir y usar las API. Lo ideal es que los usuarios de API se ayudan entre ellos. Puedes lograr esto si configuras un portal para desarrolladores. Un portal para desarrolladores sirve como punto de entrada a todos los consumidores de la API (internos para la empresa o externos para los consumidores, como los desarrolladores del ecosistema de socios).
Apigee, el paquete de producto administrado de la API de Google, te ayuda a administrar el ciclo de vida completo de tus API desde el diseño, la compilación y la publicación.
Seguridad
El ámbito de la seguridad es amplio y, además, incluye sistemas operativos, redes y firewalls, seguridad de datos y de bases de datos, seguridad de apps y administración de identidades y accesos. Es de suma importancia abordar todas las dimensiones de seguridad en el ecosistema de una empresa.
Desde el punto de vista de una app, las API proporcionan acceso a las apps en el ecosistema de tu empresa. Por lo tanto, debes asegurarte de que estos pilares fundamentales abordan las consideraciones de seguridad durante el proceso de diseño y compilación de la app. A continuación, se mencionan algunas consideraciones para ayudar a proteger el acceso a la app:
- Seguridad de la capa de transporte (TLS) Usa TLS para ayudar a proteger los datos en tránsito. Se recomienda usar una TLS mutua para tus apps empresariales. Esto es más fácil si usas mallas de servicios como Istio en Google Kubernetes Engine. También es común, en algunos casos prácticos, crear listas permitidas y denegadas basadas en direcciones IP como una capa adicional de seguridad. La seguridad del transporte también implica proteger tus servicios contra ataques DSD y de bots.
- Seguridad de la app y del usuario final. La seguridad del transporte ayuda a proteger los datos en tránsito y establece confianza. Sin embargo, se recomienda agregar seguridad a nivel de la app para controlar el acceso a tu app en función de quién es el consumidor. Los consumidores pueden ser otras apps, empleados, socios o clientes finales de tu empresa. Puedes aplicar la seguridad mediante claves de API (en aplicaciones para consumidores), autenticación y autorización basadas en certificación, intercambio de JSON Web Tokens (JWT), o el Lenguaje de marcado para confirmación de seguridad (SAML).
El panorama de seguridad evoluciona de manera constante dentro de una empresa, lo que dificulta la codificación de construcciones de seguridad en las apps. Los productos de administración de la API, como Apigee, ayudan a las API seguras en todas las capas que se mencionaron en esta sección.
La seguridad de la cadena de suministro de software es un problema difícil de resolver. Es importante que tomes precauciones. Software Delivery Shield es una solución completamente administrada de extremo a extremo que ayuda a mejorar la seguridad de la cadena de suministro de software durante todo el ciclo de vida del desarrollo de software. Ofrece los siguientes servicios y otros:
Cloud Build Admite compilaciones de SLSA de nivel 3 para imágenes de contenedor y genera una fuente de compilación autenticada y no factible para aplicaciones en contenedores.
Software de código abierto garantizado Ayuda a reducir el riesgo de la cadena de suministro de software mediante los mismos paquetes de OSS que usa Google.
Además, se preparan varios servicios y funciones para ayudar a mejorar la seguridad de la cadena de suministro de software.
Para obtener más información sobre la seguridad de la cadena de suministro de software, consulta Seguridad de la cadena de suministro de software. Para obtener más información sobre Software Delivery Shield, consulta Descripción general de Software Delivery Shield.
¿Qué sigue?
- Revisa la app de demostración de microservicios que emplea principios de apps de doce factores y está compilada con productos y servicios de Google Cloud.
- Visita el Centro de arquitectura de Cloud y descubre arquitecturas de referencia, orientación y prácticas recomendadas para compilar o migrar tus cargas de trabajo en Google Cloud.
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.