Implementación de Amazon Web Services

10 lecciones de 10 años de Amazon Web Services

Carlos Olivares Amazon Web Services Leave a Comment

Werner Vogels, CTO de Amazon, comenta las más importantes lecciones que se han aprendido a lo largo del desarrollo e implementación de Amazon Web Services, a 10 años de su lanzamiento. Diez aprendizajes que se pueden extrapolar e implementar en cualquier negocio online.

La época de inicio de la implementación de Amazon Web Services (AWS) es la del lanzamiento de Amazon S3, el 14 de marzo de 2006, hace casi 10 años. En retrospectiva, en estos 10 años hubo cientos de lecciones aprendidas acerca de construir y operar servicios que necesitan ser seguros, confiables, escalables y predecibles al menor costo posible.

Dado que AWS es pionero en construir y operar estos servicios a nivel mundial, estas lecciones han sido de importancia crucial para nuestro negocio.

Como hemos dicho tantas veces: “No hay algoritmo de compresión para la experiencia”.

Con más de un millón de usuarios activos al mes, quienes a su vez pueden servir a miles de millones de clientes, no escasean las oportunidades para ganar más experiencia y tal vez no haya un mejor ambiente para la mejora continua en la forma como servimos a nuestros clientes.

¿Quiere migrar los sistemas de su empresa a la nube con Amazon Web Services?

En GPC somos especialistas y estamos certificados por AWS. Contamos con un equipo competitivo que tiene años de experiencia.

SOLICITE SU COTIZACIÓN AQUÍ

He escogido algunas de esas lecciones para compartirlas con ustedes, deseando que puedan serles útiles también.

1. Construye sistemas que puedan evolucionar

Construye sistemas que puedan evolucionar

Casi desde el primer día, sabíamos que el software que estábamos construyendo no sería el que estaríamos corriendo el año siguiente. La expectativa era que con cada salto de crecimiento necesitaríamos volver, revisar la arquitectura y asegurarnos de que podríamos atender problemas de mayor escala.

No podíamos adoptar el viejo estilo de hacer actualizaciones de sistemas mediante cortes por mantenimiento, ya que muchos negocios alrededor del mundo se sostienen de nuestra plataforma y de su disponibilidad 24/7.

Necesitábamos construir una arquitectura tal que pudiésemos introducir nuevos componentes de software sin tener que darle de baja al servicio.

Marvin Theimer, ingeniero distinguido de Amazon, dijo una vez en broma que la evolución de Amazon S3 podría describirse mejor como haber comenzado con una sencilla avioneta Cessna que con el pasar del tiempo se fue transformando en un 737, luego en un grupo de 747s, hasta llegar a ser la gran flota de Airbus 380 que es ahora.

Todo esto sucediendo mientras llenábamos combustible en pleno vuelo y movíamos a los pasajeros de un avión a otro sin que se dieran cuenta.

2. Espera lo inesperado

Espera lo inesperado

Los fallos son un hecho y todo eventualmente fallará con el pasar del tiempo: desde routers hasta discos duros, desde sistemas operativos hasta unidades de memoria corrompiendo paquetes TCP, desde errores transitorios hasta fallos permanentes. Es un hecho, estés usando hardware de la mejor calidad o componentes de bajo costo.

Esto se vuelve una lección mucho más importante a mayor escala. Por ejemplo, como S3 procesa trillones y trillones de transacciones de almacenamiento, cualquier error con muy baja probabilidad de suceder, sucederá. Muchos de estos escenarios de error pueden ser anticipados de antemano, pero muchos más son desconocidos al momento del diseño y construcción.

Necesitábamos construir sistemas que asumieran el error como una ocurrencia natural incluso sin saber en qué consistirá el error. Los sistemas tienen que mantenerse funcionando incluso si la “casa se está incendiando”. Es importante poder manipular aisladamente las partes que se vean afectadas sin tener que detener el sistema entero.

Hemos desarrollado la habilidad de atender el “radio de onda expansiva” de un fallo, de tal forma que podemos mantener la salud general del sistema.

3. Sólo lo básico, sin frameworks

Solo lo básico. Sin frameworks

Rápidamente nos dimos cuenta de que la forma como a los clientes les gusta usar nuestros servicios era impredecible.

Cuando los clientes se alejan de las restricciones del viejo mundo del hardware y los datacenters, comienzan a desarrollar sistemas con nuevos e interesantes patrones de uso que nadie había visto antes. En este sentido, tuvimos que ser muy ágiles para asegurarnos de que atendíamos las necesidades de nuestros clientes.

