Los desarrolladores están cuestionando el futuro de la plataforma como servicio (PaaS), y por una buena razón. Muchos de ellos han creado productos exitosos en PaaS, pero cuando su aplicación alcanza cierta escala, se encuentran con la necesidad de más. No pueden depurar fácilmente los problemas de rendimiento debido a la falta de transparencia y las características de caja negra obstinadas. No pueden implementar controles de cumplimiento y seguridad totalmente configurables como un firewall de aplicaciones web. Están atrapados con los complementos limitados que ofrece la plataforma, si es que se ofrecen. Las características como el almacenamiento persistente, el equilibrio de carga configurable y el escalado automático no existen o son demasiado limitados para el uso real en PaaS.
Entonces, ¿qué hacen los desarrolladores? Portan sus aplicaciones a la infraestructura como servicio (IaaS).
No es que IaaS sea mejor, sino que no tiene límites de implementación. Los desarrolladores pueden crear lo que quieran con los proveedores de IaaS. La compensación es de tiempo, experiencia y personal adicional. Pero eso está bien para la mayoría de los desarrolladores con aplicaciones PaaS exitosas porque ya han superado la parte difícil de crear algo y encontrar el producto adecuado para el mercado. No están tan preocupados por la curva de aprendizaje de migrar a IaaS porque, en ese momento, tienen una base de usuarios, ingresos y una pista.
Es probable que los desarrolladores no transfieran sus aplicaciones a IaaS si PaaS fuera una opción viable a escala. Pero, ¿eso significa que PaaS debe descartarse como inferior a IaaS? Difícilmente. El futuro de PaaS es brillante, mucho más brillante de lo que reconocen muchos desarrolladores. De hecho, creo que PaaS dominará el futuro del desarrollo de software. El mercado está ansioso por que surja una plataforma "excelente para comenzar, excelente para escalar" y supere la experiencia y el valor de los desarrolladores de hoy. PaaS admitirá absolutamente la entrega de aplicaciones escalables a nivel mundial, pero primero tendrá que superar algunos desafíos.
La belleza de IaaS es que ofrece opciones de configuración y escalabilidad casi infinitas. Los proveedores de IaaS han generalizado sus productos lo suficiente como para admitir prácticamente cualquier caso de uso a cualquier escala. Es increíblemente potente y rentable. Además, los proveedores de IaaS están felices de otorgar créditos de uso y precios con descuento para impulsar la adopción y enganchar a los equipos.
Sin embargo, puede ser increíblemente difícil construir configuraciones escalables sin pegarse un tiro en el pie. Los cambios de configuración incorrectos pueden tener resultados catastróficos que son casi imposibles de solucionar y remediar sin una gran experiencia en infraestructura. Prácticamente no hay soporte de plataforma disponible (fuera de los compromisos empresariales costosos) y la documentación de IaaS es notoriamente inconsistente y difícil de leer. Y ni siquiera me hagas comenzar con la experiencia real del usuario de las consolas IaaS.
Apostar por IaaS significa crear costosos equipos de infraestructura para usar y administrar IaaS. Los expertos en infraestructura no solo son algunas de las personas más solicitadas en la industria, sino que es extremadamente difícil encontrar a las personas adecuadas que sepan cómo superar las necesidades de crecimiento únicas. A estas complicaciones se suman las realidades de un entorno de recaudación de fondos más estricto, se les dice a los equipos que "hagan más con menos" y la complejidad cada vez mayor de las soluciones IaaS. El trabajo del equipo es configurar y mantener la infraestructura a medida que crece, y el trabajo nunca está "terminado".
Entre los problemas de financiación y la falta de talento de infraestructura disponible, es difícil recomendar profundizar la inversión en infraestructura y trabajo de plataforma. Las características y capacidades de IaaS son cada vez más complejas, lo que justifica aún más la necesidad de abstracciones de mayor nivel, como las que proporciona PaaS.
Los proveedores de IaaS lo saben, por lo que están invirtiendo en abstracciones similares a PaaS. Google está haciendo un buen trabajo con su plataforma en la nube y Firebase , su plataforma de desarrollo móvil. Amazon ha estado tratando de crear abstracciones, pero su experiencia como desarrollador no es buena. Sin embargo, está claro que entienden que los desarrolladores quieren (y merecen) mejores experiencias, como el cifrado automático de objetos S3 y la integración de RDS con AWS Secrets Manager . Azure ahora ofrece App Service , que permite una implementación simplificada en una infraestructura de escalado automático.
Los principales proveedores de la nube están mejorando en las ofertas similares a PaaS, pero también se centran en las estrategias heredadas de "lift-and-shift" o en las fantasías de "Kubernetes sin servidor" de ciencia ficción. Obtienen la mayor parte de su efectivo de las empresas, lo que sesga su desarrollo de características para servir a más empresas. Las nuevas empresas y las medianas empresas cruzan los dedos con la esperanza de que sus comentarios conduzcan a entornos similares a PaaS más fáciles de usar y de construir que no requieran experiencia avanzada en infraestructura para utilizarlos por completo.
Raman Sharma observó astutamente que "al menos dos importantes proveedores de nube de hiperescala (Azure y GCP) comenzaron su viaje en la nube con productos PaaS, solo para darse cuenta rápidamente de que el dinero real (y montones y montones de músculo y memoria institucional) todavía estaba en la infraestructura . Por lo tanto, giraron para centrarse en IaaS (como AWS en ese momento)”.
En otras palabras, IaaS estaría haciendo PaaS si IaaS no fuera tan lucrativo. No están sirviendo a nuevas empresas, están sirviendo a empresas.
Construir en IaaS ofrece mucha libertad y oportunidades, pero ¿preferiría gastar $150 000 en un administrador certificado por AWS o $150 000 en un desarrollador que puede crear funciones que generan ingresos?
Si no tiene que preocuparse por la infraestructura, contratar al desarrollador es una obviedad. Desafortunadamente, no es raro que las empresas obtengan lo peor de ambos mundos: contratan al desarrollador de $ 150K y lo obligan a hacer también todo el trabajo de DevOps. Eso es mucho menos por el dinero.
Realmente no existe una ventaja competitiva para los equipos de productos que pasan de PaaS a IaaS, ni para aquellos que comienzan con IaaS y escalan. En algún momento, inevitablemente requerirá la contratación de un arquitecto de infraestructura de nube costoso y experimentado. Por supuesto, no tengo nada en contra de los ingenieros expertos en infraestructura de la nube, pero cuando me enfrento a una presión financiera cada vez mayor para "hacer más con menos", no estoy muy entusiasmado con aumentar mis gastos generales.
Además, incluso si tuviera el equipo de infraestructura de nube más grande del mundo e incluso si no fuera tan costoso como temo hipotéticamente, ¿cuál es la ventaja competitiva de tener ese equipo? ¿Qué ventaja ofrece eso realmente a cualquier negocio? Si soy honesto, prefiero tener un equipo reducido de desarrolladores que generen valor que administradores que protejan el valor. Sí, puedo dedicar tiempo y energía a IaaS para obtener discos persistentes, recuperación puntual en mis bases de datos, equilibrio de carga configurable, lógica de implementación azul/verde y escalado automático, pero garantizo que la mayoría de los desarrolladores preferirían tener todo que está disponible con una casilla de verificación en una interfaz de usuario bien diseñada.
Cuanto más tiempo tengo para concentrarme en mantener las luces encendidas, menos tiempo dedico a ofrecer excelentes funciones a los clientes que quieren gastar dinero en mis productos. Más infraestructura, menos valor.
La razón principal por la que PaaS existe en primer lugar es porque IaaS es demasiado complicado. Los desarrolladores quieren escribir e implementar código. Quieren crear nuevas aplicaciones y funciones, ver cómo responde el mercado e iterar. Y quieren hacer esto con la menor cantidad de obstáculos posibles.
Por ejemplo, si necesito una infraestructura compatible con HIPAA para crear un SaaS centrado en el cuidado de la salud, puedo comenzar con la arquitectura de referencia de Amazon , que es incompleta y compleja, y pasar semanas poniéndola en funcionamiento. O bien, puedo activar una aplicación en Aptible en minutos y saber que cumple con HIPAA.
Lo mismo ocurre con el cumplimiento de PCI. Stack Overflow y Reddit están llenos de ejemplos y advertencias de la batalla cuesta arriba para establecer y mantener una infraestructura compatible con PCI en cualquiera de las grandes nubes de IaaS. O bien, puede encontrar un PaaS compatible con PCI y no dedicar tiempo a la configuración del firewall.
Aquí está la cosa: nadie está eligiendo comenzar con una arquitectura e implementación de infraestructura compleja. Simplemente no tienen muchas opciones o no conocen las opciones existentes. Cualquier desarrollador o líder de producto elegiría PaaS si fuera rentable y capaz de satisfacer las necesidades de escalamiento a largo plazo. PaaS no tiene un problema de rentabilidad, sino de quedar en la esquina con su capacidad a largo plazo para respaldar negocios en crecimiento. Si ese no fuera el caso, PaaS sería una obviedad para iniciar y escalar aplicaciones.
Esto plantea la pregunta: ¿quién no pagaría una cantidad sostenible de dinero extra para que todo “simplemente funcione”, excelente documentación y soporte integrado?
IaaS ha hecho un gran trabajo al ofrecer una solución generalizada que funciona en cualquier caso de uso. PaaS aún no ha llegado allí. Hay demasiadas funciones pequeñas que faltan y ofuscaciones que hacen que los equipos abandonen PaaS. No existe una PaaS única que pueda admitir todas las aplicaciones que una empresa necesita para ejecutar, y ese es un problema no trivial.
Además, los patrones de desarrollo de aplicaciones también han evolucionado desde que PaaS comenzó a florecer en 2010. Heroku y los de su clase simplemente no se han mantenido al día. Estos son algunos de los "trabajos por realizar" comunes del equipo de ingeniería que son esenciales para el negocio, pero que PaaS no cubre:
Las necesidades son claramente diversas. El mundo de PaaS ha hecho un gran trabajo con plataformas especializadas que claramente se posicionan como las mejores en su clase en una sola tarea, pero el mundo necesita una PaaS que pueda admitir una colección de funciones que habilitan el negocio.
Las aplicaciones PaaS tienden a ser monolíticas para aprovechar las diversas capacidades de la plataforma de infraestructura subyacente. Sin embargo, es probable que los productos en crecimiento eventualmente necesiten dividirse en un conjunto de microservicios dependientes.
En este momento, los desarrolladores tienen que pasar por contorsiones para mantener una arquitectura de microservicios que funcione correctamente en PaaS. Necesitan construcciones como el descubrimiento de servicios y la conectividad directa de contenedores para funcionar de manera eficiente. Esas son difíciles de encontrar como capacidades nativas en el mundo PaaS.
Hay una dinámica problemática que aparece cuando las aplicaciones se vuelven más complejas de lo que PaaS puede comprender. Es una gran razón para que los desarrolladores se cambien a IaaS. Si una PaaS no puede admitir un almacén de datos, existen pocas razones para mantener todo lo demás implementado en la PaaS.
Una vez que una empresa pasa de PaaS a IaaS, paradójicamente anhelará las cosas que hacen que PaaS sea excelente: complejidad reducida, una excelente experiencia de desarrollador, excelente documentación y costos predecibles. Lea cualquier informe sobre el "Estado de DevOps" hoy y escuchará sobre el movimiento de "ingeniería de plataformas" y sus fundamentos filosóficos.
Pero las empresas no deberían necesitar reinventar la plataforma. Es un costo importante para la productividad. Crear y desarrollar una experiencia de desarrollador de primer nivel es suficiente trabajo para convertirse en una línea de negocios en sí misma. La creación de abstracciones sobre IaaS probablemente tendrá un ROI mínimo o nulo para las empresas fuera de Fortune 50 (mucho menos para sus clientes y accionistas). Es una propuesta comercial sin sentido.
PaaS resuelve muchos de los problemas de IaaS:
Vemos una oportunidad para un SaaS de propósito general que no arrincone a los desarrolladores y estamos entusiasmados. Estamos tomando lo que ya hemos creado, el mejor y único PaaS que no es de Heroku que se escala para satisfacer las necesidades empresariales, y lo hacemos más fácil y accesible para comenzar a crear aplicaciones.
A medida que AWS y otros proveedores de IaaS agregan más y más servicios a su consola, debemos esperar una mayor complejidad. Un número creciente de clientes de IaaS terminará confiando en lo que pronto serán arquitecturas de nube heredadas y paradigmas de desarrollo. Estas empresas inevitablemente buscarán una PaaS para liberarse, o simplemente para evitar las complejidades y frustraciones de lidiar con IaaS de servicios públicos.
Terminaré prestando especial atención a los desarrolladores en equipos más pequeños y relativamente independientes dentro de empresas más grandes. El movimiento "usted lo construye, usted lo ejecuta" probablemente será un impulsor para una mayor adopción de PaaS. De hecho, ya se está convirtiendo en "lo construyes, lo ejecutas, lo aseguras". A medida que los equipos de desarrollo se vuelvan más responsables de su infraestructura, serán responsables de sus propios DevOps. No podrán administrar mucho, por lo que PaaS será más que atractivo. PaaS se convertirá en una necesidad.
La gente puede ser pesimista con PaaS hoy, pero llegará el día en que estos equipos exijan un verdadero competidor de Heroku de nivel empresarial. Una plataforma va a abrir ese camino y se dará cuenta más rápido de lo que lo hizo Heroku.
En 2023, Aptible demostrará que es esa plataforma.