¿Cuáles son los principios que guían vuestra transformación en la nube?

• Por Jonathan Allen, AWS Enterprise Strategist & Evangelist.

Como parte de mi labor como estratega empresarial para AWS, recorro el mundo trabajando en colaboración con líderes de algunas de las organizaciones más grandes del planeta. Uno los retos en materia de liderazgo que las empresas siguen encontrándose cada día es cómo lograr que todos los trabajadores de una empresa tomen decisiones y actúen de forma homogénea y coherente. Nos resulta cómodo pensar que todas las empresas emprenden sus tránsitos de transformación partiendo de la misma situación y tesitura, y resulta fácil dar por sentado que todos comprenden el cómo y el porqué de la transformación. Sin embargo, con frecuencia incluso los equipos ejecutivos que parecen ser más armoniosos (y he trabajado con muchos de ellos) y que piensan que están de acuerdo en el alcance del problema, nunca han conversado sobre cómo alinear esfuerzos apropiadamente y nunca han debatido el cómo y el porqué de la transformación en el contexto de sus sectores de actividad.
Uno de los mecanismos que utilizamos en Amazon para lidiar con estas posibles faltas de armonía y esta ambigüedad es la formulación de principios que guíen la transformación. Así, un equipo deberá formular estos principios, que podrán ser objeto de debate por parte de cualquier miembro del equipo. Si alguien se considera capaz de formular un principio mejor, entonces tendrá la responsabilidad de recomendar un cambio de principios. Tomarse cierto tiempo para definir los principios que guiarán nuestro proceso de adopción de la nube y ofrecer deliberadamente al equipo la capacidad de replanteárselos y corregirlos según vamos descubriendo nuevas posibilidades nos ahorrará muchísimo tiempo.

En mis años de trabajo he colaborado con equipos y he visto a profesionales pasar días, meses e incluso años, (sí, años), creando software e infraestructuras que parecían importantes para luego descubrir que nadie las usa. Uno de los ejemplos más habituales en nuestro sector son los repositorios de datos. Ya he perdido la cuenta de cuántas de las empresas con las que he colaborado tenían a un equipo trabajando en un departamento estanco creando elaboradas instalaciones físicas de Hadoop, con sus recursos de almacenamiento, para luego ver cómo nadie las utiliza para almacenar datos ni para extraer información. Qué pérdida de tiempo y recursos. Con solo habernos puesto de acuerdo de antemano en los principios que regirían nuestros datos, podría haberse evitado. Algo tan simple como: “Cada equipo es responsable de sus datos y debe hacerlos accesibles de forma segura a quien los necesite a través de una API”, podría haberles evitado enormes pérdidas de tiempo y energía.

Las organizaciones que se toman su tiempo para plantear y consensuar unos principios tienen cuatro cosas en común: 1) los principios se utilizan continuamente en la toma de decisiones a nivel macro, lo que evita la creación de soluciones sin valor y evita conflictos internos; 2) las organizaciones suelen lograr una mayor cadencia de comercialización de productos gracias a una toma de decisiones más rápida; 3) los principios se utilizan a todos los niveles para fomentar una mayor coherencia y homogeneidad de acción; 4) los principios se usan como referencias que guían su tránsito hacia la nube.

Aquí, en Amazon, los principios de liderazgo de Amazon son los elementos conductores que nos permiten a todos los empleados tomar decisiones coherentes con los objetivos de la empresa, a cualquier nivel. Nuestro equipo se compone de más de 560.000 profesionales, pero me resulta muy sencillo tener una conversación con cualquiera de ellos sobre “profundizar” en el problema que experimenta un cliente o explicarles por qué me tengo que ausentar de una reunión interna porque la “obsesión por el cliente” requiere toda mi atención. Estos principios fueron diseñados para ser inherentemente polémicos, con el objetivo de suscitar conversaciones en torno a ellos. Cada día, los trabajadores de Amazon reflexionan y sopesan estos principios. En ocasiones tenemos que “profundizar” antes de poder mostrar “preferencia por la acción”. A veces simplemente tenemos que hacer que las cosas funcionen. Cómo utilizar estos principios, por supuesto, requiere decisiones por parte del trabajador, y en nuestros procesos de selección de personal cómo se toman estas decisiones en función de los principios es un factor muy importante.

Entendido todo esto, ¿cómo dar con los principios correctos para la nube?

Mi compañero y buen amigo Joe Chung publicó un gran artículo sobre esta cuestión, que desarrolla con ejemplos muy reveladores. No obstante, querría expandir un poco más las cuestiones que se comentaban en aquel artículo. A lo largo del pasado año, he ayudado a más de 147 organizaciones de todo el mundo en sus respectivos tránsitos a la nube y he dado con un gran número de principios diferentes. Aunque esta lista dista de ser completa, quería ofrecer una lista de ejemplos que cualquiera pudiese copiar, alterar y utilizar conforme considere oportuno y aplicarlos a su empresa. He organizado esta lista de ejemplos de principios estructurándolos en torno a las seis ventajas principales que llevan a las compañías a realizar su tránsito a la nube: seguridad, costes, flexibilidad, adecuación a normativas, disponibilidad y personal.