Uno de los mecanismos más importantes que implementamos fue ofrecerle a los clientes una serie de servicios y herramientas básicas, de las que ellos pudiesen elegir y decidir la forma como quisieran abordar la nube de AWS, en lugar de proveerles de un único framework que estuvieran obligados a usar aunque tuviera todas las opciones imaginables.

Esta aproximación permitió a nuestros usuarios ser tan exitosos que incluso generaciones posteriores de servicios AWS hacen uso de las mismas herramientas y servicios básicos a las que se han acostumbrados nuestros clientes.

Es importante notar lo difícil que es predecir las prioridades de tus usuarios hasta que tienen el servicio en sus manos y realmente comienzan a construir con él. Por eso entregamos nuestros nuevos servicios con la menor cantidad de funcionalidades y vamos dejando que sean los usuarios quienes nos ayuden a ampliarles el servicio con nuevas características.

4. La automatización es clave

La automatización es clave

Desarrollar servicios de software para ser operados, es radicalmente diferente a crear softwares que funcionen a los clientes. Administrar sistemas a gran escala requiere un estado mental diferente para asegurarse de cumplir con las expectativas de confiabilidad, desempeño y escalabilidad de nuestros clientes.

Un mecanismo clave para lograr esto es automatizar la administración lo máximo posible, eliminando las operaciones manuales, tan propensas a error. Para hacer eso tuvimos que construir APIs de administración que controlaran las funcionalidades clave de nuestras operaciones.

AWS también ayuda a sus usuarios a hacer esto.

Descomponiendo tus aplicaciones en bloques esenciales de construcción, cada uno con una API de administración, puedes aplicar reglas de automatización que mantengan confiable y predecible el desempeño a escala. Una buena forma de comprobar esto es que si necesitas hacer SSH en un servidor o una instancia, todavía tienes cosas por automatizar.

5. Las APIs son para siempre

Las Apis son para siempre

Esta es una lección que ya habíamos aprendido de nuestras experiencias con las ventas de Amazon, pero se hizo mucho más importante para el negocio centrado en APIs de AWS. Una vez que los clientes comienzan a construir sus aplicaciones y sistemas usando nuestras APIs, cambiar esas APIs se vuelve imposible, porque estaríamos impactando en las operaciones de negocio de nuestros clientes si lo hiciéramos.

Nos dimos cuenta que diseñar APIs era una tarea muy importante cuando teníamos solo una oportunidad para hacerlo bien.

¿Quiere migrar los sistemas de su empresa a la nube con Amazon Web Services?

En GPC somos especialistas y estamos certificados por AWS. Contamos con un equipo competitivo que tiene años de experiencia.

SOLICITE SU COTIZACIÓN AQUÍ

6. Conoce tu uso de recursos

Conoce tu uso de recursos

Cuando construyes un modelo financiero a un servicio para identificar el modelo apropiado de cobro, tienes que asegurarte de tener buena data sobre los costos del servicio y sus operaciones, especialmente si llevas un negocio de alto volumen y bajos márgenes de ganancia. En AWS tuvimos que ser muy conscientes de nuestros costos como proveedores de servicios para poder asumir la oferta a nuestros clientes, e identificar áreas en donde pudiéramos aplicar eficiencia operacional para reducir más los costos y entonces ofrecer esos ahorros de nuevo a nuestros clientes en forma de precios más bajos.

Un ejemplo de los primeros días, cuando no sabíamos los recursos requeridos por S3 para ofrecer ciertos patrones de uso, asumimos que el almacenamiento y el ancho de banda eran los recursos por los que debíamos cobrar. Luego de hacerlo por un tiempo, nos dimos cuenta de que el número de requerimientos al servidor era un recurso igual de importante. Si los clientes tienen muchos archivos pequeños, el espacio y el ancho de banda no suman mucho, incluso haciendo millones de requerimientos. Tuvimos que ajustar nuestro modelo para dar cuenta de todas las dimensiones de uso de recursos para que AWS fuera un negocio sostenible.

7. Construir seguridad desde cero

Construir seguridad desde cero

Proteger a tus usuarios debe ser siempre tu principal prioridad, y así ha sido para AWS… desde la perspectiva operacional hasta las herramientas y mecanismos, será siempre nuestra área de inversión número uno.
Una aproximación que aprendimos rápidamente fue que para construir servicios confiables es necesario integrar protección desde el inicio del diseño. El equipo de seguridad no es un equipo que valida algo luego de que está construido. Ellos deben ser nuestros socios desde el primer día, para garantizar que la seguridad es roca sólida desde el comienzo.

8. La encriptación es clave

La encriptación es clave

