Técnicamente hablando, Now.sh e Hyper.sh no son un cambio de paradigma, sino solo la próxima evolución de Heroku.
Cuando define sin servidor no como AWS Lambda, sino que ejecuta código sin preocuparse por la infraestructura subyacente y no inicia sesión en un servidor o servidor virtual, uno de los principales pioneros de lo que encontró la tracción del consumidor fue heroku. Usted escribe su código y luego lo implementa sin necesidad de preocuparse por cómo se implementa ese código.
Esto se logró mediante el uso de contenedores que se ejecutan sobre los servidores virtuales de AWS.
- ¿Cuál es la importancia de la computación en la nube?
- ¿Cuáles son las limitaciones de Dropbox frente a otras plataformas de almacenamiento en la nube?
- ¿Quién está usando AWS Direct Connect para reducir los costos de transferencia de datos en AWS? ¿Cuáles son sus mejores prácticas y comentarios sobre el servicio?
- ¿Qué es el cscope en la computación en la nube?
- Quiero trabajar en computación en la nube. ¿Qué habilidades debo aprender?
Había limitaciones sobre qué pila podía ejecutar Heroku, por eso dotCloud se centró en un enfoque más independiente del lenguaje. Desafortunadamente, no pudieron competir con la penetración en el mercado de Heroku y, finalmente, Heroku le permitió ejecutar diferentes idiomas en su plataforma.
Cuando dotCloud estaba a punto de doblarse, lanzaron su capa de orquestación de contenedores que era Docker y que despegó, aunque los contenedores habían existido durante bastante tiempo.
Entonces, poder ejecutar su código en un contenedor localmente y enviarlo a la nube, es solo el siguiente paso más genérico de Heroku.
También tiene kubernetes que puede implementar para orquestar aplicaciones basadas en contenedores, etc.
A medida que las necesidades de ingeniería evolucionan, las tecnologías se crean naturalmente para resolver esos desafíos y, finalmente, terminan siendo de código abierto. Lo que le ofrece kubernetes es el desarrollo local de contenedores junto con la implementación a gran escala y se encarga de la capa de administración para crear más recursos, que es cómo Google también ejecuta sus bases de código.
Pero recuerde que a medida que agrega complejidad disminuye la cantidad de clientes que ejecutarán su software. Del mismo modo, a medida que alcanzas la escala, alcanzas la complejidad, por lo que, a menos que te sientas cómodo sin manos, se vuelve limitante. Entonces, lo que fue beneficioso al principio puede convertirse en un cuello de botella y viceversa.
Rara vez existe una solución verdaderamente única para todos.
Cuando eso ocurre es porque la “función” se trata de una unidad atómica lo suficientemente pequeña y la complejidad proviene de la escala. Pero si lo usa para una unidad o un millón no importa porque la unidad está completamente segmentada.
El mejor ejemplo de esto sería el almacenamiento de objetos, pero allí se trata de un contenido estático que es muy limitado porque no se puede transmitir desde y hacia él. Ciertamente, el almacenamiento de objetos en sí mismo fue un cambio de paradigma mucho mayor.
Sin embargo, los cambios en la forma en que realmente se desarrolla el software son complicados debido a la complejidad de escribir código, conectarse con bases de datos, colas de trabajadores, etc.
Por lo tanto, es una evolución interesante, pero no es un cambio de paradigma.
