Externalización de servicios IT

Este año visité una gran empresa del sector aéreo que decidió internalizar de nuevo parte del servicio externalizado de infraestructuras IT después de varios años sufrir maletendidos con un proveedor de “los grandes”.

Hace ya unos años la misma empresa decidió también hacer lo mismo internalizar (o realizar un “INsourcing”) del desarrollo de aplicaciones.

La diferencia es que, al internalizar de nuevo, la empresa se decidió por trasladar los servicios de un país Europeo de costes laborales altos a otro país con costes más bajos, pero con personal propio. Además para los datacenters se decidió por un modelo híbrido de cloud privada y pública. Al ser una compañía aérea antigua tiene mucho “legacy”.

Como personalmente me he encontrado con tanta frustración y malentendidos con los contratos de outsourcing de IT siempre me pregunto cómo podrían mejorarse estos contratos para que no acaben tan mal. Y la verdad que no lo tengo del todo claro.

Parece que cliente y proveedor de servicios IT estén condenados al conflicto, pero algo debemos hacer mal cliente y proveedor sino somos capaces de mejorar esta situación.

La responsabilidad de firmar y llevar adelante un buen contrato de servicios es algo que corresponde a ambas partes:

Por parte del cliente

  • Proveer de la información correcta (Inventarios, Volúmenes, costes actuales, documentación, etc) y más detallada posible para que el proveedor pueda hacer una oferta lo más ajustada a la realidad.
  • Ofrecer el tiempo razonable para que el proveedor de servicio puede analizar con tiempo toda la información que se provee y resolver las dudas que el proveedor plantee
  • Disponer del tiempo necesario del equipo de personas que puedan dar soporte al proveedor para realizar la oferta. Una buena solución es considerar el proceso de externalización de servicios como un proyecto con recursos dedicados parcial o totalmente
  • Informar claramente al personal interno directamente afectado por el proceso de externalización sobre su futuro laboral una vez externalizado el servicio para reducir la resistencia al cambio
  • Dependiendo de la duración del contrato, preveer crecimientos o decrecimientos que puedan afectar a los volúmenes establecidos en la línea base del contrato
  • Reconocer que el proveedor de servicio es otra empresa que busca ganar dinero, con sus márgenes de beneficio. No puede haber un buen entendimiento y buen servicio si el cliente piensa en “exprimir” al máximo al proveedor de servicios. Aquí hay mucha empresa final que pretende conseguir del proveedor lo que se conoce como “your mess for less” – te paso mi IT desastrosa, me quito el problema y me lo administras por un menor coste
  • Conocer cómo pretente conseguir las reducciones de costes el proveedor:
    • Economías de escala: No es lo mismo administrar 100 servidores que 1000, pero sin automatización difícilmente conseguiremos reducción de costes
    • Transformar la infraestructura – Automatización y estandarización
    • Contratos de larga duración – para dar capacidad al proveedor de transformar la infraestructura – No puedo pretender entregar al proveedor un “zoológico” de sistemas y que al cabo de un año finalice un contrato con una infraestructura automatizada y con reducción de costes!
  • Pretender personalizar el servicio demasiado … por mucha automatización que pongamos siempre tendremos personas tras un servicio y aquí no tengo claro qué es lo mejor:
    • Queremos únicamente un servicio con un SLA a cumplir, sin importar las personas que hay detrás?
    • O quizás un servicio basado en FTEs (Full Time Employees) con nombres y apellidos ?
    • El personal de nuestro proveedor está exprimido a base de guardias, turnos, sin motivación?
    • Preferimos tener un servicio barato aunque se de desde otro país con costes más bajos?
    • Nuestro proveedor tiene una alta rotación de personal, dificultando el traspaso de conocimiento de nuestros sistemas cuando el personal cambia?
    • Qué pasa con el servicio en periodo vacacional: Por ejemplo trabajando en una empresa turística julio y agosto pueden ser meses pico pero habrá que ver cómo cubre las vacaciones el outsourcer

