Cuando comencé en la industria del software en la década de 1980, me presentaron la Ley de Conway que establecía que la arquitectura del software y la estructura de la organización de ingeniería están íntimamente relacionadas. La Ley de Conway desapareció de la vista poco después y no escuché mucho hasta los últimos años porque se habla con tanta frecuencia en el contexto de los microservicios.
La página de Wikipedia para la Ley de Conway es entretenida e incluye una nota de Eric S Raymond que explica:
La organización del software y la organización del equipo de software serán congruentes, dijo. Resumiendo un ejemplo en el artículo de Conway, Raymond escribió que “si tienes cuatro grupos trabajando en un compilador, obtendrás un compilador de 4 pasadas”
- ¿Por qué Amazon no ofrece un servicio de búsqueda basado en la nube?
- ¿Cómo se ha beneficiado su negocio de las comunicaciones basadas en la nube?
- ¿Qué son los servicios de computación en la nube?
- ¿Cuál es el gran problema del segmento de tecnología en la nube?
- ¿Qué mejores prácticas debemos seguir al hacer la transición a la nube?
He visto esta alineación en muchas organizaciones a lo largo de las décadas: el equipo de base de datos, el equipo de UI, el equipo de funciones X. En tales casos, lo que posee el equipo está contenido dentro del equipo. Esto no es bueno ni malo, pero darse cuenta de que sí lo es, probablemente sea útil. También estoy seguro de que hay contraejemplos, pero al reflexionar sobre mi experiencia, veo principalmente la alineación.
Ahora, a su pregunta: ¿cuál es la mejor estructura organizativa para adoptar la nube?
Dudo en pensar que sé cuál es el “mejor”, pero permítanme ofrecer dos guías básicas a través de dos casos extremos. Asumiré que el objetivo es una plataforma de nube pública rica en funciones como Amazon Web Services o Microsoft Azure.
Caso 1
Si está realizando un desarrollo de “elevación y cambio” en el que está tomando aplicaciones existentes y moviéndolas a la nube pública para que se ejecuten como hoy, excepto en una VM en la nube, entonces posiblemente su organización actual pueda hacer el trabajo (suponiendo que las cosas funcionen) bastante bien ahora). Esto se debe a que probablemente ya tenga personas en suficientes roles adecuados. Tendrá que cambiar la forma en que implementa … pero supongo que tiene un equipo de implementación. Deberá cambiar algunas configuraciones de red (desde nombres DNS a una canalización privada hasta el centro de datos en la nube) … pero probablemente ya tenga un equipo de redes.
El enfoque de levantar y cambiar es un lugar muy popular para comenzar. Lo he visto funcionar bien. El principal beneficio es que simplemente no es tan disruptivo (incluso organizativo), al tiempo que ofrece una forma de bajo riesgo y baja complejidad para familiarizarse con la nube.
Caso 2
Sería más desafiante si desea aprovechar la nube, más que levantar y cambiar, mediante el uso de servicios más allá de las máquinas virtuales y las redes. Estos pueden ser la base de datos como servicio, mensajería (pub / sub, colas, etc.), equilibrio de carga geográfica, autoescalado, HSM, implementación continua, servicios de identidad (como SSO con Office 365), etc. En contraste con lift & shift, digamos que este es un enfoque ” nativo de la nube “, donde la nube se usa para diseñar sus sistemas, no solo como un lugar alternativo para implementarlos.
Para hacerlo aún más interesante, estipulemos más al mismo tiempo que volverá a diseñar para usar microservicios, implementación continua (CD) y cambiar a una mentalidad devops.
No puedo decir exactamente qué debería ser diferente sobre su estructura organizativa actual, pero puede ser instructivo observar cómo se organizan las operaciones exitosas existentes en la nube. Amazon ofrece un gran ejemplo.
Se dice que el equipo de Amazon.com (que no debe confundirse con el equipo de Amazon Web Services) tiene “2 equipos de pizza” que poseen todos los servicios. Y un equipo de servicio es responsable de diseñar, construir y operar el servicio. Eso significa que (por ejemplo) el equipo que posee el servicio “Comprar con un clic” (desde la interfaz de usuario en adelante) es responsable de actualizar ese servicio (quizás varias veces por semana), gestionando las relaciones con los equipos que operan los servicios que dependen de él y a su vez depende de, corregir todos los errores en ese servicio y manejar los problemas de producción (incluso en medio de la noche). Probablemente pueda ver que tener una estructura organizativa con un equipo de control de calidad monolítico, un equipo de operaciones dedicado, etc., simplemente no se ajusta a este modelo. Al igual que el servicio en sí es independiente de su equipo, también lo es el control de calidad, etc. Tenga en cuenta la realización de la Ley de Conway: la arquitectura de la organización coincide con la arquitectura del sistema.
Tenga en cuenta que el punto principal no es que la organización está optimizada para la nube, per se, sino más bien que la organización es un reflejo de la filosofía de ingeniería de despliegue rápido, minimizando el “lanzamiento por la pared” (sin operaciones separadas o equipo de qa para nuestro servicio, solo “nosotros”), y que esta filosofía se alinea muy bien (desde la rentabilidad, la reducción de la complejidad y la maximización de la flexibilidad) con las aplicaciones nativas de la nube.
