Este es un gráfico recreado de una presentación que hice para un seminario web hace unos años. Se trata más de impulsores comerciales que de casos de uso específicos, pero debería ayudar a responder la pregunta de una manera que le brinde un marco para revisar sus propios casos de uso y si son adecuados para un modelo en la nube (ya sea público, privado o híbrido).
Comenzando en la parte inferior están los cambios organizacionales , donde las empresas adoptan metodologías más nuevas en torno al desarrollo y la administración de software. Muchos equipos de desarrollo están utilizando el desarrollo ágil internamente, incluso si la empresa aún exige un plan de proyecto de gran alcance con un proyecto “terminado” en una fecha de entrega. La intención detrás del desarrollo ágil es alejarse de esta idea de que todo se puede planificar por adelantado, ya que los requisitos cambian cuando alguien se da cuenta de que se pasó por alto una pieza crucial y ahora necesita ser revisada. Al entregar pequeños incrementos de producto en funcionamiento, los equipos de desarrollo pueden obtener comentarios de inmediato y reorganizar el trabajo en función de la validación de los clientes o partes interesadas. La computación en la nube puede ayudar a habilitar este tipo de metodologías al proporcionar computación de autoservicio (los desarrolladores pueden obtener una VM, implementar algún código, probarlo / demo y desaprovisionarlo en cuestión de horas o incluso minutos).
Mejor aún, con los modelos de administración de DevOps, los desarrolladores ya no “arrojan el código por encima” para que las operaciones se implementen / depuren / solucionen problemas cuando las cosas salen mal y comienzan a señalar con el dedo de un lado a otro (“¡bueno, funcionó en mi entorno! deben ser sus servidores “). Los desarrolladores resuelven sus propias implementaciones de lanzamiento y pueden deshacer el código rápidamente. Piense cuán eficientes pueden ser las actualizaciones cuando todo lo que necesita hacer es implementar un nuevo código en un nuevo conjunto de instancias de servidor, actualizar mediante programación el equilibrador de carga para que apunte a la nueva ubicación y simplemente “revertir” sus cambios volviendo a nombrar el equilibrador de carga volver a los servidores originales? Si la nueva implementación se realizó correctamente, desaprovisione los servidores antiguos. Enjabonar, enjuagar, repetir.
Todo esto lleva al siguiente cuadro, que es la eficiencia operativa . En los “viejos” días, su departamento de TI envía una solicitud de presupuesto para comprar un montón de servidores y los especifica lo suficientemente alto como para durar los tres años que estarán en los libros. Has sobreespecificado ese servidor web, que en su mayoría está inactivo, solo para manejar un posible crecimiento que realmente no has estimado bien. Y el cielo te prohíbe calcular mal y necesitas solicitar un servidor más nuevo y actualizado antes de que llegue el momento. Durante un tiempo, la “consolidación del servidor” fue el proyecto de TI para virtualizar todo y reducir este problema. Ahora tenemos la computación en la nube, que lo lleva un paso más allá y proporciona los mecanismos de autoservicio para implementar lo que necesita y solo lo que necesita. No importa, porque si necesita más recursos informáticos, solo debe aprovisionarlos, ya sea que los necesite durante un año o solo unos minutos. Esto proporciona una elasticidad y escalabilidad rápidas a pedido, no más esperas para la aprobación del presupuesto y no más aprovisionamiento excesivo para los peores escenarios.
Esto fluye muy bien en el tercer cuadro en torno a la gestión de costos . Tenga en cuenta que no dije ahorro de costos. Muchas empresas intentan elevar sus aplicaciones a la nube mediante el aprovisionamiento excesivo de algunas máquinas virtuales, desplegar su aplicación en ellas y quedarse satisfechos hasta quedar satisfechos con grandes facturas OPEX. Las startups que crean aplicaciones nativas en la nube supervisan todo, cuántas consultas a la base de datos, cuántos accesos al disco, etc., porque esto a menudo se mide. Pueden sintonizar, no solo por el rendimiento, sino también por el costo. Las aplicaciones empresariales nunca requirieron este nivel de granularidad. Simplemente configuran una base de datos y dejan que las aplicaciones la golpeen, agregando más recursos para acomodar un poco de crecimiento cuando las cosas se ralentizan (vea las eficiencias operativas más arriba). La idea de medir el crecimiento incremental en pequeñas unidades de tiempo nunca se consideró fuera de unas pocas aplicaciones especializadas. Simplemente le arrojan más hardware hasta que deja de romperse por un tiempo (estoy simplificando demasiado, por supuesto, pero entiendes la idea). Con la facturación basada en recursos, se pueden establecer verdaderos mecanismos de contracargo / devolución y los equipos de aplicación pueden ajustar sus aplicaciones en consecuencia.
En realidad, hay mucho más en esto, pero puede tomar cualquier caso de uso y ver si encaja en uno o más de estos cuadros. Si es así, entonces podría ser un buen candidato para la computación en la nube.