Seguridad

Seguridad del código fuente: todo el código debe ser almacenado de forma segura en un repositorio centralizado específico para el mismo. Todo acceso a este repositorio estará monitorizado.

Las políticas importan: aunque los equipos tendrán autonomía para escoger sus herramientas, las soluciones elegidas deberán cumplir con los objetivos establecidos en materia de seguridad y disponibilidad.

Reducción de la onda expansiva de las credenciales: reduciremos los accesos al mínimo imprescindible.

Da por entendido que el enemigo conoce tu contraseña: baila como si nadie mirase, usa cifrado como si todos te vieran.

Restringe radicalmente y monitoriza el acceso humano a los datos: fomenta que los usuarios utilicen herramientas para acceder a los datos, en lugar de hacerlo manualmente.

Primará la inmutabilidad: los datos y registros confirmados serán inmutables. Se guardarán copias de los datos de forma independiente a los equipos que mantengan dichos datos.

Confía, pero verifica: confiaremos intrínsecamente en nuestros líderes, ingenieros y desarrolladores a la hora de tomar decisiones acertadas para la protección de nuestros datos y sistemas, pero tendremos mecanismos con los que verificar que esa confianza es acertada.

Hay una seria de herramientas de AWS y de eficaces soluciones de nuestros partners que pueden ayudaros con este aspecto, entre las que se cuentan Turbot, Stratus Cloudtamer, CloudCkr, Savyint, CSRA Agility, Red Hat, Telos, Evident, Cisco Cloud Manager, CloudAbility, Fugue.io y DivvyCloud.

Costes

La nube como prioridad: elimina tanto trabajo no productivo como sea posible; todos los desarrollos deberán ser nativos de la nube.

Deberemos ser nativos de la nube: allí donde sea posible, utilizaremos funcionalidades de AWS, en lugar de crear nuestras propias soluciones. Crearemos el plano de control más liviano posible sobre AWS para sacar el máximo partido a sus eficiencias de escala. Somos conscientes de que lo perfecto es lo enemigo de lo aceptable. Aunque la prioridad será utilizar funcionalidades de AWS, cuando tengamos un bloqueo, innovaremos creando nuestras soluciones a título temporal.

Utilizaré menos software: si un componente se ha convertido en un lujo, no invertiremos valioso tiempo de desarrollo en mantenerlo, sino que lo consumiremos como si fuera un servicio.

En la historia de las empresas esto resulta controvertido, pero hoy en día hasta los contenedores se ejecutan y operan en régimen de servicio. Si vuestros ingenieros ya no están gestionando y montando centros de datos, ¿por qué habrían de crear sus propias plataformas de contenedores?

Nos centraremos en los datos y lógica de nuestros clientes: intentaremos crear y mantener los datos y estructuras lógicas de la compañía, no sistemas que no hacen de nuestro producto algo diferente y más competitivo.

Partner prioritario para nubes públicas: seleccionaremos a un partner para la nube que nos ayude a concentrar nuestros esfuerzos como organización para llegar a ser expertos de la plataforma en cuestión rápidamente, evitándonos así las distracciones que se producen cuando distintos usuarios, procesos y tecnologías utilizan diferentes plataformas.

Nube/producto mínimo viable: investigaremos para determinar cuáles son los objetivos mínimos en materia de seguridad, disponibilidad y eficiencia que deben cumplirse para llevar la primera carga de trabajo de producción a la nube. Expandiremos nuestra investigación para abarcar otras herramientas cuando las funcionalidades que nuestros clientes necesitan así lo exijan.

Cerrar los centros de datos para cierta fecha (quemar las naves): para una fecha determinada, deberemos haber migrado o reubicado todos nuestros sistemas, de forma que nos sea posible cerrar nuestros centros de datos.

Establecer una fecha inamovible, aunque pueda resultar algo abrumador, contribuye a concentrar esfuerzos, crear un impulso de transformación y da a todas las partes implicadas un objetivo irrefutable. En 2015 Rob Alexander (responsable de información mundial de Capital One) hizo su exposición con motivo del evento AWS:Reinvent y nos contó a todos cómo Capital One iba a clausurar múltiples centros de datos y migrarlo todo a la nube de AWS. Este es un ejemplo inequívoco de objetivos declarados.

Ahorra a medida que ingresas: el equipo y el jefe de producto serán responsables de sus gastos en la nube, siempre que representen medios justificados para la creación de activos que representen ganancias económicas para la organización.

