Mostrando entradas con la etiqueta Cloud computing. Mostrar todas las entradas
Mostrando entradas con la etiqueta Cloud computing. Mostrar todas las entradas

lunes, 27 de abril de 2026

Amazon AWS 'breaks guitars': un caso de mal servicio y una queja sin respuesta

Este es una especie de 'post protesta', un lanzar una queja al aire con la esperanza, que no la expectativa, de que alguien tome nota.

Ese alguien debería ser Amazon AWS, que es la empresa de la que me voy a quejar, pero ese alguien también podría ser cualquier cliente potencial de Amazon AWS...para que esté advertido, se lo piense y tome precauciones antes de contratar a Amazon AWS, incluyendo la de buscar una alternativa. 

Tengo varias críticas que formular a Amazon AWS, pero la más importante, la verdaderamente importante, es la de su pésimo, en realidad inexistente, servicio de soporte.

Y, a la hora de redactar este artículo, no he podido evitar acordarme del, en su momento, muy famoso caso de Dave Carroll y United Airtlines, que dio origen a un fenómeno viral en Internet con la canción titulada 'United breaks guitars'.


Sobre Amazon AWS


Aunque Amazon AWS ('Amazon Web Services') creo que es bien conocida, por si acaso recuerdo que se trata de la división de cloud computing de Amazon, una división que le genera grandes beneficios al gigante online, una división a la que le cabe el mérito de haber sido quien inventó de alguna manera este concepto de los servicios en la nube, y además, una división líder mundial desde entonces del sector, con más de un 30% de cuota, en competencia, fundamentalmente, con los otros dos hiper-escaladores: Microsoft Azure y Google Cloud Platform.

Dada esa relevancia, hace años que la sigo, que he leído libros e informes sobre ella, y que he hablado sobre ella, e incluso hecho sencillas demos, en mis clases, tanto en el ámbito de tecnología y transformación digitales, como de innovación.

Y por eso, desde hace años, la verdad es que no recuerdo cuántos, tengo una cuenta de formación gratuita (supuestamente) en Amazon AWS.


Antecedentes


Hace unos par de meses o así, y de cara a una formación, decidí que era una buena idea hacer un pequeña demo, una demo grabada, del funcionamiento de Amazon SageMaker, el conjunto de herramientas y servicios de Amazon en materia de Machine learning. 

Cursé un pequeño MOOC sobre SageMaker y, siguiendo los ejemplos que allí se exponían, configuré un dominio y los recursos mínimos necesarios para, simplemente, visualizar SageMaker, navegar por él y entender mejor lo que ofrece. Al hacer esto, utilicé mi cuenta gratuita y entendí al profesor del MOOC que lo que estaba configurando también era gratuito.

De hecho, sólo hice la configuración, pero no llegué a crear ningún Notebook, no cargué datos, no entrené ningún modelo, no lancé ningún trabajo. Apenas hice nada más que configurar y entender el entorno.

Esto fue suficiente para poder luego hacer una recorrido demo y grabar lo que pretendía.

Y me quedé tan tranquilo. 

Esto debió ocurrir a principios de Marzo.


Los hechos (I): esto no era gratuito


Cual no sería mi sorpresa cuando, dos o tres semanas más tarde, me llega un correo de Amazon diciendo que tenían problemas con mis medios pago para cobrar la factura de Marzo.

¿Factura? ¿Cobrar? ¿De qué me hablan? ¿Pero esto no era gratuito?

Bueno, me pongo a mirarlo y, en efecto, me estaban intentando cobrar la friolera de 743,18$, en una cuenta que se supone es gratuita, por algo que yo había entendido que era gratuito y por no hacer prácticamente nada de computación real. 

Aunque yo había entendido que todo lo que había utilizado era gratuito, y aunque me parece una pasada cobrar esa cantidad por no hacer realmente nada, asumí que el error había sido mío, que seguramente en alguna parte en que yo no había reparado, había alguna cláusula que especificaba que eso que había hecho no era gratuito. Así que decidí pagar esa factura por más que me doliese en el bolsillo y que me molestase en su concepto.

En Abril, 6-Abril, exactamente. abrí un ticket de soporte quejándome de los hechos, pidiendo que me lo explicaran y solicitando (aunque sin ninguna expectativa real de conseguirlo) la devolución del dinero. La devolución del dinero no esperaba que se produjera, pero la explicación, sinceramente, sí.


Los hechos (II): defectos de usabilidad e información en Amazon AWS


Lo siguiente, por supuesto, fue darme de baja de SageMaker y de cualquier servicio que pudiera tener contratado sin yo ser consciente, con Amazon AWS,

¿Debería ser fácil, verdad?

Pues no lo es.

No existe una forma sencilla (en realidad, no me consta que haya una forma en absoluto) de visualizar qué servicios tienes contratados con Amazon AWS. Sí que existe una forma bastante razonable de visualizar aquello que te han facturado hasta el momento e, incluso, una previsión de lo que te pueden facturar en el futuro.

Esa visión de facturación, sin embargo, no te lleva directamente a conocer qué tienes realmente contratado. Me explico: Amazon AWS no tiene un esquema sencillo de servicios, sino que unos dependen de otros e, incluso, en el caso por ejemplo de SageMaker, lo que te cobran depende de recursos concretos que hayas creado, no del servicio como tal. Y no existe, al menos que yo haya encontrado, una forma panorámica, directa y razonablemente sencilla de saber qué servicios y recursos tienes y por los que te están cobrando.

Tengo que suponer, y de hecho supongo, que sí existe alguna forma. No me puedo imaginar que una empresa que contrate variedad de servicios de Amazon AWS, que haga uso intensivo de ellos, que pague mucho por ello y no pueda saber qué tiene contratado y configurado realmente. No lo puedo creer, y no lo creo de hecho, pero lo que sí digo es que no es sencillo o, al menos, no evidente.

Y esa dificultad en la interfaz de usuario, ese mal planteamiento de la consola, me parece lamentable en los tiempos actuales y más para el líder mundial de servicios en la nube.

pero lo realmente grave no es esto.


Los hechos (III): la inexistente respuesta de Amazon AWS


A todas estas, claro, mi prioridad era darme de baja inmediatamente de todo, y para eso necesitaba saber qué era exactamente ese 'todo' de lo que me tenía que dar de baja.

Aparte de consultar en la web de Amazon AWS y a ChatGPT, abrí, el 8 de Abril, tres nuevos tickets de soporte pidiendo ayuda para darme de baja en los servicios, cada vez más desesperado ante la para mí inexplicable dificultad de la tarea de ejecutar tal baja y la falta de respuesta de Amazon AWS. 

Debo decir, además, que cuando abrí los últimos tickets ya había comprobado que cada día que pasaba sin que lograra dar de baja lo que fuera que tuviese que dar de baja, me seguían apuntando un debe de unas decenas de dólares (¡cada día!).

Al final, llegué a abrir cuatro tickets de soporte en tres días (muestro imagen en la herramienta AWS Support)



¿Respuesta?

De esos cuatro tickets sólo llegaron a contestar a uno de ellos, pero con una respuesta automática, creada con inteligencia artificial generativa y que era insuficiente por genérica, cosa que les hice saber. Lo que me decían, y mejor, ya lo sabía yo a partir de consultas a ChatGPT.

Es decir, es el día en que esto escribo, 27 de Abril, no han contestado al ticket original del 6 de Abril (¡¡¡ 21 días sin contestar!!!), no han contestado a dos de los tickets que abrí el 8 de Abril (¡¡¡19 días sin contestar!!!) y sólo han contestado a uno de los tickets de 8 de Abril, pero no han contestado a mi observación de que esa respuesta era demasiado genérica, respuesta que les di el 9 de Abril (¡¡¡ 18 días sin contestar!!!).


Los hechos (IV): ni siquiera en X (twitter)