Por parte del proveedor de servicios

  • No vender “humo”, ser honestos en cuanto a experiencia y capacidad para llevar adelante un proyecto de outsourcing. Exponer claramente en qué se dispone de experiencia con ejemplos y referencias y en qué casos tendremos que “re-inventar” la rueda
  • Proporcionar transparencia en cuanto a las subcontratas, qué contratos tendrá el proveedor con las empresas subcontratadas y cómo se gestionarán a lo largo del contracto de servicio con el cliente final – evitemos un cambio de subcontrata, salvo por motivos justificados, a mitad de nuestro contrato de servicio
  • Comprometerse, tanto en tiempo como en recursos, a una transformación y modernización real de la infraestrutura IT del cliente con indicadores claros de grado de transformación a lo largo del cliente
  • Proporcionar costes unitarios claros del servicio y establecer los volúmenes máximos y mínimos donde aplicarán estos costes unitarios
  • Adaptar los costes unitarios al mundo cloud, por ejemplo de cada vez tiene menos sentido ofrecer costes por tamaño de servidor en un mundo cloud
  • Cómo gestionaremos de forma integral la seguridad de la infraestructura IT – no podemos tener ya parcheos mensuales de servidores
  • Trabajar para satisfacer las expectativas del cliente. Sabremos si hemos hecho un buen contrato y cumplido con las espectativas si, al finalizar el contrato, el cliente se encuentra satisfecho y quiere renovar el contrato porque realmente está contento con el servicio y no por el coste o esfuerzo de salida del cambio de proveedor

My very first travel app

The nine weeks of the web development training at Ironhack Berlin are gone! I had a great time and I will miss my teachers and colleagues, as well as enjoying life at the German capital.

Web development teachers and students

To finish my training I had to present a final project and decided to develop a travel app. I have been working many years in the Tourism / Travel industry and wanted to develop a website using well-know API (Application Programming Interface).

So I developed a website called “myTravelApp” in 2 iterations. The website is a full-stack responsive application developed using JavaScript. You can access the code in my GitHub repository: https://github.com/amerzbach/myTravelAppReact

You can test the app accessing to: https://mytravelapp-react.herokuapp.com/

User story

myTravelApp” allows you to search for flights, hotels and activities in any destination worldwide in a simple way.

Also from the homepage you can search in a combined way for all 3 products.

Based on a tabbed interface you can access to:

  • Flights information including total duration, number of stops, airline and flight number, arrival and departure times
  • Hotel description, photos and location
  • Activities description
Flights search implemented using Lufthansa Open API
Hotel Information provided by Hotelbeds APItude
Combined search of Flights + Hotels + Activities

Front-End

In the first iteration was developed using Handlebarsjs while for the second version presented I re-designed it using the popular React library. In both cases, I used also Bootstrap and CSS. In the beginning, React was a bit hard to understand, but after the learning process, I started to love it.

Back-End

For the back-end part, I used NodeJS, Express and a MongoDB database. To access the APIs I used Axios library.

One of my main objectives was learning to use well-known APIs, the ones I use are:

The most interesting part here was to setup a multi-layer API calls from the front-end to the back-end and from there to the API Provider. I had to do it this way because the APIs required authentication and this is only to be set up securely from the back-end.
Moreover, for the combined search of Flights + Hotels + Activities, I learned how to parallelize 4 API calls at the same time to improve performance.

Tools

During the Ironhack training and the project I learned also to use:

  • Microsoft Visual Studio Code
  • GitHub as the code repository
  • MongoDB Compass
  • Postman to simulate API calls
  • Heroku as the hosting platform
Using Microsoft Visual Studio Code to code

Lessons learned

  1. React is much better for front-end development compared to other alternatives​
  2. Is important to read the API documentation​, however, could not be easy to understand for beginners like me.
  3. API authentication is the first step to use the API​
  4. API Authentication – requires API Calls from the back to store authentication keys​
  5. Each API use its authentication method, for example: Lufthansa Open API uses Token-based auth​entication and Hotelbeds APITUDE: SHA-256 Encryption​
  6. As I used non-productive test API – not always stable – Plan alternatives for your app demo in case your API does not work or perform well.

Modernizando el departamento de TI

Aquí va un resumen de algunos artículos que pueden ayudar a modernizar el departamento de TI.

Cloud

Cómo empezar la migración al cloud

