Existem várias abordagens modernas para a arquitetura e o desenvolvimento de aplicações que, basicamente, seguem a ideia de "torná-las menores e, portanto, mais eficientes".
Tanto os microsserviços quanto a Função como Serviço (FaaS) se baseiam no conceito de código altamente especializado. Embora seja verdade que a maioria das organizações não esteja decompondo aplicações em centenas de microsserviços ou milhares de funções, elas estão adotando cada vez mais esse modelo. Isso geralmente ocorre porque ele facilita o desenvolvimento ágil, já que uma equipe relativamente pequena consegue projetar, desenvolver e aperfeiçoar um serviço com muito mais rapidez do que uma aplicação monolítica de grande porte. Afinal, é muito mais fácil escrever e testar algo com 1.000 linhas de código do que uma aplicação maior, que chega a 100.000 linhas.
Mas há outro benefício interessante dos microsserviços e do FaaS que não recebe o devido destaque: a segurança.
Há muitas discussões na Internet — e eu já li um número considerável delas — que tentam determinar a densidade de defeitos e vulnerabilidades considerada a "média do setor". Você encontrará uma ampla variedade de estimativas, algumas baseadas em varreduras reais de código aberto e outras em números autodeclarados. A NASA, por exemplo, tem destacado com orgulho sua densidade extremamente baixa de defeitos como um dos motivos do sucesso do programa dos ônibus espaciais. Também há relatórios baseados em dados coletados de forma objetiva por empresas de segurança como a WhiteHat, mas seus números se concentram em vulnerabilidades por aplicação e não necessariamente por linha de código.
Não há um consenso real sobre a densidade de defeitos e vulnerabilidades, exceto quanto ao fato de que, sim, ela existe.
No entanto, é razoável supor que, quanto menos linhas de código você escrever, menor será a probabilidade de introduzir defeitos e vulnerabilidades. Igualmente importante: quanto menos linhas de código você tiver que examinar para encontrar uma vulnerabilidade ou um defeito, mais rápido você conseguirá encontrá-lo e, presume-se, corrigi-lo.
Um dos motivos pelos quais isso é verdade é o escopo. Se meu microsserviço ou minha função estiver focado em codificar um aspecto da lógica de negócios, serão necessários menos lógica e menos bibliotecas para implementá-lo. Esse escopo menor reduz as chances de introduzir erros na lógica ou vulnerabilidades nas bibliotecas (de terceiros ou não) necessárias para implementar essa lógica adicional. Sempre que você precisa incluir outro componente ou fazer uma chamada para outro serviço, cria oportunidades para o surgimento de defeitos e vulnerabilidades.
Um número menor de interfaces para a função ou o microsserviço também contribui para um código mais seguro. Cada interface (um ponto de entrada, como uma chamada de API) cria a possibilidade de uma vulnerabilidade, pois envolve o processamento de entradas do usuário. E as entradas do usuário, como todos sabemos, devem sempre ser consideradas suspeitas e potencialmente maliciosas.
E, se os microsserviços reduzem o potencial de vulnerabilidades e falhas, restringir ainda mais o escopo a uma função deve diminuir ainda mais essa possibilidade.
Isso não quer dizer que microsserviços e FaaS sejam inerentemente mais seguros do que seus equivalentes de três camadas e monolíticos. Código malfeito continua sendo código malfeito, independentemente de quantas linhas tenha. Mas é verdade que ambas as arquiteturas favorecem práticas de desenvolvimento e entrega que podem resultar em códigos mais seguros.
Ter em mente os benefícios de segurança ao avaliar ou implementar microsserviços e/ou FaaS pode ajudar a evitar que o código fique inchado, além de impedir a introdução de vulnerabilidades.
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...