Arquitectura global del sistema e implicaciones de la integración

5.5 Arquitectura global del sistema e implicaciones de la integración

  Como resultados de las secciones anteriores, ya disponemos de un posicionamiento claro dentro de Cloud Computing, de una definición clara de lo que va a ser nuestro modelo de negocio y de una fuerte infraestructura que nos proporcionará elasticidad y escalabilidad a nuestro sistema. Pero se han detectado algunos obstáculos en la integración del sistema con la IaaS y con el MarketPlace.

  Obstáculos con la integración del MarketPlace

  Como se ha comentado en los primeros capítulos, los proveedores de servicios basados en Cloud Computing, bien sea, SaaS, PaaS, IaaS, necesitan estandarizar su oferta y sus interfaces, de lo contrario no podrían responder a la demanda del servicio con las bondades que ofrece la nube. Por ello debemos asumir que cualquier ISV que quiera integrarse con un

  72 José Manuel Arévalo Navarro MarketPlace debe hacer un desarrollo adicional que consiste en implementar su contrato de

  integración (WSDL). Gracias a nuestro diseño de partida SOA y posterior modularización del sistema este impacto es menor de lo que podría ser con un sistema tradicional. Esta implementación se requiere para poder transmitir nuestro modelo de negocio al Marketplace, debemos tener en cuenta que cada ISV tendrá su propio modelo de negocio. Por ello el MarketPlace solicita a través de una interfaz única y estandarizada el modelo de negocio concreto de cada aplicación en el momento que el usuario desee comprarla.

  El último obstáculo encontrado en esta parte del proceso de integración es la de proporcionar las interfaces de autenticación, debemos tener en cuenta que cuando un usuario quiera comprar la aplicación y usarla, el Marketplace debe autenticar al usuario contra nuestro sistema. Pero este obstáculo no ha sido tal, ya que partíamos de un sistema basado en SOA, con interfaces claramente definidas, tan solo es necesario proporcionar los endpoints al equipo de desarrollo del MarketPlace, por otro lado si fuera necesario podemos proporcionar más interfaces como Billing y CRM, por lo comentado anteriormente.

  Obstáculos con la integración la IaaS

  El principal problema encontrado en la integración de la IaaS es el de adaptación a sus interfaces, esto se ve muy claro con la migración de las imágenes desde la base de datos al servicio de almacenamiento S3. Ahora debemos acceder a ellas mediante servicios REST y ello

  ha causado impacto en el Front-End ya que la interfaz de comunicación es totalmente diferente.

  Este hecho es bastante sintomático de lo que es Cloud Computing, ya que si hubiera sido la IaaS la que se hubiera tenido que adaptar a nosotros, no estaríamos realmente ante un servicio en la nube, no sé si estaríamos ante algo mejor o peor, pero no sería Cloud Computing. Debemos tener en cuenta que en este caso Amazon Web Services tiene todo un reto por delante debido al tipo de servicio que ofrece y esto no sería posible si no estandariza su oferta e interfaces tal y como pasaba con el MarketPlace. A continuación se muestra la arquitectura global del sistema.

  Cloud Computing: Fundamentos, diseño y arquitectura aplicados a un caso de estudio

  Ilustración 18 Arquitectura final integración Marketplace

  Por último se ha realizado un análisis comparativo de los costes de toda la solución llevada a cabo, tanto la adopción de un modelo SaaS como la integración con una IaaS, frente a los costes que supondría no haber escogido Cloud Computing y haber optado por una solución dedicada in-house.

  Tabla 8 Análisis de costes Cloud Computing frente solución in-house

  74 José Manuel Arévalo Navarro

  De esta tabla se pueden sacar varias conclusiones. La primera está claramente que se puede observar el alto coste inicial de los recursos hardware en mi infraestructura interna frente a los costes planos de una IaaS y un coste mensual de ese gasto energético que provocan mis instalaciones. Sin embargo los riesgos serán mucho menores, debido a esa alta inversión en firewalls y seguridad que no proporciona una IaaS pública.

  La segunda gran conclusión de esta tabla, es el alto coste que ha ocasionado migrar nuestro modelo de negocio a SaaS, ya que ahora debemos afrontar soporte y mantenimiento, ya que estamos ofreciendo un servicio. Sin embargo en un modelo de software tradicional esto no tiene por qué ser así. Cabe destacar comparando inversiones, se tardaría unos ochos años en llegar al gasto que tiene una solución interna, sin embargo esta, estaría diseñada y pensada totalmente por el cliente, no como en la IaaS en la que el usuario más que diseñar su solución, escoge entre lo que le ofrecen.

  Cloud Computing: Fundamentos, diseño y arquitectura aplicados a un caso de estudio

  Capítulo 6:

  Conclusiones y trabajos futuros