Cloud Híbrida: Telefónica y AWS

No-Trust Infrastructures

AWS Certified Solutions Architect

AWS: Machine Learning

Colaboración y puesto de trabajo

Microsoft Teams – ¿ Sustituto del e-mail?

Herramientas de colaboración

Ventajas de una docking station universal

Nueva Surface Pro 6 – Sin USB-C

iPad Pro – Tablet a precio de oro

Gestión de equipos de TI

El efecto “Apple Store” en el primer día de trabajo

Comunicación en equipos virtuales

No-Trust Infrastructures

La forma tradicional de implantar sistemas IT se ha basado en tener una red interna de confianza considerada “segura”, protegida por uno o varios firewalls y capas de seguridad. Fuera de esta zona, teníamos Internet público y la zona de red insegura.

En la zona segura teníamos hospedados nuestros servidores y sistemas críticos, con sus bases de datos, directorios, datos críticos, etc.

Sin embargo cada vez resulta necesario, por no decir imprescindible conectar nuestros servidores y sistemas internos de la zona segura con el mundo exterior para conectarlos a servicios en el cloud público, APIs, microservicios, etc. Y todos estas conexiones externas han convertido a los firewalls en auténticos “quesos de gruyere” con tanta conexión abierta.

Lo mismo sucede con los equipos de usuario final como PCs, Smartphones o Tablets: Aunque sean equipos de empresa la mayoría de las veces se conectan directamente a Internet desde fuera de la oficina. Ya no sirve que los protejamos suponiendo que se conectarán siempre a través de un proxy o un firewall para acceder a innumerables servicios que, en la mayoría de casos, también son accesibles únicamente a través de Internet público.

Y lo mismo sucede con otros elementos de infraestructura como switches, access points, sensores IoT, impresoras, etc – todos requieren cada vez más conectividad con servicios accesibles por Internet fuera de la red interna de la empresa.

La solución a esto implica un cambio de paradigma y en lo que se basa la filosofía de infraestructura “no-trust”: Ya no podemos distinguir en una zona de red segura y confiable y otra insegura. Debemos considerar todas las redes y sistemas no confiables y preparar la infraestructura y los sistemas para ello.

Cómo securizar las infraestructutras “No-trust”

  1. Securizar cualquier sistema (“Hardening”) desde su puesta en marcha: Ya no podemos esperar a la puesta en producción para securizar los sistemas. El “Security by design” se debe aplicar desde el primer momento que se pone en marcha cualquier sistema
  2. Hacer accesibles a los sistemas únicamente a través de conexiones cifradas y securizadas: SSL / TLS, IPSec, doble factor de autenticación, etc
  3. Cifrar los datos
  4. Parchear continuamente los sistemas. Ya no podemos espesar semanas a securizar los sistemas. Se deben parchear tan pronto como se puedan y se publiquen las vulnerabilidades. Si tenemos externalizada la administración de sistemas debemos asegurar que nuestro proveedor lo cumple por contrato
  5. Retirar inmediatamente los sistemas que no se utilicen

En definitiva debemos diseñar la seguridad de nuestros sistemas, aunque sean internos, para que puedan exponerse a Internet.

Por supuesto por temas de compliance y normativas (PCI-DSS, GDPR, etc) puede ser que aun así tengamos que proteger los sistemas en “burbujas” especiales con una protección dedicada.

Xiaomi Mi Box – Actualiza tu televisor a un Smart TV

Buscaba una alternativa a un Apple TV o un Google Chromecast y la encontré en este dispositivo Android TV de Xiaomi para convertir un viejo televisor Samsung en una Smart TV actualizada.

El por qué de la compra

En mi búsqueda de una solución el Apple TV no me convencía porque no dispone de una app de Movistar. Estuve a punto de comprar un Google Chromecast Ultra pero tampoco no me terminaba de gustar tener que controlar la TV desde el Smartphone o un tablet y también la falta de soporte para Chromecast para Movistar.

Finalmente me decidí por el Mi Box por estos motivos:

  • Soporte en Android TV de varias apps incluyendo Movistar
  • Soporte 4K para Netflix
  • También funciona como un Google Chromecast, permitiendo enviar contenido desde un dispositivo móvil iOS o Android
  • Precio similar al Chromecast Ultra, aproximadamente 75 euros o menos, pero con mayores prestaciones

Android TV y el soporte de apps

Como televisor principal tengo un Samsung Smart TV bastante nuevo y, de lo que más me gusta, es que todas las apps de servicios de video en streaming están disponibles para esta plataforma, algo que en el caso de Apple TV está más limitado.

Y buscaba el máximo soporte de apps para mi viejo televisor.

Por suerte el Mi Box con Android TV también ofrece soporte para la mayoría de apps, incluyendo Netflix a 4K, Movistar, Filmin, HBO, RTVE, etc aunque echo en falta alguna para TV3 por ejemplo, aunque lo puedo solucionar utilizando la funcionalidad de Chromecast y utilizando la app de TV3 en mi móvil.

Nada más instalar el Mi Box se actualizó a Android TV 8.0 con un interfaz bastante mejorado.

Mi Box se actualiza de Android TV 6.0 a la versión 8.0 – Oreo

La importancia del mando a distancia

Hace unos años tuve una mala experiencia con una SmartTV de Sony y Android TV debido al mando a distancia: Resultaba imposible manejar la TV y las apps sin tener que mirar el mando a distancia para acertar la tecla a pulsar.

Por suerte esto ya no pasa con el Mi Box y su mando a distancia, resulta muy sencillo a utilizar – de hecho es similar al del Apple TV – y no es necesario desviar nuestra vista al mando cada vez que queremos utilizarlo.

El mando a distancia funciona por Bluetooth y soporta también control remoto por voz, aunque debo confesar que utilizo poco el control por voz.

Mi Box y su mando a distancia

Conectividad

El Mi Box dispone de una conexión HDMI y un puerto USB 2.0 para conectar almacenamiento externo,

A diferencia del Apple TV o el Chromecast Ultra no permite conectarse a la red por cable Ethernet, únicamente a través de WIFI, por lo que, si nos decidimos por un Mi Box tenemos que asegurarnos que nuestra red WIFI funciona perfectamente sin problemas.

Conectividad del Mi Box: USB y HDMI. WIFI pero no Ethernet

 

Guía de compras tech para Navidades

Para los que estéis apurando la compra de regalos o tengáis pendiente la compra de regalos de reyes aquí van algunas sugerencias para todos los presupuestos:

Hasta 50 euros

Hasta 100 euros

Hasta 500 euros

Hasta 1.300 euros

Amazon Echo – Regalo perfecto

Justo el día que publiqué mi post sobre el  Apple HomePod  , mis compañeros de trabajo de TUI – a los cuales voy a echar mucho de menos – me regalaron un Amazon Echo. Entre bromas les prometí un artículo Alexa versus Siri y aquí viene mi artículo.

La relación calidad/precio del Amazon Echo (2a generación) es muy buena. Este altavoz inteligente se puede adquirir por 99,99 euros y la calidad del sonido y prestaciones impresionan para un equipo de tan reducido tamaño.

Además el equipo puede personalizarse y ajustarse a la decoración de nuestra casa con diversas fundas de distintos materiales.

También la ventaja es que el equipo puede utilizarse como altavoz Bluetooth, algo que el el HomePod de Apple no permite. Conecté sin problemas el Echo a mi MacBook Pro para reproducir música.

Si tengo que añadir algún pero es que la configuración del equipo y la de Alexa y sus “Skills” puede resultar un poco menos sencilla que la del Apple HomePod, pero nada extremadamente difícil: Por ejemplo para la configuración inicial hay que configurarse por WIFI a una red del propio Echo o la configuración de las skills, servicios de música, automatización de domótica con bombillas Philips HUE en la app de Alexa resulta un poco confusa.

Recomiendo este equipo a quien busque un altavoz con un sonido de calidad sin tener que gastar demasiado. Además es el equipo que se integra con mayor número de servicios de música en streaming como los propios de Amazon, Spotify y TuneIn. También estos días se tiene que activar el soporte para Apple Music, pero por el momento a mí todavía no se me ha activado.

Amazon Echo 2Amazon Echo 3

Amazon Echo 5