22 diciembre 2024

Experiencias de un académico al interior de Google


Matt Welsh es un profesor de Computer Science en la Universidad de Harvard y de forma perentoria trabaja en Google. Al académico le interesan los sistemas distribuidos y las redes y al cabo de cuatro meses de su pasantía por Google, él escribe código fundamentalmente en Python, pero hace mucho uso de las tecnologías en Google como MapReduce, BigTable, GFS y Sawzall

Volatile and Descentralized es definitivamente un blog recomendado para cualesquier estudioso de las computadoras.

Lo que hace a continuación hace Welsh es describirnos el ambiente de trabajo en Google lo cual explica en tres acápites. Qué significa ver en cada laptop funcionando en Google un adhesivo con este mensaje:«My other computer is a data center»?

La percepción en torno a la computación se ha transformado en el académico. Ahora puede dar por hecho el que pueda trabajar en cientos de máquinas a la vez y con un control totalmente confiable y una muy sofisticada red de almacenamiento. He aquí sus razones:

La nube es real Comparando lo que se vive en Harvard y Google, es justo decir que la computación científica no está encaminada por el camino correcto en esta universidad. No existe aún total confianza en las herramientas de administración a control remoto. A diferencia de Google, donde es posible a través de SSH, hacer prácticamnte todo. Poco importa donde se encuentren los centros de información. La idea de tener físicamente una computadora para realizar un trabajo ya no es concebible en un ambiente de trabajo como Google, para ello solamente es necesario lo que Welsh llama una virtual Linux machine , en su caso personal.

Cuestión de horas y no de semanas – Las bases de datos virtuales no le ofrecen las mismas garantías que las tradicionales pero le permiten hacer el trabajo rápido. Ejemplos de ello son GFS y BigTable en Google. Olvídese de complejas memorias compartidas o de arquitecturas para trasmitir mensajes, ni siquiera se comparan. Es muy fácil efectuar trabajos paralelos en grandes bases de datos cuando usted tiene una interface tan simple como MapReduce a su disposición, escribe el profesor. (Nótese que cuando decimos profesor nos referimos a los profesores universitarios con al menos un PhD).

Olvídese de la unidades de prueba, para ello está printf() – Para los desarrolladores no hay siquiera esperanza de realizar correción de errores en tiempo real en este tipo de ambiente. Es mejor grabar todo con printf() y luego analizar la situación. Cuando tiene que corregir errores y bugs en trabajos paralelos grandes corriendo en miles de procesadores remotos, la tarea no es fácil. Así que es mejor guardar todo y sortearlo después por si algo sale mal.

Por favor antes de irse le recomiendo leer los comentarios respecto al tema en el mismo blog Y aún está a tiempo de aprender cloud computing!

[Imagen cortesía de Matt Welsh]

Siguenos por Twitter a través de @Geeksroom y no te pierdas todas las noticias, cursos gratuitos y demás artículos. También puedes seguirnos a través de nuestro canal de Youtube para ver nuestros vídeos, a través de Instagram para ver nuestras imágenes! O vía Bluesky si ya estás cansado de Twitter

Milton Ramirez

Milton Ramirez es Senior Editor de este sitio web en los EE.UU y ha escrito casi mil artículos para GeekRoom.com. Ha estado en el mundo de los blogs por más de 10 años y es un apasionado por la Education & Tech. Un Ed.D. con experiencia en educación, comunicaciones online y tradicional. Es a jack of all trades, le gusta leer y no es muy difícil encontrarle en Facebook /MiltonRamirezPage, Instagram y Twitter @tonnets.

Ver todas las entradas de Milton Ramirez →