Todos los componentes de la arqutectura son diseñados para ser usados como servicios
A partir de esta aproximación, podemos definir una aplicación como un conjunto de servicios interoperables
- Es mas sencillo formar a los usuarios de los servicios cuando hay una nueva versión
- Mas sencillo recuperarse de errores cometidos en el diseño, ya que los cambios importantes no se "ven" desde fuera, ya que la capa de servicio puede mantener la comptibilidad hacia atrás
Esto contrasta con los "silos" software que conforman los APIs internos (In-process)
Un ejemplo real y que toda la comunidad del software conoce es el de Amazon
Su CEO estableció las siguientes premisas a los equipos de desarrollo de la compañía : (traducción literal del email que envío el CEO a todos sus empleados de las divisiones de software)
1. " Todos los equipos a partir de ahora deben exponer sus datos y la funcionalidad a través de interfaces de servicio.
2.Los equipos deben comunicarse entre sí a través de estas interfaces.
3.No habrá otra forma de comunicación entre procesos: no debe haber vinculación directa, ni lecturas directas del almacenamiento de datos de otro equipo (ejemplo, aplicación de backend leyendo de base de datos de front-end, por ejemplo) , no hay un modelo de memoria compartida, no hay puertas traseras de ningún tipo. La comunicación sólo se permite es a través de las llamadas de interfaz de servicio en la red.
4.No importa que tecnología (protocolo del API) se utilice. (SOAP, REST..)
5. Los interfaces del servicio , sin excepción, deben ser diseñados desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores en el mundo exterior. No hay excepciones.
6. Cualquiera que no haga esto será despedido.
7.Gracias, ! y que tengas un buen día "!
¿ Consecuencias de esto? Amazon tiene uno de los sistemas mas abiertos de los existentes, donde se potencia la reusabilidad de las funcionalidades, aumentando la productividad de sus equipos.
