Archivo de la categoría: Internet

He aprobado las tres certificaciones nivel Associate de Amazon Web Services

Hace diez días me examiné de las tres certificaciones de nivel Associate de AWS y aprobé las tres: Solutions Architect, Developer y SysOps Administrator. Después de muchos años de carrera profesional como administrador de Linux primero, experto en seguridad después, y últimamente como arquitecto de soluciones, y varios años trabajando en distintos proyectos con AWS, creo que era el siguiente paso lógico.

He escrito un post en los foros de A Cloud Guru detallando la experiencia y añadiendo algunos consejos para estudiar los exámenes:

Passed all three Associate-level certifications in two consecutive days: experience and tips

En resumen (y en español):

  • Los cursos y exámenes de prueba de A Cloud Guru están muy bien, completos y al grano. Los exámenes de prueba vienen con explicación de por qué esa respuesta es la adecuada, y enlaces a la documentación relacionada con esa pregunta, algo que ayuda mucho a detectar temas que aún no sabes bien y poder remediarlo con la documentación. El curso de Solutions Architect está en español, pero yo los hice todos en inglés (soy muy reacio a las traducciones de temas técnicos). También están disponibles en Udemy, y a veces en oferta por 10€ (si lo compras en Udemy, puedes pedir acceso gratis al mismo curso en A Cloud Guru).
  • La guía de estudio oficial (AWS Certified Solutions Architect Official Study Guide: Associate Exam) está también muy bien. Cubre bastante material, incluso cosas que no entran en el Solutions Architect, y te da acceso a una herramienta online on flashcards y más preguntas y exámenes de prueba.
  • Tener experiencia con los conceptos de arquitectura, seguridad, redes y alta disponibilidad es muy importante. Los cursos y el libro los cubren hasta donde es necesario para sacarse las certificaciones, pero de una forma muy AWS-céntrica. Si no se tiene experiencia previa con estas materias yo recomendaría que, antes de empezar con el material de AWS, se leyera algunos libros o artículos genéricos sobre estos temas. Conocer estos conceptos de antemano ayuda (y mucho!) a entender cómo ponerlos en práctica con los servicios de AWS. También ayuda mucho en las preguntas de situación y de troubleshooting.
  • Los White Papers de AWS y los FAQ de cada servicio son un recurso impagable, Amazon se lo ha currado mucho a la hora de documentar cada servicio. Si hay algo que no entiendes en los cursos de A Cloud Guru, algún concepto que se te escapa, algo en lo que quieres profundizar más… nada como ir a la fuente oficial. La mayoría de estos documentos deberían ser de lectura obligada, aunque la verdad es que yo apenas me leí dos o tres white papers y la FAQ de DynamoDB, y miré por encima alguna otra FAQ de los servicios con los que no había trabajado. Pero claro, después de leerme el libro oficial y teniendo ya experiencia con algunos de los servicios más importantes de cara a estas certificaciones.
  • Otra fuente de información son los webinars: AWS organiza seminarios online prácticamente a diario (en inglés, en español cada semana o dos semanas) sobre todos sus servicios, con un enfoque bastante práctico con ejemplos de proyectos concretos. Muchos de los webinars ya pasados están disponibles en el canal AWSwebinars de YouTube.
  • Aunque los exámenes sean tipo test, la experiencia de primera mano con AWS creo que es vital. Al crear una cuenta nueva en AWS tenemos acceso al “free tier“, una serie de servicios básicos gratuitos durante un año pero limitados en horas de uso, tamaño, número de instancias, etc. Aún con estas limitaciones, es una herramienta perfecta para poner en práctica los conceptos que estamos estudiando de cara al examen.
  • Otra opción para practicar es QwikLabs. Sus laboratorios se realizan con acceso (muy limitado) a la consola real de AWS, nada de simulaciones. Igual que si lo hiciéramos con nuestra cuenta del free tier, pero con problemas más guiados en vez de ir haciendo cosas al tuntún. Yo sólo hice un puñado de los gratuitos, básicos pero suficientes para hacerme una idea de los servicios con los que no había trabajado antes. Hay también laboratorios de pago, incluso “quests” con conjuntos de 9-10 labs para prepararse las distintas certificaciones.
  • Para acabar de aprenderme los detalles que había que saberse de memoria sí o sí (límites de archivo en ciertos servicios, timeouts en otros, llamadas del API más comunes, etc.) utilicé AnkiDroid: mientras leía el libro o veía los vídeos de A Cloud Guru, iba apuntando los detalles que parecían importantes y que estaba seguro que iba a olvidar. Luego cuando tenía cinco minutos libres (esperando a alguien, haciendo cola en el super, incluso andando por la calle) los iba repasando.
  • Después de verme todos los vídeos de A Cloud Guru, repasé varias veces los vídeos de resumen al final de cada capítulo. En estos casos casi no hace falta ver la imagen, con el sonido sobra, así que me lo ponía cuando salía a correr, al ir en el coche, etc.

