Este blog analiza cómo la creación de un equipo de ingeniería de plataforma en la nube (" CPE ") en su organización acelerará el desarrollo de SaaS, reducirá el desperdicio organizacional y mejorará el intercambio de conocimientos.
Como arquitecto del grupo de ingeniería de plataformas en la nube de CyberArk , en este blog compartiré nuestra trayectoria durante los últimos tres años, analizaré lo que hacemos, cómo reducimos el desperdicio organizacional (y lo revertimos), los desafíos que enfrentamos y cómo los solucionamos.
Desarrollo de una aplicación SaaS: los problemas iniciales
Crear una aplicación SaaS no es una tarea fácil.
Cuando las organizaciones crean múltiples ofertas de SaaS, varios equipos se encargan de la investigación y el desarrollo. Los equipos enfrentan desafíos y preguntas similares con respecto a las capacidades de la infraestructura en la nube.
¿Cómo se implementa en la nube?
¿Cómo se gestiona el registro y la observabilidad?
¿Cuáles son las mejores prácticas de seguridad?
¿Cómo mantener el aislamiento de los inquilinos? y muchos más.
Cada aplicación SaaS requiere las mismas capacidades de infraestructura en la nube que la preparan para la producción. Estas capacidades no están relacionadas con un dominio empresarial específico.
Con frecuencia, distintos equipos desarrollan estas capacidades de infraestructura en la nube simultáneamente mientras continúan su camino hacia una aplicación SaaS lista para producción.
Este desarrollo puede dar lugar a múltiples soluciones, tal vez incluso a una pila tecnológica diferente, todas dentro de la misma organización, lo que da como resultado un gran desperdicio organizacional.
¿Qué pasaría si le dijera que es posible reducir este desperdicio y convertirlo en un catalizador de innovación, intercambio de conocimiento organizacional y aceleración del desarrollo?
¿Qué es la ingeniería de plataformas en la nube (CPE)?
En primer lugar, en pocas palabras, el propósito de los grupos CPE es reducir la carga cognitiva de otros equipos y desarrolladores de la organización, convertirse en una fuente de conocimiento y ayudarlos a centrarse en su lógica empresarial. Proporciona a los demás equipos de la organización los servicios, los SDK, el conocimiento y la pila tecnológica necesarios para iniciar una nueva aplicación SaaS desde cero con relativa facilidad.
En segundo lugar, es el lugar más emocionante para estar en una empresa, ya que uno trata con las últimas tecnologías, enfrenta muchos desafíos y obtiene como recompensa una vasta influencia organizacional.
En tercer lugar, no es un grupo DevOps. Yo diría que en los mundos SaaS/Serverless y las capacidades de implementación de Infraestructura como código, todos los desarrolladores también son desarrolladores DevOp que necesitan definir sus funciones, roles y bases de datos de AWS Lambda como parte de su trabajo habitual. Además, como verá a continuación, el CPE crea aplicaciones Serverless; algunas están orientadas al cliente externo y requieren ingenieros de software como la mayoría de las aplicaciones SaaS estándar.
Responsabilidades de los CPE
El grupo CPE tiene clientes tanto internos (desarrolladores internos de otros equipos) como externos "habituales" de la empresa.
Las responsabilidades incluyen:
Mantener entornos de producción de aplicaciones SaaS externas orientadas al cliente que también puedan servir a equipos internos (lagos de datos, interfaz de usuario compartida, incorporación de clientes, etc.).
Mantener entornos de producción de aplicaciones SaaS internas que aporten valor a otros equipos. Servicios como autenticación, autorización, observabilidad y más.
Cree bibliotecas SDK consumidas por todos los servicios internos: aislamiento de inquilinos, registro, indicadores de funciones, etc.
Proporcionar plantillas reutilizables de infraestructura como código (construcciones CDK, etc.) que permitan a los equipos internos implementar recursos en la nube configurados con las mejores prácticas de seguridad.
Cree guías de mejores prácticas nativas de la nube, planes de capacitación de SaaS, consultas y orientación para nuevos equipos que recién comienzan su recorrido hacia SaaS.
Como se puede inferir de la lista anterior, estas responsabilidades brindan soluciones a los problemas que toda aplicación SaaS lista para producción requiere.
Estas soluciones tienen UN propietario, el grupo CPE .
Otros equipos pueden centrarse en su lógica empresarial y acelerar su camino hacia la GA de la aplicación SaaS.
¿Cómo empezó para nosotros?
CyberArk es líder mundial en seguridad de identidad y gestión de acceso privilegiado.
Fue fundada en 1999 y en el momento de escribir este artículo cuenta con más de 2.300 empleados en todo el mundo.
La línea de productos de la empresa ha sido durante mucho tiempo una solución local.
En los últimos años se ha producido un cambio global hacia productos basados en SaaS, y CyberArk no es ajeno a este cambio.
Varios equipos han comenzado a crear productos SaaS y a aprender sobre la marcha.
Entregaron productos excelentes. Sin embargo, como en ese momento no había un grupo CPE, crearon múltiples soluciones e infraestructuras para los mismos problemas de las aplicaciones SaaS modernas.
Estas soluciones provocaron un incremento del desperdicio organizacional y de múltiples pilas de tecnología.
Algunos equipos investigaron el aislamiento de inquilinos o desarrollaron un mecanismo de indicadores de características para la función AWS Lambda.
En resumen, es un desperdicio; los equipos deberían haber compartido mejor el conocimiento y un solo propietario debería haber sido dueño de estas infraestructuras de nube sin lógica empresarial.
Introduciendo la ingeniería de plataformas en la nube al campo de juego.
Así se creó el grupo CPE y me uní tan pronto como pude.
Objetivos iniciales
La idea era encontrar las mejores soluciones ya que toda la empresa dependería de nosotros.
Nuestra pila tecnológica estaba compuesta por funciones AWS Lambda basadas en Python y tecnologías AWS Serverless.
Además, desde una etapa relativamente temprana del grupo, CyberArk decidió que algunos miembros del grupo desarrollarían una nueva aplicación SaaS comercial y consumirían los servicios CPE desde el principio.
Este enfoque ayudará al grupo CPE a comprender las necesidades y los problemas reales de una aplicación SaaS y ayudará a persuadir a otros equipos de la empresa de que el trabajo de CPE tiene valor y que deberían integrarlo lo antes posible.
¿Por qué la CPE es buena para nosotros (y para usted)?
Hoy en día, cuando un equipo inicia una nueva aplicación SaaS sin servidor en CyberArk, se enfrenta a numerosos desafíos:
Un nuevo lenguaje de programación (generalmente provienen de C++): Python
El desarrollo sin servidor en la nube y AWS es un territorio desconocido
En lugar de aprenderlo todo por sí solos desde cero, utilizan la capacitación del taller SaaS de CPE y su orientación durante todo el proceso.
El taller cubre los fundamentos de AWS, el uso del SDK y los servicios de CPE, las mejores prácticas para AWS Serverless y consejos y trucos de Python.
Hacia el final del taller, el equipo crea un nuevo repositorio de GitHub para su nuevo servicio a partir de la plantilla de aplicación sin servidor de CPE y aprende a escribir pruebas, implementar código nuevo en AWS y cómo depurar en la nube. Una vez completado, deberían tener todas las herramientas necesarias para comenzar a trabajar en la nube con la pila tecnológica de la empresa y las herramientas de CPE.
Por supuesto, cuando surgen preguntas o dilemas, el equipo puede consultar a los miembros del CPE.
Los miembros del CPE deben prestar ayuda y actuar como defensores de sus utilidades y métodos. De lo contrario, nadie los utilizaría.
Dos clics para una nueva aplicación sin servidor
Entonces, ¿qué es esta mágica plantilla CPE Serverless?
Es un proyecto de plantilla de GitHub que puedes usar para crear tu aplicación Serverless. Sin embargo, no es una plantilla estándar: obtienes un proyecto con una Infraestructura como código (CDK v2) que implementa una AWS API Gateway y varias funciones de AWS Lambda que forman juntas una API CRUD REST simple.
Además, los controladores de AWS Lambda utilizan todas las mejores prácticas y los SDK de CPE, como registro, observabilidad, validación de entrada y más.
En caso de que te lo hayas perdido, he creado una versión de código abierto de este proyecto.
Puedes encontrarlo aquí .
Este proyecto le da al nuevo equipo un gran impulso en el mundo de AWS Serverless y garantiza que comprendan los conceptos básicos correctamente. A partir de allí, pueden concentrarse en sus requisitos comerciales y desarrollar su aplicación de acuerdo con las pautas de CPE.
Suena genial en el papel, pero ¿funciona?
¡Sí!
Un equipo formado por desarrolladores que no utilizaban Python pero que habían recibido esta formación y utilizaron la plantilla pudieron entregar un producto de manera increíblemente rápida.
En solo cuatro meses, pudieron crear una nueva aplicación Serverless y llegar a las etapas de socios de diseño, lo que significa que clientes reales evaluaron su servicio en producción.
¡En una empresa tan grande como CyberArk, esto era inaudito!
Los desafíos del CPE
Los clientes de CPE son desarrolladores internos de CyberArk y clientes externos que pagan por el servicio. Estas dos entidades aportan una capa adicional de complejidad al equipo de CPE y a mi trabajo como arquitecto de sistemas de CPE.
Además, el CPE no ofrece un único servicio SaaS. Su cartera de servicios es compleja y única, ya que contiene varios servicios SaaS, SDK internos e infraestructura como recursos de código compartido.
El equipo de CPE enfrenta los siguientes desafíos:
Cree y mantenga servicios a nivel de producción. Maneje casos de clientes, errores y fallas de producción y mejore la resiliencia de SaaS. Como cualquier equipo de aplicaciones SaaS normal.
Gánate la confianza de los demás equipos de la organización como asesor de confianza y fuente de conocimiento. Si nadie utiliza tus herramientas, es como si nunca hubieras existido. Aporta valor o desaparece.
Ayudar a los nuevos equipos a llegar a producción e integrarse con los servicios de CPE.
Proporcionar una excelente experiencia de desarrollo y una mentalidad orientada al servicio tanto para los clientes internos como para los externos. Sin embargo, el equipo de CPE contacta a los clientes internos, es decir, los desarrolladores de CyberArk, con más frecuencia que a los externos. Se requiere que ayuden lo antes posible (tenga un desarrollador "bombero" listo para problemas críticos) y esté abierto a los comentarios o críticas. El trabajo del CPE es saber cómo mantener contentos a sus clientes internos. Los clientes satisfechos usan sus productos y los clientes insatisfechos se diversifican y desarrollan soluciones competitivas, lo que contribuye al desperdicio organizacional.
Evite convertirse en un cuello de botella en el desarrollo. Dado que todos los equipos utilizan los mismos servicios y SDK internos de CPE, muchas solicitudes de funciones y errores pueden retrasar a los equipos hasta que CPE los solucione.
Comparta información y conocimiento en toda la organización de manera eficiente. Si desarrolla una nueva función y nadie la usa porque no la conoce, no tiene ningún valor para la organización.
Cómo superamos estos desafíos
Comentarios de clientes internos
A los desarrolladores no les gusta sentirse excluidos o que sus opiniones no se tengan en cuenta.
La retroalimentación es fundamental. A nadie le gusta que le den un montón de soluciones y SDK y que le digan que así es como trabajamos; acéptelo. La comunicación debe ser compartida, para que las opiniones de las personas se escuchen y se tengan en cuenta al diseñar un nuevo SDK o servicio.
En el equipo de CPE, recopilamos los requisitos de todas las partes. Publicamos un documento de diseño de funciones y solicitamos comentarios. Nos aseguramos de que satisfaga las necesidades de todos.
No resolvemos nuestros problemas ni el problema específico de un cliente interno; producimos soluciones que utiliza toda la organización.
Las soluciones y los debates se escriben y documentan en Confluence para futuras referencias. La documentación puede ayudar a convencer a los nuevos equipos en el futuro de que el diseño es sólido y de que CPE tuvo en cuenta todas las alternativas.
Recopilar comentarios en la etapa de diseño es una cosa, pero es aún más importante hacerlo una vez que se lanza la función. Yo recopilo comentarios pidiéndoles comentarios a mis colegas arquitectos o enviando un cuestionario interno.
Necesita comprender si los clientes están usando sus soluciones, por qué no usan algunas de ellas y qué tan satisfechos están.
Mentalidad de código abierto
Comenzamos a tratar nuestros repositorios y el código como código interno de fuente abierta.
Es evidente por varios medios:
Animamos a los desarrolladores de toda la organización a donar código, abrir solicitudes de incorporación de cambios y corregir errores a los que el CPE no puede acceder con la suficiente rapidez. Esto requiere una nueva cultura organizacional, ya que los gerentes de otros equipos deben dedicar tiempo a que sus desarrolladores donen código al CPE. Esto se hace con la convicción de que ayudan a toda la empresa y hacen avanzar no solo su servicio, sino a la organización en su conjunto. Una vez que se fusiona el código, pertenece al CPE y es responsabilidad del equipo de CPE mantenerlo. Por lo tanto, estas donaciones se coordinan con los arquitectos y líderes de equipo del CPE.
Mejora la visibilidad de los cambios: cada repositorio ahora usa las versiones de GitHub para publicar nuevas funciones y correcciones de errores. Cada nueva versión se transmite en los canales del equipo creados para actualizaciones de CPE.
Mejorar la documentación
Puedes tener las mejores utilidades y servicios, pero nadie los usará a menos que sean fáciles de integrar y estén bien documentados. Solíamos tener archivos README largos en nuestros repositorios de GitHub o páginas de guía dispersas en Confluence, y era difícil para los servicios encontrar información. Recibimos esa retroalimentación de los equipos e hicimos un cambio.
Hemos creado un centro de documentación de CPE interno donde puedes encontrar enlaces a todos los sitios web de documentación de servicios y SDK. Cada SDK/servicio tiene su sitio web de documentación basado en páginas de GitHub. Si no sabes qué es la documentación de páginas de GitHub, consulta mi documentación de plantilla Serverless aquí . Es fácil de navegar, tiene un motor de búsqueda interno y debería ofrecer una mejor experiencia que un archivo README largo.
Es importante tener en cuenta que estas páginas de GitHub no reemplazan a otras herramientas organizativas para compartir conocimientos (como Confluence), sino que son un complemento. Cada repositorio debe tener un sitio web que explique qué hace, cómo usarlo con ejemplos de código detallados y que ofrezca enlaces a las páginas de diseño de Confluence.
Defensores del CPE
Mejorar la experiencia de los desarrolladores es parte de mis responsabilidades diarias como arquitecto de sistemas en el grupo CPE. La documentación es excelente y las versiones de GitHub también son fantásticas, pero al final, la gente intenta usar el código y puede encontrar dificultades. En esos casos, es esencial contar con miembros de CPE dedicados que ayuden a otros equipos a integrar los servicios y los SDK de CPE.
¿Cómo se decide que algo pertenece a CPE?
Si se trata de una característica que toda aplicación SaaS empresarial requiere, pertenece a CPE.
En esta categoría, puede encontrar registro, observabilidad, aislamiento de inquilinos, etc.
Si existe un caso de uso compartido entre varios productos o equipos, podría tratarse de una biblioteca o servicio compartido. Sin embargo, a veces la decisión es más compleja.
Por ejemplo, varios servicios requieren un mecanismo para implementar recursos en las cuentas de AWS de los clientes. Cada servicio puede desarrollar y mantener esa capacidad, lo que genera un desperdicio organizacional, ya que todos los servicios crean la misma solución técnica.
Una mejor solución sería dejar que el CPE construya y mantenga una capacidad que se ajuste a todos los requisitos de los servicios.
Para eliminar el cuello de botella de CPE, en algunos casos, otros equipos que podrían tener un cronograma más ajustado comenzarán a desarrollar el servicio de la plataforma (con la orientación de sus arquitectos). Una vez completado, el servicio pasa a ser responsabilidad total de CPE.
Dónde estamos ahora
Cada nueva aplicación SaaS comienza su recorrido con capacitación de CPE, SDK, documentación y orientación.
El grupo CPE ha recibido el sello de aprobación y calidad de la organización.
Seguimos trabajando duro para mantener la confianza que la organización nos ha brindado.
Seguimos mejorando nuestra documentación y reduciendo el esfuerzo de integración.
Seguimos aprendiendo nuevas tecnologías y servicios de AWS y actualizamos nuestras recomendaciones en consecuencia.
Recibimos donaciones de código y solicitudes de relaciones públicas semanalmente. Las solicitudes de funciones y los debates suelen derivar en una donación de código. Los donantes saben que otros equipos se beneficiarán de su trabajo y lo mejor es que no necesitan mantener el código una vez que se fusiona.
¿Cuándo debería iniciar un grupo de CPE?
Esta sección es estrictamente mi propia opinión.
La regla general aquí es que cuanto más grande sea la empresa, más pronto necesitará un grupo de CPE a medida que el desperdicio organizacional se hace cada vez mayor.
Pequeña organización o startup: cuando todos hacen todo, puede haber un solo producto y menos desperdicio. Sin embargo, puedes iniciar un equipo dedicado ad hoc que proporcione un impulso en la infraestructura y los SDK necesarios, que luego se desmantelan.
Empresa mediana/grande que desea iniciar su primera aplicación SaaS - crear un CPE.
Ya en la nube, la empresa ha comenzado a desarrollar múltiples aplicaciones SaaS por parte de numerosos equipos, para crear un CPE.
Supongamos que usted decide iniciar una organización de grupo CPE; ¡genial!
Tenga en cuenta estas conclusiones finales, ya que son las más importantes:
Como actor clave de la organización, es fundamental mantener la más alta calidad, ya sea en la documentación, la investigación y la implementación. Si el CPE falla, todas las aplicaciones SaaS también lo harán.
Comentarios, comentarios y más comentarios. Haz que todos se sientan socios valiosos del CPE. Haz que el diseño sea el correcto o nadie lo usará.
La nube cambia constantemente. Esté atento a los nuevos servicios, mejoras y SDK de AWS. Puede liderar un cambio enorme en su empresa.
¡Buena suerte en tus esfuerzos de CPE!
Para más preguntas no dude en utilizar el formulario de contacto .
Comments