Desesperado, acudí a X (antiguo Twitter) lanzando un post de queja y mencionando a diversas cuentas de Amazon AWS: la cuenta de España (@awscloud_es), alguna cuenta general (@aws, @awscloud) y la cuenta de soporte (@AWSSupport) e, incluso, la de Jeff Bezos (@JeffBezos)..

Lo normal cuando haces eso es que, una hora o dos después del mensaje, alguna cuenta te conteste (suponía que la de España), te pida que le sigas, te sigue, y continuas la conversación mediante mensajes directos y, con mayor o menor acierto te ayudan. Al menos esa era mi experiencia hasta ahora con otras empresas.

¿Qué hizo en este caso Amazon AWS?

De nuevo, nada.  

Bueno, casi nada. Al final contestó de forma  pública la cuenta @AWSSupport, diciendo que habían hablado con su equipo para que revisasen los tickets. Adjunto el post



¿Algún resultado tras esto? ¿Alguna contestación adicional? ¿Algún otro contacto? No, cero 'patatero'. Los tickets siguieron igual, y no hubo más acción por parte de la cuenta de AWSSupport.


Los hechos (V): el fin de la historia


Escribo esto cuando, desde hace unos días, parece que he logrado resolver el problema. A base de consultar a ChatGPT y explorar y recorrer por arriba y por abajo la consola de Amazon SageMaker, parece que he logrado localizar y borrar todos los recursos por los que me estaban cobrando. Desde hace unos días, ya no me acumulan nuevos costes.

Pero, me ha llevado mucho tiempo conseguirlo, en un momento, además, en que tenía un pico de trabajo brutal y lo último que quería era dedicar esfuerzos a nada que no fuese mi verdadero trabajo. Además, y mientras he logrado borrarlo y no, este mes de Abril me han seguido acumulando costas  hasta un total de 171,54 $ que seguro que, esto si, me cobran puntualmente sin la más mínima dilación.


Inciso: Dave Carroll y United


Como decía al inicio de este post, he utilizado como metáfora y título el caso 'United breaks guitars'. 

Se trata de un caso que se hizo muy famoso ocurrido en 2009, en pleno 'boom' de la web 2.0. El caso se refiere al cantante country Dave Carroll. En un viaje que éste realizó con la aerolínea United Airlines' fue avisado de que los empleados de equipaje estaban lanzando por los aires su guitarra 'Taylor' (que costaba unos 3.500$). El cantante intento advertir de ello, pero no le hicieron ni caso. Al llegar a su destino comprobó que, en efecto, habían roto la guitarra. A esto siguió una larga cadena de acciones por parte del cantante para que United Airlines asumiese su responsabilidad, todo ello sin encontrar respuesta.

Harto de ello, grabó la canción 'United breaks guitars' que se hizo viral (150.000 visualizaciones el primer día). Dejo aquí el famoso vídeo.



Con esto, United no tuvo más remedio que que reaccionar y atender a Dave Carroll


El verdadero problema no son las guitarras rotas


En el caso de Carroll, hubo un fallo de raíz por parte de United, que fue romper la guitarra por descuido o incluso desprecio por parte de sus empleados. Pero, más allá de este error de partida, lo realmente exasperante y mucho más grave, fue la negativa de United a atender la justa reclamación de Dave Carrol.

En mi caso, creo que Amazon AWS muestra fallos en su servicio cuando no explicita claramente qué te da gratuito y por qué te cobra, o cuando no ofrece una consola razonable para tener perspectiva clara y sencilla de tus servicios y recursos y facilitar su gestión y, en mi caso, su baja inmediata. Pero asumo como propio el no haberme informado suficientemente de los costes en que estaba incurriendo o no estar más ducho en el manejo de la consola, y sólo me referiré a esto que creo fallos de Amazon AWS como meras oportunidades de mejora.

En ese sentido, a lo mejor en mi caso debo asumir como problema propio el que la 'guitarra se haya roto' (en forma de servicio de pago) y que 'la broma' me vaya a costar más de 900$.

Lo que realmente es de todo punto inaceptable, es que Amazon AWS no responda (¡¡¡ 21 días sin dar una respuesta!!!) 

He pensado que, quizá, 'tardan' tanto en contestar porque estoy en esa cuenta presuntamente gratuita y, quizá, es que por eso no me consideran un verdadero cliente.

Pero, por un lado, la cuenta no ha sido tan gratuita, como ha quedado claramente demostrado y, por otro, para facturarme y cobrarme sí que me han tratado como a un cliente. Es para darme soporte y para atenderme para lo que no me han considerado como un cliente y no me han atendido ni ayudado en absoluto.

¿O es que Amazon AWS trata así a todos sus clientes? 

En el estribillo de su canción, Dave Carroll dice:


I should have flown with somewhere else or gone by car... cause United breaks guitars


Y, claro, esa es la sensación que me queda, que debería haber usado otra plataforma en la nube en lugar de Amazon AWS. Y, claro, para futuras formaciones, exploraré Microsoft Azure o Google Cloud Platform e intentaré no volver a recurrir a Amazon AWS. Y pongo en alerta, a quien me quiera escuchar, que tenga cuidado con Amazon AWS y, sobre todo, con su servicio de soporte.

Y es que, aunque sea de manera figurada 'Amazon AWS breaks guitars'.


Conclusiones


Pese a que Amazon AWS es el creador de la categoría de servicios en la nube, pese a que se trata del líder mundial de este mercado, su servicio de soporte deja mucho que desear, en realizad es casi inexistente, al menos esa es mi experiencia personal.

viernes, 1 de noviembre de 2024

El servicio Azure OpenAI explicado por Adrián González Sánchez

He leído con ilusión el libro 'Azure Open AI services for cloud native applications', no sólo por mi claro interés en la temática (tanto en lo relativo a la inteligencia artificial generativa, como a las arquitecturas cloud nativas y la oferta de hiperescaladores como Microsoft) sino también por conocer personalmente, y apreciar, a su autor, Adrian González.

Nos encontramos ante un libro serio y bien fundamentado, que trata de manera rigurosa, el servicio Azure OpenAI lo que, además, arrastra consigo la explicación de muchos aspectos técnicos relevantes más allá del propio servicio o la propia oferta de Microsoft en Azure.

El contenido se estructura en siete capítulos, como sigue:
  • '1. Introduction to Generative AI and Azure OpenAI Service:' Un capítulo para fijar conceptos previos. Empieza con la disciplina de la inteligencia artificial explicando, por ejemplo, las formas de aprendizaje o los casos de uso habituales Sigue con inteligencia artificial generativa comentando sus capacidades, los modelos fundacionales o los principales actores actuales de la industria. Y finaliza poniendo en suerte lo que seguirá en siguientes capítulos, ya que introduce el concepto de Copilot y una muy rápida introducción del servicio Azure OpenAI.

  • '2. Designing Cloud Native Architectures for Generative AI:' Como una preparación, ya mucho más profunda y técnica al servicio Azure OpenAI, este capítulo explica elementos arquitecturales en relación con la nube, fijando lo que son las arquitecturas cloud nativas, los microservicios, los contenedores, 'serverless o el modelo DevOps de integración y despliegue continuos CI/CD. Y luego, ya desde un plano mucho más práctico, presenta el portal Azure y los modelos de servicio del servicio OpenAI.

  • '3. Implementing Cloud Native Generative AI with Azure OpenAi Service:' Quizá el capítulo nuclear, el que más explica realmente el servicio Azure OpenAI y sobre todo, cómo usarlo. Comienza explicando cómo fijar o ampliar el conocimiento que utilizará el modelo mediante el empleo del modelo tal cual es, o su extensión mediante técnicas de 'fine tunning' o RAG. Luego cuenta los diferentes componentes ('building blocks') del servicio Azure Open AI dentro de Azure Studio (Assistants playgound, Chat playground, Completions playground, DALLE-E playground y Bring your own data). A continuación, aborda los diferentes enfoques de implementación según se use el modelo tal cual, o se entrene mediante ejemplos, o se amplie con 'fine tunning' o RAG. Finaliza explicando formas de evaluar el desempeño de la solución creada.

  • '4. Additional Cloud and AI Capabilities:' Un capítulo un poco 'collage' pero muy interesante, donde explica aspectos relacionados de forma algo más indirecta con el servicio Azure OpenAI. Comienza explorando un poco el ecosistema global con diferentes soluciones complementarias o alternativas como la orquestación mediante Langchain, el SDK de software abierto 'Semantic Kernel', el framework LlamaIndex, el Bot Fraework de Azure para la construcción de chatbots tradicionales (previos a la explosión de la IA Generativa) y otros productos de Microsoft como la Power Platform, Copilot o AI Builder. En el siguiente bloque pasa revista a los almacenes de vectores ('vector stores') tan importantes en RAG y, en concreto, revisa Azure AI Search, Cosmos DB, Azure DataBricks, Redis, etc. En el tercero y último bloque del capítulo examina otros elementos relevantes de la plataforma Azure como son Azure AI Document Intelligence, Fabrics Lakehouse, Azure AI Speech o Azure API Management.

  • '5. Operationalizing Generative Ai Implementations:' Aborda aspectos mas relacionados ya con el despliegue e incluso el uso de servicios basados en Azure OpenAI, como son la ingeniería de instrucciones ('prompt engineering'), la operación de servicios basados en grandes modelos de lenguaje, la adaptación de las ideas de DevOps y MLOps al caso de los grandes modelos de lenguaje, la llamada LLMOps, incluyendo el denominado 'prompt flow', la securización de los modelos y el tratamiento de la privacidad y el cumplimiento normativo. Y finaliza con una mirada a los aspectos de uso responsable y de regulación.

  • '6. Elaborating Generative AI Business Cases:' De alguna forma se acerca a los pasos a dar en un proyecto. Comienza con el análisis 'pre-mortem' (qué podría ir mal), sigue con la selección del enfoque de implementación, la identificación de tareas y recursos, la estimación de duraciones y esfuerzos y la creación de un 'roadmap'. Luego proporciona consejos sobre cómo definir y dimensionar un caso de uso y finaliza con una visión de caso de negocio con el cálculo de costes y retorno de la inversión.

  • '7. Exploring the Big Picture:' Un curioso capítulo final en que, mediante entrevistas, se exploran aspectos relevantes del panorama actual que rodean a la IA Generativa o a la nube. En concreto, dialoga con David Carmona, Brendan Burns, John Maeda, Sara Bird, Tim Ward, Seth Juarez y Saurabh Tiwari.

'Azure OpenAI service for cloud native architectures' es un gran recurso para entender, no sólo el propio servicio que justifica el libro, sino todos los elementos técnicos, arquitecturales e incluso de gestión que lo rodean, específicamente cómo trabajar con grandes modelos de lenguaje y cómo trasladarlos a casos de uso reales así como todo el ecosistema que rodea a la IA Generativa y el mundo cloud. Un libro que quizá por ello podríamos decir que trasciende un poco lo que es su objetivo primario, proporcionando muchos, muy interesantes y muy bien explicados conceptos de inteligencia artificial generativa y de aquitecturas cloud, con una visión quizá bastante más amplia de lo que el título pueda sugerir.

Un libro técnico pero que ofrece una mirada global, claro y bien escrito, con la calidad, en fin, que cabe esperar de los libros de O'Reilly, y para mi, y en este caso concreto, del conocimiento y buen hacer de su autor.

Recomendable, sin duda.

Adrián González Sánchez

(Fuente: Fuente: Ligera elaboración propia de su ficha de profesor en ENAE)

Adrián González Sánchez
Destacado experto en Inteligencia Artificial y Tecnología, enfocado en la ética de la IA y la regulación de la UE. Actualmente, forma parte del equipo de Microsoft como Principal Specialist in Cloud, Data and AI for Public Sector.

Adrián González también imparte clase en ENAE Business School y en otras prestigiosas instituciones como Concordia University o École des dirigeanst HEC Montréal.

Asimismo, ha ocupado puestos como ejecutivo tecnológico, asesor de empresas y coach, por lo que cuenta con experiencia en múltiples industrias como Telecomunicaciones, Educación, Cadena de Suministro, Retail y Fintech. Además, tiene experiencia en desarrollo de software y cloud computing, siendo cofundador de una startup.

En este sentido, ha ocupado puestos como CTO en Smartbonds; Artificial Intelligence Consultant en IVADO Labs; y miembro del comité de LF AI and Data Fundation. Además también es miembro del Observatorio del Impacto Social y Ético de la IA (OdiseIA) y de FiinOps Foundation.

Posee certificaciones como Certified Product Manager (CPM®) y Certified Scrum Product Owner (CSPO®), y tiene habilidades en gestión de proyectos, estrategia, arquitectura y productos para proyectos de Ciencia de Datos, IA, Cloud y Blockchain.

Además, comparte sus conocimientos y experiencias en su blog en Medium y en redes sociales como Twitter y Clubhouse. Adicional, Adrián González Sánchez es autor en la editorial O’Reilly donde es autor del libro 'Azure OpenAI Service for Cloud Native Applications', además de haber colaborado en diversas publicaciones:

  • Case Study: How the Port of Montreal Used NLP to Fast-Track Critical Cargo in 2020
  • Azure OpenAI for Cloud Native Applications
  • Kubernetes and Cloud Native Associate (KCNA) Study Guide

Puedes conocer más del autor visitando su perfil en LinkedIn o siguiéndole en X donde se presenta como @adriangs86.

Ficha técnica:


EDITORIAL: O'Reilly Media
AÑO: 2024 
ISBN: 978-1098154998
PAGINAS: 246

lunes, 17 de junio de 2024

La sorprendentemente sencilla adopción de la inteligencia artificial

Recientemente he finalizado la lectura del libro 'Microsoft Copilot: Mastering the AI Revolution in Office 365, Strategies for Innovation, Knowledge and Lifelong Learning' de Bryan J. Silva, un libro bastante limitado, la verdad (quizá por el demasiado cercano lanzamiento de Copilot), y de donde he sacado poco en limpio pero donde, sin embargo, y bastante al final, he visto algo que me ha hecho pensar y que motiva este post.

Bastante avanzado el libro, como digo, se expone brevemente la viabilidad de integrar scripts o modelos desarrollados en Python con Copilot 365. En el fondo, no es nada demasiado sorprendente. Sin embargo, me hizo pensar en lo potente que es esta integración y, yendo algo más allá, lo fácil que resulta hoy en día la adopción de la inteligencia artificial, tanto para incluirla en otro tipo de sistemas como para su uso directamente por personas.


Reflexión previa: nuestra incapacidad para sorprendernos con la tecnología


Antes, me gustaría hacer una breve reflexión previa. Y es una reflexión sobre nuestra relativa incapacidad para asombrarnos con los avances de la tecnología, en este caso con la inteligencia artificial.

Parece como que, de alguna forma, nos hubiésemos acostumbrado a que la tecnología nos aporte cosas que, no tanto antes, hubiésemos considerado 'alucinantes' o, como diría Arthur Clarke, 'indistinguibles de la magia'. En cierto modo ocurrió con Internet, ocurrió también con las redes sociales (asombrosas no tanto por su funcionalidad como por su escalabilidad), ocurrió con el smartphone y el internet móvil y creo que ahora ocurre con la inteligencia artificial en sus múltiples facetas.

No sé si esta incapacidad para el asombro es buena o mala. Entiendo que es un buen síntoma porque, si nos acostumbramos, es porque empieza a ser 'normal' que la tecnología avance a toda velocidad. Y eso es bueno. 

Pero, síntoma aparte, no estoy seguro de si es bueno de que no seamos conscientes de esos cambios y de lo transformadores, y muchas veces maravillosos que resultan.

No estoy seguro, pero no sé si esa incapacidad para el asombro nos puede restar capacidad para su adecuada gestión de todo tipo: técnica, económica, social y ética. O si, incluso, puede ser síntoma de algo que sería negativo: una cierta pasividad e incluso hastío casi existencial, que pudiera conducir, incluso, a problemas psicológicos.

Pero dejo aquí, bastante abierto la verdad, este excurso para entrar en lo que realmente era el tema de este post: la facilidad de adopción de la inteligencia artificial.


Una doble facilidad de adopción


Planteo esa facilidad de adopción con una doble cara.

Por un lado, y desde un punto de vista más técnico, lo sencillo que resulta incorporar capacidades, algoritmos y modelos de inteligencia artificial en todo tipo de sistemas y soluciones, sean estos en modo de sistema empresariales (ERP, CRM, SCM, HCM, etc), soluciones de RPA, soluciones BPMS o incluso soluciones a medida.

Por otro, la facilidad de uso por los usuarios, por las personas.


Una valiosísima y crucial herencia


Lo cierto es que, comenzando por el lado técnico, la actual facilidad de adopción de la inteligencia artificial se apoya en otro tipo de soluciones y planteamientos, ajenos y previos en general al auge actual de la inteligencia artificial y que, en el fondo, también se podrían utilizar para ayudar en la adopción de muchas otras tecnologías.

Comenzaría por algo que lleva ya muchísimos años entre nosotros, como es el planteamiento SOA ('Service Oriented Architecture') que ya hace muchos años nos mostró el camino para organizar la lógica de nuestros sistemas y soluciones en modo de componentes y, sobre todo, de servicios de negocio, unos componentes autocontenidos y de bajo acoplamiento que, además, se exponen hacia el exterior mediante una serie de servicios bien delimitados.

Acompañando y concretando la propuesta SOA, el desarrollo, generalización e implantación del concepto de API ('Application Programing Interface'), con especial relevancia hoy en día en las interfaces tipo Web Service y, sobre todo, hoy en día, REST.

Aunque no es una tecnología en sí misma, pero sí un planteamiento, destacaría también el muy extendido uso del concepto de conector que, en forma nativa, disponibiliza esas APIs para soluciones fundamentalmente basadas en filosofía 'low-code', y que simplifican enormemente el desarrollo de las integraciones.

Y como 'guinda del pastel', la expansión de la filosofía cloud computing, no sólo para alojamiento o virtualizacion de servidores, sino, sobre todo, para el ofrecimiento de servicios precisamente basados en APIs. Todo ello potenciado por la existencia de los denominados hiperescaladores (Amazon, Microsoft, Google,...) que disponibilizan, de forma tremendamente escalable y ubicua, ese tipo de servicios.

Algunas de estas tecnologías y planteamientos, para el lector que no las conozca, merecerían una explicación, pero no voy a entrar en ella para no alargarme en exceso.

Y algunas de estas tecnologías y planteamiento pueden resultar alejadas del foco mediático actual (aunque lo estuvieron en su momento), quizá incluso parecer, erróneamente, algo 'viejunas' y pasadas de moda, pero, sin embargo, son absolutamente clave y de plena actualidad, si no mediática, sí tecnológica y práctica.


La sencillez de la integración de componentes de inteligencia artificial


La multiplicación de APIs y conectores, en este caso recubriendo servicios de inteligencia artificial y con frecuencia en la nube (especialmente la nube de los hiperescaladores o grandes actores de la inteligencia artificial), y la enorme facilidad para integrar, mediante conectores o uso directo de APIS, esos componentes y servicios en otras soluciones, unida a la proliferación de herramientas 'low-code' que apenas exigen conocimientos de programación para desarrollar soluciones incluyendo integraciones, hace tremendamente simple la inclusión de capacidades de inteligencia artificial en todo tipo de soluciones y es un factor que favorece enormemente su adopción en empresas y administraciones.


La facilidad de uso de la inteligencia artificial


Pensando ya no tanto en la inclusión de capacidades en nuevas soluciones y sistemas, sino en su adopción por las personas, en el trabajo y el ámbito privado, cabe destacar el enorme avance que supone el haber conseguido interfaces conversacionales basadas en voz y lenguaje natural muy eficaces en el tratamiento de esa voz y los 'significados' del lenguaje.

Esto hace que muchas aplicaciones, tanto de inteligencia artificial como de otro tipo, resulten absolutamente naturales en su utilización. eliminando curvas de aprendizaje que traen consigo otro tipo de interfaces (comandos, ventanas, etc) y facilitando la llegada masiva, como así está siendo, de la inteligencia artificial a las personas, a los profesionales y los ciudadanos en general.


Conclusiones


De alguna manera, la inteligencia artificial actual es heredera de los buenos planteamientos que se han venido haciendo desde hace años e incluso décadas en el ámbito de las tecnologías de la información e interfaces de usuario. Y la confluencia de los avances específicos en inteligencia artificial con esos planteamientos, no brinda una sorprendente facilidad de uso e integración de la inteligencia artificial, al menos desde el punto de vista técnico y operativo, y esto debería garantizar una masiva y exitosa adopción de la inteligencia artificial.

En parte lo estamos viendo, pero, en realidad, todavía nos queda, creo, mucho por ver.


martes, 8 de noviembre de 2022

Kubernetes y Docker de la mano de Scott Surovich y Marc Boorshtein

'Kubernetes and Docker. An enterprise guide' es un libro claramente técnico y especializado, que nos explica los conceptos y uso de todo un ecosistema de contenedores, claves en los planteamientos cloud y DevOps actuales, y en cuyo núcleo se encuentran los casi omnipresentes Docker y Kubernetes, especialmente este último, pero que los autores rodean de una larga serie de otras herramientas 'open-source'.

El libro comprende catorce capítulos agrupados en tres secciones como sigue:
  • 'SECTION 1 - DOCKER AND CONTAINER FUNDAMENTALS:' Presenta las ideas básicas sobre contenedores y Docker. Abarca tres capítulos:

    • 'Chapter 1 - Docker and container essentials:' Tras una muy breve explicación de la utilidad de los contenedores, explica, aunque con no demasiada extensión, algunos conceptos sobre Docker como las imágenes o el acceso a servicios. Y luego ya pasa a detallar aspectos muy prácticos y de tipo 'manos a la obra'. Así, explica cómo instalar Docker, cómo asignar permisos y cómo usar su interfaz de línea de comandos (CLI, 'Command Line Interface').

    • 'Chapter 2 - Working with Docker Data:' Comienza explicando la necesidad de persistencia en el mundo de los contenedores y eso le conduce a dedicar la mayor parte de lo que resta del capítulo a los llamados volúmenes Docker contando cómo se crean, montan, limpian y listan los volúmenes. Finaliza con una sección dedicada a 'tmpfs', un tipo de volúmenes en memoria.

    • 'Chapter 3 - Undestanding Docker Networking:' En la primera parte del capítulo habla de conceptos de conectividad y networking aunque trasladados a Docker. Recuerda ideas sobre los puertos TCP/IP y cómo hacer el 'binding' de servicios a puertos, para luego presentar los drivers de networking en Docker y explicar la idea del 'default bridge'. En la segunda parte explica el uso de comandos para realizar tareas como conectar un contenedor a una red, exponer servicios, exponer puertos, borrar redes o ejecutar un contenedor sin red.

  • 'SECTION 2 - CREATING KUBERNETES DEVELOPMENT CLUSTERS, UNDERSTANDIING OBJECTS AND EXPOSING SERVICES:' Se centra en clusters y Kubernetes. Incluye tres capítulos:

    • 'Chapter 4 - Deploying Kubernetes using KinD:' Un capítulo dedicado al despliegue de clusters Kubernetes locales, normalmente empleados como clusters de desarrollo o demostración, usando para ello la herramienta KinD. Se explican temas de detalle como las imágenes y luego se pasa a los aspectos prácticos de cómo instalar KinD y cómo crear y revisar un cluster. Se añade al final una sección, bastante técnica y detallada, dedicada a contar el uso de un balanceador de carga para Ingress.

    • 'Chapter 5 - Kubernetes Bootcamp:' Un capítulo en que, de una forma práctica, se revisan los conceptos más nucleares de Kubernetes. Primero se cuentan los diferentes elementos de un cluster Kubernetes distinguiendo entre los que se encuentran en el plano de control (API server, la base de datos etcd, kube-scheduler, kube-controller-manager y cloud-controller-manager) y los que se encuentran en los 'worker nodes' (kubelet y kube-cloud-proxy)

    • 'Chapter 6 - Services, Load Balancing and DNS:' Explica la exposición de servicios para su invocación desde el exterior introduciendo elementos avanzados como los repartidores de carga. Comienza recordando cómo funcionan los servicios incluyendo el detalle de cómo se crean y cómo se emplea DNS para resolver nombres. Luego explica los cuatro tipos de servicios (ClusterIP, NodePort, LoadBalancer y ExternalName) y luego se extiende explicando ideas sobre repartidores de carga y detallando tanto los balanceadores de nivel 7 (aplicación) como de nivel 4 (transporte). Finalmente se explica el uso de DNS externos y su integración con el balanceador de carga.

  • 'SECTION 3 - RUNNING KUBERNETES IN THE ENTERPRISE:' Se ocupa del despliegue real de Kuberntes y Docker en la empresa, con mucho foco en los aspectos de seguridad y rodeando a las herramientas principales de todo un ecosistema de herramientas 'open-source' complementarias. Incluye ocho capítulos:

    • 'Chapter 7 - Integrating Authentication into your Cluster:' Trata el tema de autenticación en los entornos Kubernetes. Primero se explica cómo Kubernetes identifica al invocante de un servicio y se introducen las ideas de grupos y cuentas de servicio. Luego se explica OpenID Connect, un protocolo de identidad federada y cómo se configura KinD para interactuar con él. Luego se presenta el mecanismo de impersonación de Kubernetes que no necesita de credenciales ni identidades OpenID y cómo se configura un cluster para usar este mecanismo.

    • 'Chapter 8 - RBAC Policies and Auditing:' Si el capítulo anterior estaba enfocado a la autenticación, este mira más hacia los otros dos mecanismos de la denominada triple AAA, es decir, la autorización (authorization) y audiitoria (audit). Prrimer repasa RBAC ('Role Based Access Control') y dedica bastante espacio a hablar de los roles para luego ver cómo ligar las identidades de una empresa con Kubernetes para implementar ese mecanismo de autorización. Luego se cubre la auditoría, explicando cómo crear una política ('policy') y cómo depurar políticas usando la herramienta 'audit2rbac'.

    • 'Chapter 9 - Deploying a Secured Kubernetes Dashboard:' A través del Dashboard se ilustra lo que los autores consideran un 'anti-patrón' de acceso que utiliza las capacidades 'proxy' o 'port-forward'. Primero se ilustra cómo el Dashbard sabe quién el es usuario y las opciones de autenticación. Se revisan luego los riesgos de autenticación y se finaliza revisando cómo desplegar un Dashboard con un proxy inverso.

    • 'Chapter 10 - Creating PodSecurity Policies:' Si en los capítulos anteriores el foco era securizar las APIs de Kubernetes, en este lo importante es securizar los nodos y con esa idea se abordan las denominadas PodSecutityPolicies (PSPs). Primero se explica en qué consisten estas PSPs y luego se ilustra cómo activarlas y, para finalizar, se revisan algunas alternativas a las PSPs.

    • 'Chapter 11 - Extending Security Using Open Policy Agent:' Con los mecanismos vistos en los capítulos anteriores de esta sección se cubren la mayor parte de las necesidades en materia de autenticación y autorización pero existen algunas casuísticas que quedan fuera. Para abordarlas se utilizan los denominados controladores dinámicos de admisión. En este capítulo se estudia el más popular de ellos: el Open Policy Agent u OPA. Se explica lo que es y cómo funciona incluyendo una descripción de su arquitectura. Se introduce brevemente Rego, un lenguaje para evaluación de políticas y se ilustra su uso para escribir políticas y para su depuración. Se finaliza explicando cómo se fuerza el cumplimiento de las políticas definidas con OPA.

    • 'Chapter 12 - Auditing using Falco and EFK:' En el capítulo se abordan mecanismos y herramienta de cara a la realización de auditoría procesando los logs. En ese caso, se emplea por un lado Falco para generar logos más ricos y el 'stack' EFK que incluye ElasticSearch, Fluent y Kibana para el procesamiento de esos logs. Al final, la mayor parte del capítulo está dedicado a Falco explicando sus principales conceptos, su configuración y su despliegue. Finaliza el capítulo con una descripción del kernel de Falco.

    • 'Chapter 13 - Backing Up Workloads:' Aborda la realización de copias de seguridad para lo que se usa la herramienta Velero. Primero se explican ideas generales sobre los backups de Kubernetes. Antes de entrar en Velero se describe cómo realizar un backup de la base de datos etcd. A continuación se describe MinIO una solución de almacenamiento compatible con Amazon AWS S3. Y luego ya se entra de lleno en Velero, explicando su instalación y confguración, su dashboard. A continuación se explica cómo se utiliza velero para la realización y restauración de backups y el uso de su interfaz de comandos.

    • 'Chapter 14 - Provisioning a Platform:' Como remate, este último capítulo se describe una plataforma completa para el despliegue de aplicaciones basada en lo visto en capítulos anteriores y que incluye el diseño de la 'pipeline', la preparación del cluster, el despliegue de GitLab, el despliegue de Tekton y el despliegue de ArgoCD.
'Kubernetes and Docker. An enterprise guide' es un buen libro pero desde luego no para principiantes. Los autores explicitan, de hecho, que ya presuponen en los lectores los conocimientos básicos de Docker y Kubernetes, aunque hacen una pequeña concesión en el capítulo 5 para hacer una especie de rápido repaso. En cualquier caso, claramente, el público de este libro es un público técnico, principalmente, arquitectos y administradores cloud/DevOps y con al menos medianos conocimientos de las arquitecturas cloud, del concepto de contenedores e ideas sobre DevOps. Sin esa base, la lectura es ardua y quizá de escaso aprovechamiento.

Sin embargo, con el punto de partida adecuado, es un libro que ofrece una visión a un tiempo amplia y detallada, con ejemplos y herramientas muy prácticos y realistas y con mucho foco en todo lo que tiene que ver con los mecanismos de seguridad: autenticación, autorización, auditoría y backup.

Una lectura, pues, bastante especializada. 

Scott Surovich

(Fuente: Traducción y ligera elaboración propia de su biografía en Amazon)

Scott Surovich
Scott Surovich ha estado en el mundo de la empresa durante más de 20 años y es actualmente Global container engineering lead en un banco Global Tier 1, trabajando en estándares sobre diseño y despliegue con Kubernetes, incluyendo el ecosistema que lo rodea. Sus puestos anteriores incluyen el trabajo en otros equipos globales de ingeniería incluyendo Windows, Linux y virtualización. Su experiencia empresarial le ha permitido trabajar con múltiples compañías en sus primeras ofertas Kubernetes, incluyendo Kasten, Reduxio, VMware y Google.

Scott posee las certificaciones CKA, CKAD, y Mirantis Kubernetes. Como integrante de un equipo piloto, fue una de las primeras personas en recibir la certificación Google Certified Hybrid Multi-Cloud Fellow.

Puedes saber más del autor visitando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @surovich.

Marc Boorshtein

(Fuente: Traducción y ligera elaboración propia de su biografía en Amazon)

Marc Boorshtein
Marc Boorshtein ha sido ingeniero de software y consultor durante casi veinte años y actualmente es CTO de Tremolo Security, Inc. Marc ha invertido la mayor parte de su carrera construyendo soluciones de gestión de identidad para grandes empresas, agencias civiles del gobierno norteamericano y sistemas de seguridad pública de administraciones locales. En los últimos años, Marc se ha enfocado en aplicar la gestión de identidad a DevOps y Kubernetes, construyendo herramientas open-source para automatizar la seguridad de la infraestructura.

Marc está certificado como CKAD y se le puede encontrar en los canales slack de Kubernetes contestando preguntas sobre autenticación y autorización.

Puedes saber más del autor visitando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @mlbiam.


Ficha técnica:

EDITORIAL: Packt Publishing
AÑO: 2020 
ISBN: 978-1839213403
PAGINAS: 526

viernes, 14 de octubre de 2022

Un panorama de Amazon AWS con Alberto Artasanchez

'AWS for solutions architects' es un libro técnico y descriptivo que aborda los aspectos arquitecturales y servicios fundamentales de Amazon AWS.

El libro se estructura en 14 capítulos agrupados en cuatro secciones como sigue:
  • 'SECTION 1: EXPLORING AWS': Ofrece una visión introductoria y de alto nivel sobre cloud computing, AWS y la migración a la nube y lo hace en dos capítulos:

    • 'Chapter 1 Understanding AWS Cloud Principles and Key Characteristics': Capítulo introductorio al mismo concepto de cloud computing y algún detalle de AWS. Primero explica qué es el cloud computing y por qué es tan popular hoy día y también detalla qué es AWS y aporta algunos términos. A continuación menciona unos principios para una buena arquitectura y dedica gran parte del resto del capítulo a comentar la importancia y mecanismos para certificarse en AWS.

    • 'Chapter 2 Leveraging the Cloud for Digital Transformation': Incluye dos partes bien diferenciadas. En la primera cuenta la estructuración hardware y geográfica de AWS, hablando de las regiones, 'Availability Zones' y 'Local Zones'. En la segunda parte se centra más en los proyectos para ir a la nube comentando las diferentes estrategias posibles y las herramientas que ofrece AWS para ayudar en esa migración. Además, habla de una forma que se me antoja algo genérica y casi forzada de transformación digital.

  • 'SECTION 2: AWS SERVICE OFFERING AND USE CASES': Una revisión de los servicios fundamentales de AWS muy centrados en la computación, en la seguridad y, sobre todo, en el almacenamiento y el tratamiento de datos. A ello dedica seis capítulos:

    • 'Chapter 3 Storage in AWS – Choosing the Right Tool for the Job': Aborda primero el almacenamiento de bloques con el servicio EBS ('Elastic Block Storage') y EFS ('Elastic File System') y luego dedica gran parte del espacio a hablar de almacenamiento de objetos y del servicio S3 ('Simple Storage Service') en sus diferentes variantes: 'Standard', 'Intelligent-Tiering', 'Standard-IA', 'One-Zone IA', 'Glacier' y 'Glacier Deep Archive' y finaliza aportando algunas buenas prácticas.

    • 'Chapter 4 Harnessing the Power of Cloud Computing': Tras explicar los conceptos de IaaS, PaaS y SaaS, aborda el servicio EC2 ('Elastic Compute Cloud') para cuyo uso también proporciona buenas prácticas y finaliza poniéndolo en relación con el servicio S3 visto en el capítulo anterior.

    • 'Chapter 5 Selecting the Right Database Services': Hace un repaso de los tipos de bases de datos existenes y, al hilo de ese repaso, va presentando servicios de AWS que las soportan. Así, en cuanto a bases de datos relacionales menciona el servicio RDS ('Relational Database Service'), en relación con las bases de datos de tipo clave-valor y las documentales saca a relucir 'DinamoDB', en cuanto a bases de datos columnares aparece MCS ('Managed Cassandra Service'), en cuanto a consultas se habla de ElasticSearch y Kendra, en lo relativo a bases de datos en memoria se menciona Elastic Cache, en bases de datos de grafo aparece Neptune, en series temporales Timestream, en las de tipo 'ledger' Quantum y, finalmente, para procesamiento analítico (OLAP), se habla de Redshift.

    • 'Chapter 6 Amazon Athena – Combining the Simplicity of Files with the Power of SQL': Aborda Athena, una solución para consultar ficheros y objetos usando una sintaxis SQL como si fuesen tablas. Explica algunos de los formatos de ficheros que puede leer (CSV, JSON, ORC, Avro, Parquet), algo del funcionamiento interno de Athena y también la idea de las consultas federadas. Tambien menciona brevemente el concepto de workgroups, las APIs athena y la optimización de Athena.

    • 'Chapter 7 AWS Glue – Extracting, Transforming, and Loading Data the Simple Way': Trata el servicio 'Amazon Glue' dedicado a laboras de ETL ('Extract Transform, Load'), explica el manejo desde la consola y conceptos como el catálogo, los 'crawlers' y los 'classifiers'. También cuenta las capacidades para procesar datos provenientes de servicios de streaming y finaliza aportando unas buenas prácticas.

    • 'Chapter 8 Best Practices for Application Security, Identity, and Compliance': Se cierra esta sección con un capítulo sobre identidad y seguridad. Tras remarcar la importancia de la gestión de identidad y la seguridad, explica la gestión de identidad y gestión de acceso (IAM, 'Identity and Access Management') dentro de AWS. Luego habla de la administración de usuarios, grupos, roles, políticas y permisos y finaliza apuntando algunas ideas sobre una larga lista adicional de servicios relacionados con la seguridad como Control Tower, Shield, Key Management Services y así un largo etcétera.

  • 'SECTION 3: APPLYING ARCHITECTURAL PATTERNS AND REFERENCE ARCHITECTURES': Abandona en cierto sentido la descripción de servicios concretos para adoptar una perspectiva más global y de arquitectura aunque eso lleve, a su vez a descubrir nuevos servicios. Se compone de cinco capítulos:

    • 'Chapter 9 Serverless and Container Patterns': habla de dos conceptos fundamentales en la visión de sistemas en general y de cloud en particular hoy en día: contenedores y 'serverless'. Explica las ideas sobre virtualización así como los productos Docker y Kubernettes, lo que lleva a la mención del servicio EKS ('Elastic container service for Kubernetts'). También se describen Fargate y AWS Batch.

    • 'Chapter 10 Microservices and Event-Driven Architectures': Habla de servicios y de arquitecturas orientadas a eventos, explicando los conceptos, las ventajas y desventajas y algunas buenas prácticas.

    • 'Chapter 11 Domain-Driven Design': Habla del diseño orientado a dominios para lo que parte de una perspectiva histórica que nace con la orientación a objetos. Dedica bastante espacio a explicar los conceptos detrás de esta arquitectura y luego retoma el tema de los microservicios iniciado en el capítulo anterior, explicando diferencias y ventajas frente a arquitecturas monolíticas, para luego explicar cómo se manejan los microservicios en AWS y finalizar con algunos ejemplos.

    • 'Chapter 12 Data Lake Patterns – Integrating Your Data across the Enterprise': Le toca el turno a los 'datalakes'. Explica lo que son, sus componentes, algunas buenas prácticas y una selección de indicadores.

    • 'Chapter 13 Availability, Reliability, and Scalability Patterns': Habla de alta disponibilidad y de escalabilidad, explicando primero los conceptos arquitecturales para luego volver la vista hacia AWS y describir cómo se gestiona la disponibilidad en servicios como EC2 o RDS y explicar aspectos de reparto de carga soportados por el servicio EBS ('Elastic Load Balancer').

  • 'SECTION 4: HANDS-ON LABS': Ejempifica todos los conceptos aplicados en un capítulo final único.

    • 'Chapter 14 Hands-On Lab and Use Case': Un capítulo final en que desarrolla de principio a fin una caso de uso de una arquitectura web serverless.

'AWS for solutions architects' es un libro correcto, efectivo aunque sin brillantez, que supone una buena introducción a AWS y que, de paso, permite entender, llevado a un proveedor y soluciones reales, los principales conceptos actuales en materia de cloud computing y arquitecturas cloud nativas.

Una referencia no definitiva, pero sí bastante útil.

Alberto Artasanchez


(Fuente: Traducción y ligera elaboración propia de su ficha de autor en el libro 'AWS for solutions architects')

