No diría que ninguno de los dos es mejor, tienen implicaciones diferentes en el negocio y en la aplicación misma.
Al usar un proveedor de nube pública, un equipo de aplicaciones puede implementar la aplicación en la infraestructura que necesitan y nada más. Pueden aprovisionar recursos adicionales a corto plazo para satisfacer la demanda de tráfico temporal o agregar recursos gradualmente a medida que la demanda de la aplicación aumenta con el uso.
Esta flexibilidad y control de costos es exactamente lo que anhelan las nuevas empresas de software: la capacidad de nunca sobreaprovisionar y malgastar dinero.
- ¿Debo usar Parse para crear perfiles de usuario y AWS para el almacenamiento?
- ¿Es la computación paralela algo importante hoy en día en comparación con la computación distribuida?
- ¿Cuáles son algunos ejemplos de cargas de trabajo con requisitos de seguridad muy altos que se ejecutan en AWS?
- ¿Las instancias EC2 permanecen en el mismo hardware durante toda su vida?
- ¿Cuál de las academias Linux y Cloud Academy es mejor para la certificación AWS?
Comprar infraestructura para una nube privada es una cuestión diferente. Históricamente, cuando compra un único servidor, su CFO aprueba una orden de compra. Ese dinero se paga por adelantado a un proveedor, y el CFO lo deprecia en sus libros durante ~ 36 meses. Usted sabe que debe conservarlo durante 3 años, por lo que compra el servidor más robusto del que puede salirse con la suya para que la aplicación esté subutilizando este servidor para “crecer” según sea necesario. Significado: ha gastado dinero en algo que realmente no necesita en este momento. Y si calculó mal la demanda, es posible que necesite recursos informáticos adicionales que no planeó (y necesita obtener otra aprobación, ordenar / aprovisionar el servidor e implementar su aplicación, ¡un proceso que consume mucho tiempo!).
La moda de consolidación de servidores en TI a mediados de la década de 2000 utilizó la virtualización para superar algunos de estos problemas de recursos y aprovisionamiento. Permitió a las organizaciones gestionar mejor los recursos informáticos (agrupación de recursos), pero aún carecía del rápido aprovisionamiento y autoservicio que proporcionan las nubes públicas.
Hoy, eso se ha convertido en nubes privadas, que proporcionan la misma experiencia de nube pública: autoservicio a pedido, elasticidad rápida, agrupación de recursos, acceso amplio y servicio medido. Al desarrollar un servicio como este, la organización puede admitir una amplia gama de equipos de aplicaciones que con frecuencia pueden consumir los recursos según sea necesario. Aún mejor, los costos se pueden controlar, ya que los desarrolladores / operaciones ya no necesitan sobreespecificar el hardware para satisfacer una necesidad teórica teórica … solo producen un prototipo v1, prueban y cambian según sea necesario.
Ahora, dicho esto, si la organización para la que está desarrollando una aplicación tiene los recursos y la infraestructura para proporcionarle servicios desde una nube privada (incluso mejor si proporcionan pautas reales sobre cuándo usar nubes públicas o privadas para una aplicación), entonces, por supuesto, úsalo!
Pero si usted es un desarrollador de inicio o autofinanciado (o un desarrollador en una organización que no puede obtener la aprobación del presupuesto CAPEX), no tiene sentido atar su dinero en hardware que podría gastarse mejor en desarrolladores para construir un producto. Vaya con la opción de nube pública y desarrolle su propia infraestructura más adelante cuando tenga sentido financiero hacerlo.