Cloud Agnostic Architecture?

Question

Estoy haciendo algunos trabajos de arquitectura en una nueva solución que inicialmente se ejecutará en Windows Azure. Sin embargo, me gustaría que la solución (o al menos la arquitectura/diseño) sea Cloud Agnostic (en cualquier medida sea realista). ¿Alguien ha hecho algún trabajo en este frente o ha visto buenos libros blancos/publicaciones de blog?

Nuestra arquitectura de alto nivel consistirá en una carga útil que se enviará a un servicio web (WCF por ejemplo), esta será abandonada en una cola (por razones de argumentos) y un proceso de trabajo tomará mensajes de esta cola y los procesará. Habrá una base de datos de información del cliente que idealmente desearíamos mantener fuera de la nube, sin embargo, existen consideraciones de rendimiento obvias.

Deseoso de escuchar los pensamientos de los demás.

Saludos de Dave

Answer 1

Después de publicar originalmente esta pregunta hace 2,5 años, hemos avanzado en nuestra solución. Hace poco escribí una publicación sobre Evitar el bloqueo en la nube que habla sobre cómo definir una arquitectura independiente de la nube. http://www.cloudycover.com/post/26549365156/avoiding-cloud-lock-in

La empresa en cuestión es un proveedor de la plataforma HPC basado en la nube que ofrece la descarga sin problemas de cargas de trabajo de cálculo intensivo a la nube en la que sólo tiene que pagar por milisegundos de tiempo de cálculo que se consumen: http://www.greenbutton.com

Answer 2

yo diría que este es un partido bastante bueno para Java Enterprise Edition. Si bien esto significa que se encontrará con Java, al menos tendrá varias soluciones comerciales disponibles para la mayoría de los servicios que describe.

Answer 3

Supongo que por agnóstico en la nube quiere decir agnóstico a la plataforma particular en la que se está ejecutando, como GAE, Amazon EC2 o Azure y desea escribir una, implementar en cualquier lugar.

En teoría, eso debería ser posible si todos los proveedores de la nube admiten los mismos idiomas. Por lo que sé, GAE admite Python y Java. Amazon EC2 puede usar prácticamente cualquier cosa en el servidor real y Azure es una plataforma totalmente .net. Entonces, el lado del procesamiento real de las cosas, es decir, escribir el servicio web de la cola y las unidades de procesamiento, puede ser difícil.

Otra barrera es que no hay una API común unificada para llamar a servicios de computación en la nube. Las implementaciones son diferentes en GAE/Azure/EC2 de todos modos, por lo que los métodos que expone su API son todos diferentes y para ese fin, su código de primera línea necesitará saber qué tipo de API está llamando para controlar los recursos de computación en la nube.

Sin embargo, por naturaleza, los servicios web están débilmente acoplados. Significado siempre que haga un esfuerzo para abstraer el control de recursos para poder crear una instancia en la nube que desee, si esa nueva instancia es otra unidad que maneja la entrada/computación de un servicio web y el servicio web expuesto es el mismo en GAE como EC2, por ejemplo, no hay nada que detenga a los dos hablando. Del mismo modo, siempre que utilice algún tipo de servicio web/protocolo entre instancias, aún debería poder hablar con otras instancias a través de Internet a través de plataformas informáticas. Dicho esto, al hacerlo, exponer los datos de su aplicación interna al mundo en general y, por lo tanto, presentar un riesgo de seguridad.

Estoy de acuerdo con el rechazo: Java es una muy buena forma de hacerlo. Hay una gran cantidad de contenedores EJB e incluso más servidores de servicios web como Tomcat. Supongo que EC2 lo soporta (bueno, definitivamente lo hace, pero si ejecutan Tomcat/Geromino en lugar de las ediciones de IBM y cómo son los cargos, no lo sé). GAE suena limited based on this blog post: sea lo que sea lo que Google esté haciendo en el back-end, han diseñado algo muy extraño.

Answer 4

SOA es una forma perfecta de abstraer la implementación de un subsistema. Siempre que las responsabilidades del servicio estén claramente definidas y se priorice la interoperabilidad, teóricamente sería posible cambiar una implementación alternativa basada en la nube más adelante. EC2 es compatible con Windows, por lo que la implementación de Azure sería altamente reutilizable. Sin embargo, App Engine está basado en Java/python, lo que significa que todo lo que se puede reutilizar son sus contratos de mensajería y RPC. Por lo tanto, una implementación de WCF debe ser schema-first contract-first.

En lo que a rendimiento se refiere, mi enfoque estándar es

1. trabajo con los clientes de negocios para definir un rendimiento aceptable,
2. implementar un prototipo de lo que creemos que es el aspecto más rendimiento crítico (s) del sistema, y ​​
3. miden el rendimiento.

Si el rendimiento es inaceptable, se convierte en una decisión comercial determinar el mayor riesgo: no ser capaz de cambiar a otro proveedor de la nube o enfrentar posibles problemas de rendimiento. Sin embargo, tendría cuidado de mantener los estándares de rendimiento realistas. Para las empresas nuevas, hacer hincapié en el rendimiento extremo en anticipación al crecimiento es una pérdida de esfuerzo. OMI, ese esfuerzo generaría mayores recompensas si se dirige hacia la diferenciación de características, el marketing, los comentarios de los usuarios, etc. Optimice solo cuando sea necesario, y solo con un plan.

Por cierto, también recomendaría buscar en protocol buffers como formato de mensajería, para un mayor rendimiento con bajo riesgo de proyecto.

Answer 5

Somos en su mayoría una tienda de MS en esta etapa o al menos esa es la dirección que estamos buscando tomar (razones comerciales convincentes para una puesta en marcha) pero queremos evitar cualquier lock-in. Un enfoque que estoy viendo es tener un marco de middleware que resuma los detalles de la nube. El middleware comprendería dos capas principales, la capa inferior sería un adaptador de nube para abstraer los matices y API de la nube específica. La capa superior proporcionaría servicios de marco general.

El middleware sería responsable de:

• usuario, credenciales, etc: se proporcionará toda la información del usuario, perfiles, etc.
y autorización
• de seguridad: se proporcionará toda implementaciones de seguridad e imponer ninguna restricción.
• Proveedor de nube específico: gestión de instancias y almacenamiento. Medición del uso y el costo del uso de la nube.
• Servicios de instancia: servicios de nivel inferior en una instancia, p. CPU, memoria, almacenamiento local. Proporcione la implementación de procesamiento paralelo. Creación de puntos finales/puertos, etc.
• Reclute el acceso al almacenamiento en la nube (por ejemplo, tablas, colas, manchas en azul).
• Configuración de servicios de aplicaciones.
• Despliegue: Cualquier información específica necesaria para la implementación en una nube: intentará automatizar la implementación específica de la nube.
• Registro: debe ser un marco integral de registro que permita la medición del rendimiento en la nube.

Comentarios bienvenidos.