Imaginemos, por ejemplo, como sería la vida sin estándares de enchufes?, sin un enchufe que se adapte o detalles estándares (a menudo llamados especificaciones), como podríamos conectar aparatos en las paredes de los edificios. Esto implicaría reunir las herramientas necesarias, desembainar todos los cables y empalmar los cables juntos. Por supuesto, también tendríamos que saber algo sobre los cables que salen de la pared. Mover un aparato de un lugar a otro sería una gran tarea en la desconexión y la reconexión.
Afortunadamente, no tenemos que hacer nada de esto. Tenemos enchufes y adaptadores de enchufes que se ajustan a un estándar, que ofrece las siguientes «comodidades»:
- A través de la interfaz estándar, cualquier consumidor compatible (en este caso, un dispositivo) puede externalizar fácilmente sus requisitos eléctricos al servicio y el dispositivo puede esperar obtener los mismos resultados. Sabiendo que la electricidad puede ser subcontratada a través de una interfaz estándar previsiblemente disponible, los fabricantes de dispositivos pueden centrarse en fabricar grandes dispositivos y no en averiguar cómo esos dispositivos van a obtener su energía (aparte de soportar la interfaz estándar).
- Los dispositivos de consumo se mueven fácilmente de un enchufe a otro. Gracias a una interfaz estándar, mover un secador de pelo de una casa en Buenos Aires a un hotel en Honduras no es diferente de moverlo de su dormitorio a su cocina. E incluso si el patrón de la interfaz estándar cambia -como sucede cuando se viaja desde Norteamérica hacia el Reino Unido-, los dispositivos de consumo pueden adaptarse fácilmente.
- La interfaz de socket eléctrico es una capa de abstracción (oculta las especificaciones) al servicio subyacente. El consumidor (de nuevo, no una persona, sino un dispositivo) es ciego a cosas como el color del cableado en las paredes, otros dispositivos con los que se comparte el cableado, cómo se genera la electricidad (ya sea de un parque eólico, nuclear planta, generador de carbón o matriz solar) o donde se encuentran esas fuentes de energía. Para cualquier motivación (como ahorro de costes, política o presión pública), siempre y cuando el servicio proporcione 120 voltios de corriente alterna de 60Hz a la toma de pared de una manera que se ajuste a la norma, el proveedor de servicios es libre de cambiar cualquier cosa desde justo detrás del enchufe todo el camino a la fuente de energía. Estos cambios son transparentes para los dispositivos que consumen.
- La misma transparencia funciona en ambos sentidos. Para el servicio, todos los consumidores tienen el mismo aspecto. Es esencialmente ciego a las especificaciones del dispositivo de consumo que está en el otro lado de la toma eléctrica.
A medida que avanzan las interfaces, las API y los beneficios que proporcionan a sus consumidores (como aplicaciones de escritorio, Web, móviles y del lado del servidor) no son muy diferentes de los enchufes eléctricos y los beneficios que proporcionan a sus consumidores (como ordenadores y electrodomésticos) .
Por ejemplo, de la misma manera que un dispositivo consumidor puede externalizar su electricidad a un servicio a través de una interfaz de toma de pared, una aplicación consumidora puede externalizar sus requisitos de datos (como un registro de pacientes) o funcionalidad (como una ubicación representada como pin en un mapa interactivo) a un servicio a través de una interfaz de programación de aplicaciones. Aunque la aplicación y el servicio que consumen (conocidos como proveedores de API) están suficientemente desacoplados hasta el punto de que saben poco o nada acerca del otro, la interfaz a través de la cual se comunican representa un conjunto de estándares acordados (similar a los 120v / 60Hz AC estándar para la electricidad) que permite a las aplicaciones hacer solicitudes del servicio y obtener datos y / o funcionalidad a cambio.
Y, de manera similar a la forma en que los dispositivos consumidores externalizan sus necesidades de energía a los proveedores de servicios a través de una red eléctrica, las aplicaciones pueden externalizar sus requisitos de datos y funcionalidad a los proveedores de servicios que están a través de redes digitales, como Internet (o incluso a través de un local en un negocio). Por ejemplo, una aplicación móvil para compradores de vivienda puede incorporar mapas interactivos y navegación en su experiencia de usuario al subcontratar esa funcionalidad a Google Maps. Cada vez que la aplicación móvil muestra un nuevo mapa interactivo, lo hace enviando una solicitud a través de Internet a una API especial que ofrece Google para ese propósito.
Así, como con la electricidad, las API pueden ser consumidas (en la medida en que una aplicación subestima ciertos requisitos a una API) y se proporciona como un servicio.
Además de llamar a APIs de una red, los desarrolladores de aplicaciones pueden aprovechar las API que ofrece el sistema o dispositivo local en el que se ejecuta su aplicación. Por ejemplo, las aplicaciones pueden descubrir la ubicación actual de un smartphone llamando a la API asociada con el receptor GPS del teléfono.
También hay una clase emergente de APIs ofrecidas por los modernos navegadores web, como Chrome y Firefox, que son como los mencionados enchufes eléctricos estándar – a través de todo tipo de sistemas (desktops, tablets, smartphones, etc.), estos navegadores ofrecen una forma estándar para que las aplicaciones basadas en navegador accedan al almacenamiento del dispositivo host, al sistema de audio, a las cámaras y mucho más. A través de una red, la fuente de datos o la funcionalidad que se llama a través de una API podría ser un servidor de aplicaciones (un servidor de base de datos, por ejemplo), un servicio de traducción o incluso un refrigerador habilitado para la red.
Tu responsabilidad como CIO, COO, o Responsable máximo de desarrollo es responder con tiempos de mercados acelerados, monetizar y externalizar servicios de la manera mas eficiente, rápida y segura.
Sin lugar a dudas, creo que la comunidad está tomando confianza y convicción en la necesidad de comenzar a implementar APIs como herramienta de desarrollo
No dudes en cominicarte conmigo para lograr definir una estrategia y arquitectura eficiente de microservicios.
Lic. Diego San Esteban
CRISC, Scrum Master, Devops Certified
Humanizing Banking 