¿Cuál es el cuello de botella actual del desarrollo de la computación en la nube?

Permítame responder esto de manera diferente desde la perspectiva del hardware al que alude, ya que esas preocupaciones las maneja principalmente el proveedor de computación en la nube que elija. Después de todo, eso es lo que significan los recursos a pedido (en cualquier cantidad). Por supuesto, el ancho de banda de red desde su instalación local hasta el proveedor de la nube podría ser un problema, pero si se encuentra en un área geográfica con un buen soporte de banda ancha, no será un factor limitante. Entonces, dejando de lado los cuellos de botella de recursos tradicionales (que es la razón principal para pasar a la computación en la nube), examinemos algunos de los cuellos de botella de la administración y los negocios para la adopción de la nube …

A medida que la computación en la nube “cruza el abismo” desde la adopción temprana hasta la aceptación general, el papel de la estandarización se vuelve más importante.

En este momento, todavía tenemos una competencia agresiva en el espacio, por lo que no hay incentivos para estandarizar. A medida que las “reglas del camino” se solidifiquen y, en general, conozcamos las mejores formas de utilizar los recursos informáticos (dominando cosas como la elasticidad bajo demanda, la informática sin servidor, la contenedorización y el análisis emergente), entonces estaremos listos para estandarizar esos escenarios y estandarizar las API para acceder a la nube sin el bloqueo del proveedor.

Entonces, en este momento, el cuello de botella es cómo migrar con éxito sus aplicaciones existentes a la nube, cualquier nube. Nota: el cuello de botella clave para la migración sigue siendo la confianza y la seguridad. Dentro de 3 a 5 años, el cuello de botella será la falta de estandarización de las API en la nube y, a largo plazo, habrá varios tipos de desafíos de integración, como la integración de la robótica con la nube y la integración de IoT con la nube.

¡Los mejores deseos!

A nivel de instancia, hay algunas limitaciones:

1. Disk I / O y Bandwidth a menudo comparten la misma cuota. Eche un vistazo a este enlace para ver lo que AWS llama límite de rendimiento de EBS. Instancias optimizadas de Amazon EBS. Tenga en cuenta que EBS es el dispositivo de almacenamiento más utilizado, aplicable a la mayoría de los casos de uso. Las máquinas de clase C y M son las instancias más utilizadas en los tipos de instancias de AWS. Puede obtener fácilmente mejores resultados de servidores independientes que lo que AWS puede proporcionarle por instancia.
2. El ancho de banda podría ser un problema limitante cuando varios servidores necesitan intercambiar gran cantidad de datos rápidamente. AWS tiene un concepto llamado grupos de colocación. Es equivalente a colocar todos sus servidores en un solo rack para reducir la latencia y aumentar el ancho de banda entre servidores. Pero es imperfecto.

A nivel del sistema, la nube tiene muy pocas limitaciones. La mayoría de los problemas informáticos pueden resolverse mediante la paralelización y arrojando más recursos informáticos al problema. Incluso los problemas de nivel de 2 instancias que cité antes no son un problema cuando usa un clúster para resolver un problema en lugar de usar una sola instancia.

Lo que solía ser una aplicación de instancia única, como la base de datos y la informática de alto rendimiento, se está moviendo hacia una implementación distribuida. El rendimiento del sistema es la suma de todas las partes. En este caso, el rendimiento a nivel de instancia importa menos; y la capacidad de obtener muchas instancias rápidamente se vuelve mucho más importante. La capacidad de escalar rápidamente los recursos es donde la nube tiene éxito.