Un último detalle por si alguien quiere estudiar los tres exámenes a la vez: hay MUCHO material común entre las tres certificaciones, IAM, VPC, EC2, S3 y Route53 entran en los tres exámenes. Para evitar volver a mirar lo mismo varias veces, después de ver el curso de Solutions Architect de A Cloud Guru, repasé los otros dos fijándome en los nombres y duración de los vídeos de las secciones comunes, y directamente los marqué como leídos para saltármelos más fácilmente. Una vez que te has estudiado el Solutions Architect, ir a por Developer supone profundizar bastante más en DynamoDB y un poco en SQS y SNS (y aprenderse de memoria el nombre de unas cuantas funciones del API); y el SysOps profundizar en CloudWatch, OpsWorks, y algunos detalles extra de troubleshooting del resto de servicios.

¡Mucho ánimo a los que intentéis certificaros! Creo que merece la pena.

 

Hello world! – mudanza

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

O eso es lo que reza el post por defecto que te mete WordPress en cada nueva instalación.

Si, nueva instalación. Después de n años arrastrando un WordPress-mu 2.x y aprovechando un cambio de servidor, me he decidido a migrar a WordPress 3. Así que cambio de servidor y de software… va a petar todo. O más. Se va a cagar la perra.

Ya iré arreglando cosas poco a poco, instalando plugins, temas, acabando de configurar, migrando ficheros que no se hayan copiado bien y demás. Pero es que si no me tiro a la piscina a lo bestia, no lo hago. Y más con lo dejado que tengo esto últimamente, a ver si así lo retomo.

Además y aprovechando el nuevo servidor he montado un mirror de esto. :-)

tinydns por dominios

[spanish]Los que han trabajado conmigo saben que me gustan mucho los servidores de DJB. Creo que tanto qmail como djbdns son dos servidores estables como una roca en los que se puede confiar sin problemas. Pero hay mucha gente que simplemente no los entiende y los critica por cualquier motivo.

Por ejemplo, con el djbdns. He oído muchas veces la queja de que tener todos los dominios del tinydns en un único fichero de configuración (data) es un coñazo, cuando tienes muchos dominios (>50) la cosa se vuelve inmanejable. Eso prueba mi argumento de que esta gente no se entera de una de las ventajas de los programas de DJB: si, puedes editar los ficheros de configuración a mano, ¡pero lo bueno que tienen es que usan formatos simples fácilmente automatizables! ¿No quieres tener todos los dominios en un único fichero? Perfecto, sepáralos como te resulte más cómodo administrarlos y luego los vuelves a juntar antes de compilarlos.

El siguiente Makefile sirve precisamente para esto: en vez de trabajar con el “data” de toda la vida se crea un directorio “domains” donde se usa un fichero por dominio (el formato es el mismo), a partir de ese momento se usan estos ficheros y no el “data” para la administración. Al ejecutar make el makefile junta todos los ficheros de los dominios en el data y lo compila. Y si defines la IP o FQDN del servidor de backup en env/BACKUP, lo sincroniza. Fácil, ¿verdad?[/spanish]

[english]It’s no secret that I really like DJB‘s software. I think that qmail and djbdns are rock-solid pieces of software, something you can really rely on. But some people just don’t get them and bash them for whatever reasons.

Case in point, djbdns. Many a time I’ve heard the argument that having all tinydns’ domains in a single data file is a PITA. Well, that proves those people don’t get the point in DJB configuration files: you can edit them by hand, but their real power is that they’re easily scriptable! You don’t want having all the domains in a single file? Ok, split them and join them before compiling!

You can do this with the following makefile: split the domains, one per file on the “domains” directory, and work with those files, don’t ever touch the original “data” file again. And if you have a backup server put it’s IP address or FQDN on an env/BACKUP file. Then when you run “make” it will join all the files, compile them and sync the results with the backup server. Easy as pie, don’t you think?[/english]


all: data.cdb

data: domains/*[^bB][^aA][^kK~]
        cat $+ > data

data.cdb: data
        /usr/bin/tinydns-data
        [ -f ../env/BACKUP ] && rsync -azv * root@`cat ../env/BACKUP`:`pwd`

clean:
        -rm -f *~ domains/*~