Os desenvolvedores estão questionando o futuro da plataforma como serviço (PaaS) — e por boas razões. Muitos deles criaram produtos de sucesso em PaaS, mas quando seu aplicativo atinge uma certa escala, eles precisam de mais. Eles não podem depurar problemas de desempenho facilmente devido à falta de transparência e recursos de caixa preta opinativos. Eles não podem implementar controles de segurança e conformidade totalmente configuráveis, como um firewall de aplicativo da web. Eles estão presos a quaisquer complementos limitados que a plataforma oferece, se é que são oferecidos. Recursos como armazenamento persistente, balanceamento de carga configurável e dimensionamento automático são inexistentes ou muito limitados para uso no mundo real em PaaS.
Então, o que os desenvolvedores fazem? Eles portam seus aplicativos para a infraestrutura como serviço (IaaS).
Não é que IaaS seja melhor, mas que não tem limites de implementação. Os desenvolvedores podem criar o que quiserem com provedores de IaaS. A compensação é de tempo, experiência e pessoal adicional. Mas tudo bem para a maioria dos desenvolvedores com aplicativos PaaS bem-sucedidos, porque eles já passaram pela parte difícil de criar algo e encontrar o produto adequado ao mercado. Eles não estão tão preocupados com a curva de aprendizado da migração para IaaS porque, a essa altura, eles têm uma base de usuários, receita e pista.
É provável que os desenvolvedores não portassem seus aplicativos para IaaS se PaaS fosse uma opção viável em escala. Mas isso significa que PaaS deve ser considerado inferior a IaaS? Dificilmente. O futuro da PaaS é brilhante — muito mais brilhante do que muitos desenvolvedores reconhecem. Na verdade, acredito que a PaaS dominará o futuro do desenvolvimento de software. O mercado está ansioso por uma plataforma “ótima para começar, ótima para escalar” para emergir e superar a experiência e o valor do desenvolvedor de hoje. A PaaS oferecerá absolutamente suporte à entrega de aplicativos globalmente escaláveis, mas terá que superar alguns desafios primeiro.
A beleza do IaaS é que ele oferece configurações quase infinitas e opções de escalabilidade. Os provedores de IaaS generalizaram seus produtos o suficiente para suportar praticamente qualquer caso de uso em qualquer escala. É incrivelmente poderoso e econômico. Além disso, os provedores de IaaS têm o prazer de oferecer créditos de uso e preços com desconto para impulsionar a adoção e atrair as equipes.
No entanto, pode ser incrivelmente difícil criar configurações escaláveis sem dar um tiro no próprio pé. Mudanças de configuração incorretas podem ter resultados catastróficos que são quase impossíveis de solucionar e corrigir sem conhecimento profundo de infraestrutura. Praticamente não há suporte de plataforma disponível (além de compromissos corporativos caros) e a documentação de IaaS é notoriamente inconsistente e difícil de ler. E nem me fale sobre a experiência real do usuário dos consoles IaaS.
Apostar tudo em IaaS significa construir equipes caras de infraestrutura para usar e gerenciar IaaS. Os especialistas em infraestrutura não são apenas algumas das pessoas mais solicitadas do setor, mas também é extremamente difícil encontrar as pessoas certas que saibam como atender às necessidades específicas de crescimento. Somando-se a essas complicações estão as realidades de um ambiente de arrecadação de fundos mais restrito, equipes sendo instruídas a “fazer mais com menos” e a complexidade cada vez maior das soluções de IaaS. O trabalho da equipe é configurar e manter a infraestrutura conforme ela cresce – e o trabalho nunca está “concluído”.
Entre questões de financiamento e falta de talentos de infraestrutura disponíveis, é difícil recomendar o aprofundamento do investimento em infraestrutura e trabalho de plataforma. Os recursos e capacidades da IaaS estão se tornando cada vez mais complexos, justificando ainda mais a necessidade de abstrações de alto nível, como as fornecidas pela PaaS.
Os provedores de IaaS sabem disso, e é por isso que estão investindo em abstrações do tipo PaaS. O Google está fazendo um bom trabalho nisso com sua plataforma de nuvem e Firebase , sua plataforma de desenvolvimento móvel. A Amazon tem tentado construir abstrações, mas a experiência do desenvolvedor não é boa. No entanto, é claro que eles entendem que os desenvolvedores querem (e merecem) melhores experiências, como autocriptografia de objetos S3 e integração RDS com o AWS Secrets Manager . O Azure agora oferece App Service , que permite a implantação simplificada na infraestrutura de dimensionamento automático.
Os principais provedores de nuvem estão melhorando em ofertas semelhantes a PaaS, mas também estão focados em estratégias legadas de elevação e mudança ou fantasias de ficção científica de “Kubernetes sem servidor”. Eles ganham a maior parte de seu dinheiro com empresas, o que influencia o desenvolvimento de recursos para atender a mais empresas. Startups e empresas de médio porte ficam cruzando os dedos, esperando que seus comentários levem a ambientes semelhantes a PaaS mais fáceis de usar e mais fáceis de construir, que não exijam conhecimentos avançados de infraestrutura para serem totalmente utilizados.
Raman Sharma astutamente observou que “pelo menos dois grandes provedores de nuvem de hiperescala (Azure e GCP) começaram sua jornada na nuvem com produtos PaaS, apenas para perceber rapidamente que dinheiro real (e montes e montes de músculos e memória institucional) ainda estava na infraestrutura . Então, eles passaram a ser centrados em IaaS (como a AWS era na época).”
Em outras palavras, IaaS estaria fazendo PaaS se IaaS não fosse tão lucrativo. Eles não estão atendendo startups, estão atendendo empresas.
Construir em IaaS oferece muita liberdade e oportunidade, mas você prefere gastar US$ 150.000 em um administrador certificado pela AWS ou US$ 150.000 em um desenvolvedor que pode criar recursos geradores de receita?
Se você não precisa se preocupar com infraestrutura, contratar o desenvolvedor é um acéfalo. Infelizmente, não é incomum que as empresas obtenham o pior dos dois mundos: elas contratam o desenvolvedor de $ 150.000 e o forçam a também fazer todo o trabalho de DevOps. Isso é muito menos retorno para o fanfarrão.
Não há realmente nenhuma vantagem competitiva para as equipes de produto que mudam de PaaS para IaaS, nem para aquelas que começam em IaaS e escalam. Em algum momento, isso inevitavelmente exigirá a contratação de um arquiteto de infraestrutura de nuvem caro e experiente. É claro que não tenho nada contra engenheiros de infraestrutura de nuvem qualificados, mas quando estou enfrentando uma pressão financeira crescente para “fazer mais com menos”, não estou muito animado para aumentar minha sobrecarga.
Além disso, mesmo que eu tivesse a maior equipe de infraestrutura de nuvem do mundo e mesmo que não fosse tão caro quanto hipoteticamente temo, qual a vantagem competitiva de ter essa equipe? Que vantagem isso realmente oferece a qualquer negócio? Para ser honesto, prefiro ter uma equipe enxuta de desenvolvedores que geram valor do que administradores que protegem o valor. Sim, posso gastar tempo e energia em IaaS para obter discos persistentes, recuperação pontual em meus bancos de dados, balanceamento de carga configurável, lógica de implantação azul/verde e dimensionamento automático, mas garanto que a maioria dos desenvolvedores prefere ter todos disponível com uma caixa de seleção em uma interface de usuário bem projetada.
Quanto mais tempo tenho para me concentrar em manter as luzes acesas, menos tempo gasto oferecendo ótimos recursos para clientes que desejam gastar dinheiro com meus produtos. Mais infraestrutura, menos valor.
A principal razão pela qual a PaaS existe em primeiro lugar é porque a IaaS é muito complicada. Os desenvolvedores querem escrever e implantar código. Eles querem criar novos aplicativos e recursos, ver como o mercado responde e iterar. E eles querem fazer isso com o menor número possível de obstáculos.
Por exemplo, se eu precisar de uma infraestrutura compatível com HIPAA para criar um SaaS com foco em assistência médica, posso começar com a arquitetura de referência da Amazon , que é incompleta e complexa, e passar semanas colocando-a em funcionamento. Ou posso criar um aplicativo no Aptible em minutos e saber que é compatível com HIPAA.
O mesmo vale para a conformidade com PCI. O Stack Overflow e o Reddit estão repletos de exemplos e avisos da batalha difícil para estabelecer e manter a infraestrutura compatível com PCI em qualquer uma das grandes nuvens IaaS. Ou você pode encontrar uma PaaS compatível com PCI e não perder tempo na configuração do firewall.
O problema é o seguinte: ninguém está optando por começar com arquitetura e implementação de infraestrutura complexa. Eles simplesmente não têm muitas opções ou não estão cientes das escolhas existentes. Qualquer desenvolvedor ou líder de produto escolheria PaaS se fosse econômico e capaz de atender às necessidades de dimensionamento de longo prazo. A PaaS não tem um problema de custo-benefício, mas de se destacar com sua capacidade de longo prazo de oferecer suporte a negócios em crescimento. Se não fosse esse o caso, PaaS seria um acéfalo para iniciar e dimensionar aplicativos.
Isso levanta a questão: quem não pagaria uma quantia sustentável de dinheiro extra para ter tudo “simplesmente funcionando”, excelente documentação e suporte integrado?
A IaaS fez um ótimo trabalho ao oferecer uma solução generalizada que funciona em qualquer caso de uso. A PaaS ainda não chegou lá. Há muitos recursos menores ausentes e ofuscações que fazem com que as equipes saiam do PaaS. Não existe uma PaaS única que suporte todos os aplicativos que uma empresa precisa executar, e isso não é um problema trivial.
Além disso, os padrões de desenvolvimento de aplicativos também evoluíram desde que o PaaS começou a florescer em 2010. O Heroku e seus semelhantes simplesmente não acompanharam. Aqui estão alguns dos “trabalhos a serem realizados” comuns da equipe de engenharia que são essenciais para os negócios, mas não estão sendo cobertos pela PaaS:
As necessidades são claramente diversas. O mundo da PaaS fez um ótimo trabalho com plataformas especializadas que claramente se posicionam como as melhores da categoria em uma única tarefa, mas o mundo precisa de uma PaaS que possa dar suporte a uma coleção de recursos que capacitam os negócios.
Os aplicativos PaaS tendem a ser monolíticos para aproveitar os vários recursos da plataforma de infraestrutura subjacente. No entanto, os produtos em crescimento provavelmente precisarão se dividir em um conjunto de microsserviços dependentes.
No momento, os desenvolvedores precisam passar por contorções para manter uma arquitetura de microsserviço funcionando corretamente no PaaS. Eles precisam de construções como descoberta de serviço e conectividade direta de contêiner para funcionar com eficiência. Esses são difíceis de encontrar como recursos nativos no mundo PaaS.
Há uma dinâmica problemática que aparece quando os aplicativos se tornam mais complexos do que o PaaS pode entender. É um grande motivo para os desenvolvedores mudarem para IaaS. Se uma PaaS não puder oferecer suporte a um data warehouse, haverá poucos motivos para manter qualquer outra coisa implantada na PaaS.
Depois que uma empresa muda de PaaS para IaaS, paradoxalmente, ela anseia pelas coisas que tornam a PaaS excelente: complexidade reduzida, uma ótima experiência de desenvolvedor, excelente documentação e custos previsíveis. Leia qualquer relatório de “State of DevOps” hoje e você ouvirá sobre o movimento de “engenharia de plataforma” e seus fundamentos filosóficos.
Mas as empresas não precisam reinventar a plataforma. É um grande custo para a produtividade. Criar e desenvolver uma experiência de desenvolvedor de alto nível é trabalho suficiente para se tornar uma linha de negócios por si só. Construir abstrações sobre IaaS provavelmente terá pouco ou nenhum ROI para empresas fora da Fortune 50 (muito menos para seus clientes e acionistas). É uma proposta de negócio absurda.
PaaS resolve muitos dos problemas de IaaS:
Vemos uma oportunidade para um SaaS de uso geral que não encurrala os desenvolvedores e estamos entusiasmados. Estamos pegando o que já construímos - o melhor e único PaaS não Heroku que pode ser dimensionado para atender às necessidades da empresa - e tornando mais fácil e acessível começar a criar aplicativos.
À medida que a AWS e outros provedores de IaaS adicionam mais e mais serviços ao console, devemos esperar mais complexidade. Um número crescente de clientes de IaaS acabará contando com o que em breve serão arquiteturas de nuvem legadas e paradigmas de desenvolvimento. Essas empresas inevitavelmente buscarão uma PaaS para se libertar, ou até mesmo para simplesmente evitar as complexidades e frustrações de lidar com IaaS de serviços públicos.
Vou encerrar dando atenção especial aos desenvolvedores em equipes menores e relativamente independentes dentro de empresas maiores. O movimento "você constrói, você executa" provavelmente será um impulsionador para o aumento da adoção de PaaS. Na verdade, já está se tornando “você constrói, executa e protege”. À medida que as equipes de desenvolvimento se tornam mais responsáveis por sua infraestrutura, elas serão responsáveis por seus próprios DevOps. Há um limite para o que eles poderão gerenciar, então PaaS será mais do que atraente. A PaaS se tornará uma necessidade.
As pessoas podem estar pessimistas em PaaS hoje, mas está chegando o dia em que essas equipes exigirão um verdadeiro concorrente Heroku de nível empresarial. Uma plataforma vai abrir esse caminho e vai pegar mais rápido do que o Heroku jamais fez.
Em 2023, a Aptible mostrará que é essa plataforma.