Computação em Nuvem
Problema
Imagine que uma empresa desenvolve um novo sistema para vendas pela Internet. Nos primeiros meses, o número de clientes é pequeno e um único servidor atende todas as solicitações sem dificuldades. Entretanto, após uma campanha publicitária bem-sucedida, milhares de novos usuários passam a acessar o sistema simultaneamente. O servidor começa a responder lentamente, algumas páginas deixam de carregar e, em determinados momentos, o serviço torna-se indisponível.
Diante dessa situação, a equipe de Tecnologia da Informação precisa tomar uma decisão. A solução mais imediata parece ser adquirir novos servidores, instalar sistemas operacionais, configurar redes, preparar ambientes de segurança e migrar parte da carga de trabalho para esses novos equipamentos. Contudo, essa estratégia apresenta diversos inconvenientes. A compra de hardware demanda investimento financeiro, processos de aquisição, espaço físico, consumo adicional de energia elétrica e tempo para instalação e configuração. Mesmo após todo esse esforço, ainda existe uma incerteza: será que essa capacidade extra continuará sendo necessária após o período de maior demanda?
Esse problema não é exclusivo de uma única organização. Durante muitos anos, empresas de diferentes portes enfrentaram o mesmo desafio. Em alguns períodos, seus servidores permaneciam sobrecarregados; em outros, operavam com grande parte dos recursos ociosos. A infraestrutura precisava ser dimensionada para suportar os momentos de pico, mesmo sabendo que, durante a maior parte do tempo, boa parte desse investimento permaneceria subutilizada.
Na aula anterior estudamos como a virtualização reduziu significativamente esse desperdício. Em vez de manter um servidor físico para cada serviço, tornou-se possível executar diversas máquinas virtuais em um mesmo equipamento, aumentando o aproveitamento do hardware e reduzindo custos operacionais. Essa inovação representou um enorme avanço na administração de Data Centers.
Entretanto, a virtualização resolveu apenas parte do problema.
Mesmo com dezenas de máquinas virtuais disponíveis, ainda era necessário que administradores instalassem equipamentos, configurassem hipervisores, criassem novas máquinas, definissem redes virtuais, monitorassem recursos e realizassem todo o processo de provisionamento da infraestrutura. Em outras palavras, a infraestrutura havia se tornado mais eficiente, mas ainda dependia de intervenção humana para ser disponibilizada aos usuários.
Nesse momento surgiu uma nova pergunta, muito mais ambiciosa do que todas as anteriores:
Seria possível transformar toda essa infraestrutura em um serviço, permitindo que qualquer pessoa pudesse obter servidores, armazenamento, bancos de dados e redes em poucos minutos, independentemente de onde estivesse?
Responder a essa pergunta exigiu uma mudança profunda na forma de pensar a Tecnologia da Informação.
Até então, organizações adquiriam computadores para executar aplicações. A partir desse novo paradigma, passou a ser possível consumir capacidade computacional da mesma forma que utilizamos energia elétrica ou abastecimento de água: sob demanda, pagando apenas pelos recursos efetivamente utilizados.
Essa mudança marcou o nascimento de um dos modelos tecnológicos mais transformadores do século XXI: a Computação em Nuvem (Cloud Computing).
É importante observar que a expressão “nuvem” não significa que os dados estejam em um local indefinido ou “flutuando” na Internet. Na realidade, eles continuam armazenados em computadores físicos instalados em grandes Data Centers distribuídos pelo mundo. A diferença está na forma como esses recursos são disponibilizados. Em vez de adquirir e administrar toda a infraestrutura localmente, o usuário passa a acessá-la como um serviço oferecido por provedores especializados.
Essa mudança alterou profundamente a economia da Tecnologia da Informação. Organizações deixaram de investir grandes quantias em infraestrutura própria para consumir recursos computacionais de maneira elástica, aumentando ou reduzindo sua capacidade conforme a necessidade do negócio. Pequenas empresas passaram a utilizar recursos que, anos antes, estavam disponíveis apenas para grandes corporações. Novos modelos de negócios surgiram, startups cresceram rapidamente e aplicações passaram a atender milhões de usuários sem que seus proprietários precisassem construir enormes Data Centers.
Contudo, essa transformação levanta uma nova questão.
Se provedores conseguem disponibilizar milhares de servidores para milhões de clientes em diferentes países, como toda essa infraestrutura é organizada e administrada?
É justamente essa pergunta que conduzirá a próxima parte da aula, na qual compreenderemos como os Data Centers modernos evoluíram para se tornar a base física da Computação em Nuvem.
À medida que a infraestrutura crescia, os Data Centers também se tornavam maiores e mais complexos. Empresas que antes administravam alguns poucos servidores passaram a operar centenas ou milhares deles. A virtualização havia resolvido o problema do desperdício de hardware, mas introduziu um novo desafio: administrar um número cada vez maior de máquinas virtuais.
Imagine um provedor de serviços que atende milhares de clientes. Cada cliente pode precisar de um servidor com características diferentes. Um deseja um servidor Linux com 2 GB de memória RAM. Outro necessita de um servidor Windows com 16 GB. Um terceiro precisa de um banco de dados, enquanto outro deseja apenas espaço para armazenar arquivos.
Se cada solicitação dependesse da intervenção manual de um administrador, seria impossível atender à demanda com rapidez. Alguém precisaria criar a máquina virtual, configurar a rede, definir regras de segurança, conectar discos virtuais, instalar o sistema operacional e verificar se todos os recursos haviam sido alocados corretamente. Mesmo utilizando virtualização, esse processo ainda consumiria tempo e exigiria uma equipe numerosa.
A própria eficiência obtida com a virtualização passou, então, a evidenciar uma nova limitação. O problema já não era a capacidade do hardware, mas a forma como essa capacidade era disponibilizada aos usuários.
Começo da Solução
Foi nesse contexto que surgiu um conceito fundamental para compreendermos a Computação em Nuvem: provisionamento.
Provisionar significa disponibilizar recursos computacionais para utilização. Em um ambiente tradicional, o provisionamento de um servidor podia levar dias ou semanas, dependendo da aquisição de equipamentos, da instalação física e da configuração da infraestrutura. Em um ambiente virtualizado, esse tempo foi reduzido para horas ou minutos. Entretanto, ainda havia forte dependência da atuação humana.
A Computação em Nuvem levou essa ideia um passo adiante.
Em vez de solicitar a criação de um servidor a um administrador, o próprio usuário passou a realizar essa operação por meio de um portal web ou de uma interface de programação (API). Em poucos minutos, a infraestrutura necessária estava disponível, pronta para utilização.
Essa mudança alterou profundamente a relação entre usuários e infraestrutura computacional.
Durante décadas, os departamentos de Tecnologia da Informação funcionaram como intermediários entre a necessidade do negócio e os recursos tecnológicos. Sempre que uma nova aplicação precisava ser implantada, era necessário abrir solicitações, aguardar aprovações e acompanhar longos processos de aquisição e configuração.
Na Computação em Nuvem, grande parte dessas etapas passou a ser automatizada.
Quando um cliente solicita um novo servidor em um provedor de nuvem, não existe um técnico escolhendo manualmente um computador em um rack ou conectando cabos para atender à solicitação. Todo o processo é executado automaticamente por sistemas capazes de localizar recursos disponíveis, criar máquinas virtuais, configurar redes, alocar armazenamento e disponibilizar o ambiente em poucos minutos.
Essa automação é um dos principais fatores que diferenciam um ambiente simplesmente virtualizado de um ambiente verdadeiramente baseado em Computação em Nuvem.
Uma analogia ajuda a compreender essa diferença.
Imagine um hotel. A construção do edifício corresponde à infraestrutura física: terreno, fundações, instalações elétricas, elevadores e quartos. A virtualização seria equivalente à divisão desse edifício em apartamentos independentes, permitindo que diferentes hóspedes utilizassem a mesma estrutura sem interferir uns nos outros.
Entretanto, um hotel moderno oferece muito mais do que quartos. Existe um sistema de reservas, recepção funcionando continuamente, limpeza, manutenção, controle de acesso, faturamento e diversos serviços automatizados que permitem atender milhares de clientes diariamente.
Da mesma forma, a Computação em Nuvem não consiste apenas em máquinas virtuais executando sobre servidores físicos. Ela integra mecanismos de automação, monitoramento, gerenciamento de recursos, autenticação, faturamento e orquestração, transformando a infraestrutura em um serviço disponível sob demanda.
Essa característica explica por que provedores como Amazon Web Services (AWS), Microsoft Azure e Google Cloud conseguem atender simultaneamente milhões de clientes distribuídos por diferentes países. O segredo não está apenas na quantidade de servidores instalados em seus Data Centers, mas na capacidade de administrar toda essa infraestrutura de forma automatizada e escalável.
Nesse ponto da evolução tecnológica, a pergunta deixa de ser como criar servidores rapidamente e passa a ser outra, ainda mais importante:
Se a infraestrutura agora é oferecida como um serviço, todos os clientes precisam exatamente do mesmo tipo de serviço?
A resposta é negativa. Algumas organizações desejam controlar praticamente toda a infraestrutura, enquanto outras preferem utilizar apenas aplicações prontas, sem qualquer preocupação com servidores, sistemas operacionais ou redes.
Foi justamente para atender a essas diferentes necessidades que surgiram os modelos de serviço da Computação em Nuvem, tema que será desenvolvido na sequência natural desta aula.
Modelos de Serviço da Computação em Nuvem
Depois de compreendermos que diferentes organizações possuem necessidades distintas, torna-se evidente que oferecer exatamente o mesmo tipo de infraestrutura para todos os clientes seria pouco eficiente. Uma startup que está desenvolvendo seu primeiro sistema possui demandas completamente diferentes das de um banco, de uma universidade ou de uma empresa multinacional. Enquanto algumas organizações desejam controlar cada detalhe da infraestrutura, outras preferem concentrar seus esforços exclusivamente no desenvolvimento de aplicações ou na prestação de seus serviços.
Foi dessa diversidade de necessidades que surgiram os modelos de serviço da Computação em Nuvem. Em vez de disponibilizar um único produto, os provedores passaram a oferecer diferentes níveis de abstração, permitindo que cada cliente escolhesse quanto da infraestrutura deseja administrar e quanto pretende delegar ao provedor.
Antes de estudarmos cada modelo, vale refletir sobre uma situação bastante comum.
Imagine que uma empresa pretenda criar um sistema para gerenciamento de uma clínica médica. Seus desenvolvedores dominam programação, conhecem bancos de dados e entendem as regras do negócio. Entretanto, eles não possuem interesse em administrar servidores físicos, configurar switches, instalar sistemas operacionais ou monitorar discos rígidos. O objetivo da empresa é desenvolver uma aplicação, e não construir um Data Center.
Agora imagine outro cenário. Uma instituição financeira precisa cumprir rigorosos requisitos legais e de segurança. Ela deseja escolher o sistema operacional, definir políticas de acesso, configurar redes privadas, instalar ferramentas específicas de monitoramento e controlar todos os componentes da infraestrutura. Nesse caso, entregar apenas uma aplicação pronta não atenderia às suas necessidades.
Perceba que ambos os clientes utilizam Computação em Nuvem, mas esperam níveis completamente diferentes de controle sobre os recursos computacionais.
É justamente para atender a essas diferenças que os provedores estruturaram seus serviços em camadas.
Essas camadas costumam ser representadas por três modelos fundamentais:
- Infraestrutura como Serviço (Infrastructure as a Service – IaaS);
- Plataforma como Serviço (Platform as a Service – PaaS);
- Software como Serviço (Software as a Service – SaaS).
Embora sejam apresentados separadamente para facilitar o estudo, esses modelos não competem entre si. Pelo contrário, eles se complementam. Cada um atende a um perfil específico de usuário e resolve um conjunto diferente de problemas.
Uma analogia ajuda a compreender essa organização.
Imagine a construção de uma casa.
Algumas pessoas desejam comprar apenas o terreno e conduzir toda a obra, escolhendo materiais, contratando profissionais e acompanhando cada etapa da construção. Outras preferem adquirir uma casa já pronta, realizando apenas pequenas adaptações. Há ainda quem opte por morar em um hotel, utilizando toda a infraestrutura existente sem qualquer preocupação com manutenção, limpeza ou segurança.
Na Computação em Nuvem ocorre algo semelhante. Alguns clientes querem controlar toda a infraestrutura; outros desejam apenas um ambiente para desenvolver aplicações; e muitos preferem utilizar um software pronto, acessível por um navegador ou aplicativo, sem sequer saber onde ele está instalado.
Essa analogia evidencia um aspecto essencial: à medida que avançamos de IaaS para SaaS, diminui a responsabilidade do cliente sobre a infraestrutura e aumenta a responsabilidade do provedor.
Essa relação entre responsabilidades será o ponto de partida para compreender o primeiro modelo de serviço, Infraestrutura como Serviço (IaaS), no qual o cliente mantém amplo controle sobre o ambiente computacional, enquanto o provedor fornece a infraestrutura física necessária para sua operação.
Responsabilidades Compartilhadas: o primeiro nível da Computação em Nuvem
A possibilidade de contratar infraestrutura sob demanda representou uma mudança profunda na forma de consumir recursos computacionais. Entretanto, disponibilizar servidores pela Internet não significa que todas as responsabilidades passem automaticamente para o provedor.
Pense em uma empresa que decide migrar seus sistemas para a nuvem. Ela continua precisando definir quais aplicações serão executadas, quais usuários terão acesso aos serviços, quais políticas de segurança deverão ser adotadas e como seus dados serão protegidos. Ao mesmo tempo, deixa de se preocupar com atividades como a aquisição de servidores, substituição de componentes defeituosos, fornecimento de energia elétrica, climatização do Data Center e manutenção da infraestrutura física.
Perceba que existe uma divisão de responsabilidades.
Quanto maior for o controle desejado pelo cliente, maior será também sua responsabilidade pela administração do ambiente. Por outro lado, quanto mais serviços forem delegados ao provedor, menor será a necessidade de gerenciar aspectos técnicos da infraestrutura.
Essa divisão é conhecida como modelo de responsabilidade compartilhada e está presente em praticamente todos os serviços de Computação em Nuvem. Embora cada provedor possua pequenas diferenças em sua implementação, o princípio permanece o mesmo: cliente e provedor colaboram para manter o ambiente funcionando de forma segura, eficiente e disponível.
Essa forma de organização beneficia ambos os lados. O provedor especializa-se na operação de grandes infraestruturas, alcançando níveis de eficiência dificilmente obtidos por organizações isoladas. Já o cliente pode concentrar seus esforços nas atividades relacionadas ao seu negócio, utilizando apenas os recursos computacionais de que realmente necessita.
Entretanto, nem todas as organizações desejam abrir mão do mesmo nível de controle. Algumas precisam instalar sistemas operacionais específicos, configurar redes complexas, criar políticas próprias de segurança e administrar bancos de dados corporativos. Para essas situações, o modelo mais adequado é aquele que oferece infraestrutura praticamente “em branco”, permitindo que o cliente construa seu ambiente conforme suas necessidades.
Esse modelo recebe o nome de Infraestrutura como Serviço, ou Infrastructure as a Service (IaaS).
Infraestrutura como Serviço (IaaS)
No modelo IaaS, o provedor disponibiliza os recursos fundamentais da infraestrutura computacional, como processamento, memória, armazenamento e conectividade de rede. Esses recursos são apresentados ao cliente como máquinas virtuais, volumes de armazenamento, redes virtuais e outros componentes básicos, prontos para serem configurados.
A partir desse ponto, a administração do ambiente passa a ser responsabilidade do cliente. Ele escolhe o sistema operacional, instala aplicações, configura serviços, define políticas de segurança e administra os usuários. Em outras palavras, recebe um ambiente flexível, semelhante a um servidor físico tradicional, mas sem precisar investir na aquisição e manutenção do hardware.
Essa abordagem oferece elevado grau de liberdade e é amplamente utilizada por organizações que necessitam de ambientes personalizados ou que desejam migrar aplicações existentes para a nuvem com poucas adaptações.
Uma analogia ajuda a compreender esse modelo.
Imagine que uma empresa alugue um galpão industrial completamente equipado com energia elétrica, abastecimento de água, climatização e acesso viário. O proprietário do imóvel garante que toda a infraestrutura esteja disponível e funcionando. Entretanto, cabe à empresa instalar suas máquinas, organizar o espaço interno, definir os processos de produção e administrar seus funcionários.
No IaaS ocorre exatamente essa divisão. O provedor entrega uma infraestrutura pronta para uso; o cliente é responsável por transformá-la no ambiente necessário para executar suas aplicações.
Essa característica explica por que o IaaS costuma ser escolhido por administradores de redes, equipes de infraestrutura e profissionais de DevOps. Eles mantêm amplo controle sobre o ambiente computacional, preservando a flexibilidade necessária para implantar soluções específicas.
Contudo, essa liberdade também aumenta a quantidade de atividades sob responsabilidade da equipe técnica. Instalar sistemas operacionais, aplicar atualizações, monitorar servidores e configurar serviços continuam fazendo parte da rotina administrativa.
Essa constatação conduz naturalmente à próxima questão:
Seria possível manter a flexibilidade da Computação em Nuvem sem que o cliente precisasse administrar sistemas operacionais e toda a infraestrutura de suporte?
A resposta para essa pergunta levou ao surgimento do segundo modelo de serviço, Plataforma como Serviço (Platform as a Service – PaaS), que estudaremos na sequência.
Plataforma como Serviço (PaaS)
Para muitas organizações, administrar servidores não representa um objetivo, mas apenas uma etapa necessária para executar suas aplicações. Desenvolvedores de software, por exemplo, desejam dedicar seu tempo à criação de novos sistemas, à implementação de funcionalidades e à correção de problemas de programação. Atividades como instalar sistemas operacionais, aplicar atualizações de segurança, configurar servidores web ou administrar bancos de dados normalmente não fazem parte do produto que será entregue ao cliente.
Esse cenário levou os provedores de Computação em Nuvem a desenvolver um modelo intermediário entre a infraestrutura totalmente administrada pelo cliente e o software completamente pronto para uso.
Em vez de disponibilizar apenas máquinas virtuais, o provedor passou a oferecer uma plataforma de desenvolvimento já preparada, contendo os principais componentes necessários para executar aplicações. O cliente não precisa instalar ou manter o sistema operacional, configurar servidores de aplicação ou administrar boa parte da infraestrutura. Sua principal responsabilidade passa a ser o desenvolvimento, a implantação e a manutenção do próprio software.
Esse modelo recebe o nome de Plataforma como Serviço, ou Platform as a Service (PaaS).
Ao assumir a administração desses componentes, o provedor reduz significativamente a complexidade operacional enfrentada pelas equipes de desenvolvimento. Atualizações de segurança, aplicação de correções, gerenciamento de disponibilidade e manutenção do ambiente passam a ser executados automaticamente, permitindo que os profissionais concentrem seus esforços na criação de soluções para o negócio.
Essa mudança altera profundamente o fluxo de trabalho das equipes de desenvolvimento.
Em um ambiente IaaS, antes de implantar uma aplicação é necessário preparar toda a infraestrutura: criar máquinas virtuais, instalar o sistema operacional, configurar servidores web, ajustar permissões, instalar bibliotecas e garantir que todos os componentes estejam funcionando corretamente.
No modelo PaaS, grande parte dessas etapas desaparece. O desenvolvedor apenas envia sua aplicação para a plataforma, que automaticamente disponibiliza os recursos necessários para sua execução.
Uma analogia ajuda a compreender essa diferença.
Imagine um chef de cozinha que deseja abrir um restaurante.
No modelo equivalente ao IaaS, ele recebe um prédio vazio. Cabe a ele instalar equipamentos, montar a cozinha, contratar equipes de manutenção, providenciar gás, energia, utensílios e organizar toda a infraestrutura antes de preparar o primeiro prato.
No modelo equivalente ao PaaS, a cozinha já está completamente equipada e pronta para funcionar. Fogões, fornos, bancadas, utensílios e sistemas de exaustão já foram instalados e testados. O chef pode dedicar-se imediatamente àquilo que realmente importa: criar receitas e atender seus clientes.
Da mesma forma, o PaaS entrega um ambiente preparado para que desenvolvedores concentrem seus esforços na construção de aplicações, deixando a administração da plataforma sob responsabilidade do provedor.
Esse modelo tornou-se especialmente popular em organizações que desenvolvem sistemas continuamente, adotando metodologias ágeis e processos de integração e entrega contínuas (CI/CD). Como a infraestrutura é administrada pelo provedor, novas versões das aplicações podem ser publicadas com rapidez e segurança, reduzindo o tempo entre o desenvolvimento e a disponibilização de novas funcionalidades aos usuários.
Entretanto, ainda existe um grupo de usuários para os quais até mesmo desenvolver aplicações representa uma atividade desnecessária. Muitas organizações precisam apenas utilizar um sistema pronto, acessível por meio de um navegador ou aplicativo, sem qualquer preocupação com servidores, plataformas de desenvolvimento ou infraestrutura.
Essa necessidade levou ao surgimento do nível mais elevado de abstração da Computação em Nuvem: o Software como Serviço (Software as a Service – SaaS).
Software como Serviço (SaaS)
Ao longo da evolução da Computação em Nuvem, observamos um movimento contínuo de transferência de responsabilidades do cliente para o provedor. No modelo IaaS, o cliente ainda administra sistemas operacionais e aplicações. No PaaS, concentra-se apenas no desenvolvimento do software. Entretanto, existe um número muito maior de organizações e usuários cujo objetivo não é desenvolver sistemas, mas simplesmente utilizá-los.
Uma escola que deseja registrar matrículas, uma clínica que precisa agendar consultas, uma empresa que administra sua folha de pagamento ou um profissional que utiliza correio eletrônico não pretendem instalar servidores, configurar bancos de dados ou acompanhar atualizações de sistemas operacionais. O que realmente lhes interessa é executar suas atividades com segurança, disponibilidade e desempenho.
Esse cenário impulsionou o desenvolvimento do Software como Serviço, conhecido pela sigla SaaS (Software as a Service).
Nesse modelo, o provedor entrega ao cliente uma aplicação completa, pronta para utilização. Toda a infraestrutura necessária para executar esse software permanece sob responsabilidade do provedor, incluindo servidores físicos, virtualização, sistemas operacionais, bancos de dados, mecanismos de segurança, atualizações e monitoramento.
O usuário precisa apenas acessar o serviço, normalmente por meio de um navegador Web ou de um aplicativo instalado em seu computador ou dispositivo móvel.
Essa mudança simplificou profundamente o acesso à tecnologia. Em vez de adquirir licenças, instalar programas em cada computador e manter equipes especializadas para realizar atualizações, as organizações passaram a utilizar aplicações continuamente atualizadas pelo próprio fornecedor.
Sempre que um usuário acessa um serviço de e-mail corporativo, participa de uma videoconferência, utiliza um ambiente virtual de aprendizagem, edita documentos colaborativamente ou registra informações em um sistema de gestão empresarial hospedado na nuvem, está utilizando uma solução baseada no modelo SaaS.
Redes no Mundo Real
Diversos serviços amplamente utilizados seguem esse modelo, entre eles:
- Microsoft 365.
- Google Workspace.
- Salesforce.
- Moodle Cloud.
- Dropbox.
- Trello.
- Canva.
Embora possuam finalidades distintas, todos compartilham uma característica comum: o usuário utiliza o software sem administrar a infraestrutura necessária para executá-lo.
A principal vantagem do SaaS é permitir que pessoas e organizações concentrem seus esforços em suas atividades-fim. O provedor assume praticamente toda a complexidade técnica relacionada à infraestrutura, enquanto o cliente utiliza apenas as funcionalidades oferecidas pela aplicação.
Entretanto, essa simplicidade possui um contraponto importante. Como a administração da plataforma permanece sob responsabilidade do provedor, o cliente dispõe de menor liberdade para realizar personalizações profundas no ambiente. Em muitos casos, é possível configurar parâmetros da aplicação, criar usuários e definir permissões, mas não modificar componentes internos do sistema ou escolher versões específicas do banco de dados e do sistema operacional.
Essa característica evidencia um aspecto fundamental da Computação em Nuvem: quanto maior o nível de abstração oferecido pelo serviço, menor tende a ser o controle direto exercido pelo cliente sobre a infraestrutura.
Comparando os modelos de serviço
Agora que conhecemos os três principais modelos, torna-se mais fácil compreender como eles se relacionam.
| Aspecto | IaaS | PaaS | SaaS |
| Controle do cliente | Alto | Médio | Baixo |
| Administração do sistema operacional | Cliente | Provedor | Provedor |
| Desenvolvimento de aplicações | Opcional | Principal atividade | Não se aplica |
| Aplicação pronta para uso | Não | Não | Sim |
| Flexibilidade | Muito alta | Alta | Limitada à configuração da aplicação |
| Perfil típico | Administradores de infraestrutura e DevOps | Desenvolvedores | Usuários finais e organizações consumidoras de software |
A tabela deixa claro que nenhum modelo é superior aos demais. Cada um foi concebido para atender necessidades específicas. A escolha depende do nível de controle desejado, das competências técnicas disponíveis e dos objetivos da organização.
Ao observar essa evolução, percebemos que a Computação em Nuvem não consiste em uma única tecnologia, mas em um conjunto de serviços organizados em diferentes níveis de abstração. Todos eles compartilham a mesma infraestrutura física, porém oferecem experiências distintas aos seus usuários.
Essa constatação conduz naturalmente ao próximo tema da aula.
Independentemente do modelo de serviço utilizado, todos eles dependem de uma infraestrutura distribuída globalmente, composta por Data Centers estrategicamente posicionados, regiões geográficas, zonas de disponibilidade e mecanismos de redundância capazes de manter os serviços funcionando continuamente. Compreender essa arquitetura permitirá explicar por que aplicações hospedadas na nuvem conseguem oferecer elevados níveis de disponibilidade, desempenho e tolerância a falhas.
A infraestrutura invisível da Computação em Nuvem
Ao observarmos os modelos IaaS, PaaS e SaaS, percebemos que eles representam diferentes formas de consumir recursos computacionais. Em todos os casos, entretanto, existe uma característica comum: nenhum desses serviços existe de forma abstrata.
Quando um usuário cria uma máquina virtual, publica uma aplicação ou acessa um software em um navegador, há sempre uma infraestrutura física executando essas operações. Processadores realizam cálculos, memórias armazenam informações temporárias, discos gravam dados e equipamentos de rede encaminham milhões de pacotes por segundo.
Em outras palavras, a “nuvem” não elimina os computadores. Ela apenas torna sua existência praticamente invisível para quem utiliza os serviços.
Essa invisibilidade constitui um dos maiores êxitos da Computação em Nuvem. O usuário concentra sua atenção naquilo que realmente deseja realizar, enquanto toda a complexidade da infraestrutura permanece administrada pelo provedor.
Essa separação entre consumo e infraestrutura alterou profundamente a maneira como os profissionais de Tecnologia da Informação passaram a enxergar os recursos computacionais.
Durante décadas, possuir infraestrutura significava comprar servidores, instalar equipamentos em salas climatizadas, manter equipes de suporte e planejar expansões de capacidade. Na Computação em Nuvem, possuir infraestrutura deixou de ser um requisito para utilizar infraestrutura.
O recurso computacional passou a ser tratado como um serviço.
Entretanto, essa mudança levanta uma questão importante.
Se milhões de pessoas utilizam simultaneamente os mesmos provedores de Computação em Nuvem, onde toda essa infraestrutura está instalada?
A resposta não é “na Internet”, como frequentemente se imagina.
Ela está distribuída em instalações altamente especializadas conhecidas como Data Centers.
Data Centers: o alicerce físico da nuvem
Embora a expressão Computação em Nuvem sugira algo intangível, toda operação realizada na nuvem depende de instalações físicas cuidadosamente projetadas.
Um Data Center é uma instalação construída para hospedar grandes quantidades de equipamentos computacionais, oferecendo as condições necessárias para que funcionem continuamente, com segurança, desempenho e elevada disponibilidade.
Muito mais do que um edifício repleto de servidores, um Data Center moderno integra diversos subsistemas que trabalham de forma coordenada. A indisponibilidade de qualquer um deles pode comprometer milhares ou até milhões de usuários.
Entre seus principais componentes destacam-se:
- Servidores de alto desempenho.
- Sistemas de armazenamento distribuído.
- Equipamentos de rede de alta capacidade.
- Fontes redundantes de energia.
- Geradores e bancos de baterias (UPS).
- Sistemas de climatização de precisão.
- Monitoramento ambiental contínuo.
- Controle rigoroso de acesso físico.
- Sistemas automáticos de detecção e combate a incêndio.
Observe que diversos componentes dessa lista não executam aplicações nem armazenam dados diretamente. Mesmo assim, são essenciais para o funcionamento da infraestrutura.
Imagine um hospital que perde o fornecimento de energia elétrica durante uma cirurgia. Ou um aeroporto cujo sistema de climatização deixa de funcionar em sua sala de equipamentos. Em ambos os casos, o problema não está nos computadores, mas na infraestrutura que os mantém operando.
Nos Data Centers ocorre exatamente o mesmo.
Um servidor de última geração torna-se inútil se faltar energia, se a temperatura ultrapassar os limites seguros de operação ou se uma falha de rede impedir sua comunicação com os demais equipamentos.
Por esse motivo, provedores de Computação em Nuvem projetam seus Data Centers considerando que falhas podem ocorrer a qualquer momento. Em vez de tentar impedir completamente essas falhas, a arquitetura é concebida para continuar funcionando mesmo quando parte da infraestrutura apresenta problemas.
Essa filosofia de projeto conduz ao próximo conceito da nossa jornada.
Não basta possuir grandes Data Centers. É necessário distribuí-los estrategicamente e organizá-los de forma que uma interrupção em um local não comprometa a continuidade dos serviços.
Foi dessa necessidade que surgiram os conceitos de regiões geográficas (Regions) e zonas de disponibilidade (Availability Zones), fundamentais para compreender como os provedores modernos oferecem elevados níveis de disponibilidade e tolerância a falhas.
Quando um único Data Center deixa de ser suficiente
Imagine que toda a infraestrutura de um grande provedor de Computação em Nuvem estivesse concentrada em um único Data Center.
À primeira vista, essa solução poderia parecer suficiente. Afinal, instalações modernas dispõem de milhares de servidores, sistemas redundantes de energia, enlaces de comunicação de alta velocidade e equipes técnicas especializadas.
Entretanto, mesmo a infraestrutura mais sofisticada está sujeita a eventos inesperados.
Uma interrupção prolongada no fornecimento de energia, um incêndio, uma inundação, um desastre natural ou uma falha grave na rede de telecomunicações podem comprometer parcial ou totalmente o funcionamento de uma instalação. Embora esses eventos sejam pouco frequentes, seu impacto pode ser significativo quando toda a operação depende de um único local.
Para provedores que atendem milhões de usuários simultaneamente, essa dependência representa um risco inaceitável.
A disponibilidade de um serviço em nuvem não depende apenas da confiabilidade dos equipamentos instalados em um Data Center. Ela depende, principalmente, da capacidade de continuar operando mesmo quando parte da infraestrutura apresenta problemas.
Em outras palavras, a pergunta deixa de ser:
“Como construir um Data Center extremamente confiável?”
e passa a ser:
“Como continuar oferecendo o serviço mesmo que um Data Center inteiro fique indisponível?”
Essa mudança de perspectiva representa um dos princípios fundamentais da arquitetura moderna de Computação em Nuvem.
Essa estratégia não é nova.
Na Aula 01 estudamos que um dos princípios que orientaram o desenvolvimento da ARPANET foi justamente eliminar pontos únicos de falha (Single Point of Failure). Em vez de concentrar toda a comunicação em um único equipamento, a rede foi projetada para continuar funcionando mesmo quando parte de sua infraestrutura estivesse indisponível.
Décadas depois, a Computação em Nuvem passou a aplicar exatamente o mesmo princípio em escala muito maior.
Em vez de concentrar toda a infraestrutura em um único local, os provedores passaram a distribuí-la geograficamente.
Foi dessa necessidade que surgiu o conceito de Região (Region).
Regiões: distribuindo a infraestrutura pelo mundo
Uma Região corresponde a uma área geográfica específica onde um provedor mantém infraestrutura própria para oferecer seus serviços.
Dependendo do provedor, uma região pode atender um país inteiro, um conjunto de estados ou uma grande área metropolitana estrategicamente escolhida.
Cada região opera de forma relativamente independente das demais, possuindo capacidade própria de processamento, armazenamento, conectividade e gerenciamento.
Essa organização oferece diversas vantagens.
Entre elas destacam-se:
- Redução da latência para usuários localizados próximos à região.
- Maior conformidade com legislações nacionais sobre armazenamento de dados.
- Distribuição da carga de processamento entre diferentes localidades.
- Continuidade dos serviços em caso de indisponibilidade de outra região.
Entretanto, distribuir a infraestrutura entre diferentes regiões resolve apenas parte do problema.
Imagine que toda a infraestrutura de uma determinada região estivesse instalada em um único edifício.
Embora outra região pudesse assumir parte das operações em caso de desastre, uma interrupção local ainda afetaria significativamente os usuários atendidos por aquela região.
Os provedores perceberam que era necessário ir além.
Não bastava distribuir a infraestrutura entre cidades ou países diferentes. Também era preciso evitar que todos os recursos de uma mesma região dependessem de um único Data Center.
A solução foi dividir cada região em unidades menores, fisicamente separadas, mas interligadas por redes de altíssima velocidade.
Essas unidades recebem o nome de Zonas de Disponibilidade (Availability Zones).
Ao separar fisicamente esses Data Centers, os provedores reduzem significativamente a probabilidade de que um único evento comprometa toda a região.
Entretanto, essa estratégia só produz os resultados esperados quando as aplicações também são distribuídas entre diferentes Zonas de Disponibilidade. É justamente essa distribuição inteligente dos serviços que permite alcançar elevados níveis de disponibilidade e tolerância a falhas.
Esse será o próximo passo da nossa jornada, quando compreenderemos como a redundância e o balanceamento de carga trabalham em conjunto para manter aplicações acessíveis mesmo diante de falhas inesperadas.
Redundância: preparando a infraestrutura para falhar
Até este ponto, compreendemos que grandes provedores distribuem sua infraestrutura entre diferentes Regiões e Zonas de Disponibilidade. Entretanto, simplesmente possuir vários Data Centers não garante, por si só, a continuidade dos serviços.
Imagine que uma aplicação esteja sendo executada apenas em uma única Zona de Disponibilidade. Mesmo que existam outras zonas na mesma região, uma falha naquele ambiente específico interromperá o funcionamento da aplicação até que ela seja restaurada ou migrada para outro local.
Perceba que a existência de infraestrutura alternativa não é suficiente.
É necessário que essa infraestrutura esteja preparada para assumir o funcionamento do serviço sempre que necessário.
Essa estratégia recebe o nome de redundância.
Em Tecnologia da Informação, redundância significa manter recursos adicionais capazes de substituir imediatamente aqueles que deixarem de funcionar. Esses recursos podem envolver servidores, enlaces de comunicação, sistemas de armazenamento, equipamentos de rede, fontes de alimentação e até mesmo Data Centers inteiros.
Em um primeiro momento, pode parecer contraditório investir em equipamentos que permanecerão parcialmente ociosos durante grande parte do tempo. Entretanto, quando o objetivo é garantir a continuidade de serviços essenciais, a redundância deixa de representar desperdício e passa a constituir um investimento em disponibilidade.
A redundância pode ser implementada em diferentes níveis.
Alguns exemplos incluem:
- Fontes de alimentação duplicadas em um mesmo servidor.
- Múltiplos enlaces de comunicação conectando um Data Center à Internet.
- Sistemas de armazenamento replicados em equipamentos distintos.
- Servidores executando simultaneamente a mesma aplicação.
- Cópias de dados distribuídas entre diferentes Zonas de Disponibilidade.
- Replicação entre Regiões geograficamente separadas.
Observe que todos esses mecanismos possuem um objetivo comum: eliminar pontos únicos de falha (Single Point of Failure).
Esse princípio já havia aparecido quando estudamos a ARPANET. Naquela ocasião, a preocupação era manter a comunicação funcionando mesmo diante da indisponibilidade de parte da rede. Na Computação em Nuvem, o mesmo conceito é aplicado em uma escala muito maior, abrangendo não apenas redes, mas toda a infraestrutura computacional.
Conectando Ideias
Na Aula 01 vimos que a arquitetura distribuída da ARPANET buscava garantir que a perda de um nó não interrompesse completamente a comunicação. Na Aula 02 observamos que a virtualização permitiu distribuir diferentes serviços em máquinas independentes. Agora percebemos que a Computação em Nuvem amplia essa lógica, distribuindo aplicações, armazenamento e recursos entre múltiplas infraestruturas físicas.
A evolução das Redes de Computadores revela um padrão recorrente: reduzir dependências e aumentar a capacidade de continuar operando diante de falhas.
Entretanto, manter componentes redundantes não significa que a aplicação continuará funcionando automaticamente.
Se um servidor deixar de responder, alguém ou algum mecanismo precisará identificar o problema e direcionar os usuários para os recursos que permanecem disponíveis.
Essa capacidade de continuar oferecendo o serviço, mesmo quando parte da infraestrutura apresenta falhas, é conhecida como tolerância a falhas.
Tolerância a falhas: quando a interrupção deixa de ser um desastre
Uma infraestrutura tolerante a falhas é projetada para continuar funcionando mesmo quando componentes individuais deixam de operar corretamente.
Isso não significa que falhas deixarão de existir.
Ao contrário, parte-se do princípio de que elas são inevitáveis.
Servidores podem apresentar defeitos de hardware. Discos podem falhar. Enlaces podem ser interrompidos. Atualizações podem introduzir erros inesperados. Até mesmo desastres naturais podem comprometer instalações inteiras.
A diferença está na forma como a infraestrutura reage a esses eventos.
Em vez de interromper completamente os serviços, mecanismos automáticos identificam a indisponibilidade, ativam recursos redundantes e restabelecem rapidamente a operação.
Para o usuário final, muitas dessas transições ocorrem de forma praticamente imperceptível.
Embora esse processo pareça simples quando observado em um diagrama, ele depende da atuação coordenada de diversos mecanismos de monitoramento, sincronização e distribuição de carga.
É justamente esse último componente que estudaremos na sequência.
Afinal, como decidir para qual servidor cada nova requisição deverá ser enviada quando vários servidores estão disponíveis simultaneamente?
Essa pergunta conduz naturalmente ao conceito de balanceamento de carga, que representa o próximo passo na construção de uma infraestrutura altamente disponível.
Balanceamento de carga: distribuindo o trabalho de forma inteligente
Quando uma aplicação passa a ser executada em vários servidores ao mesmo tempo, surge um novo desafio. Se todos os usuários continuarem enviando suas solicitações para um único servidor, os demais permanecerão praticamente ociosos, desperdiçando recursos computacionais e reduzindo a eficiência da infraestrutura.
Perceba que a simples existência de múltiplos servidores não garante melhor desempenho. É necessário distribuir as requisições de maneira equilibrada, aproveitando a capacidade disponível em toda a infraestrutura.
Essa função é desempenhada pelo balanceador de carga (Load Balancer).
Em termos gerais, um balanceador de carga é um componente responsável por receber as solicitações dos usuários e decidir para qual servidor cada requisição será encaminhada. Em vez de permitir que todos os acessos sejam direcionados a um único equipamento, ele distribui automaticamente o trabalho entre vários servidores capazes de executar a mesma aplicação.
Para o usuário, esse processo ocorre de forma completamente transparente. Ao acessar um site, um sistema corporativo ou um serviço em nuvem, ele normalmente não percebe que sua requisição pode ser atendida por qualquer um entre dezenas ou centenas de servidores diferentes.
O balanceamento de carga oferece benefícios que vão além da melhoria do desempenho.
Entre os principais destacam-se:
- Distribuição equilibrada das requisições entre os servidores.
- Melhor aproveitamento dos recursos computacionais.
- Redução da sobrecarga em equipamentos individuais.
- Maior capacidade de atendimento durante períodos de pico.
- Continuidade do serviço quando um servidor deixa de responder.
Observe que o último benefício estabelece uma ligação direta com o conceito estudado anteriormente.
Quando um servidor apresenta falha, o balanceador de carga pode interromper automaticamente o envio de novas requisições para esse equipamento e redirecioná-las aos servidores que permanecem operacionais. Dessa forma, a indisponibilidade de um componente deixa de provocar a interrupção completa do serviço.
Conectando Ideias
A redundância garante que existam recursos alternativos. A tolerância a falhas permite que o sistema continue funcionando quando ocorre uma interrupção. O balanceamento de carga integra esses elementos, distribuindo continuamente as requisições e direcionando os usuários apenas para servidores disponíveis.
Esses três mecanismos trabalham de forma complementar e constituem a base das arquiteturas modernas de alta disponibilidade.
Uma analogia ajuda a compreender esse funcionamento.
Imagine um grande supermercado com diversos caixas funcionando simultaneamente. Se todos os clientes insistirem em utilizar apenas um caixa, formar-se-á uma longa fila enquanto os demais permanecem vazios. Para evitar esse problema, um funcionário orienta cada novo cliente para o caixa com menor tempo de espera.
O balanceador de carga exerce exatamente esse papel. Ele organiza o fluxo de requisições para que nenhum servidor fique sobrecarregado enquanto outros permanecem subutilizados.
Embora o balanceamento de carga resolva o problema da distribuição das requisições, ainda existe uma situação que precisa ser considerada.
Imagine que uma aplicação se torne extremamente popular e o número de usuários continue crescendo. Mesmo distribuindo perfeitamente as requisições, chegará um momento em que toda a infraestrutura disponível será insuficiente para atender à demanda.
Nesse ponto, distribuir melhor os recursos existentes deixa de ser suficiente.
Será necessário aumentar a capacidade da própria infraestrutura.
É justamente essa necessidade que conduz ao próximo conceito da nossa jornada: escalabilidade.
Escalabilidade: crescendo conforme a demanda
Uma das características mais marcantes da Computação em Nuvem é a capacidade de adaptar seus recursos às necessidades do momento.
Em ambientes tradicionais, o aumento da capacidade computacional frequentemente exigia a compra de novos servidores, expansão do espaço físico, adequação da infraestrutura elétrica e instalação de equipamentos adicionais. Esse processo podia levar semanas ou até meses.
Na Computação em Nuvem, esse crescimento pode ocorrer de forma muito mais rápida e, em muitos casos, automática.
Essa capacidade recebe o nome de escalabilidade.
Escalar significa aumentar ou reduzir os recursos computacionais de acordo com a demanda da aplicação, evitando tanto a sobrecarga quanto o desperdício de infraestrutura.
Existem duas estratégias principais para ampliar a capacidade de uma aplicação.
A primeira consiste em tornar um servidor individual mais poderoso. A segunda consiste em aumentar a quantidade de servidores disponíveis.
Essas abordagens são conhecidas, respectivamente, como escalabilidade vertical e escalabilidade horizontal, conceitos que aprofundaremos no próximo trecho, concluindo o arco principal desta aula.
Escalabilidade vertical e horizontal: duas estratégias para crescer
Ao afirmar que uma infraestrutura precisa ser escalável, ainda não respondemos como esse crescimento ocorre na prática. Existem duas estratégias fundamentais para ampliar a capacidade de uma aplicação: aumentar o poder de um servidor existente ou distribuir a carga entre vários servidores.
Embora ambas tenham o mesmo objetivo, elas seguem abordagens bastante diferentes e atendem a necessidades distintas.
Escalabilidade vertical (Scale Up)
A estratégia mais intuitiva consiste em tornar um servidor individual mais poderoso. Em vez de adicionar novos equipamentos, amplia-se a capacidade do servidor já existente.
Isso pode ser feito, por exemplo, por meio da instalação de mais memória RAM, processadores mais rápidos, unidades de armazenamento de maior desempenho ou interfaces de rede com maior largura de banda.
Em ambientes virtualizados e em Computação em Nuvem, esse processo frequentemente ocorre de maneira bastante simples. Um administrador pode aumentar a quantidade de memória ou de núcleos virtuais de uma máquina, muitas vezes sem necessidade de substituir o hardware físico.
A principal vantagem dessa abordagem é sua simplicidade. Como a aplicação continua sendo executada no mesmo servidor, normalmente são necessárias poucas alterações na arquitetura do sistema.
Entretanto, essa estratégia possui um limite físico.
Chegará um momento em que não será possível instalar mais memória, adicionar novos processadores ou ampliar indefinidamente a capacidade do equipamento. Além disso, concentrar toda a aplicação em um único servidor aumenta a dependência desse equipamento.
Mesmo extremamente potente, ele continua representando um ponto potencial de falha.
Analogia – Reformando uma loja
Imagine uma pequena loja que começa a receber um número crescente de clientes.
Uma possibilidade consiste em ampliar o próprio estabelecimento: aumentar a área de atendimento, instalar mais caixas, contratar mais funcionários e expandir o estoque.
A loja continua sendo a mesma, apenas maior e mais capaz de atender um número superior de clientes.
A escalabilidade vertical segue exatamente essa lógica. O ambiente permanece concentrado em um único servidor, que recebe recursos adicionais para suportar uma carga de trabalho maior.
Escalabilidade horizontal (Scale Out)
Quando aumentar continuamente a capacidade de um único servidor deixa de ser suficiente, surge uma alternativa diferente.
Em vez de fortalecer um equipamento individual, adicionam-se novos servidores ao ambiente, distribuindo as requisições entre eles por meio de balanceadores de carga.
Essa abordagem caracteriza a escalabilidade horizontal.
Em uma arquitetura horizontal, cada novo servidor amplia a capacidade total da infraestrutura. Caso a demanda continue crescendo, basta incorporar novos equipamentos ao conjunto existente.
Essa estratégia tornou-se a base da Computação em Nuvem moderna.
Em vez de depender de um único servidor extremamente poderoso, os provedores preferem construir grandes conjuntos de servidores trabalhando cooperativamente. Se um equipamento apresentar falha, os demais continuam atendendo às requisições enquanto outro servidor é incorporado ao ambiente.
Perceba como esse modelo reúne todos os conceitos estudados anteriormente.
A infraestrutura é distribuída entre diferentes Regiões e Zonas de Disponibilidade. Os recursos redundantes garantem alternativas em caso de falha. Os mecanismos de tolerância a falhas mantêm os serviços disponíveis. Os balanceadores de carga distribuem as requisições entre os servidores. Finalmente, a escalabilidade horizontal permite aumentar continuamente a capacidade da infraestrutura conforme a demanda.
Comparando as duas estratégias
| Característica | Escalabilidade Vertical | Escalabilidade Horizontal |
| Estratégia | Aumentar os recursos de um único servidor | Adicionar novos servidores |
| Crescimento | Limitado pelo hardware disponível | Elevado, com expansão gradual |
| Complexidade | Menor | Maior |
| Dependência de um único equipamento | Alta | Baixa |
| Integração com balanceamento de carga | Geralmente não necessária | Essencial |
| Uso típico | Aplicações monolíticas ou ambientes menores | Aplicações distribuídas e Computação em Nuvem |
Redes no Mundo Real
Grandes plataformas digitais, como serviços de streaming, comércio eletrônico e redes sociais, atendem milhões de usuários simultaneamente porque utilizam arquiteturas distribuídas baseadas predominantemente em escalabilidade horizontal. Em períodos de grande demanda, novos servidores podem ser adicionados automaticamente ao ambiente e removidos quando o tráfego retorna aos níveis habituais.
Conectando Ideias
Ao longo desta aula, acompanhamos uma sequência lógica de evolução tecnológica.
Tudo começou com a necessidade de utilizar melhor os recursos dos servidores, o que levou à virtualização. Em seguida, a automação transformou a criação desses recursos em um processo rápido e eficiente. A Computação em Nuvem ampliou essa ideia ao disponibilizar infraestrutura como serviço. Para garantir disponibilidade global, os provedores distribuíram seus Data Centers em Regiões e Zonas de Disponibilidade. A redundância, a tolerância a falhas e o balanceamento de carga permitiram manter os serviços funcionando continuamente. Finalmente, a escalabilidade tornou possível adaptar automaticamente a capacidade da infraestrutura ao crescimento da demanda.
Perceba que nenhum desses conceitos existe de forma isolada.
Cada um resolve uma limitação identificada na etapa anterior, formando uma arquitetura integrada capaz de sustentar os serviços digitais utilizados diariamente por bilhões de pessoas.
Encerramento da Aula 04
Síntese Integradora
Ao iniciar esta aula, analisamos o desafio enfrentado por organizações que precisavam ampliar rapidamente sua infraestrutura de Tecnologia da Informação. A aquisição de novos servidores, a preparação de ambientes físicos e o longo tempo necessário para implantação dificultavam a adaptação das empresas ao crescimento de suas demandas.
Ao longo desta aula, acompanhamos a evolução das soluções desenvolvidas para superar esse problema. Observamos como a virtualização permitiu utilizar melhor os recursos computacionais, como a automação reduziu drasticamente o tempo de provisionamento de novos ambientes e como a Computação em Nuvem transformou infraestrutura em um serviço disponível sob demanda.
Também estudamos os três principais modelos de serviço da Computação em Nuvem.
No modelo Infraestrutura como Serviço (IaaS), o provedor disponibiliza recursos computacionais básicos, enquanto o cliente mantém grande parte do controle sobre sistemas operacionais e aplicações.
No modelo Plataforma como Serviço (PaaS), o provedor assume a administração da plataforma de desenvolvimento, permitindo que os profissionais concentrem seus esforços na criação de software.
Finalmente, no modelo Software como Serviço (SaaS), o usuário utiliza aplicações prontas, sem precisar administrar servidores ou infraestrutura.
Na segunda metade da aula, voltamos nosso olhar para aquilo que normalmente permanece invisível aos usuários: a infraestrutura física da Computação em Nuvem.
Compreendemos que grandes Data Centers distribuídos em diferentes regiões do planeta constituem o alicerce que sustenta todos os serviços em nuvem. Estudamos também como Regiões e Zonas de Disponibilidade aumentam a confiabilidade dos serviços, reduzindo o impacto de falhas localizadas.
Por fim, analisamos quatro conceitos fundamentais para a alta disponibilidade:
- Redundância.
- Tolerância a falhas.
- Balanceamento de carga.
- Escalabilidade.
Esses mecanismos trabalham de forma integrada para garantir que aplicações permaneçam disponíveis mesmo diante do crescimento da demanda ou da ocorrência de falhas em componentes da infraestrutura.
Ao concluir esta aula, percebemos que a Computação em Nuvem representa muito mais do que uma tecnologia.
Ela constitui um novo paradigma para disponibilização de recursos computacionais, permitindo que infraestrutura, plataformas e aplicações sejam consumidas como serviços, de maneira flexível, escalável e economicamente eficiente.
Conectando Ideias
Ao longo desta disciplina, estamos acompanhando uma sequência lógica de evolução tecnológica.
Compreendemos como as Redes de Computadores surgiram e evoluíram até se tornarem uma infraestrutura essencial para a sociedade moderna.
Estudamos a virtualização, tecnologia que revolucionou a utilização dos recursos computacionais ao permitir que diversos sistemas compartilhassem um mesmo servidor físico.
Nesta aula demos mais um passo nessa evolução.
Percebemos que a Computação em Nuvem somente se tornou possível graças à combinação de diversas tecnologias desenvolvidas ao longo das últimas décadas: virtualização, automação, redes de alta velocidade, Data Centers distribuídos e mecanismos avançados de alta disponibilidade.
Essa visão integrada é uma das competências mais importantes para o profissional moderno de Redes de Computadores.
Mais do que conhecer equipamentos ou comandos específicos, é necessário compreender como diferentes tecnologias trabalham em conjunto para oferecer serviços confiáveis, seguros e escaláveis.
Mapa Conceitual da Aula
Problema da infraestrutura tradicional
↓
Virtualização
↓
Provisionamento automatizado
↓
Computação em Nuvem
↓
Responsabilidade Compartilhada
↓
IaaS → PaaS → SaaS
↓
Data Centers
↓
Regiões
↓
Zonas de Disponibilidade
↓
Redundância
↓
Tolerância a Falhas
↓
Balanceamento de Carga
↓
Escalabilidade
↓
Infraestrutura Computacional como Serviço
Glossário
Balanceamento de carga
Mecanismo responsável por distribuir automaticamente as requisições entre diversos servidores, evitando sobrecarga e melhorando a disponibilidade.
Computação em Nuvem
Modelo de disponibilização de recursos computacionais sob demanda por meio da Internet.
Data Center
Instalação física que concentra servidores, armazenamento, equipamentos de rede e infraestrutura de suporte.
Escalabilidade
Capacidade de aumentar ou reduzir recursos computacionais de acordo com a demanda.
IaaS
Modelo de serviço em que o provedor disponibiliza infraestrutura virtualizada e o cliente administra sistemas operacionais e aplicações.
PaaS
Modelo de serviço que fornece uma plataforma pronta para desenvolvimento e execução de aplicações.
Provisionamento
Processo de disponibilização automática de recursos computacionais para utilização.
Região
Área geográfica onde um provedor mantém infraestrutura própria para oferta de serviços em nuvem.
Redundância
Disponibilização de recursos alternativos capazes de assumir o funcionamento do sistema em caso de falha.
SaaS
Modelo em que o usuário utiliza uma aplicação pronta, administrada integralmente pelo provedor.
Tolerância a Falhas
Capacidade de um sistema continuar funcionando mesmo quando alguns de seus componentes apresentam falhas.
Zona de Disponibilidade
Conjunto de Data Centers fisicamente independentes dentro de uma mesma região.
Questões para Revisão
- Explique por que a virtualização foi um passo importante para o surgimento da Computação em Nuvem.
- Diferencie os modelos IaaS, PaaS e SaaS quanto às responsabilidades do cliente e do provedor.
- Qual é a função dos Data Centers na infraestrutura da Computação em Nuvem?
- Explique a diferença entre Região e Zona de Disponibilidade.
- Por que a redundância é considerada um requisito essencial para serviços críticos?
- Como o balanceamento de carga contribui para a alta disponibilidade?
- Diferencie escalabilidade vertical e escalabilidade horizontal.
- Explique o conceito de responsabilidade compartilhada.
Estudo de Caso
Uma empresa de comércio eletrônico realiza, todos os anos, uma campanha promocional que aumenta em dez vezes o número de acessos ao seu portal durante um fim de semana. Nos anos anteriores, sua infraestrutura local apresentou lentidão, interrupções e dificuldades para atender ao grande volume de usuários.
Com base nos conceitos estudados nesta aula, proponha uma solução utilizando Computação em Nuvem. Em sua resposta, indique:
- O modelo de serviço mais adequado.
- A estratégia de escalabilidade recomendada.
- Os mecanismos de redundância e tolerância a falhas que deveriam ser adotados.
- A importância das Regiões e Zonas de Disponibilidade para garantir a continuidade do serviço.
Justifique tecnicamente cada decisão.
Atividade Prática
Escolha um dos principais provedores de Computação em Nuvem (Amazon Web Services, Microsoft Azure, Google Cloud Platform ou Oracle Cloud Infrastructure) e realize uma pesquisa sobre sua infraestrutura.
Identifique:
- As Regiões disponíveis na América do Sul.
- A quantidade de Zonas de Disponibilidade em uma dessas Regiões.
- Um serviço equivalente a IaaS.
- Um serviço equivalente a PaaS.
- Um serviço equivalente a SaaS.
Organize os resultados em uma tabela comparativa e apresente suas conclusões em sala de aula.
Fim da aula 04