Alberto Artasanchez
Alberto Artasanchez es un arquitecto de soluciones con experiencia en cloud, soluciones de datos y machine learning en una carrera que se extiende durante más de 30 años en varios sectores.

Es embajador AWS y escribe frecuentemente en una variedad de publicaciones sobre cloud y ciencia de datos. Es requerido a menudo como speaker sobre temas que incluyen la ciencia de datos, big data y analítica.

Tiene un importante historial en el diseño y construcción de plataformas de machine learning a gran escala. También tiene un largo historial en la dirección de equipos y en su mentorización, coaching y motivación. Posee un gran entendimiento sobre cómo la tecnología impulsa el valor de negocio y le apasiona crear soluciones elegantes para problemas complejos.

Puedes saber más del autor visitando su perfil en LinkedIn o siguiéndole en Twitter donde se identifica como @aartasanchez.

Ficha técnica:

EDITORIAL: Packt Publishing
AÑO: 2021 
ISBN: 978-1789539233
PAGINAS: 454


martes, 27 de septiembre de 2022

Conociendo Azure DevOps con Zaal, Demillani y Malik

'Azure DevOps explained' es, exactamente, lo que su título promete: una explicación de cómo aplicar DevOps usando las herramientas y los servicios que para ello proporciona Microsoft Azure. Con esa idea, tras una breve pero correcta introducción, de alguna forma recorre el ciclo de vida del software en filosofía DevOps, explicando las ideas y, sobre todo, cómo se plasman y usan en Azure.

Con esta línea argumental, el libro se estructura en once capítulos agrupados en cuatro secciones, como sigue:
  • 'SECTION 1: DEVOPS PRINCIPLES AND AZURE DEVOPS PROJECT MANAGEMENT': Pone las bases antes de abordar ei ciclo de vida propiamente dicho. Abarca dos capítulos:

    • 'Chapter 1 - Azure DevOps Overview': Un capítulo introductorio que explica lo que es DevOps y sus principios, para seguir con alguna idea también básica de su enfoque en Azure, comentando conceptos en realidad generales del mundo DevOps como el ciclo 'Plan, Develop, Deliver, Operate', 'Continous Integration, Continuous Delivery (CD/CI)', 'Infrastructure as Code' y algún detalle más propio de Azure como la forma de hacer control de versiones. Finalmente, presenta brevemente los servicios Azure implicados: Azure Boards, Azure Repos, Azure Pipelines, Azure Test Plans y Azure Artifacts.

    • 'Chapter 2 - Managing Projects with Azure DevOps Boards': Explica los primeros pasos para la gestión de proyectos con Azure Boards: los 'templates' con foco en Scrum, cómo crear una organización y cómo crear el proyecto, sus actividades e items. También muestra el tratamiento del 'product backlog', de los 'sprints' y las 'queries'.


  • 'SECTION 2: SOURCE CODE AND BUILDS': Se ocupa de la parte más orientada a la construcción: el código fuente, las 'pipelines' y las pruebas unitarias, para lo que emplea los siguientes cuatro capítulos:

    • 'Chapter 3 - Source Control Management with Azure DevOps': Habla del control de configuración y del código fuente. Tras explicar en qué consiste y cómo funciona el control de código fuente y algunas estrategias de 'branching', aborda luego su manejo en Azure DevOps, el uso de Azure Repos, el importado de un repositorio desde GitHub, el trabajo con 'commits', 'pushes', 'branches' y 'pull requests'. Acaba con el etiquetado ('tagging' de releases).

    • 'Chapter 4 - Understanding Azure DevOps Pipelines': Aborda lo que quizá sea uno de los conceptos fundamentales: las 'pipelines'. Primero explica los conceptos básicos de la integración y despliegue continuos (CI/CD), para y luego detalla el funcionamiento de las 'pipelines' de Azure. En esa tarea habla de los agentes, del lenguaje YAML, de la creación de una pipeline con un repositorio GitHub y del uso de contenedores en las 'pipelines' de Azure.

    • 'Chapter 5 - Running Quality Tests in a Build Pipeline': Pasa ahora a las pruebas. Como en otros capítulos, introduce primero los conceptos de forma general, en este caso, las pruebas unitarias y los beneficios de la automatización de pruebas para luego ya verlo reflejado en Azure.

    • 'Chapter 6 - Hosting Your Own Azure Pipeline Agent': Explica la construcción de 'pipelines' usando en lugar de agentes alojados por Microsoft, agentes alojados por el cliente incluyendo el caso de contenedores.


  • 'SECTION 3: ARTIFACTS AND DEPLOYMENTS': Se centra sobre todo en el despliegue, pero teniendo en cuenta también el uso de recursos externos. En esta labor, empeña los dos siguientes capítulos:

    • 'Chapter 7 - Using Artifacts with Azure DevOps': Habla del uso de artefactos, que se refieren a componentes que son reutilizables, que eventualmente proceden de una fuente externa y que son recogidos en 'packages'. Aborda luego Azure Artifacts y así Habla del concepto de 'feed' de artefactos, (una forma de agrupar paquetes y sus permisos) y cuenta cómo crearlo, como introducirlo en una 'pipeline', cómo publicarlo y cómo consumirlo.

    • 'Chapter 8 - Deploying Applications with Azure DevOps': Se ocupa del despliegue de aplicaciones usando 'pipelines' de Azure, explicando, entre otras cosas, cómo configurar el despliegue continuo o cómo introducir puertas y permisos para controlar las 'releases'.


  • 'SECTION 4: ADVANCED FEATURES OF AZURE DEVOPS': Una sección un poco complementaria, revisa algunas situaciones particulares (integración con GitHub y pruebas manuales) y remata con ejemplos de la vida real:

    • 'Chapter 9 - Integrating Azure DevOps with GitHub': Explica la integración con GitHub abordando esa integración tanto en Azure Pipelines como Azure Boards.

    • 'Chapter 10 - Using Test Plans with Azure DevOps': Explica Azure Test Plans y cómo gestionar con él pruebas manuales, pruebas exploratorias o pruebas de aceptación de usuario.

    • 'Chapter 11 - Real-World CI/CD Scenarios with Azure DevOps': Muestra algunos ejemplos de proyectos de la vida real que incluye un caso con aplicaciones .Net y otro con contenedores.
'Azure DevOps explained' es un libro, creo, completo, correcto, directo y efectivo que, sin adornos, explica lo que hay que explicar en una obra de esta naturaleza: los conceptos relevantes de DevOps y cómo se implementan en Azure. La parte del uso de Azure es detallada y con abundantes capturas de pantallas lo que permite su traslación bastante directa a la práctica.

Un libro útil, en definitiva.

Ficha técnica:

AUTORES: Sjoukje Zaal, Stefano Demillani y Amit Malik
EDITORIAL: Packt
AÑO: 2020 
ISBN: 978-1800563513
PAGINAS: 438


viernes, 30 de julio de 2021

Características clave del cloud computing para la transformación digital

No cabe duda de que el cloud computing ha sido una de las tendencias tecnológicas clave de los últimos años, una fuerza transformadora cuyos efectos se hacen sentir en la gestión de la TI de las organizaciones, en el propio uso de particulares en sus hogares y móviles, o en la democratización y expansión de tecnologías avanzadas como el machine learning o los chatbots.

Podríamos decir que, al contrario que otras tecnologías rodeadas del famoso 'hype', cloud computing sí ha estado a la altura de su promesa y que es un enorme motor de transformación aunque a veces pueda pasar ligeramente inadvertida frente a tecnologías más originales o brillantes como la inteligencia artificial, el blockchain o el big data a las que, sin embargo, sirve con frecuencia de soporte e impulso.

He leído el libro 'Digital Transformation : survive and thrive in the era of mass extinction' de Tom Siebel autor conocido y reconocido  por la empresa y herramienta de CRM que llevaba su nombre y que tras una época de enorme éxito fue adquirida luego por su rival Oracle. En el libro, Siebel identifica cuatro grandes tecnologías para la transformación digital y una de ellas es, precisamente, el cloud computing. Las otras son big data, internet de las cosas e inteligencia artificial.

