Hace 10 años, en marzo de 2006, se produjo el lanzamiento de Amazon S3. Volviendo la vista atrás, durante este tiempo hemos aprendido cientos de lecciones sobre cómo crear y gestionar servicios de forma que sean seguros, fiables, escalables y con un rendimiento predecible, todo ello al menor coste posible.
AWS (Amazon Web Services) fue pionera en la creación y provisión de estos servicios a nivel global. Con más de un millón de clientes activos al mes, que a su vez ofrecen sus servicios a cientos de millones de usuarios, tenemos un sinfín de oportunidades de obtener más experiencia y un entorno inmejorable que fomenta constantes mejoras.
He escogido unas pocas de estas lecciones para compartirlas con los lectores, con la esperanza de que también sean de utilidad para ellos.
1. Construye sistemas capaces de evolucionar
Casi desde el primer día, fuimos conscientes de que el software que estábamos creando no sería el mismo que estaría en funcionamiento un año más tarde. Nuestras expectativas eran que, al multiplicar nuestra base de clientes por 10 o por 100, tendríamos que reexaminar y replantear nuestras arquitecturas para garantizar que seríamos capaces de responder a posibles problemas de escalabilidad.
Sin embargo, no podíamos adoptar el clásico planteamiento de expandir nuestros sistemas mediante paradas de mantenimiento, ya que un sinfín de empresas de todo el mundo confían en nuestra plataforma para contar con disponibilidad 24×7. Para ello, nos vimos en la necesidad de diseñar arquitecturas que nos permitieran introducir nuevos componentes de software sin vernos en la obligación de interrumpir nuestro servicio.
2. Espera lo inesperado
Los fallos son algo que se da por entendido y, con el tiempo, todo acabará fallando: desde routers hasta discos duros, pasando por sistemas operativos o unidades de memoria que acaban corrompiendo paquetes TCP; todos sufren desde errores pasajeros hasta fallos permanentes. Esto es algo que debe asumirse como inevitable, independientemente de si usamos el hardware de la mayor calidad o los componentes más baratos del mercado.
Esta lección resulta de especial importancia a grandes escalas. Por ejemplo, al procesar billones de transacciones de almacenamiento, todo aquello que tenga la posibilidad de fallar, por remota que sea la probabilidad, acabará haciéndolo. Es posible prever y prepararse ante muchos de estos hipotéticos escenarios de fallo, pero muchos de ellos resultan completas incógnitas a la hora de diseñar y construir los sistemas.
Por ello, nos vimos en la necesidad de construir sistemas diseñados con los fallos entendidos como un fenómeno natural, independientemente del tipo de fallo, incluso si no sabemos qué posibles fallos podemos sufrir. Por así decirlo, los sistemas tienen que continuar funcionando incluso si el edificio está en llamas. Por ello, es de vital importancia poder gestionar los componentes afectados, sin que ello tenga que conllevar la desconexión del sistema. Hemos acabado desarrollando la capacidad de gestionar la “onda expansiva” de posibles errores, de forma que podamos garantizar la integridad general del sistema en todo momento, una capacidad que ha demostrado ser fundamental.
3. Elementos esenciales, no estructuras complejas
Pronto nos dimos cuenta de que las diversas formas en que nuestros clientes querían utilizar nuestros servicios nunca eran fijas y estaban en constante cambio. Cuando nuestros clientes abandonaron las limitaciones del antiguo paradigma informático, constreñido por el hardware y los centros de datos, comenzaron a desarrollar sistemas con nuevos patrones de uso muy interesantes, que nadie había visto antes. Por ello, nos vimos en la necesidad de ser sumamente ágiles para garantizar que estábamos respondiendo eficazmente a sus necesidades.
Uno de los mecanismos más importantes que ofrecimos era dotar a nuestros clientes de un conjunto de elementos esenciales y herramientas que pudieran escoger y utilizar a su gusto para interactuar con la nube de AWS, en lugar de imponerles un entorno que se vieran obligados a utilizar y que incluyera de todo y más. De hecho, las posteriores generaciones de servicios AWS usan los mismos elementos esenciales a los que nuestros clientes ya se han habituado.
También resulta importante comprender que resulta difícil predecir cuáles serán las prioridades de los clientes hasta que tienen el servicio a su disposición y empiezan a utilizarlo para crear sus soluciones. Es precisamente por ello que, cuando ofrecemos nuevos servicios, solemos hacerlo con un conjunto mínimo de funciones, permitiendo a nuestros clientes contribuir a la hoja de ruta que seguimos a la hora de extender el servicio mediante la inclusión de nuevas funciones.
Nuestros servicios incluyen un conjunto mínimo de funciones para que los clientes contribuyan a extenderlo
4. En la automatización está la clave
Desarrollar servicios de software para que sean operados por terceros es algo radicalmente distinto a crear software que se distribuye directamente a clientes. Gestionar sistemas a gran escala requiere una mentalidad completamente diferente, para garantizar que ofrecemos los niveles de fiabilidad, rendimiento y escalabilidad que nuestros clientes esperan de nosotros.
Un mecanismo clave para hacer esto posible es la automatización de la administración de los sistemas en la medida de lo posible, lo que contribuye a eliminar las operaciones manuales, tan dadas a errores. Para hacer esto posible, nos vimos obligados a diseñar API de gestión que nos permitiesen controlar las funciones clave de nuestras operaciones. AWS contribuye además a que sus clientes puedan hacer lo mismo. Al deconstruir sus aplicaciones hasta reducirlas a sus componentes más básicos, cada uno de ellos con su API de gestión, cualquiera puede aplicar normas de automatización, que permiten mantener un rendimiento fiable y predecible a gran escala. Para nosotros, la “prueba del nueve” suele ser la siguiente: si uno necesita utilizar SSH para acceder a un servidor o a una instancia, es que aún queda trabajo de automatización por hacer.
5. Las API son para siempre
Esta es una lección que ya habíamos aprendido de nuestra experiencia con la parte de retail de Amazon, pero que resultó ser aún más importante en el caso del negocio de AWS, tan centrado en API. Una vez nuestros clientes comenzaron a crear sus aplicaciones y sistemas empleando nuestras API, cambiarlas se convirtió en algo imposible ya que, al hacerlo, estaríamos afectando a las operaciones comerciales de nuestros clientes. Sabíamos que diseñar API era una labor sumamente importante, ya que solo tendríamos una oportunidad de hacerlo bien.
6. Conoce bien tu uso de recursos
Al crear un modelo financiero para un servicio con el fin de dar con el modelo de precios más apropiado, recomendamos tener datos lo más sólidos y precisos posible acerca del coste del servicio y sus operaciones, especialmente en el caso de negocios de gran volumen y márgenes de beneficio reducidos.
Como proveedor de servicios, en AWS nos vimos en la necesidad de tener muy presentes nuestros costes, de forma que pudiéramos permitirnos ofrecer servicios a nuestros clientes e identificar los ámbitos en los que pudiéramos mejorar la eficiencia operativa para así reducir costes. Esto, a su vez, nos ha permitido trasladar este ahorro a nuestros clientes, en forma de tarifas más reducidas.
Como ejemplo de esto, en los primeros días de S3 no éramos conscientes de los recursos que eran necesarios para proveer ciertos patrones de uso. Dábamos por hecho que el almacenamiento y el ancho de banda serían los recursos que debíamos facturar a nuestros clientes. Sin embargo, tras cierto tiempo, nos dimos cuenta de que el volumen de solicitudes era un recurso igualmente importante. Así, si los clientes disponían de muchos archivos de pequeño tamaño, los costes de almacenamiento y ancho de banda no serían demasiado altos, incluso si hacían millones de solicitudes. Precisamente por ello, nos vimos en la necesidad de ajustar nuestro modelo, de forma que cubriese todas las dimensiones del uso de recursos, permitiendo así que AWS fuera un negocio sostenible.
Es importante tener datos sólidos y precisos acerca del coste del servicio y sus operaciones
7. Construye tu seguridad partiendo de lo básico
Proteger a los clientes siempre debería ser la prioridad número uno, tanto desde una perspectiva operativa como de herramientas y mecanismos. La seguridad es, y siempre será, nuestro ámbito de inversión número uno.
Un planteamiento que adoptamos muy pronto fue la creación de servicios seguros. Para ello, es necesario integrar la seguridad desde el primer estado del diseño del servicio. El equipo de seguridad no debe entenderse como un grupo que se limita a hacer labores de validación a posteriori, una vez se ha diseñado el servicio. El personal de seguridad debe tomar parte desde el primer día, para garantizar que la seguridad es férrea desde el principio. En lo que respecta a la seguridad, no debes haber concesiones.
8. El cifrado de datos entendido como un ciudadano de primera categoría
El cifrado de datos es una herramienta clave para los clientes, ya que les permite asegurarse de que tienen un control total sobre quién puede acceder a sus datos. Hace 10 años, las herramientas y servicios de cifrado resultaban difíciles de utilizar, pero con el tiempo dimos con la mejor forma de integrar el cifrado de datos en nuestros servicios.
Todo comenzó por ofrecer cifrado de datos desde los servidores en S3 para aquellos usos que requerían adecuarse a ciertas normativas. Si uno accediese a cualquiera de los discos de nuestros centros de datos, no encontraría datos que resultasen accesibles. Sin embargo, con el lanzamiento de Amazon CloudHSM (para modelos de seguridad de hardware) y, posteriormente, con Amazon Key Management Service, ofrecimos a nuestros clientes la capacidad de utilizar sus propias claves de cifrado, lo que eliminaba la necesidad de que tuviéramos que gestionar las claves de nuestros clientes.
Desde hace ya años, hemos integrado funciones de cifrado de datos directamente en la fase de diseño de cada nuevo servicio. Por ejemplo, en Amazon Redshift, cada uno de los bloques de datos está cifrado por defecto con una clave aleatoria y el conjunto de estas claves aleatorias está cifrado, a su vez, con una clave maestra. Ofrecemos a nuestros clientes la posibilidad que sean ellos los que determinen cuál será la clave maestra, garantizando así que sean únicamente ellos quienes puedan descifrar y acceder a los datos críticos de sus negocios o a datos que contengan datos personales.
Integramos funciones de cifrado de datos directamente en la fase de diseño de cada nuevo servicio
9. La importancia de la red
AWS es ahora compatible con muchas cargas de trabajo diferentes: desde el procesamiento de grandes volúmenes de transacciones, hasta la transcodificacion de vídeo, pasando por la computación paralelizada de alto rendimiento o el tráfico Web a gran escala. Cada una de estas cargas de trabajo conlleva requisitos específicos en lo que respecta a la red.
AWS ha desarrollado la capacidad de innovar en el diseño y operación de sus centros de datos, lo que nos permite disponer de infraestructuras de red flexibles, capaces de adaptarse para responder a las necesidades de las cargas de trabajo de nuestros clientes, sean cuales sean. Con el tiempo, hemos aprendido que uno nunca debe dejarse intimidar por la perspectiva de tener que desarrollar soluciones de hardware propias, con el fin de garantizar que nuestros clientes puedan alcanzar sus objetivos. Esto nos permite responder a necesidades muy específicas, como la capacidad de aislar a unos clientes de AWS de otros en la red, garantizando así las cotas más altas de seguridad.
Otro ejemplo exitoso de cómo el hardware y software de redes diseñado por AWS nos ha permitido mejorar nuestro rendimiento fue nuestro planteamiento al abordar las solicitaciones que la virtualización impone sobre la infraestructura de red, fruto del acceso a la red por parte de las máquinas virtuales. Al ser el acceso de red un recurso compartido, en ocasiones nuestros clientes experimentaban ciertos bloqueos puntuales en la red. Respondimos a este problema desarrollando adaptadores de red compatibles con la especificación SR-IOV (Single Root I/O Virtualization), lo que nos permitió asignar a cada máquina virtual su propio adaptador de red, virtualizado de forma nativa por hardware. Esto contribuyó a reducir la latencia a menos de la mitad y resultó en una variabilidad de la latencia en la red 10 veces mejor a la experimentada previamente.
10. Nadie dicta las normas
A lo largo de los años, el equipo de AWS ha creado muchos servicios y funciones, creando con ello una gran plataforma llena de posibilidades. Sin embargo, AWS es mucho más que el conjunto de servicios que hemos diseñado, es un ecosistema sumamente rico que incluye servicios ofrecidos por nuestros partners y que extiende la plataforma en un sinfín de nuevas direcciones.
Así, por ejemplo, tenemos a partners como Stripe, que ofrece servicios de gestión de pagos, o Twilio, que ofrece servicios de telefonía programable a través de AWS. Además, muchos de nuestros clientes también están creando plataformas sobre AWS, con el fin de responder a sus propias necesidades verticales: Philips, por ejemplo, está creando su plataforma Healthsuite Digital Platform para la gestión de datos sanitarios; Ohpen ha creado una plataforma de banca comercial sobre AWS; y Eagle Genomics ha diseñado una plataforma de procesamiento de datos genéticos. Y como estos, hay un sinfín más de ejemplos.
Nadie dicta las normas de qué es posible y qué no. Esto es un principio que abre las puertas a la innovación
Lo que resulta esencial para que todo esto sea posible es que, en la plataforma de AWS, nadie dicta las normas de qué es posible y qué no en la plataforma. “Nadie dicta las normas” es un principio que abre las puertas a la innovación, lo que resulta un sinfín de invenciones inesperadas.
Francamente, espero con ilusión ver qué vamos a aprender y qué van a lograr nuestros clientes a lo largo de los próximos 10 años.
Y recuerda, como decía Jeff Bezos, aún estamos en el primer día…