La frugalidad es importante: deberemos ser prudentes y controlaremos nuestro gasto en la nube. Los equipos deberían afanarse continuamente en recortar gastos. Los fondos son mucho más productivos cuando se invierten en funcionalidades para los clientes que cuando se gastan en recursos que se desaprovechan.

Flexibilidad

“Two-Pizza Teams”: nos organizaremos en equipos pequeños, de no más de 12 miembros. El nombre viene de la posibilidad de dar de comer a todo el equipo con tan solo dos pizzas. Allí donde fuere posible, los equipos deberán ser autónomos y contar con la capacidad de determinar sus propios objetivos y calendarios.

El que lo crea, lo mantiene: a medida que los nuevos equipos compactos vayan creando nuevas funcionalidades, también deberán llevar la responsabilidad de la asistencia técnica que traen consigo, 24 horas al día, 7 días a la semana. DevOps en su estado más puro.

Me suelen preguntar con frecuencias cómo distribuir las responsabilidades. Lo que buscamos en última instancia es que todos los despliegues de código y todas las operaciones estén automatizadas en gran medida, utilizando flujos de código para todo. Si necesitáis mantener controles de doble confirmación manual, os recomiendo que establezcáis diferentes grados de responsabilidad en cada equipo y/o establecer una aprobación automatizada para vuestros procesos de despliegue.

El equipo que tengo es el equipo que necesito: siempre trabajaremos en actualizar nuestras destrezas, cambiar nuestras herramientas y potenciar nuestra plantilla dotándola de los mejores conocimientos, para que así puedan poner en práctica nuestra visión para la nube. Esta será nuestra prioridad, no la contratación externa.

Los equipos eligen: cada equipo, con su responsable de producto, decidirá cómo crear soluciones y qué herramientas utilizar, siempre que se cumplan los objetivos de la compañía en materia de seguridad y eficiencia.

No hay una solución única que valga para todo: nuestro equipo es amplio y diverso. Utilicemos la herramienta más indicada para cada labor. Nunca daremos por entendido que una herramienta o producto es idónea para todos los supuestos, pero sí tenemos opiniones firmes sobre cómo resolver problemas comunes. Automatizaremos y codificaremos nuestras opiniones en experiencias sencillas e integradas. Eliminaremos y evitaremos deliberadamente las tareas de ingeniería que no contribuyen a diferenciarnos en el mercado y potenciar nuestra competitividad.

Eliminando obstáculos: permitiremos a nuestros equipos de servicio a ser responsables autónomos de sus soluciones bajo AWS. Buscamos descentralizar los proyectos de desarrollo y eliminar dependencias. Preferiremos usar salvaguardas, en lugar de controles. Automatizaremos nuestras auditorías de conformidad a normativas.

Publicaremos nuestras API: publicar nuestras propias API cada vez que creamos una solución garantizará que es posible acceder a los datos y a los productos de forma segura, a través de una API interna y, allí donde fuera razonable, una API externa basada en REST.

Adecuación a normativas y disponibilidad

Todo falla continuamente; diseñemos con ello en mente: diseñaremos y realizaremos testeos de fallos a los niveles que corresponda al problema que intentamos resolver para nuestro cliente. Seguiremos principios de ingeniería que garanticen la fiabilidad, que es algo que nos surge de forma natural.

Fallos en producción: seremos atrevidos y utilizaremos ingeniería del caos para provocar fallos deliberados de los componentes en entornos controlados.

La producción siempre se ha de realizar en múltiples zonas de disponibilidad: los servicios en producción y los datos asociados a ellos siempre deberán operar en más de una zona de disponibilidad en cada momento.

Personal

Todos somos ingenieros de seguridad: todos nos centramos cada día en garantizar que la seguridad es la adecuada.

La programación en pareja funciona: tanto la formación como para el desarrollo de código para producción y la asistencia técnica, seguiremos con frecuencia la práctica de que dos desarrolladores trabajen codo con codo frente a un único ordenador. El total siempre es algo más que la suma de sus partes.

Herramientas indicadas para un aprendizaje continuo: nos aseguraremos de que los desarrolladores cuentan con las herramientas que necesitan para realizar su labor e implantaremos mecanismos destinados a fomentar y recompensar un aprendizaje técnico continuo.

Certificaciones, ante todo: fomentaremos, reconoceremos y recompensaremos a los ingenieros y desarrolladores que obtengan su certificación de AWS.

Llegar al 10%: nuestro objetivo será llegar a que un 10% de ingenieros y desarrolladores cuenten con certificación de AWS.

La contratación de personal deberá ir en armonía con nuestros principios: asegurémonos de que los profesionales que buscamos contratar tienen experiencias demostrables que van en línea con nuestros principios.

Reconozcamos qué motiva a ingenieros y desarrolladores: la motivación surge de la autonomía, el dominio de la profesión y objetivos claros. Demos a nuestros profesionales la capacidad de poner en práctica sus propias ideas, dominarlas y traer el cambio con ellas.