Seja bem-vindo, futuro servidor! Os temas de arquitetura de aplicações, modelos de computação em nuvem e ciclos de desenvolvimento de software são pilares fundamentais da tecnologia da informação e, por isso, figurinhas carimbadas em concursos públicos de alto nível. A capacidade de diferenciar modelos como PaaS, IaaS e SaaS, compreender as implicações do acoplamento em arquiteturas e conhecer metodologias como TDD e BDD é crucial. A questão da FGV para a Prefeitura de BH em 2024 que analisaremos é um excelente exemplo de como a banca pode, em uma única questão, testar um vasto leque de conhecimentos. Usaremos cada afirmativa como um trampolim para aprofundar o conhecimento e garantir que você não seja pego de surpresa.
Desvendando a Nuvem: Modelos de Serviço e a Controvérsia do PaaS
A primeira afirmativa da questão aborda o modelo de Plataforma como Serviço (PaaS) e sua relação com tecnologias como Docker e Kubernetes. Vamos analisar e expandir.
O item da questão afirmava: “( ) O modelo de cloud computing do tipo Plataforma como Serviço (PAAS, Platform-as-a-Service) oferece ambiente compartilhado de desenvolvimento de software que fornece, às equipes de desenvolvimento e operações, acesso a todas as ferramentas de que necessitam, a partir de qualquer local com uma conexão à Internet, sendo frequente o emprego das tecnologias Docker e Kubernetes.”
A banca considerou esta afirmativa como VERDADEIRA. Vamos entender o porquê.
Plataforma como Serviço (PaaS)
PaaS é um modelo de computação em nuvem que fornece aos desenvolvedores uma plataforma para construir, implantar e gerenciar aplicações sem se preocuparem com a complexidade da infraestrutura subjacente (hardware, sistemas operacionais, redes, armazenamento). O provedor de nuvem gerencia tudo isso, e o desenvolvedor foca no código e nos dados da aplicação. Pense no PaaS como um “ambiente de execução” pronto para uso.
A Relação com Docker e Kubernetes
Aqui reside o ponto que gera mais dúvidas. Tradicionalmente, Docker (plataforma de contêineres) e Kubernetes (orquestrador de contêineres) são fortemente associados ao modelo IaaS (Infraestrutura como Serviço), onde o usuário tem mais controle, ou a um modelo intermediário chamado CaaS (Containers as a Service). No entanto, muitas plataformas PaaS modernas, como Heroku, Google App Engine e Red Hat OpenShift, foram reconstruídas ou projetadas sobre uma base de contêineres e Kubernetes. Para o desenvolvedor que usa a PaaS, a complexidade do Kubernetes é abstraída, mas a tecnologia está lá, garantindo escalabilidade, resiliência e portabilidade. Portanto, o emprego de Docker e Kubernetes tornou-se, de fato, “frequente” na implementação de ambientes PaaS.
Arquiteturas de Aplicação: O X da Questão do Acoplamento
A segunda afirmativa tratava da classificação de arquiteturas pelo nível de acoplamento, um erro clássico em provas.
O item da questão afirmava: “( ) Quanto ao nível de acoplamento, podemos diferenciar as arquiteturas de aplicação como monolíticas e em N camadas (levemente acopladas), microsserviços (fortemente acopladas); e, orientadas a eventos ou serviços (desacopladas).”
A banca considerou esta afirmativa como FALSA. A análise é direta: os conceitos de acoplamento estão deliberadamente trocados.
- Arquitetura Monolítica: É caracterizada pelo alto acoplamento. Todos os componentes da aplicação (interface, regras de negócio, acesso a dados) são desenvolvidos e implantados como uma única unidade. Uma alteração em uma pequena parte pode exigir que toda a aplicação seja testada e reimplantada.
- Arquitetura de Microsserviços: O princípio fundamental é o baixo acoplamento (ou desacoplamento). A aplicação é dividida em pequenos serviços independentes, cada um com sua própria responsabilidade e, muitas vezes, seu próprio banco de dados. Eles se comunicam por APIs bem definidas.
- Arquitetura Orientada a Eventos (EDA) e a Serviços (SOA): São inerentemente desacopladas. Na EDA, os componentes reagem a eventos, sem conhecerem diretamente quem os produziu. Em SOA, serviços são disponibilizados na rede para serem consumidos por outras aplicações, promovendo reuso e baixo acoplamento.
- Arquitetura em N Camadas: O nível de acoplamento pode variar, mas é geralmente menor que no monolito e maior que em microsserviços. As camadas (apresentação, negócio, dados) são separadas logicamente, mas frequentemente implantadas juntas, o que as torna moderadamente acopladas.
Ciclo de Vida de Desenvolvimento (SDLC): TDD vs. BDD
A terceira afirmativa diferenciava duas importantes metodologias de desenvolvimento guiado por testes.
O item da questão afirmava: “( ) No ciclo de vida do desenvolvimento de software (SDLC, Software Development Lifecycle) podem ser aplicadas as metodologias TDD (Test Driven Development), quando o foco está em uma linguagem mais técnica e no objetivo de testar alguma funcionalidade, e o BDD (Behavior Driven Development), quando o foco está em uma linguagem mais próxima da linguagem natural e no objetivo de realização de testes de comportamento.”
A banca considerou esta afirmativa como VERDADEIRA, e a descrição é precisa e didática.
Test Driven Development (TDD)
O Desenvolvimento Guiado por Testes (TDD) é uma prática de desenvolvimento focada no desenvolvedor. O ciclo é conhecido como “Red-Green-Refactor”:
- Red (Vermelho): Escrever um teste automatizado (geralmente um teste de unidade) para uma nova funcionalidade que ainda não existe. O teste, obviamente, falha.
- Green (Verde): Escrever a quantidade mínima de código necessária para fazer o teste passar.
- Refactor (Refatorar): Melhorar a estrutura do código escrito sem alterar seu comportamento (os testes devem continuar passando).
A linguagem é técnica (código) e o objetivo é garantir a correção de pequenas unidades de funcionalidade.
Behavior Driven Development (BDD)
O Desenvolvimento Guiado por Comportamento (BDD) evoluiu do TDD. Ele amplia o foco do teste de uma unidade técnica para o comportamento do sistema sob a ótica do usuário ou do negócio. A principal característica do BDD é o uso de uma linguagem ubíqua, próxima da linguagem natural, que pode ser entendida por desenvolvedores, analistas de qualidade (QAs) e gerentes de produto (POs). Frequentemente, utiliza-se a sintaxe Gherkin (Given-When-Then / Dado-Quando-Então).
- Given (Dado): Um contexto inicial.
- When (Quando): Uma ação é executada.
- Then (Então): O resultado esperado (o comportamento) é verificado.
Dominar esses três pilares — modelos de nuvem, acoplamento de arquiteturas e metodologias de desenvolvimento — é um passo gigante rumo à sua aprovação na área de TI.
Mapa da Aprovação: Resumo Esquematizado
Modelos de Serviço em Nuvem
| Modelo | O que VOCÊ Gerencia | O que o PROVEDOR Gerencia | Analogia |
|---|---|---|---|
| IaaS (Infra as a Service) | Aplicações, Dados, Runtime, Middleware, S.O. | Virtualização, Servidores, Storage, Rede | Alugar um terreno vazio. |
| PaaS (Platform as a Service) | Aplicações, Dados | Runtime, Middleware, S.O., Virtualização, Servidores, Storage, Rede | Alugar uma oficina com todas as ferramentas. |
| SaaS (Software as a Service) | Nada (apenas usa o software) | Tudo | Usar um carro por aplicativo. |
Arquiteturas de Aplicação vs. Acoplamento
| Arquitetura | Nível de Acoplamento | Característica Principal |
|---|---|---|
| Monolítica | Forte | Aplicação como uma única unidade implantável. |
| Microsserviços | Fraco / Desacoplado | Aplicação como um conjunto de serviços pequenos e independentes. |
| Orientada a Eventos (EDA) | Desacoplado | Comunicação assíncrona baseada na produção e consumo de eventos. |
Metodologias de Desenvolvimento: TDD vs. BDD
| Metodologia | Foco Principal | Linguagem | Público-Alvo |
|---|---|---|---|
| TDD | Implementação correta da unidade de código. | Técnica (código de teste). | Desenvolvedores. |
| BDD | Validação do comportamento do sistema. | Natural (ex: Given-When-Then). | Equipe multidisciplinar (Devs, QAs, POs). |
Teste Seus Conhecimentos: Questões de Fixação
Referências:
- Kubernetes vs. Docker – Atlassian
- Kubernetes vs Docker – Microsoft Azure
- Kubernetes vs. Docker: qual a relação entre os dois? – Supero
- Monolítico x microsserviços — Diferença entre arquiteturas – AWS
- Do monolito aos microsserviços com arquitetura orientada a eventos – Speaker Deck
- Qual é a diferença entre TDD e BDD? – Alura
- Saiba qual é a diferença entre TDD e BDD – Locaweb