La encriptación es un mecanismo clave para dar seguridad a los clientes de que están en total control sobre quién tiene acceso a sus datos. Hace diez años las herramientas y servicios de encriptación eran difíciles de usar y no fue sino hasta hace unos años que aprendimos la mejor forma de integrar la encriptación en nuestros servicios.

Comenzamos por proveer encriptación del lado del servidor en S3 para casos de uso obligatorio. Si hubieras inspeccionado cualquier disco en nuestros datacenters, ninguna data hubiera sido accesible.

Pero con el lanzamiento de Amazon CloudHSM (para modelos de seguridad de hardware) y luego el Amazon Key Management Service, los clientes pueden usar sus propias claves de encriptación, lo que eliminó a AWS la necesidad de administrar sus claves.

Desde hace tiempo hemos integrado a la fase de diseño de cada nuevo servicio, el soporte para la encriptación.

Por ejemplo, en Amazon Redshift cada uno de los bloques de datos es encriptado por defecto con una clave aleatoria y el conjunto de estas claves aleatorias es encriptado de nuevo con una clave maestra. La clave maestra puede ser proporcionada por los clientes, asegurando que ellos son los únicos que pueden desencriptar y tener acceso a sus datos de identificación personales e información crítica de su negocio.

La encriptación sigue siendo de alta prioridad para nuestro negocio. Continuaremos haciendo aún más fácil para nuestros clientes el hacer uso de la encriptación para protegerse a sí mismos y a sus propios usuarios.

9. La importancia de la red

La importancia de la red

AWS ha venido soportando muchas y diferentes cargas de trabajo. Desde procesamiento de alto volumen de transacciones hasta transcodificación de video a gran escala, desde computación paralela de alto desempeño hasta tráfico masivo de sitios web. Cada una de esas cargas de trabajo tiene requerimientos únicos cuando se trata de la red.

AWS ha desarrollado una habilidad única para innovar en diseño y operación de datacenters, con la que podemos tener infraestructuras de red flexibles que pueden adaptarse para satisfacer las necesidades de nuestros usuarios, cualesquiera que sean estas. Hemos aprendido con el tiempo que no debemos temer a desarrollar nuestras propias soluciones de hardware para asegurar que nuestros clientes alcancen sus metas.

Esto nos permite satisfacer nuestros propios requerimientos específicos, como la habilidad de aislar unos de otros a los clientes de AWS en la red y conseguir los más altos niveles de seguridad.

Otro ejemplo exitoso de cómo el hardware y software de redes diseñado en AWS nos permite mejorar más nuestro desempeño con nuestros clientes, fue abordar el costo de la virtualización de acceso a redes desde máquinas virtuales. Como el acceso a la red es un recurso compartido, los clientes podían experimentar por momentos una significativa inestabilidad en la red.

Desarrollar un NIC que soportara virtualización IO de raíz única, nos permitió dar a cada máquina virtual su propio NIC virtualizado. Esto redujo la latencia en más del doble y mejoró más de diez veces la variabilidad de la latencia sobre la red.

10. Sin barreras

Sin barreras

El equipo de AWS ha creado muchos servicios con muchas características para ofrecer una amplia y profunda plataforma a nuestros usuarios. Pero AWS es mucho más que sus servicios construidos “en casa”. Existe un rico ecosistema de servicios ofrecidos por nuestros socios que extiende la plataforma en muchas direcciones nuevas.

Por ejemplo, tenemos socios como Stripe ofreciendo servicios de pago o Twilio haciendo telefonía programable en AWS. Muchos de nuestros clientes también construyen sus propias plataformas sobre AWS para cubrir necesidades específicas. Philips construye su Healthsuite Digital Platform para administrar datos de cuidados de salud, Ohpen construyó una plataforma para ofrecer banca a negocios retail, Eagle Genomics ha construido una plataforma de procesamiento genómico, y muchos más. Lo que es esencial es que no hay barreras en la plataforma AWS que le digan a nuestros socios lo que pueden hacer o no. “Sin barreras”, se liberan los procesos innovadores y se abren las puertas a invenciones inesperadas que seguro están por ocurrir.

Espero poder ver lo nuevo que aprendamos -y logren nuestros clientes de AWS- en los próximos 10 años. Y recuerda, ya es el día uno…


Este artículo es una traducción libre del texto 10 Lessons from 10 Years of Amazon Web Services, publicado originalmente por Werner Vogels en su blog All Things Distributed.

¿Quiere migrar los sistemas de su empresa a la nube con Amazon Web Services?

En GPC somos especialistas y estamos certificados por AWS. Contamos con un equipo competitivo que tiene años de experiencia.

SOLICITE SU COTIZACIÓN AQUÍ

Comparte esta entrada

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *