Não sei ler mentes (meus filhos discordariam, mas isso não vem ao caso), porém sei interpretar as respostas à nossa pesquisa sobre o Estado da Entrega de Aplicações. E, quando as analiso sob a perspectiva dos participantes que se identificam como desenvolvedores de aplicações, vejo surgir um cenário muito interessante.
Os desenvolvedores se preocupam com velocidade. E segurança. E escalabilidade. Não necessariamente nessa ordem, mas se preocupam com os três aspectos. E não apenas se preocupam: eles também reconhecem o valor dos serviços de aplicações para ajudá-los a alcançar os três.

Ou seja, os desenvolvedores não querem apenas serviços vagos de “aceleração” de aplicações; eles querem serviços específicos que ofereçam otimizações de TCP e armazenamento em cache. Eles também querem um firewall de aplicações web e, de quebra, algum balanceamento de carga.
O problema é que a maioria desses serviços de aplicação é fornecida em um modelo de infraestrutura compartilhada. Cada aplicação tem sua própria “representação virtual”, mas está fisicamente hospedada em um software ou hardware compartilhado.
Isso pode causar problemas reais — e é, em parte, uma das fontes do atrito que ainda existe entre a TI e o desenvolvimento de aplicativos. Foi essa natureza compartilhada dos sistemas que nos trouxe as janelas de mudança, os comitês de revisão e as implantações nas noites de sábado (com pizza, para nos manter satisfeitos) — processos que atrasam o desenvolvimento e tornam a implantação uma experiência frustrante para todos os envolvidos.
Não estamos mais implantando aplicativos monolíticos gigantescos. Mesmo que não tenhamos aderido à febre dos microsserviços e decomposto os aplicativos em centenas de pequenos serviços, ainda temos mais aplicativos com ciclos de implantação mais frequentes. Aplicativos desenvolvidos em sprints de uma semana, em vez de projetos de um ano, e que precisam disponibilizar atualizações com mais rapidez e frequência.
Em última análise, esse é um dos principais motivos pelos quais a nuvem (pública) tem feito tanto sucesso. Porque é o meu aplicativo e a minha infraestrutura, e não preciso esperar pelo Bob, pela Alice ou pelo John para publicar uma atualização. Porque tudo é meu, e a responsabilidade é toda minha se algo der errado.
Essa mesma abordagem também é possível (e, a meu ver, preferível) em ambientes locais. Para isso, é necessário que todos os elementos que compõem a cadeia de entrega de uma aplicação ofereçam suporte ao mesmo tipo de abordagem por aplicação que a nuvem tornou desejável.
Basicamente, uma abordagem por aplicativo para fornecer os serviços de rede e de aplicação necessários é semelhante a dedicar uma sub-rede ao aplicativo — uma VLAN de entrega de aplicativos, por assim dizer. Tudo gira em torno desse único 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 demais. Falhas acontecem e, quando isso ocorre, é importante limitar ao máximo o raio de impacto. Arquiteturas específicas para cada aplicativo mantêm o impacto das falhas estritamente limitado, o que deixa felizes todas aquelas pessoas de plantão “por precaução”, pois não receberam nenhuma chamada. Posso lançar e implantar toda semana sem entrar em conflito com os aplicativos que fazem lançamentos e implantações 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 em produção. E eles surgem com frequência. Na verdade, 50% dos desenvolvedores relataram problemas em produção após o lançamento do código em uma pesquisa da Atlassian de 2017. Não há possibilidade de outra pessoa ter feito uma alteração que possa afetar o aplicativo. Você pode ir direto aos sistemas envolvidos, em vez de perder um tempo valioso tentando descobrir quais sistemas podem estar envolvidos.
Uma arquitetura por aplicativo se adapta naturalmente melhor à nuvem — seja ela pública ou privada — porque esse é o pressuposto do modelo. Cada aplicativo conta com um conjunto dedicado de serviços de aplicação para garantir escalabilidade, velocidade e segurança.
A realidade é que uma arquitetura por aplicativo era inevitável. Não é a primeira vez que digo isso. A força gravitacional dos aplicativos é grande demais para ser ignorada, e a segurança cada vez mais específica necessária para manter um aplicativo protegido significava que, mais cedo ou mais tarde, surgiria uma abordagem por aplicativo.
E isso é bom, porque os serviços de aplicação que os desenvolvedores desejam são, na maioria das vezes, específicos para cada aplicação. O que funciona para uma não necessariamente funcionará para outra — e pode, na verdade, ser prejudicial. Ao adotar uma abordagem arquitetônica por aplicação para a entrega de aplicações, você pode garantir que os desenvolvedores não apenas obtenham o que desejam e precisam para escalar, proteger e acelerar as aplicações, mas também oferecer melhor suporte ao modelo de autoatendimento que eles esperam da nuvem, seja no ambiente local ou fora dele.
Sobre o autor

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...