Cuando se refiere a cloud computing, el autor identifica cinco características clave que son las que lo convierten en esa fuerza impulsora de la transformación digital. Son estas:


  • Capacidad infinita: Aunque no, evidentemente, de manera literal, pero a efectos prácticos para una empresa los recursos de computación y almacenamiento existentes en la nube son virtualmente infinitos.

  • Autoservicio a demanda: Los usuarios pueden, cuando lo deseen y bajo su propia decisión, provisionar recursos sin necesidad de mayor intervención humana, dado el nivel de automatización habitual de dicha provisión.

  • Acceso en banda ancha: Se refiere al acceso, y en banda ancha, desde cualquier lugar y dispositivo. En realidad, más que una aportación del cloud computing lo es de las telecomunicaciones pero es cierto que habilita de manera muy notable al cloud computing.

  • 'Pooling' de recursos: Los proveedores de servicios cloud pueden agrupar y concentrar recursos físicos y lógicos que luego se asignan y reasignan de manera dinámica según las necesidades de clientes y usuarios.

  • Elasticidad rápida: Los recursos se provisionan y 'desprovisionan' de manera rápida, automática y trasparente a medida que la demanda de los usuarios se incrementa o disminuye.


En efecto, se trata de cinco características muy propias del cloud computing y que le confieren gran parte de su poder transformador. Quizá añadiría, de mi cosecha, y pensando en empresas concretas, el cambio de modelo de modelo económico, de la inversión al pago por uso, del Capex al Opex y la masiva externalización de capacidades TI, no sólo materiales sino también humanas.

Uniendo todo ello tenemos bastante explicado por qué el cloud computing está cambiando tanto el panorama digital. Lo ha hecho en los últimos años y creo que continuará haciéndolo hasta convertirse, ya casi lo es, en el 'new normal'.


viernes, 18 de junio de 2021

Modelos de software en la nube y el impacto en sistemas cognitivos

A estas alturas, creo que es indudable el gran impacto, la gran transformación que a nivel de TI y de todo el mundo digital, ha tenido la nube, el cloud computing.


La evolución del cloud computing


Debo confesar que, cuando hace ya bastantes años oí hablar de este concepto por primera vez, no creí que llegara a ser tan revolucionario...pero sí que lo ha sido y lo va a seguir siendo.

En sus  primeras implementaciones prácticas, el cloud computing puso más énfasis, como heredero de los llamados hosting y housing, en todo lo relativo al hardware y la infraestructura, lo que posteriormente se ha reconvertido en los así llamados IaaS (Infrastructure as a Service) y PaaS (Platform as a Service).

Pero con todo y lo importante que desde un punto de vista de negocio y de operación TI es la externalización de la infraestructura y su paso del modelo de propiedad al de uso, creo que la transformación más profunda y su carácter impulsor de la transformación digital global viene dada por la prestación de capacidades de software desde la nube, una prestación que inicialmente se centraba en el modelo SaaS (Software as a Service), que viene a ser, por decirlo coloquialmente, como el alquiler de una aplicación completa pero que se extiende y completa posteriormente con la visión más orientada a servicios, derivada de la filosofía SOA (Service Oriented Architecture) y que con ingredientes adicionales ha dado lugar a las APIs web (típicamente REST), a los contenedores, a los microservicios y al concepto de Función como Servicio (FaaS, Functions as a Service), generando una panoplia de opciones caracterizadas todas ellas por su prestación desde la nube y en modo pago por uso y unas opciones que cada vez se orienta menos a la aplicación y más al servicio, la función y las APIs.


Modelos de software en la nube


Aunque no es el objetivo principal del libro, me ha gustado mucho, por lo compacto y clarificador, el esquema que al respecto de todas las opciones existentes, plantea Jaume Miralles en 'Proyectos de Inteligencia Artificial' y que, a su vez, se basa en el articulo '¿Qué modelo Cloud es el mejor para los desarrolladores?' escrito por Ana López Mancisidor y José Miguel Ordax en un blog de IBM.

El modelo es el que se muestra en la figura:


En ese modelo se observan 9 niveles de capacidades hardware y software que, de abajo a arriba son:

  • Networking
  • Almacenamiento
  • Servidores
  • Virtualización
  • Sistema operativo
  • Middleware
  • Configuración del middleware
  • Datos
  • Aplicaciones

En esos niveles, se puede ver que los tres primeros (Networking, Almacenamiento y Servidores) se concentran más en los aspectos hardware; los siguientes se concentran el el software de plataforma (Virtualización, Sistema Operativo, Middleware y configuración del middleware) y los dos dos últimos (Datos y Aplicaciones) en las aplicaciones finales.

A su vez, el esquema muestra mediante un código de colores en quién recae la responsabilidad de cada uno de esos bloques (azul oscuro es el modelo tradicional, con responsabilidad por parte del cliente o usuario, y azul claro responsabilidad por parte de un proveedor de servicio).

Y con esas bases, los autores encajan seis modelos, que, en orden creciente de externalización y servitización (que no de orden cronológico de aparición en el mercado) son:

  • Tradicional ('on premises'): el cliente usuario mantiene la propiedad y responsabilidad de todos los elementos y en sus propias instalaciones.

  • IaaS (Infrastructure as a Service): El proveedor de servicio proporciona ya lo relativo al hardware (Networking, Almacenamiento y Servidores) y algo de virtualización.

  • CaaS (Containers as a Service): Se introduce el concepto de contenedor y el proveedor del servicio se hace cargo ya del sistema operativo y el middleware.

  • PaaS (Plataform as a Service): El proveedor de servicio se hace ya cargo de todo el software de plataforma, añadiendo al caso anterior la configuración del middleware.

  • FaaS (Functions as a Service): En realidad no añade externalización ni servitización de ninguna capa, pero sí es cierto que la capa de aplicación y datos cambia y se convierte, de hecho, en lo que los autores denominan 'acciones y disparadores' puesto que, en el caso de FaaS, no existe una aplicación como tal, sino una serie de funciones autocontenidas.

  • SaaS (Software as a Service): Supone la externalización y servitización completas donde toda la aplicación y los elementos inferiores necesarios es proporcionada por el proveedor de servicios.


En este esquema se indica que los modelos más a la izquierda proporcionan un mayor rendimiento y control por parte del cliente / usuario, mientras que los de la derecha tienen a proporcionar velocidades crecientes de desarrollo.


El impacto en sistemas cognitivos


¿Y por qué Jaume Miralles se detiene a hablar sobre cloud computing y los modelos de prestación de las capacidades software cuando su libro trata de inteligencia artificial y de proyectos de inteligencia artificial?

Pues porque el impacto de estos modelos en la nube es enorme en el caso de la implantación y popularización de la inteligencia artificial. Porque, como el autor también explica en su libro, con cierta frecuencia (aunque no siempre), cuando una empresa se plantea realizar un proyecto de inteligencia artificial no desarrolla las capacidades cognitivas por sí mismo sino que se apoya en capacidades ya existentes y disponibles normalmente en la nube bajo alguno de los esquemas mencionados o alguno similar, muy especialmente los esquemas en que el software no se ofrece como aplicación sino como servicios y APIs (como sucede, por ejemplo, en CaaS y FaaS). Esto es especialmente notorio cuando hablamos de capacidades tecnológicamente complejas y que precisan muchísimos datos de entrenamiento como pueden ser las relativas a procesamiento de lenguaje natural.

Cuando se buscan los motivos del éxito actual de la inteligencia artificial se apuntan a aspectos como el aumento de la capacidad de computación (y el uso de las GPUs), la aparición de nuevos algoritmos (sobre todo de deep learning) y la gran disponibilidad de datos. Todo ello es cierto, pero creo que no cabe menospreciar sino, bien al contrario, resaltar, la contribución que estos modelos de prestación de servicios cognitivos desde la nube están teniendo en la democratización de la Inteligencia Artificial poniendo capacidades muy avanzadas casi al alcance de cualquiera.