Pilares de TI: visão geral para organizar o estudo
Para interpretar arquiteturas e cenários de TI (especialmente em ambientes corporativos), é útil separar os elementos em pilares: hardware (base física), software (programas e sistemas), serviços (capacidades entregues via rede), ambientes (onde o software roda ao longo do ciclo de entrega) e arquitetura (como as partes se conectam para atender um objetivo).
Mapa conceitual (alto nível) Usuário/Cliente | v Aplicação (camadas) | v Serviços de apoio (API, fila, cache) | v Dados (banco, storage) | v Infra (VMs/containers, rede, hardware) Ambientes: DEV -> HOMOLOG -> PRODUÇÃOHardware: o que é e como se relaciona com desempenho
Definição
Hardware é o conjunto de componentes físicos que executam processamento e armazenam dados. Em provas e no trabalho, costuma aparecer ligado a capacidade, desempenho e disponibilidade.
Componentes essenciais
- CPU: executa instruções; influencia tempo de resposta e capacidade de processamento.
- Memória RAM: guarda dados temporários; insuficiência pode causar lentidão por troca com disco.
- Armazenamento (SSD/HDD/SAN): persistência; afeta tempo de leitura/gravação e IOPS.
- Rede (placas, switches, roteadores): conecta sistemas; afeta latência e throughput.
Exemplo prático
Uma API lenta pode estar relacionada a: CPU saturada (muitas requisições), falta de RAM (swap), disco lento (consultas e logs) ou rede congestionada (muitos hops/baixa banda).
Software: sistema operacional, aplicações e dependências
Definição
Software é a parte lógica: sistemas operacionais, aplicativos, bibliotecas, bancos de dados, servidores web e ferramentas de execução.
Classificações úteis
- Sistema operacional (ex.: Linux/Windows): gerencia processos, memória, arquivos e rede.
- Middleware: “ponte” entre aplicação e infraestrutura (ex.: servidor de aplicação, broker de mensagens).
- Aplicação: código que implementa regras de negócio (ex.: serviço de autenticação, API de pagamentos).
- Dependências: bibliotecas e runtimes (ex.: JVM, .NET, Node.js).
Passo a passo prático: identificar o que é software em um cenário
- Liste o que “roda” (processos/serviços): web server, API, banco, fila.
- Separe o que é base (SO/runtime) do que é aplicação (código do negócio).
- Marque dependências críticas (bibliotecas, drivers, certificados).
Serviços de TI: o que a infraestrutura entrega via rede
Definição
Serviço é uma capacidade oferecida e consumida (internamente ou externamente), geralmente via rede, com um contrato: disponibilidade, desempenho, segurança e suporte.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Exemplos comuns em arquiteturas
- Serviço de autenticação (login, tokens).
- Serviço de banco de dados (consultas e transações).
- Serviço de mensageria (filas/tópicos para processamento assíncrono).
- Serviço de cache (reduz latência e carga no banco).
Conceitos associados
- SLA: meta de disponibilidade/tempo de resposta.
- Incidente: falha que afeta o serviço.
- Capacidade: quanto o serviço suporta antes de degradar.
Ambientes: desenvolvimento, homologação e produção
Definições
- Desenvolvimento (DEV): ambiente para criar e testar rapidamente; mudanças frequentes.
- Homologação (HML/QA): validação integrada; simula produção; foco em testes e aprovação.
- Produção (PROD): atende usuários reais; foco em estabilidade, segurança e monitoramento.
Por que separar ambientes
- Reduz risco: erro em DEV não derruba PROD.
- Permite testes controlados: performance, integração, regressão.
- Garante rastreabilidade: o que foi aprovado é o que vai para produção.
Passo a passo prático: como reconhecer o ambiente em um enunciado
- Procure termos como “usuários finais”, “clientes”, “indisponibilidade” → tende a ser PROD.
- Procure “testes”, “validação”, “aprovação” → tende a ser HML.
- Procure “debug”, “alterações constantes”, “ambiente local” → tende a ser DEV.
Camadas de uma aplicação: separação de responsabilidades
Modelo em camadas (visão didática)
- Apresentação: interface (web/mobile) e interação com o usuário.
- Aplicação/Serviço: orquestra casos de uso (ex.: criar pedido, consultar saldo).
- Domínio/Regras de negócio: validações e regras centrais (ex.: limites, cálculos, políticas).
- Dados: persistência e acesso a dados (SQL, NoSQL, arquivos).
- Integrações: comunicação com APIs externas, filas, serviços corporativos.
Mapa conceitual (camadas) UI (web/app) -> API/Service -> Regras de negócio -> Banco de dados -> Integrações (APIs/filas)Exemplo prático
Se uma tela “não carrega”, o problema pode estar na apresentação (front), na API (back), na regra (erro de validação), no banco (consulta lenta) ou na integração (API externa fora).
Arquitetura cliente-servidor: base para web e APIs
Definição
Na arquitetura cliente-servidor, o cliente solicita recursos/serviços e o servidor responde. A comunicação ocorre via rede, usando protocolos (ex.: HTTP/HTTPS).
Elementos típicos
- Cliente: navegador, app mobile, outro sistema.
- Servidor web/API: recebe requisições, aplica regras e retorna respostas.
- Banco de dados: armazena dados persistentes.
Passo a passo prático: seguir o caminho de uma requisição HTTP
- Cliente envia requisição (ex.: GET /clientes/123).
- Servidor web/API autentica/autoriza (quando aplicável).
- Camada de serviço executa caso de uso.
- Camada de dados consulta/grava no banco.
- Servidor retorna resposta (JSON/HTML) ao cliente.
Computação em nuvem: conceitos e relação com disponibilidade e escalabilidade
Definição
Computação em nuvem é o fornecimento de recursos de TI (computação, armazenamento, rede, bancos, filas etc.) como serviços sob demanda, com elasticidade e cobrança por uso (dependendo do modelo).
Modelos de serviço (visão conceitual)
- IaaS: infraestrutura (VMs, rede, discos). Você gerencia SO e aplicações.
- PaaS: plataforma (runtime, banco gerenciado, serviços). Você foca mais no código.
- SaaS: software pronto (uso direto). Você configura e utiliza.
Disponibilidade e escalabilidade na nuvem
- Disponibilidade: capacidade de manter o serviço acessível. Pode ser aumentada com redundância (múltiplas instâncias, múltiplas zonas) e automação de recuperação.
- Escalabilidade: capacidade de crescer para atender mais carga. Na nuvem, é comum escalar adicionando instâncias (horizontal) ou aumentando recursos (vertical).
Mapa conceitual (disponibilidade x escalabilidade) Disponibilidade: redundância + failover + monitoramento Escalabilidade: vertical (mais CPU/RAM) ou horizontal (mais instâncias)Virtualização: por que VMs existem
Definição
Virtualização permite executar múltiplas máquinas virtuais (VMs) em um mesmo hardware físico, isolando sistemas operacionais e aplicações. Um componente (hipervisor) gerencia esse compartilhamento.
Quando é útil
- Isolamento entre sistemas.
- Melhor aproveitamento do hardware.
- Facilidade de provisionamento e migração.
Relação com disponibilidade
Com VMs, é comum ter replicação e recuperação mais rápida (subir uma VM em outro host), reduzindo tempo de indisponibilidade quando há falha de hardware.
Containers: execução leve e padronizada
Definição
Containers empacotam aplicação e dependências, executando de forma isolada no mesmo sistema operacional (compartilham o kernel). Em geral, são mais leves que VMs e facilitam padronização de execução.
VM vs Container (comparação conceitual)
- VM: inclui SO completo; maior isolamento; mais pesado.
- Container: compartilha SO; mais leve; sobe mais rápido; facilita escalar serviços.
Relação com escalabilidade
Containers favorecem escala horizontal: subir mais réplicas do mesmo serviço para atender picos (desde que a aplicação e o estado estejam bem planejados).
Arquiteturas típicas: web, APIs, filas e bancos (identificação de componentes)
Arquitetura web simples (3 camadas)
[Cliente/Navegador] --HTTPS--> [Servidor Web/App] --SQL--> [Banco de Dados]- Cliente: navegador
- Servidor: aplicação (front/back dependendo do caso)
- Dados: banco relacional (ex.: PostgreSQL, Oracle) ou outro
Arquitetura com API e front separado
[Cliente (SPA/App)] --HTTPS--> [API Gateway/Load Balancer] --> [Serviço API] --> [Banco] --> [Cache]- Front (SPA/app): apresentação
- API: regras e orquestração
- Cache: acelera leituras e reduz carga no banco
- Balanceador/Gateway: distribui tráfego e pode aplicar políticas
Arquitetura com fila (processamento assíncrono)
[Cliente] -> [API] -> (publica mensagem) -> [Fila/Broker] -> [Worker/Consumidor] -> [Banco/Serviço externo]- Fila: desacopla e absorve picos (buffer)
- Worker: processa em segundo plano
- Benefício: melhora resiliência e escalabilidade do processamento
Arquitetura com múltiplos serviços (microserviços em visão conceitual)
[Cliente] -> [Gateway] -> [Serviço A] -> [DB A] -> [Serviço B] -> [DB B] -> [Fila] -> [Worker]Nem toda arquitetura precisa ser microserviços; o importante é reconhecer: serviços separados, comunicação via rede, e dados podendo ser segregados por serviço.
Exercícios curtos (identificação de componentes)
Exercício 1
Diagrama: [App Mobile] --HTTPS--> [API] --SQL--> [Banco]
- Identifique: cliente, servidor, camada de dados.
- Qual componente deve implementar autenticação e autorização?
Exercício 2
Diagrama: [Web] -> [Load Balancer] -> [2 instâncias de API] -> [Banco]
- O que está sendo feito para melhorar disponibilidade?
- Isso é escala vertical ou horizontal?
Exercício 3
Diagrama: [API] -> [Fila] -> [Worker] -> [Serviço de e-mail]
- Qual parte é síncrona e qual é assíncrona?
- Qual componente ajuda a absorver picos de requisições?
Exercício 4
Enunciado: “O sistema funciona em DEV, mas falha em HML por diferença de configuração de conexão com banco.”
- Qual pilar está mais relacionado ao problema: hardware, software, serviços ou ambientes?
- Que tipo de controle reduz esse risco (pista: padronização e configuração)?
Exercício 5
Enunciado: “Para suportar aumento de acessos, a equipe decidiu subir mais réplicas do serviço em containers.”
- Isso está ligado a disponibilidade, escalabilidade ou ambos?
- Qual tipo de escalabilidade foi aplicada?
