Construyendo un Data Lake en AWS
Logs con ElasticSearch
Using Bootstrap Actions in EMR – Amazon (AWS)
Dentro del conjunto de herramientas que ofrece AWS para Big Data, EMR es una de las más versátiles y poderosas, brindando al usuario un sinfín de opciones de hardware y software con el propósito de enfrentar cualquier desafío -y tener éxito- relacionado con el procesamiento de grandes volúmenes de datos. Sin embargo, un usuario que trabaje con la consola EMR por primera vez encontrará que las opciones están empaquetadas en una lista generosa, pero limitada, de configuraciones de software y hardware, y puede llegar a la conclusión -¡equivocada!- de que EMR no tiene lo que se necesita para la tarea. Consola Web: Creando un Cluster de EMR En este artículo nos centraremos en estudiar cómo incluir elementos de software adicionales y/o diferentes a los que se ofrecen en el paquete de la consola Web, y dejaremos la configuración del Hardware y otras opciones para otro momento. Maestro contra esclavo Uno de los primeros desafíos para comprender cómo incorporar realmente el software en EMR es tener claro la infraestructura de hardware y software que admite EMR. En términos muy simples, solo hay 2 categorías: Master y Slave (Master + Slaves = Cluster). Map-Reduce es un modelo de programación que se beneficia de la capacidad de «divide para vencer», estableciendo cargas de trabajo para los múltiples nodos del clúster, distribuyendo y organizando las tareas de cada nodo para que un gran trabajo se convierta en pequeños trabajos múltiples, generalmente más fáciles y rápidos de realizar. completo en comparación con tratar de asumir el trabajo como una unidad completa. Modelo programático EMR En este modelo cada nodo recibe una carga de trabajo, para luego trabajar sobre ella, y finalmente entregar un resultado consolidado por el nodo maestro. Clúster EMR: Master Node y Slave Node trabajando juntos para resolver el trabajo de acuerdo con los algoritmos Map-Reduce. Para que todo esto funcione, el software incorporado en los nodos esclavos debe “corresponder” al software del nodo maestro, y así poder “hablar” correctamente durante la ejecución del trabajo del clúster. Cuando nos conectamos al clúster, normalmente lo que hacemos es conectarnos al nodo líder, ya través de este llevamos a cabo la ejecución de la obra. Es en este mismo nodo líder donde podemos tomar control remoto vía SSH, y realizar actividades a nivel de sistema operativo, como, por ejemplo, instalar nuevo software, o alterar la configuración del software ya instalado. Sin embargo, es fundamental tener en cuenta que el nodo líder no replica ni distribuye estas modificaciones al resto de nodos del clúster, por lo que si instalamos una nueva biblioteca, como Boto3, solo estará disponible en el nodo Líder, dejando a los nodos esclavos incapaces de abordar las tareas que requieren esta biblioteca, y luego cualquier trabajo que la requiera no se ejecutará. La lección que debemos aprender es muy simple: el software debe instalarse y configurarse ANTES de que exista el clúster. De lo contrario, los cambios de configuración y el software instalado solo estarán disponibles en el nodo maestro. ¿Cómo? Muy simple: con acciones de arranque. arranque Bueno, puede que no sea tan simple al principio, especialmente si no está acostumbrado a ejecutar scripts Bash en Linux. Sin embargo, ese es, en términos generales, el único desafío para comenzar a trabajar con EMR y Bootstrap Actions. Las acciones Bootstrap son esencialmente scripts Bash para Linux, que automatizan la ejecución de los pasos de instalación o la manipulación de la configuración del software instalado y del sistema operativo en general. Una supersimplificación del punto anterior es: cada paso que realizaría un humano con el mando de una consola de SSH en Linux, se lo puede llevar a una línea de un script de Bash, que se puede ejecutar de forma automática. , sin supervisión humana. Por ejemplo, para instalar Boto3: sudo pip install -U awscli boto Luego, se convierte en un script Bash. Llamaremos a este archivo install_boto3.sh: #!/bin/bash sudo pip install -U awscli boto Y finalmente lo guardamos en S3: s3://mi_bucket/scripts/install_boto3.sh Sencillo, ¿no? Ahora solo necesita hacer referencia a este script en una acción de Bootstrap desde la configuración durante la creación del clúster. Básicamente hay 2 opciones para hacer esto (hay más opciones para lanzar un clúster, pero estas son las más utilizadas): 1. Uso de la consola web Siguiendo las opciones avanzadas, en el paso 3 de la configuración durante la creación del clúster, abra la sección «Acciones de Bootstrap» Aparecerán las opciones para referenciar el script ya guardado en S3: Y finalmente solo queda lanzar la creación del clúster, siguiendo los pasos restantes de la configuración. 2. Uso de la CLI de AWS Esta opción es la más fácil de controlar y ejecutar. Requiere tener instalado y configurado correctamente AWS CLI con nuestra cuenta de AWS. Simplemente ejecute en nuestra CLI la siguiente línea de comandos: aws emr create-cluster –applications Name=Hadoop Name=Hive Name=Pig Name=Hue Name=Spark Name=Zeppelin –ec2-attributes ‘{«KeyName»:»mi_cluster»,»InstanceProfile»:»EMR_EC2_Profile»,» SubnetId»:»subnet-XXXXXXXXX»,»EmrManagedSlaveSecurityGroup»:»sg-XXXXXXXXX»,»EmrManagedMasterSecurityGroup»:»sg-XXXXXXXXX»}’ –release-label emr-5.12.0 –log-uri ‘s3n:// aws-logs-XXXXXXXXXXXXXXX-us-east-1/elasticmapreduce/’ –steps ‘[{«Args»:[«spark-submit»,»–deploy-mode»,»cluster»,»–driver-cores «,»1″,»–maximizeResourceAllocation»,»s3://mi_bucket/scripts/mi_script_python.py»],»Tipo»:»CUSTOM_JAR»,«ActionOnFailure»:»CANCEL_AND_WAIT»,»Jar»:»command-runner.jar»,»Properties»:»»,»Name»:»Mi Programa Spark»}]’ –instance-groups ‘[{«InstanceCount» :4,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»CORE» ,»InstanceType»: «r4.xlarge»,»Name»:»Core – 2″},{«InstanceCount»:1,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32 ,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»MASTER»,»InstanceType»: «r4.xlarge»,»Name»:»Master – 1″}]’ –bootstrap-actions ‘[{«Path»:»s3://mi_bucket/scripts/install-boto3. sh»,»Name»:»Instalar Boto3″}]’ –ebs-root-volume-size 50 –service-role EMR_Role –enable-debugging–name ‘mi_aplicacion’ –scale-down-behavior TERMINATE_AT_TASK_COMPLETION –region us-east-1 Vale la pena señalar que este comando es una sola línea de texto , que se ha dividido aquí para facilitar la lectura. Hay parámetros que son opcionales (es decir , –enable-debugging ) y otros que dependen de los recursos de infraestructura de su propia cuenta de AWS (es decir, ID de grupos de seguridad, nombres de perfiles de instancia como » EMR_EC2_Profile » y roles de servicio, como –service- rol EMR_Role , entre otros). Puede parecer un poco difícil de manejar al principio, pero en la práctica es la opción más fácil y rápida para lanzar un clúster, y con el tiempo es fácil acostumbrarse. 3. Recursos públicos Como no siempre somos los primeros en enfrentar un problema, la mayoría de las veces es posible encontrar a alguien que haya resuelto el problema antes que nosotros. Y una buena parte de esas veces, que alguien ha sido tan amable de poner la solución
Incorporando Acciones de Bootstrap en EMR – Amazon (AWS)
Dentro del conjunto de herramientas que AWS ofrece para Big Data, EMR es una de las más versátiles y potentes, poniendo a disposición del usuario un sinfín de opciones de hardware y software con el fin de enfrentar – con todo éxito- cualquier desafío relacionado con el procesamiento de grandes volúmenes de datos. Sin embargo, un usuario que se encuentra ante la consola de EMR por primera vez encuentra que las opciones se encuentran empaquetadas en una lista -generosa, pero limitada- de configuraciones de software y hardware, y quizás sacar la conclusión -errónea!- de que EMR no tiene lo necesario para la tarea. Consola Web: Creando un Cluster de EMR En este artículo nos enfocaremos en estudiar cómo incorporar elementos de software adicionales y/o distintos a los ofrecidos en el paquete de la consola Web, y dejaremos las configuraciones de Hardware y otras opciones para otra oportunidad. Líder contra Esclavo Uno de los primeros desafíos para entender cómo incorporar software a EMR es tener claridad acerca de la infraestructura de hardware y software que da soporte a EMR. En términos muy sencillos, existen simplemente dos categorías: Líder y Esclavo (Lider + Esclavos = Cluster). Map-Reduce es un modelo de programación que se beneficia de la capacidad de “dividir para conquistar”, utilizar cargas de trabajo para los múltiples nodos del clúster, distribuyendo y organizando las tareas de cada nodo de modo que un gran trabajo se vuelve múltiples trabajos pequeños, normalmente más fáciles y rápidos de completar comparados con intentar abordar el trabajo como una unidad. Modelo programático de EMR En este modelo cada nodo recibe una carga de trabajo, para trabajar luego en ella, y finalmente entrega un resultado que es consolidado por el nodo líder. Cluster EMR: Nodo Líder y Nodos Esclavos trabajan en conjunto para resolver el trabajo según algoritmos Map-Reduce Para que todo esto funcione, el software incorporado en los nodos esclavos debe estar “de acuerdo” con el software del nodo líder, y así poder “conversar” adecuadamente durante la ejecución del trabajo del clúster. Cuando nos conectamos al clúster, normalmente lo que hacemos es conectarnos al nodo líder, ya través de este llevamos a cabo la ejecución del trabajo. Es en este mismo nodo líder donde podemos tomar control remoto vía SSH, y realizar actividades a nivel de sistema operativo, como -por ejemplo- instalar nuevo software, o alterar la configuración del software ya instalado. Sin embargo, es imprescindible tener presente que el nodo líder no replica ni distribuye estas modificaciones al resto de los nodos del clúster, por lo que si instalamos una nueva librería -como por ejemplo Boto3- esta sólo estará disponible en el nodo Líder, dejando a los nodos Esclavos incapaces de abordar tareas que requieren de esta librería, y luego cualquier trabajo que la requiera fallará en ejecutarse. La lección que debemos sacar es muy sencilla: el software se debe instalar y configurar ANTES de que exista el clúster. De lo contrario, los cambios de configuración, y el software instalado, sólo estarán disponibles en el nodo Líder. ¿Cómo? Pues muy simple: con acciones de bootstrap. arranque Bueno, puede no resultar tan simple en un comienzo, especialmente si no están acostumbrados a realizar scripts de Bash en Linux. Sin embargo eso es, a grandes características, el único desafío para comenzar a trabajar con EMR y Acciones de Bootstrap. Las Acciones de Bootstrap son suficientes scripts de Bash para Linux, que automatizan la ejecución de pasos de instalación o manejo de configuración del software instalado y del sistema operativo en general. Una súper-simplificación de lo anterior es: cada paso que realizaría un humano al mando de una consola de SSH en Linux, es posible llevar a una línea de un script de Bash, que se puede ejecutar de forma automática, sin supervisión humana. Por ejemplo, para instalar Boto3: sudo pip install -U awscli boto Luego, esto se convierte en un script de Bash. Llamemos a este archivo install_boto3.sh: #!/bin/bash sudo pip install -U awscli boto Y finalmente lo guardamos en S3: s3://mi_bucket/scripts/install_boto3.sh Sencillo, ¿verdad?. Ahora sólo resta referenciar este script en una acción de Bootstrap desde la configuración durante la creación del clúster. Para esto, hay básicamente dos opciones (hay más opciones para lanzar un clúster, pero estas son las dos más utilizadas): 1. Uso de la consola Web Siguiendo las opciones avanzadas, en el paso 3 de la configuración durante la creación del clúster, abra la sección de Acciones de Bootstrap (Bootstrap Actions) Aparecerán las opciones para referenciar el guión que ya tenemos en S3: Y finalmente sólo resta lanzar la creación del clúster, continuando los pasos restantes de configuración. 2. Uso de la CLI de AWS Esta es la opción más fácil de controlar y ejecutar. Requiere tener la AWS CLI apropiadamente instalada y configurada con nuestra cuenta de AWS. Basta ejecutar con nuestro CLI la siguiente línea de comandos: aws emr create-cluster –applications Name=Hadoop Name=Hive Name=Pig Name=Hue Name=Spark Name=Zeppelin –ec2-attributes ‘{«KeyName»:»mi_cluster»,»InstanceProfile»:»EMR_EC2_Profile»,» SubnetId»:»subnet-XXXXXXXXX»,»EmrManagedSlaveSecurityGroup»:»sg-XXXXXXXXX»,»EmrManagedMasterSecurityGroup»:»sg-XXXXXXXXX»}’ –release-label emr-5.12.0 –log-uri ‘s3n:// aws-logs-XXXXXXXXXXXXXXX-us-east-1/elasticmapreduce/’ –steps ‘[{«Args»:[«spark-submit»,»–deploy-mode»,»cluster»,»–driver-cores «,»1″,»–maximizeResourceAllocation»,»s3://mi_bucket/scripts/mi_script_python.py»],»Tipo»:»CUSTOM_JAR», «ActionOnFailure»:»CANCEL_AND_WAIT»,»Jar»:»command-runner.jar»,»Properties»:»»,»Name»:»Mi Programa Spark»}]’ –instance-groups ‘[{«InstanceCount» :4,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»CORE» ,»InstanceType»: «r4.xlarge»,»Name»:»Core – 2″},{«InstanceCount»:1,»EbsConfiguration»:{«EbsBlockDeviceConfigs»:[{«VolumeSpecification»:{«SizeInGB»:32 ,»VolumeType»:»gp2″},»VolumesPerInstance»:1}]},»InstanceGroupType»:»MASTER»,»InstanceType»: «r4.xlarge»,»Name»:»Master – 1″}]’ –bootstrap-actions ‘[{«Path»:»s3://mi_bucket/scripts/install-boto3. sh»,»Name»:»Instalar Boto3″}]’ –ebs-root-volume-size 50 –service-role EMR_Role –enable-debugging –name ‘mi_aplicacion’ –scale-down-behavior TERMINATE_AT_TASK_COMPLETION –region us-east-1 Cabe resaltar que este comando es una sola línea de texto , que aquí hemos separado en varias líneas para facilitar la lectura. Hay varios parámetros que son opcionales (ej: –enable-debugging ) y otros que dependen de los recursos de infraestructura de su propia cuenta de AWS (ej: IDs de grupos de seguridad, nombres de perfiles de instancia como “ EMR_EC2_Profile ” y roles de servicio, como –service-role EMR_Role , entre otros). Puede parecer un tanto difícil de manejar al principio, pero en la práctica es la opción más fácil y rápida de lanzar un clúster, y con el tiempo es fácil acostumbrarse. 3. Recursos Públicos Como no siempre somos los primeros en enfrentar un problema, la mayoría de las veces es posible encontrar a alguien que haya resuelto el problema antes que nosotros. Y buena parte de esas veces, ese alguien ha
Mantenimiento Básico de Redshift – Amazon (AWS)
Dentro de los muchos factores que podrían afectar la facturación de Amazon Redshift en una cuenta de AWS, vale la pena mencionar: COPY Al cargar datos utilizando el comando COPY, Redshift se encargará de comprimir los datos de acuerdo a su tipo (en cada caso), lo que representa un ahorro de espacio, mejoras en las consultas, y posible reducción de los nodos requeridos. El siguiente comando, por ejemplo, carga un archivo existente en un bucket de S3, especificando las credenciales y la región: COPY VENTAS FROM ‘ruta_archivo_s3’ WITH CREDENTIALS ‘aws_access_key_id=XXX;aws_secret_access_key=YYY’ REGION ‘us-west-2’ IGNOREHEADER 1 CSV DELIMITER ‘,’ ; VACUUM Debido a que Redshift no ‘recupera’ automáticamente el espacio de un registro borrado o actualizado, se debe ejecutar con cierta frecuencia el comando VACUUM para reordenar las tablas y así liberar cualquier espacio que no se esté utilizando. Lo anterior representa una mejora en el desempeño y, posiblemente, pueda reducir el número de nodos que se requieran para almacenar los datos. Sólo el propietario de la tabla (o un superusuario) podría ejecutar este comando con resultados efectivos. De lo contrario el comando se ejecuta, pero sin efecto alguno. Por ejemplo, con el siguiente comando se reordenan los registros de la tabla VENTAS sólo si menos del 75% de dichos registros están ya ordenados: vacuum sort only VENTAS to 75 percent;
Construir Microservicios con el Patrón de los doce Factores para aplicaciones
¿Cómo se pueden ahorrar costos al trabajar con Amazon Redshift?
Dentro de los muchos factores que podrían afectar la facturación de Amazon Redshift en una cuenta de AWS, vale la pena mencionar: A. Regiones: Dependiendo de la región, un mismo tipo de nodo puede variar significativamente de precio (precio por hora, Dólares Americanos): Una región inapropiada podría repercutir en un sobrecosto innecesario del cluster de Redshift. B. Tipos de Nodos Al crear un cluster para Redshift, es importante decidir correctamente el tipo de nodo a emplear (precios para Octubre 4 de 2.018): Redshift divide los nodos en 2 tipos principales (https://aws.amazon.com/es/redshift/pricing): Informática Densa (dcX.XXXX): entre un 30% y 60% más económicos que los nodos de Almacenamiento Denso, optimizados para consultas más rápidas, y generalmente recomendados para conjuntos de datos que no superan los 500GB. Almacenamiento Denso (dsX.XXXX): más costosos que los nodos de Informática Densa, pero optimizados para almacenar grandes cantidades de datos, suelen recomendarse para conjuntos de datos superiores a los 500GB. C. Snapshots Supongamos que se tiene permanentemente encendido un cluster de tipo dc2.large en la región de Norte de Virginia (costo por hora = $0.25). Un mes de 30 días tiene en total 720 horas, lo que daría un costo de US $180. Pero, ¿y si se pudiera tener encendido ese mismo cluster SÓLO durante las horas laborales (8 horas al día, 5 días a la semana, 4 semanas al mes)?: ¡Esto representaría un ahorro del 78%! Sin embargo Redshift no permite detener y reiniciar un cluster. El proceso alternativo debería ser, al terminar el día laboral: Tomar snapshot del cluster Eliminar cluster y antes de iniciar el día laboral, crear un cluster con el snapshot guardado. Con el siguiente comando se puede eliminar el cluster, generando antes un snapshot: aws redshift delete-cluster –cluster-identifier motest –final-cluster-snapshot-identifier motest-daily-snapshot Mientras el snapshot se esté generando: El cluster continuará activo, pero una vez el snapshot esté completo: Comenzará la eliminación del cluster: Para restaurar el cluster se puede utilizar el comando: aws redshift restore-from-cluster-snapshot –cluster-identifier motest –snapshot-identifier motest-daily-snapshot Lo que se puede monitorear desde la consola AWS: Hasta que termina la restauración del cluster: Estos comandos pueden registrarse como tareas administrativas para ejecutarse, dependiendo del sistema operativo, para Windows (a través del “Programador de Tareas”) o para Linux (utilizando crontab). En el caso de Windows, se puede crear un archivo de PowerShell con un contenido similar a: aws configure set AWS_ACCESS_KEY_ID xxxx aws configure set AWS_SECRET_ACCESS_KEY yyyy aws configure set default.region zzzz aws redshift delete-cluster –cluster-identifier aaaa –final-cluster-snapshot-identifier bbbb En donde: xxxx = access key ID yyyy = secret access key zzzz = región del cluster aaaa = nombre del cluster bbbb = nombre del snapshot Tanto access key ID como secret access key corresponden a un usuario con permisos suficientes para ejecutar los comandos de AWS CLI: El resto del proceso es similar a la creación de una tarea normal bajo Windows. Es importante sin embargo no olvidar que el archivo .ps1 debe ser considerado como argumento de la tarea: Y el programa debe ser powershell.exe La tarea para crear restaurar el cluster puede crearse siguiendo el proceso anterior, pero esta vez el contenido del archivo debe ser: aws configure set AWS_ACCESS_KEY_ID xxxx aws configure set AWS_SECRET_ACCESS_KEY yyyy aws configure set default.region zzzz aws redshift restore-from-cluster-snapshot –cluster-identifier aaaa –snapshot-identifier bbbb Do { $ClusterJSON = aws redshift describe-clusters –cluster-identifier aaaa | ConvertFrom-Json Start-Sleep -s 30 } While ($ClusterJSON.Clusters.ClusterStatus –ne ‘available’) aws redshift modify-cluster –cluster-identifier aaaa –vpc-security-group-ids ssss En donde: xxxx = access key ID yyyy = secret access key zzzz = región del cluster aaaa = nombre del cluster bbbb = nombre del snapshot ssss = Security Group (el ID, no el nombre: sg…..) Es importante recordar que al restaurar un cluster desde un snapshot, toda la configuración inicial se mantiene EXCEPTO el SecurityGroup. De allí que el último comando debe ser actualizar el cluster para que se asocie con el SecurityGroup adecuado, pero este cambio sólo se puede realizar cuando el cluster ya se encuentra disponible. Contenido generado por el equipo de Morris & Opazo
Morris Opazo attended to the Amazon Web Services (AWS) Cloud Experience 2018 in Chile
On last August 23rd, the Titanium Tower in Santiago (Chile), was the space in which different experts and specialists such as Morris & Opazo, Amazon Web Services (AWS) partners and several technologists met to celebrate the AWS Cloud Experience 2018, meeting that allowed, among other activities, different technical sessions, demos and practical workshops. This event had many objectives, including to establish key relationships with technical and commercial leaders, to attract new business opportunities, and to spread the strengthens of the teams in their specialties. It is part of the world meetings that Amazon Web Services that gather the cloud-informatics community to connect, collaborate and learn. Just like its website states it, these “summits are held in the most important cities of the world and attract the technologist of all industries and skill levels who wish to discover how AWS can help them to quickly innovate and offer flexible and reliable scale solutions”. The several assistants were also able to participate in different testimonies from our local clients and had the chance to connect with other users and AWS partners, to know how Chilean companies and from all the world adopt the cloud in an agile way to transform their business. As one of the exponents, Marcelo Rybertt, Country Manager at Morris & Opazo highlighted that “it has been an enriching and gratifying experience being able to interchange experiences and updated information with other Amazon partners, clients and different assistants in this summit”. In the next link you can visit the website of the Activity
Morris Opazo presente en el Amazon Web Services (AWS) Cloud Experience 2018 en Chile
El pasado 23 de agosto, la torre Titanium de Santiago en Chile, fue el espacio en el que se dieron cita diferentes expertos y especialistas como Morris & Opazo, socios de Amazon Web Services (AWS) y numerosos tecnólogos para celebrar la AWS Cloud Experience 2018, encuentro que permitió realizar entre otras actividades, diferentes sesiones técnicas, demostraciones y talleres prácticos. Este evento que tiene entre otros objetivos establecer relaciones claves con los líderes técnicos y comerciales, captar nuevas oportunidades de negocios y dar a conocer las fortalezas de los equipos en cada una de sus especialidades, forma parte de las cumbres mundiales de Amazon Web Services que reúnen a la comunidad informática de la nube para conectarse, colaborar y aprender. Tal como lo indica en su sitio web, estas «cumbres se llevan a cabo en las ciudades más importantes del mundo y atraen a los tecnólogos de todas las industrias y niveles de habilidades que desean descubrir cómo AWS puede ayudarlos a innovar rápidamente y a ofrecer soluciones flexibles y confiables a escala». Los numerosos asistentes además pudieron ser partícipes de los diferentes testimonios por parte de nuestros clientes locales y tuvieron la oportunidad de conectarse con otros usuarios y partners de AWS, para conocer cómo las empresas chilenas y del mundo adoptan la nube de una manera ágil para transformar su negocio. Como parte de los exponentes, Marcelo Rybertt, Country Manager de Morris & Opazo destacó que «ha sido una experiencia enriquecedora y gratificante el poder intercambiar experiencias e información actualizada con otros partners de Amazon, clientes y diferentes asistentes a este encuentro». En el siguiente link puedes ver el sitio Web de la Actividad
Morris & Opazo achieves the level of «Advanced Consulting Partner»
Morris & Opazo achieves the level of «Advanced Consulting Partner» within the Amazon Web Services (AWS) partner network. Morris & Opazo announced today that it has reached the “Advanced Consulting Partner” level within the Amazon Web Services (AWS) partners network. Santiago, Chile. July 16th, 2018. This great achievement is an acknowledgment to our team, which has made significant investments to develop the technical resources and AWS experience necessary to implement and manage customer solutions in the AWS cloud. Our clients benefit from this valuable experience through our SysOps, Solutions Architect, Developer, Big Data, DevOps, and Cloud Practitioner certified engineers. Many thanks to our colleagues and friends at Amazon Web Services for sharing this journey with us . This is but a step forward, we’ll keep on working together! “In Morris & Opazo we have set the goal of being on the cutting edge of technological advances, which allows us to offer our clients a better service every day. We don’t just meet the requirements for each project, we constantly aim to go beyond the expectations of our clients and the AWS team. This achievement is due to our excellent human and professional team, constantly delivering the best service to our clients, with commitment and energy.” (Marcelo Rybertt, Country Manager at Morris & Opazo). In Morris & Opazo we will continue investing in technology and experience, to keep on delivering a quality service to our clients.
