Por que uma abordagem por aplicativo para serviços de aplicativos é importante
Não consigo ler mentes (meus filhos discordariam, mas isso não vem ao caso), mas consigo ler as respostas à nossa pesquisa sobre o estado da entrega de aplicativos. E quando os leio através das lentes de desenvolvedores de aplicativos autoidentificados, vejo uma imagem muito interessante surgir.
Os desenvolvedores se preocupam com velocidade. E segurança. E escala. Não necessariamente nessa ordem, mas eles se importam com todas as três. Eles não apenas se importam, mas reconhecem o valor dos serviços de aplicativos para ajudá-los a atingir todos os três objetivos.
Ou seja, os desenvolvedores não querem apenas serviços vagos de aplicativos de "aceleração", eles querem serviços específicos que forneçam otimizações de TCP e cache. Eles querem um firewall de aplicativo web e algum balanceamento de carga, para começar.
O problema é que a maioria desses serviços de aplicativos são entregues em um modelo de infraestrutura compartilhada. Cada aplicativo tem sua própria “representação virtual”, mas reside fisicamente em um pedaço compartilhado de software ou hardware.
Isso pode causar problemas reais – e é em parte uma fonte de atrito que permanece entre a TI e o desenvolvimento de aplicativos. É essa natureza compartilhada dos sistemas que nos trouxe janelas de mudança, painéis de revisão e implantações nas noites de sábado (com pizza, para nos manter apaziguados) – os processos que retardam o desenvolvimento e tornam a implantação uma experiência frustrante para todos os envolvidos.
Não estamos mais implantando aplicativos monstruosos monolíticos. Mesmo que não tenhamos adotado microsserviços e decomposto aplicativos em centenas de pequenos serviços, ainda temos mais aplicativos com cronogramas de implantação mais frequentes. Aplicativos que são desenvolvidos em sprints de uma semana, em vez de projetos de um ano, e precisam lançar atualizações com mais rapidez e frequência.
Essa, em última análise, é a principal razão pela qual a nuvem (pública) tem sido tão bem-sucedida. Porque é meu aplicativo e minha infraestrutura e não preciso esperar por Bob, Alice ou John antes de enviar uma atualização. Porque é tudo meu, e a responsabilidade é toda minha se der errado.
Essa mesma abordagem é possível (e preferível, eu acho) também no local. O que é necessário é que todas as peças e partes que compõem a cadeia de entrega de um aplicativo suportem o mesmo tipo de abordagem por aplicativo que a nuvem tornou desejável.
Basicamente, uma abordagem por aplicativo para fornecer os serviços de rede e aplicativo necessários é semelhante a dedicar uma sub-rede ao aplicativo; uma VLAN de entrega de aplicativo, por assim dizer. Tudo se resume a um aplicativo, com serviços dedicados.
Esse tipo de isolamento não é bom apenas para os cronogramas de implantação, mas também para todos os outros. Falhas acontecem e, quando isso acontece, você quer restringir o raio da explosão o máximo possível. Arquiteturas por aplicativo significam um impacto de falha fortemente restrito, o que deixa todas aquelas pessoas de plantão "só por precaução" felizes porque não receberam aquela chamada. Posso lançar e implantar toda semana sem ter problemas com os aplicativos que lançam e implantam uma vez por mês. Meu aplicativo, meus serviços, meu cronograma de implantação.
Uma arquitetura por aplicativo também facilita a solução de problemas que surgem na produção. E muitas vezes isso acontece. De fato, 50% dos desenvolvedores relataram problemas na produção após o lançamento do código em uma pesquisa da Atlassian de 2017 . Não há chance de outra pessoa ter feito uma alteração que possa impactar o aplicativo. Você pode ir direto aos sistemas envolvidos em vez de gastar um tempo valioso tentando descobrir quais sistemas podem estar envolvidos.
Uma arquitetura por aplicativo naturalmente se encaixa melhor com a nuvem – seja pública ou privada – porque essa é a suposição feita pelo modelo. Cada aplicativo tem um conjunto dedicado de serviços de aplicativo para dimensioná-lo, acelerá-lo e protegê-lo.
A realidade é que uma arquitetura por aplicativo era inevitável. Não é a primeira vez que digo isso . A gravidade dos aplicativos é forte demais para ser ignorada, e a necessidade de segurança cada vez mais específica para cada aplicativo, para mantê-lo seguro, significava que uma abordagem por aplicativo surgiria mais cedo ou mais tarde.
E isso é bom, porque os serviços de aplicativos que os desenvolvedores desejam são, na maioria das vezes, específicos do aplicativo. O que funciona para um não necessariamente vai funcionar para o outro – e pode até ser negativo. Ao adotar uma abordagem arquitetônica por aplicativo para entrega de aplicativos, você pode garantir que os desenvolvedores não apenas obtenham o que desejam e precisam para dimensionar, proteger e acelerar os aplicativos, mas também pode oferecer melhor suporte ao modelo de autoatendimento que eles esperam da nuvem, seja no local ou externamente.