Conceitos de SOA

Segundo Fitzsimmons e Fitzsimmons (2010), serviços são atividades

econômicas oferecidas por uma parte a outra, considerando frequentemente
desempenhos com base em um período de tempo para
provocar resultados desejados nos próprios usuários, em objetos ou em
outros bens pelos quais os compradores são responsáveis. Em troca
pelo seu dinheiro, tempo e esforço, os clientes de serviços esperam obter valor
com o acesso a bens, mão de obra, capacidades profissionais,
instalações, redes e sistemas, mas normalmente eles não possuem nenhum
dos elementos físicos envolvidos.
Alguns exemplos típicos de serviços que encontramos normalmente
são:
• consultar extrato de conta-corrente;
• realizar uma compra em e-commerce;
• assistir a uma aula em plataforma digital;
• jogar jogos on-line.
Esses são exemplos de relação entre empresa e cliente final
(business to consumer – B2C). Quando a relação é entre empresas
(business to business – B2B), podemos encontrar outros tipos de
exemplos para serviços, entre eles:
• validar cartão de crédito;
• verificar estoque;
• acionar logística de entrega;
• acionar logística reversa;
• enviar dados para a Receita Federal.
Para compreender melhor, vamos conhecer o “Manifesto SOA”
(ARSANJANI et al., 2009). Segundo ele, prioriza-se:
Valor do negócio em relação a estratégia técnica;
Objetivos estratégicos em relação a benefícios específicos de
projetos;
Interoperabilidade intrínseca em relação a integração personalizada;
Serviços compartilhados em relação a implementações de propósito específico;
Flexibilidade em relação a otimização; e
Refinamento evolutivo em relação a busca da perfeição inicial.
(ARSANJANI et al., 2009)
Ainda no “Manifesto SOA”, são apresentados estes princípios
orientadores:
Respeitar a estrutura social e de poder da organização.
Reconhecer que SOA, em última instância, requer mudanças em
múltiplos níveis.
O escopo da adoção de SOA pode variar. Manter os esforços gerenciáveis e
dentro de limites significativos.
Produtos e padrões, por si só, não proverão uma SOA nem aplicarão os
paradigmas de orientação a serviço por você.
SOA pode ser realizada através de uma variedade de tecnologias
e padrões.
Estabelecer um conjunto uniforme de padrões e políticas corporativas
embasado em padrões da indústria, de facto, e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre partes interessadas no
negócio e na tecnologia.
Maximizar o uso de serviços considerando o escopo de utilização
atual e futuro.
Verificar que os serviços satisfaçam os requisitos e objetivos de
Negócio
Evoluir os serviços e sua organização em resposta ao uso real.
Separar os diferentes aspectos de um sistema que mudam com
diferentes frequências.
Reduzir dependências implícitas e publicar todas as dependências externas
para aumentar a robustez e diminuir o impacto de
mudanças.
A cada nível de abstração, organizar cada serviço em torno de
uma unidade de funcionalidade coesa e gerenciável. (ARSANJANI
et al., 2009)

SOA sob a ótica do negócio

Segundo Erl (2009, p. 24):
SOA estabelece um modelo arquitetônico que visa aprimorar a
eficiência, a agilidade e a produtividade de uma empresa,
posicionando os serviços como os principais meios para que a
solução lógica seja representada no suporte à realização dos
objetivos estratégicos associados à computação orientada a
serviços.
Recentemente, um novo movimento começou a tomar conta das empresas:
mover as pessoas de tecnologia para as unidades de negócios, uma vez que
boa parte dos serviços oferecidos pelas empresas passa necessariamente por
um serviço tecnológico. Obviamente, cada empresa define a sua melhor
estratégia, e isso necessariamente passa por uma definição adequada da
arquitetura tecnológica. Para que uma arquitetura gere benefícios à empresa,
segundo Erl (2009), a SOA deve levar em consideração os seguintes itens:
• maior interoperabilidade intrínseca visa facilitar a troca de informações entre
serviços;
• maior federação onde os sistemas e aplicativos permanecem unidos, mas
mantêm a autonomia individual;
• mais opções de diversificação de fornecedores exige que a arquitetura não
esteja associada à plataforma de um fornecedor
específico;
• maior alinhamento do domínio de negócio e de tecnologia exige o
envolvimento prático de peritos no assunto de negócios em relação à definição
real dos serviços;
• maior retorno sobre o investimento por meio da utilização do
mesmo código para diferentes propósitos – reúso;
• maior agilidade organizacional avalia a eficiência com que uma
organização pode responder a mudanças;
• menor carga de trabalho relacionada a menor desperdício e
redundâncias.
4 Utilização de SOA visando flexibilidade nos
negócios
A SOA visa prover uma organização que projete uma arquitetura
eficiente para as comunicações entre empresas, ou mesmo dentro de
uma mesma organização, pois as empresas vêm adquirindo sistemas
variados. Por exemplo, uma empresa típica pode ter quatro sistemas:
• Sistema de CRM (customer relationship management ou gerenciamento da
relação com o cliente), no qual são realizados acompanhamento das
solicitações do cliente, desenvolvimento de campanhas
comerciais a fim de gerar novas vendas, entre outras necessidades.
• Sistema legado, no qual são realizados operações da companhia,
registro de vendas, alterações solicitadas pelos clientes, pedidos
aos fornecedores, entre outros.
• Sistema de cobrança e pagamento, no qual são realizadas as movimentações
financeiras da empresa.
• Sistema de BI (business intelligence ou inteligência de negócios),
no qual são armazenados os dados para a geração de informações para a
tomada de decisão.
Uma arquitetura
orientada a serviço permitirá a realização mais eficiente das comunicações,
bem como gerará benefícios de longo prazo, como simplificação
na manutenção de sistemas.
Conforme as organizações vão evoluindo, é natural que, em algum
momento, queiram atualizar seus sistemas. No exemplo anterior, caso
a empresa tenha uma arquitetura orientada a serviço, poderá mais facilmente
substituir um dos sistemas sem necessariamente gerar impacto
nos demais. Esse tema é conhecido como federação e interoperabilidade.
Caso não haja uma definição nesse sentido e os sistemas sejam integrados por
leitura de dados, por meio de bases de dados, por exemplo,
para realizar um atendimento no sistema de CRM, esse sistema de CRM
busca dados no sistema de cobrança via seleção de dados diretamente
na base (comando select). Quando desejar substituir o CRM ou realizar
alguma alteração na base de dados de cobrança, pode haver impacto
no funcionamento dos sistemas. Alguns podem dizer que é mais rápido
e barato construir um select direto na base de dados, mas pense no
seguinte cenário: sempre que for necessário buscar essas informações,
será necessário construir novas buscas de dados, o que gera custos
adicionais, além de elevar a complexidade sistêmica.
Primeiro cenário: a arquitetura tecnológica não conta com integração
entre os sistemas de CRM e cobrança. Neste caso, o atendente da central de
atendimento terá que enviar um e-mail para a área de cobrança, e
a área de cobrança vai avaliar a situação por meio do sistema de cobrança e
telefonará para o cliente para confirmar se acatará ou não o pedido.
Segundo cenário: a arquitetura tecnológica contempla uma integração dos
sistemas de CRM e cobrança. Dessa forma, o atendente da
central de atendimento faz a solicitação, o sistema de cobrança, por
meio de suas regras, define se acata ou não o pedido, e o atendente
informa ao cliente a situação.
No segundo cenário, houve uma economia de custos na realização
da operação, uma vez que não foi necessário envolver uma pessoa
da equipe de cobrança, não foi necessária uma segunda digitação de
dados no sistema de cobrança e o atendimento foi registrado na ferramenta de
CRM. Certamente, o nível de satisfação do cliente também é
melhor nesse cenário.
Com base na solicitação de serviços feita pelo cliente, a dinâmica tecnológica
aplicada aos serviços existentes se daria da seguinte (em um modelo de
arquitetura orientada a serviço, melhor cenário)
forma:
• Passo 1: o cliente liga na central de atendimento.
• Passo 2: o cliente digita seu código de cliente ou CPF na central
de atendimento (unidade de resposta audível – URA).
• Passo 3: a ligação é transferida para o atendente da central de
atendimento.
• Passo 4: o sistema de CRM executa o serviço consulta de cliente.
• Passo 5: o cliente é identificado no sistema de CRM, e o atendente pergunta
o que o cliente deseja.
• Passo 6: o cliente informa que deseja alterar o vencimento de um
pagamento.
• Passo 7: o sistema de CRM executa o serviço alteração de data
de vencimento.
• Passo 8: o serviço alteração de data de vencimento do sistema de
CRM aciona o serviço alteração de data de vencimento do sistema
de cobrança.
• Passo 9: o sistema de cobrança devolve para o sistema de CRM a
possibilidade ou não de alteração da data de vencimento.
• Passo 10: o atendente informa ao cliente o resultado.
Os passos 7, 8 e 9 envolvem a integração entre sistemas.
E se o cliente realizasse a mesma operação pelo app da empresa, quais
seriam os passos a serem seguidos? Vamos verificar os passos necessários:
• Passo 1: login no app.
• Passo 2: o app executa o serviço consulta de cliente.
• Passo 3: o cliente aciona o serviço alteração de data de vencimento.
• Passo 4: o serviço alteração de data de vencimento do app aciona
o serviço alteração de data de vencimento do sistema de cobrança.
• Passo 5: o sistema de cobrança devolve para o app a possibilidade ou não de
alteração da data de vencimento.
Repare que, por meio do app ou do sistema de CRM, foi acionado
o mesmo serviço do sistema de cobrança (alteração de data de vencimento).
Nesse caso, se a arquitetura foi projetada com o objetivo de
reutilização de serviços e independência entre os sistemas, a empresa
ganhará em flexibilidade quando desejar alterar as regras de negócios
no que tange aos critérios para a alteração de data de vencimento. Fará
uma alteração apenas no sistema de cobrança, e os demais sistemas
que consomem esse serviço não precisarão ser alterados. Além disso,
se a empresa desejar alterar o sistema de CRM para um sistema mais
novo, não precisará promover alterações no app ou no sistema de cobrança.
Esse desenho de arquitetura é o que permitirá à empresa ganhar em
flexibilidade e redução da complexidade tecnológica.
5 Barramento de serviços (ESB) – estrutura
interna e proxy service
Nos exemplos que temos discutido, nos quais são expostos serviços
de um determinado sistema para serem consumidos por outros sistemas,
podemos nos deparar com algumas dificuldades técnicas, uma
vez que os sistemas podem prover modalidades específicas de serviços
em diferentes tecnologias. Nesse caso, pode ser um problema integrar
diferentes sistemas em diferentes tecnologias. Uma alternativa para tratar esse
tipo de situação é a utilização de barramento de serviços (ESB).
Como é possível notar na figura 1, o ESB atua também como um
mediador entre os diferentes serviços de diferentes tecnologias. Além
disso, o ESB realiza a orquestração dos serviços, possibilitando maior
eficiência, respeitando as características de cada sistema e permitindo
realizar comunicações síncronas e assíncronas.

Quando necessitamos realizar integrações e comunicações entre

servidores distintos, ou mesmo comunicações entre organizações distintas,
uma solução interessante é o proxy (em português, procurador
ou representante). O proxy foi criado originalmente para conectar uma
rede local (LAN) à internet. Um dos benefícios do proxy é que ele pode
armazenar informações e, se a mesma informação for requerida várias
vezes, não necessita recorrer ao acionamento dos serviços.

Quando visualizamos uma figura em formato de nuvem, isso indica

uma comunicação via internet. Algumas pessoas podem se confundir,
entendendo que se trata de uma comunicação externa entre organizações
distintas. Entretanto, esse tipo de comunicação via internet pode
ser encontrado dentro da mesma organização em redes diferentes. Esse
conceito nos ajuda a compreender que os sistemas internos também
podem fazer parte da internet, e, com isso, seus serviços podem ficar
expostos. Um ponto de atenção é que, quando os serviços estão expostos,
ficam suscetíveis a tentativas de acesso por usuários maliciosos ou
hackers; portanto, métodos de segurança precisam ser aplicados.
CAPÍTULO 2 – Fundamentos SOA: arquitetura distribuída e sistemas de
softwares
Segundo Erl (2009), “aplicativos”, “aplicativos integrados”, “soluções”
e “sistemas” são termos que representam a composição de serviços.
Entretanto, considerando que muitas implementações SOA consistem
em uma mistura de serviços e ambientes legados, à medida que as iniciativas
de transição de SOA continuam a progredir dentro de uma organização, pode
ser útil fazer uma clara distinção entre um aplicativo
tradicional e as composições de serviços.
Em uma solução orientada a serviço, aplicativos ou sistemas equivalem a uma
composição de serviços. Se precisássemos construir uma
SOA para toda a organização a partir do zero, ela provavelmente seria
constituída por numerosas composições de serviços capazes de representar os
papéis tradicionais associados a esses termos.
Entre os sistemas e soluções encontrados comumente nas organizações, há
diferentes modelos.
• Sistemas core: são os sistemas que executam as principais operações da
organização. Por exemplo: em um banco, são os sistemas
que controlam depósitos em conta, transferências e movimentações em conta-
corrente; em uma indústria, são os sistemas que
controlam a produção, o estoque e a logística de entrega.
• Sistemas de suporte: são os sistemas integrados ao sistema
core e servem para realizar funções específicas; por exemplo:
gestão financeira, gestão contábil e gestão de vendas. Em uma
empresa de comércio eletrônico, é comum ter sistemas de suporte para as
operações, gerenciando o processo de cobrança e
pagamentos.
• Soluções: são os softwares de mercado on-premise ou open
source com um propósito determinado, podendo ser tanto um
sistema core como um sistema de suporte. Um dos mais conhecidos do mundo
é o SAP, que pode ser um sistema de suporte
para os módulos FI (financial accounting ou contabilidade financeira) e CO
(controlling ou controladoria), por exemplo, ou um sistema core, que é a razão
fundamental do nascimento do SAP para
a indústria de manufatura. Além do SAP, existem outras soluções
mundialmente conhecidas, como Oracle, Salesforce, Dynamics,
entre outros.
• Apps: são ferramentas que permitem a um usuário interagir com
a organização, por meio de uma comunicação digital ou virtual,
bem como executar operações fornecidas por ela. Por exemplo: o
app de uma operadora de telefonia no celular contém serviços e
modelos de comunicação como chat, entre outros.
As organizações enfrentam como desafio gerenciar diferentes arquiteturas,
modelos de serviços e plataformas tecnológicas. Além disso, elas atualmente
têm uma forte integração com toda a cadeia de
fornecedores e parceiros de negócios, utilizando serviços dos mais
variados tipos, podendo dar suporte ao negócio, como aqueles relacionados a
cobrança, por exemplo, ou servir de base para a própria
organização, como o BigQuery do Google Cloud.
Segundo o W3C (2004), web service (em português, serviço web),
é um sistema de software responsável por proporcionar a interação
entre duas máquinas através de uma rede. Para possibilitar essa interação,
uma interface descrita em um formato específico, WSDL (Web
Services Description Language), permite que sistemas interajam com
um web service enviando mensagens SOAP (Simple Object Access
Protocol) ou utilizando outros protocolos. As mensagens SOAP basicamente
são documentos XML serializados seguindo o padrão W3C,
enviados em cima de um protocolo de rede.
As organizações facilitam a exposição de serviços para que outras
organizações, ou até mesmo pessoas físicas (não muito comum), possam
utilizar seus web services e assim terem acesso a serviços.
Os órgãos públicos do Brasil oferecem atualmente ambientes nos
quais os web services podem ser consumidos.
Vejamos um exemplo do Tribunal de Contas da União (TCU, [s. d.]).
Um dos serviços disponíveis, consultar acórdãos, apresenta os seguintes

dados:
A partir do índice de referência e da quantidade de acórdãos, é retornado o link
para fazer o download de arquivos em formato DOC e
PDF, além de outros dados que facilitem a pesquisa e a localização das
informações requeridas.
O BPM (business process management ou gerenciamento de processos de
negócios) traz uma abordagem adicional aos sistemas de
informação. Vamos considerar o seguinte exemplo: “reclamações” é um
tema sobre o qual praticamente todas as organizações têm sua própria
abordagem de tratamento. Isso mesmo, cada empresa pode ter uma
abordagem distinta de tratamento. Essas abordagens distintas podem
existir também dentro de uma mesma organização. Isso ocorre quando
um determinado processo ou serviço é executado por uma central de
atendimento e por uma área de pagamentos, sendo o mesmo processo,
mas com características distintas entre diferentes áreas e usuários. O
BPM apoia as organizações a tratar essas características nos processos de
negócios, permitindo uma maior flexibilidade processual e mantendo as
características dos sistemas e soluções. O BPM vem evoluindo desde as
soluções workflow (fluxo de trabalho) até as automações
existentes atualmente, chamadas RPA (robotic process automation ou
automação robótica de processos).
Como identificado na figura 2, o BPM atua em conjunto com sistemas, soluções
e web services. Algumas ferramentas no mercado se
especializaram na construção de fluxos de trabalho com base em sistemas
específicos, como o ARIS, que é um acelerador em projetos SAP,
pois contém fluxos de trabalho predeterminados e pode inclusive desenhar ou
alterar fluxos baseados na atualização de processos de uma
determinada organização.
Uma das grandes vantagens de se estabelecer fluxos de trabalho é
poder conferir uma abordagem mais proativa. Considere que a sua empresa
recebeu uma reclamação por e-mail. O normal é que uma pessoa
faça a leitura dessa reclamação, busque formas de resolver o problema
dentro da organização e depois retorne ao cliente com um posicionamento.
Considere que, para resolver o problema, é necessário primeiramente falar
com uma determinada área de rastreamento de pedido,
por exemplo, e depois falar com a transportadora para confirmar a data
de entrega. Para um pedido, isso é muito simples, mas considere que
você tenha cem reclamações. Talvez, neste caso, não seja tão simples.
É nesse ponto que o BPM pode ser uma solução para a organização.
Ele poderá ser configurado para controlar todas as reclamações, enviar
mensagens e e-mails para cobrar posicionamento de áreas e parceiros
envolvidos, alertar a gestão sobre reclamações com prazo de devolutiva
próximo de vencer ou vencido, informar onde cada reclamação está
“travada”, entre outras opções. Note que esses exemplos de processos de
negócios podem ser construídos sem alterar qualquer sistema
ou solução, por isso comentamos que o BPM atua em conjunto com
sistemas, soluções e web services.

É importante, quando estiver avaliando uma solução de BPM, verificar

a arquitetura e se esta é aderente à sua SOA; com isso, você terá maior
flexibilidade na hora de integrá-la com seus sistemas, soluções e serviços.

2 Padrões de integração e tipos de mensagens

Utilizadas
Segundo Erl (2009), a integração tornou-se uma referência básica
no final da década de 1990 e muitas organizações não estavam bem
preparadas para isso. Muitos sistemas foram desenvolvidos com
pouca elaboração quanto à maneira com que os dados poderiam ser
compartilhados fora do limite do sistema. Em consequência, canais
de integração ponto a ponto eram frequentemente criados quando
surgia a necessidade de compartilhamento de dados, o que levou aos
famosos problemas associados a falta de estabilidade, extensibilidade
e frameworks de interoperabilidade inadequados. As plataformas EAI
(enterprise application integration ou integração de aplicações corporativas)
introduziram o middleware, que levou em conta a abstração de
aplicativos proprietários pelo uso de adaptadores, brokers e mecanismos de
orquestração.
A palavra “middleware” é uma alusão a software e hardware. O middleware é o
elemento central de comunicação entre softwares.

Diferente do conceito de web services, o middleware atua como um barramento

de comunicação entre diferentes sistemas e soluções, e também entre
diferentes tecnologias, permitindo assim que uma organização opera em
sistemas e soluções distribuídos.
Exemplo – houve uma mudança na legislação tributária, uma mudança na
alíquota de imposto de renda. Com esse tipo de arquitetura (middleware), a
alteração realizada na solução recolhimento de tributos não afetará os
demais sistemas e soluções, reduzindo custos das organizações com análises
de impacto e testes, fazendo esse desacoplamento uma das considerações
mais importantes de SOA.
Tipos de Middleware:
• API (application programming interface ou interface de programação de
aplicativos): é um conjunto de ferramentas e padrões
abrangentes. Fornece as definições e os protocolos utilizados
para projetar e criar aplicativos. Permite também que o serviço
criado se comunique perfeitamente com outros serviços, sem
precisar saber em que tecnologia foram construídos ou, ainda,
como sua arquitetura está estabelecida. Nesta altura, você deve
estar se perguntando qual a diferença entre web services e APIs.
Conceitualmente, eles parecem ser a mesma coisa. Os web
services utilizam três estilos de comunicação: XML, REST e SOAP,
enquanto que as APIs podem usar estilos de comunicação mais
amplos e abrangentes.
• Integração de aplicações: é o processo de combinar diferentes conjuntos de
dados de diferentes aplicações. A estrutura é voltada para integrações mais
específicas, e o ponto negativo é que pode levar a relações de dependências.
É amplamente utilizada pelas organizações por conta de algumas soluções já
entregarem esse tipo de integração nativamente.
• Servidor de aplicativos: é uma plataforma para desenvolvimento
de aplicativos que oferece ferramentas e serviços dos quais um
desenvolvedor precisa para construir qualquer aplicativo.
• Integração de dados: mescla dados de diferentes fontes de informações em
um único painel integrado de informações, permitindo que elas sejam
consultadas ou manipuladas de maneira
rápida e flexível.
• TP (transaction process ou processo de transações): tem por objetivo manter
a integridade da base de dados, sistemas e soluções
simplesmente controlando e configurando por meio da implementação de
regras de negócios ou permissões de banco de dados.
• ORB (object request broker ou corretor de requisições de
objeto): permite que serviços que estejam remotos possam ser
acessados como se estivessem registrados localmente.
• RPC (remote procedure call ou chamada de procedimento
remoto): é um protocolo de interação que permite que um serviço seja
disseminado em várias plataformas com mais facilidade
e eficiência.
• MOM (message-oriented middleware ou middleware orientado
a mensagens): é uma melhoria no RPC, por meio de um mecanismo de
enfileiramento. Permite que a interação cliente-servidor
ocorra onde um sistema, solução ou banco de dados está com
lentidão ou espera para poder responder à solicitação.
Certamente, dentro de cada organização e modelo de negócios, existem
diretrizes que
norteiam a tomada de decisão passando pela SOA, mas também existem
aspectos dentro das organizações que não necessariamente estão
desenvolvidos conforme as melhores práticas. Portanto, para escolher o
melhor modelo, é importante considerar o nível de serviço que precisa ser
oferecido versus os custos envolvidos. Certamente as organizações não
utilizam um único modelo ou um único tipo de middleware. Desse modo,
as opções a serem escolhidas passam prioritariamente pela robustez
técnica a ser empregada na integração. Um ponto certamente prioritário
é o tipo de integração necessário. Há dois tipos:
• Síncrono: no momento que se estabelece uma comunicação, ela
somente será encerrada quando toda a transação estiver concluída, ou seja, o
sistema de origem dispara uma integração, e o sistema de destino é
estimulado, realiza o processamento e faz a
devolução do resultado ao sistema de origem. Com isso, a transação é
encerrada. Esse tipo de comunicação é útil para transações
que requerem respostas imediatas e onde não há risco de lentidão entre
sistemas, uma vez que, se houver uma lentidão no sistema de destino, o
sistema de origem também será impactado. É
frequentemente utilizado em operações realizadas por usuários
e clientes.
• Assíncrono: não requer que o sistema de origem e o sistema de
destino estejam relacionados, ou seja, as integrações operam
totalmente desacopladas. O sistema de origem dispara uma integração, e essa
integração fica aguardando no middleware o
momento que o sistema de destino será acionado. No momento que o sistema
de destino identifica no middleware que há dados e transações disponíveis,
este faz a captura dos dados e o
processamento das informações, e a devolução pode acontecer
em um momento futuro. Enquanto isso, no middleware, o status
da informação pode ser gerenciado como “em processamento”.
Por exemplo, no momento que o sistema de destino faz o processamento e o
retorno das informações, essas informações no
middleware são alteradas para “processadas” e ficam à disposição para
processamento do sistema de origem. Esse tipo de comunicação é
amplamente utilizado em rotinas de processamentos em lote (batch).
Além do desacoplamento das integrações, é possível também trabalhar com o
desacoplamento dos dados. Observe o seguinte exemplo:
considere que sua empresa realiza débito em conta na conta-corrente
de seus clientes. A cada uma hora, é executada uma rotina que identifica as
novas vendas e envia a cobrança para os bancos de cada cliente.
A cada hora, é disponibilizado um lote a ser processado pelo banco. O
banco, a cada trinta minutos, faz a captura das informações e retorna
em dez minutos o resultado, ou seja, “débito efetuado”, “débito não autorizado”
ou “conta-corrente não existente”. Dessa forma, “débito não autorizado” ou
“conta-corrente não existente” ficam pendentes de ajustes
antes de serem submetidos novamente. Dentro do middleware, podem
ser estabelecidas regras mais específicas, como quantidade de repiques
(tentativas) ou devolução para o sistema de origem no caso de alguma
inconsistência. Observe que, mesmo em um exemplo, podemos ter diferentes
abordagens e arquiteturas, e cada organização pode definir a
arquitetura que melhor se adéque às suas necessidades de negócios.
Capítulo 3 – Conceito e identificação de serviços – web services
1 Definição de serviços
Conforme Marzullo (2009, p. 151), serviço é uma simples classe que
responde às chamadas de operações por meio de uma interface bem
definida. Da mesma forma, o serviço é um sistema complexo, composto por
dezenas de componentes de software, que, por sua vez, são compostos por
outros componentes e classes, que, no final, produzem o
efeito esperado de provimento de um determinado serviço mapeado a
partir de um processo de negócio.
Alguns exemplos típicos de serviços são: acessar os dados cadastrais de um
cliente, executar uma validação de cartão de crédito, rastrear
uma compra, entre outros. Web services são serviços tecnológicos expostos na
http com o objetivo de expor funções de negócios reusáveis
(W3C BRASIL, 2020). Web services foram criados para resolver deficiências de
sistemas distribuídos. Dentro de uma mesma tecnologia, por
exemplo, .NET, você pode desenvolver seus objetos e serviços, mas,
para que estes possam ser consumidos por um sistema Java, infelizmente não
é tão simples consumir as classes e os objetos desses serviços, por isso o web
service surge com uma possibilidade de ter um
serviço que possa ser consumido por diferentes tecnologias, alocadas
em diferentes localidades.

Segundo Daigneau (2011, p. 6), web services são relativamente fáceis de

reutilizar e compartilhar lógica com diferentes clientes, como
mobile, desktop e aplicações web. Essa possibilidade alcançada pelos
web services ocorre por conta dos padrões abertos, que permitem
interoperabilidade em diferentes plataformas computacionais e execução
tecnológica independente.
Um outro ponto importante na estrutura dos web services é que,
à medida que fazemos uma alteração em suas propriedades, não
necessariamente é preciso rever toda a cadeia que aciona o serviço. Para
exemplificar, se porventura você tiver um serviço que realiza pagamentos por
meio de um determinado banco, ao mudar o comportamento do web
service para realizar pagamentos por meio de um outro banco, ou até
mesmo adicionar novos bancos ao pagamento, não será necessário que
os sistemas e aplicações que consomem esse web service sejam alterados.
Isso é importante dentro de uma arquitetura orientada a serviço,
pois reduz significativamente os impactos operacionais dessa mudança.
Vejamos um exemplo no qual o web service de pagamento é acionado
pelas diferentes aplicações e envia a solicitação de pagamento para o
banco 1.

Ao adicionar mais um banco no processo de pagamentos, apenas o

web service de pagamento será alterado, sem precisar afetar as aplicações
envolvidas no processo.

Esse tipo de orientação a serviço, além de permitir

maior flexibilidade nos processos organizacionais, gera uma importante
economia. Considere, por exemplo, que uma determina organização
pode obter melhores taxas nos serviços bancários realizando pagamentos por
meio de um novo banco. Os benefícios desse tipo de arquitetura
vão além da economia de gastos em TI. Eles passam também pela geração de
benefícios operacionais à organização, tais como redução do
prazo de implantação.
Um outro benefício dessa arquitetura e desse web service é que, se
os bancos introduzirem novos processos ou mesmo novos modelos de
pagamentos, o impacto para as alterações também é reduzido. Vamos
considerar a introdução do PIX (modalidade de pagamento instantâneo
e 24 horas). A alteração seria apenas no web service de pagamento,
sem impactar os demais agentes envolvidos. Nesse caso, dentro do
web service, podem ser estabelecidas regras de negócios, determinando o tipo
de modalidade de pagamento (DOC, TED, PIX) e qual o banco
onde será feito, de forma que a organização obtenha o melhor benefício
operacional e econômico.
2 Tipos de serviços e suas características
Segundo Daigneau (2011), web services são frequentemente descritos como
operações de baixo acoplamento, o que significa que não
existe relação de dependência entre as aplicações e os web services. As
aplicações podem ser compiladas independentemente do web service, e,
como vimos no caso anterior, o web service pode ser alterado e compilado
independentemente das aplicações. Isso gera os benefícios apresentados
anteriormente, mas há certos casos no quais é importante ter um
certo nível de acoplamento. Vamos conhecer os tipos de acoplamento:
• Acoplamento funcional: quando as regras funcionais do web
service são alteradas, pode ser necessário rever as regras das
aplicações também. Por exemplo: no caso em que foi informada a adição de
um novo banco para a realização dos pagamentos, se
for interessante o usuário escolher o banco de pagamento, isso
precisará ser feito também na própria aplicação.
• Acoplamento da estrutura de dados: um dos pontos mais importantes de um
web service são os dados enviados e os dados
esperados de retorno, após processamento do web service. Caso
haja alguma alteração nessa estrutura de dados, as aplicações
também deverão ser ajustadas, a fim de reconhecer essa nova
estrutura. No caso abordado, se for necessário receber os dados
de confirmação de pagamento, é importante ter uma estrutura de
dados específica para isso, e as aplicações precisam estar preparadas para
tratar esse dado.
• Acoplamento temporal: normalmente, quando uma aplicação
realiza uma chamada a um web service, a expectativa é de que
haja um retorno imediato (síncrono). Esse acoplamento pode gerar demora na
resposta, caso um dos serviços envolvidos apresente algum tipo de lentidão.
Para contornar isso, como já vimos,
a comunicação assíncrona pode ser uma solução técnica. É importante validar
se, do ponto de vista de negócio, essa é uma solução viável, ou se deve-se
pensar em melhorar a eficiência dos serviços envolvidos. De qualquer forma,
as aplicações que acionam
o web service precisam considerar o aspecto de tempo, seja estabelecendo
time out (tempo máximo que espera o retorno), seja
estabelecendo comunicação assíncrona, entre outras soluções.
3 Modelo de serviços
Segundo Battisti (2001), o modelo de serviços é uma arquitetura na
qual o processamento da informação é dividido em módulos ou processos
distintos. Um processo é responsável pela manutenção da informação
(servidor), enquanto que outro é responsável pela obtenção dos
dados (cliente).
Nessa modalidade, o banco de dados é instalado em um servidor, os
componentes e funcionalidades, como DLLs (dynamic-link libraries ou
bibliotecas de ligação dinâmica), por exemplo, ficam em outro servidor
e a camada visual, as telas pelas quais o usuário navega, fica em um terceiro
servidor. Dessa forma, banco de dados, componentes e visual têm
independência e podem ser manuseados de uma forma mais organizada e
segura. A maior parte dos websites com funcionalidades providos
pelas organizações tem essa modelagem. Assim, as telas e chamadas
dos serviços ficam expostas na internet, e os componentes e o banco
de dados ficam protegidos dentro da organização.

Os web services geralmente ficam na camada de componentes, permitindo

que, dentro da camada visual, os serviços sejam
acionados sem comprometer a segurança da aplicação, pois, dessa forma,
dados, regras de negócios e métodos de acesso estão dentro da
barreira de segurança da organização.

4 Levantamento de serviços
Nos nossos estudos, temos apresentado alguns exemplos de serviços que as
organizações costumam desenvolver, seja para uso interno,
seja para uso externo. Para desenvolver web services, devemos levar
em consideração os seguintes aspectos:
• Decisão de negócios, porque a tecnologia é base fundamental
de grande parte dos negócios, e os negócios podem requerer o
desenvolvimento de um serviço a ser utilizado pelos clientes da
organização. Nesse caso, um web service e sua documentação
de como ser utilizado devem ser elaborados.
• Uma arquitetura tecnológica baseada em objetos independentes é
uma candidata natural a um web service. Nesse modelo, é importante avaliar o
volume de clientes que vão consumir o web service.
Se porventura houver apenas um único cliente consumindo o serviço, talvez
seja mais interessante pensar em outras soluções de
arquitetura. De qualquer forma, isso não é um impedimento para
se desenvolver um web service, porque, com a grande variação de
mudanças que existem atualmente no mundo de negócios, deve-se
considerar que novas fontes (clientes) podem surgir e ter um web
service disponível pode ser um fator diferencial na estratégia operacional. Por
fim, um outro fator importante é que, se houver tecnologias distintas na
comunicação entre aplicações, um web service
pode ser um mecanismo que resolva esse tipo de complexidade.
5 Definição e principais componentes de um web service
Um típico web service contém estes quatro elementos:
• Sistema operacional: permite as interações entre a aplicação e
o hardware.
• Servidor web: compreende código-fonte, banco de dados e arquivos HTML
que habilitam o envio do código para as aplicações
(cliente).
• Banco de dados: é o banco no qual os dados estão armazenados
e serão acionados de acordo com as regras estabelecidas na linguagem ou
script.
• Linguagem ou script: é onde as regras de negócios e funcionamento dos web
services são definidas.
6 Web service no desenvolvimento de aplicações e integração de
sistemas
Os web services têm um ciclo de vida bastante típico e passam normalmente
pelas seguintes etapas:
1. Publicação: quando o provedor do web service faz a publicação
do web service e este passa a poder ser invocado pelas aplicações (clientes).
2. Comunicação: quando o provedor do web service informa que
o web service está apto para ser consumido pelas aplicações
(clientes).
3. Invocação: quando as aplicações (clientes) invocam o web
service e o utilizam plenamente.
4. Remoção: apesar de todos os esforços para que o web service
tenha a maior vida útil possível, é natural que, em um determinado
momento, este seja substituído por um novo serviço ou arquitetura tecnológica.
Muitas vezes, quando estamos navegando na
internet, encontramos um erro 404. Esse erro significa que o web
service que está sendo invocado pela aplicação (cliente) não está
mais disponível. Pode ser que tenha havido um problema de infraestrutura ou
acesso na comunicação, mas pode ser também que
o web service tenha sido removido e não esteja mais disponível.
7 Arquitetura e protocolos de comunicação
Para Saudate (2012), uma arquitetura típica de web service pode ser
descrita da seguinte forma:
• HTTP: meio pelo qual é realizado o transporte das informações.
• UDDI (Universal Description, Discovery and Integration): repositório no qual o
web service será registrado.
• WSDL (Web Services Description Language): os documentos
com os dados que serão trocados e como esses dados estarão
organizados.
Saudate (2012) define diferentes tipos de protocolos de comunicação. São
eles:
• SOAP (Simple Object Access Protocol): protocolo para a troca de
mensagens que permite a interoperabilidade entre os sistemas.
Utiliza HTTP e XML.
• REST (Representational State Transfer): utiliza múltiplos padrões, como
HTTP, JSON, URL e XML.
Capítulo 4 Arquitetura de serviços para mobilidade
Segundo Lohrmann (2013), uma mudança radical vem ocorrendo no
contexto de negócios. A geração digital requer maior liberdade e flexibilidade
com os smartphones e PCs, com o objetivo de realizar seus trabalhos de
maneira mais rápida e assertiva. Apesar de a motivação ser variada, como
melhoria da performance ou, ainda, conveniência pessoal, as empresas
oferecem gamas distintas de equipamentos, e as pessoas utilizam uma gama
ainda maior, principalmente nas organizações que contam com programas
como BYOD (“bring your own device” ou “traga seu próprio dispositivo”).
Essa multiplicidade de equipamentos, sistemas operacionais e meios de
acesso
gera desafios extras no design de arquiteturas para aplicações móveis,
pois as aplicações podem ter comportamentos distintos em cada equipamento,
sistema operacional e browser, além da performance dos equipamentos, que
varia de acordo com sua capacidade e com a conexão
com a internet. Enfim, são temas amplos e que mudam dia a dia, por
conta de lançamentos frequentes.
Uma expectativa que os stakeholders têm é poder iniciar um serviço
em um determinado equipamento e concluí-lo em outro, ou, ainda, interagir por
diferentes ferramentas ou canais de comunicação, sejam eles
digitais ou físicos. Obviamente, os stakeholders entendem como um mau
serviço o fato de a organização não ter um histórico dessas interações
e não poder dar continuidade em um atendimento. Para exemplificar, o
stakeholder inicia um serviço pela aplicação móvel e, em um determinado
momento, migra para o call center. A expectativa é de que o atendente
recupere esse histórico da aplicação móvel e consiga dar continuidade
sem requerer dados informados anteriormente. Isso é conhecido como
“omnichannel”, que é uma estratégia de conteúdo entre canais que as
organizações usam para melhorar sua experiência do usuário e conduzir
melhores relacionamentos com seu público nos pontos de contato. Em
vez de trabalhar em paralelo, os canais de comunicação e seus recursos
de suporte são projetados e orquestrados para cooperar. O omnichannel
implica integração e orquestração de canais, de forma que a experiência
de alguém que escolher se engajar em todos os canais seja tão ou até
mais eficiente ou agradável do que usar canais únicos de maneira isolada.
1 Arquitetura geral para integração e desenvolvimento de aplicações móveis As
arquiteturas para integração e desenvolvimento de aplicações móveis devem
ser avaliadas de acordo com o tipo de utilização, e, se possível, a partir de uma
previsão de uso futuro. Com base nisso, podem ser desenhadas arquiteturas
adequadas quanto ao uso e com custos racionais. Vivemos em um momento
de negócios VUCA (volatility, uncertainty, complexity, ambiguity ou volatilidade,
incerteza, complexidade, ambiguidade); portanto, é importante também
considerar arquiteturas flexíveis. Vamos conhecer as arquiteturas mais comuns
utilizadas atualmente. Do ponto de vista de servidores, a arquitetura mais
utilizada pelas organizações é a arquitetura de três camadas: camada de
aplicação, camada de negócios e camada de banco de dados. Vamos
adicionar agora o conceito de filas:
• Arquitetura de uma fila (one-tier architecture): é orientada a ter
as três camadas em um único servidor. É mais rápida para desenvolver,
entretanto não tem escalabilidade. É orientada para aplicações móveis nas
quais a quantidade de usuários é conhecida e
não apresenta grande variação na utilização. Além disso, o grau de segurança
é menor. Um uso típico seria para aplicações móveis
destinadas aos colaboradores de uma empresa, com acesso a temas de
recursos humanos, como marcação de ponto eletrônico, acesso ao holerite,
solicitação de férias, entre outros usos.
• Arquitetura de duas filas (two-tier architecture): é orientada a ter
a camada de banco de dados separada do servidor da camada de
apresentação e negócios. É orientada para quando diferentes aplicações
móveis vão utilizar uma única base de dados corporativa.
Uma experiência comum é quando a empresa tem uma aplicação
desenvolvida com alto grau de acoplamento e não vale a pena a
separação. Nesse caso, a empresa opta em manter a atual estrutura. Este
modelo apresentará dificuldades caso seja necessário escalar, ou, ainda, não
apresenta critérios fortes de segurança. Pode,
com o tempo, se tornar mais caro, à medida que pode requerer
mais recursos de infraestrutura e apresenta dificuldade em compartilhar
serviços. Os ERPs (enterprise resource plannings ou planejamentos de
recursos empresariais) mais conhecidos do mercado operam dessa forma e,
por isso, requerem sempre mais recursos de infraestrutura à medida que o uso
se intensifica. Como as organizações estão trazendo para a sua cadeia
produtiva seus fornecedores e parceiros, este modelo acaba sendo
amplamente utilizado também em aplicações móveis, pois é comum expor os
serviços e aplicações móveis para os parceiros a fim de agilizar a operação.
• Arquitetura de três filas (three-tier architecture): é a arquitetura mais utilizada
nas aplicações móveis. Tem três camadas distintas para aplicações, negócios
e banco de dados. É a mais segura e escalável e possibilita a utilização de
mecanismos eficientes que permitem adaptar a quantidade de servidores
utilizados de acordo com a demanda de negócios, com isso, tendo gastos
controlados pela demanda e sem gerar interrupções aos negócios por falta de
disponibilidade de infraestrutura. É comum encontrarmos ambientes de alta
disponibilidade com esta arquitetura.
Segundo Veras (2016, p. 29), “as organizações buscam construir plataformas
digitais mais estáveis que permitam o crescimento mesmo em ambientes
turbulentos”. Parece contraditório, mas não é. O que se quer é o melhor dos
dois mundos: plataformas estáveis e flexíveis. Pode-se pensar em arquiteturas
e infraestrutura que suportem o crescimento do negócio. A virtualização, nesse
contexto, é uma peça-chave, pois permite alterar a infraestrutura rapidamente
utilizando instrumentos lógicos e não físicos, ao mesmo tempo que estabiliza o
ambiente, tornando as aplicações independentes do hardware.
Com isso, pode-se configurar o banco de dados de forma distinta da aplicação.
O banco de dados, por exemplo, consome muita memória, e, se uma aplicação
estiver instalada no mesmo servidor, ela tende a não ter eficiência e a
apresentar lentidão. Separando as configurações, é possível colocar mais
memória para o banco de dados e memória menor para os servidores de
aplicação e banco de dados.
2 Tecnologia e arquitetura para disponibilizar aplicações
As tecnologias e os dispositivos envolvidos atualmente para aplicações móveis
são variados e são atualizados com uma frequência que torna bastante
complexo manter as aplicações móveis operacionais em todos os dispositivos e
em todas as situações de sistemas operacionais e browsers. Uma forma de
minimizar esse impacto é pensar na aplicação utilizando o conceito responsivo
de que você tenha um único desenvolvimento e uma aplicação funcional em
diversos equipamentos e protocolos, sem prejudicar a experiência do usuário.
Segundo Zemel (2015), o web design responsivo é a chave para essa nova
web. É pensar em páginas que se adaptem a todo tipo de dispositivo e
contexto de uso. É sair das limitações de um browser desktop e seu tamanho
previsível e pensar em páginas com flexibilidade que suportem todo tamanho
de tela, qualquer tipo de resolução, interfaces com touch ou mouse.
Repare que, de uma forma geral, as informações apresentadas em ambas as
telas são iguais, exceto por um detalhe, o menu superior. Na figura 1, o menu
aparece destacado, com todas as suas opções descritas. Na figura 2, o menu é
substituído por um botão que precisa ser clicado para que as opções sejam
apresentadas. Outro ponto importante é que, na figura 1, a opção de login
ganha destaque no lado direito superior e, na figura 2, não aparece claramente.
Isso é o que chamamos de “responsivo”, ou seja, o site se adéqua aos
diferentes tipos de dispositivos, sem perder suas funções principais. Muitas
empresas ainda têm dificuldades em lidar com diferentes tipos de dispositivos;
portanto, acabam ocorrendo cortes de telas e perdas de funções.
Um ponto interessante é que, para obter mais benefícios de cada plataforma e
equipamento, o desenvolvimento nativo nas plataformas é mais eficiente,
porque utiliza melhor os recursos dos equipamentos. No entanto, esse não
deve ser o ponto principal de decisão, mas sim o quanto a utilização desses
recursos melhora a experiência do usuário e reduz a complexidade do
processo de desenvolvimento.
Uma experiência positiva de usuário tem por objetivo a utilização equilibrada
entre textos e imagens, de forma que, ao utilizar a aplicação, o usuário
encontre facilidades, como serviços que apresentem dados preenchidos
automaticamente, a partir da recuperação de dados já preenchidos ou já
existentes dentro da empresa. Por exemplo: se for necessário ter o endereço
do usuário, pedir a ele para preencher o CEP, buscando os dados como
logradouro, cidade e estado, a fim de que o usuário somente os valide e
preencha o mínimo possível de informações.
3 Comunicação e conectividade
Segundo Lee, Schneider e Schell (2005, p. 33), quando se desenha uma
arquitetura para aplicações móveis, deve-se considerar três tipos de
comunicação e conectividade:
• Sempre conectado: é quando os usuários estão sempre conectados às
aplicações.
• Parcialmente conectado: é quando permite ao usuário executar
funções, mesmo quando não está conectado a uma rede ou à internet.
• Nunca conectado: é quando permite ao usuário executar funções, menos
quando o dispositivo não permite conexão a uma rede ou à internet. É
importante que, no desenho da arquitetura, sejam considerados o tipo de
usuário e o tipo de conectividade de cada um, para então definir a melhor
estratégia de sincronização de aplicações.
4 Sincronização de aplicações
Segundo Lee, Schneider e Schell (2005, p. 33):
O tipo de conexão afeta a maneira como você pode sincronizar dados entre o
dispositivo móvel e sistemas back-end. A sincronização
pode ser efetuada de duas maneiras: continuamente ou através de
um método de armazenamento e encaminhamento.
Na comunicação contínua, as sincronizações de dados entre clientes e
servidores são contínuas e podem ser obtidas por meio síncrono
ou assíncrono.
• Comunicação síncrona: ocorre quando uma solicitação para armazenar
dados é enviada para o servidor, seguida pelos dados a serem armazenados.
Os dados são então colocados em uma área de armazenamento, como um
banco de dados, no servidor. Na comunicação síncrona, todos os dados são
completamente armazenados antes que o servidor confirme o recebimento
deles e libere a interface com o cliente.
• Comunicação assíncrona: ocorre quando uma solicitação para armazenar
dados é enviada para o servidor, seguida pelo armazenamento de dados. Os
dados são então colocados em uma área de armazenamento, como um banco
de dados, no servidor. Entretanto, na comunicação assíncrona, os dados não
precisam ser armazenados completamente antes que o servidor dê a
confirmação ao cliente. De fato, o servidor, em geral, confirma imediatamente a
solicitação e somente depois executa a solicitação de armazenamento. Em
seguida, quando a solicitação de armazenamento estiver de fato completa, o
servidor iniciará uma conversa para informar ao cliente que está pronto.
A comunicação pelo método de armazenamento e encaminhamento é para as
situações nas quais a conectividade entre cliente e servidor não pode ser
garantida. Suponha que um usuário móvel queira inserir dados enquanto o seu
dispositivo móvel não esteja conectado a um servidor. Uma aplicação cliente
móvel inicialmente pode armazenar em um banco de dados local. Mais tarde,
quando uma conexão for estabelecida, a aplicação móvel encaminhará os
dados do banco de dados local para o banco de dados no servidor. Armazenar
e encaminhar é um método que dá aos usuários móveis a capacidade de
trabalhar mesmo quando não estão conectados a um servidor
No entanto, é importante notar que, se for permitido aos usuários móveis
armazenar dados em um banco de dados local desse modo, também será
preciso assegurar a integridade dos dados quando estes forem sincronizados
com o banco de dados do servidor, já que outros usuários podem estar
adicionando ou modificando dados que possivelmente podem estar em conflito
com os dos dispositivos móveis.
Capítulo 5 – Estrutura de microsserviços
As APIs têm a função de conectar dois programas de computador, assim como
web services, troca de arquivos de texto, etc. Na SOA, podemos afirmar que
todos os web services são APIs, mas nem todas as APIs são web services. O
que ocorre é que os web services vêm sendo utilizados para comunicações
entre máquinas e requerem servidores e comunicações por rede, enquanto as
APIs vêm sendo utilizadas nas comunicações entre programas, principalmente
em aplicativos móveis. Portanto, os web services são APIs que se comunicam
por rede.
Algumas empresas vêm disponibilizando APIs para que os programadores
possam utilizá-las em suas aplicações. Entretanto, considere os temas de
segurança envolvidos, para saber se as APIs disponibilizadas atendem aos
critérios técnicos necessários.

Segundo a Red Hat ([s. d.]), os microsserviços são uma arquitetura e uma
abordagem para escrever programas de software. Com eles, as aplicações são
desmembradas em componentes mínimos e independentes. Diferentemente da
abordagem tradicional monolítica, em que toda a aplicação é criada como um
único bloco, os microsserviços são componentes separados que trabalham
juntos para realizar as mesmas tarefas. Cada um dos componentes ou
processos é um microsserviço. Essa abordagem de desenvolvimento de
software valoriza a granularidade, a leveza e a capacidade de compartilhar
processos semelhantes entre várias aplicações. Trata-se de um componente
indispensável para a otimização do desenvolvimento de aplicações para um
modelo nativo em nuvem.
Quando adotamos uma arquitetura baseada em microsserviços, devemos levar
em consideração o nível de granularidade. Como o próprio nome diz,
microsserviços podem ser entendidos como serviços menores. Quando
trabalhamos com aplicações com microsserviços, devemos considerar o
gerenciamento e a orquestração dos microsserviços. Apesar do desafio de
gerenciamento envolvido com os microsserviços, trata-se de uma arquitetura
que vem sendo amplamente utilizada em projetos de modernização tecnológica
e migração de sistemas monolíticos em aplicações mais versáteis. Um exemplo
importante é o projeto de open banking que permitirá aos correntistas
compartilharem seus dados bancários com outras instituições financeiras e,
com isso, obter melhores condições em empréstimos e investimentos. Para
isso, os bancos terão que desenvolver microsserviços e APIs que permitirão
essa comunicação entre instituições financeiras.
Um ponto importante é que microsserviços são uma arquitetura,
enquanto APIs são meios de comunicação e integração entre aplicações.
Normalmente, as APIs são utilizadas como meio de comunicação entre os
microsserviços.
2 Aplicação de negócio
Em uma aplicação de negócio, temos vários aspectos que podem ser utilizados
e transformados em serviços.
Essa arquitetura de microsserviços está granularizada e permite um
desenvolvimento independente e com equipes distintas atuando em conjunto.
Enquanto uma equipe desenvolve o módulo login, outra pode desenvolver a
execução de pesquisa. Esse modelo também permite que a aplicação seja
entregue à medida que seja desenvolvida e testada. Cada um dos
microsserviços pode ser desenvolvido, testado e implementado. Nesse tipo de
abordagem, também é possível ter um processo de integração contínua
(DevOps).
Podemos notar que esses microsserviços são autônomos. Podem ser
desenvolvidos, testados, implementados, operados e principalmente escalados
sem afetar o funcionamento de outros microsserviços. Eles podem ou não
compartilhar códigos, e cada um é especializado e cumpre uma determinada
função. Futuramente, podem ser desmembrados ou incorporados a outros
microsserviços. Uma vantagem das APIs sobre os web services é que as APIs
permitem a utilização de CRUDs (create, read, update, delete ou criar, ler,
atualizar, deletar). Nesse modelo de microsserviços, será possível criar novas
pesquisas de produtos sem necessitar alterar códigos, ou seja, os usuários
podem desenvolver novas pesquisas ou até mesmo excluí-las.
3 Estrutura e conectividade
As estruturas e os métodos de conexão dos microsserviços podem variar de
acordo com a necessidade de cada aplicação, mas, de uma forma geral, a
estrutura mais comum é a representada na figura 1, no caso de um modelo da
Microsoft, mas que também é encontrado em outros provedores de serviços
que utilizam arquitetura de microsserviços como base em seu
desenvolvimento.
Esse modelo de arquitetura e conectividade prevê três tipos de aplicações que
podem consumir os microsserviços, sendo duas aplicações para usuários que
estejam fora da organização (aplicativo mobile cliente e WebApp SPA cliente) e
uma aplicação para usuários que estejam dentro do domínio corporativo
(WebApp MVC cliente), desenvolvida em três camadas. Todas as
comunicações entre essas três aplicações passam pelo API gateway, que é
responsável pelo gerenciamento das comunicações e integrações. No caso da
arquitetura da Microsoft, são disponibilizados o ambiente para o desenvolvedor
(portal do desenvolvedor) e o portal de publicação. O API gateway é
responsável pela realização das chamadas aos microsserviços e pelo envio do
retorno dos resultados do processamento.
Conforme comentado anteriormente, esse tipo de arquitetura oferece uma
oportunidade de escalar os serviços de forma independente. Caso os
microsserviços estejam instalados em servidores independentes, habilita-se a
possibilidade de alocar mais servidores e aumentar a capacidade de
processamento.
Consideremos como exemplo um hospital. Normalmente, os hospitais fazem
previsões de quantos pacientes vão receber em um determinado período, mas
sempre é possível que haja um aumento da demanda, por causa de doenças
ou até mesmo de tratamentos eletivos, como exames. Mesmo com as
previsões, pode ser que, em um determinado momento, haja um aumento
expressivo pela consulta de exames. Para suportar esse aumento expressivo
na consulta on-line de exames, caso conte com uma arquitetura baseada em
microsserviços, o hospital poderá aumentar a carga de processamento
(servidores) em relação ao microsserviço de consulta de exame, e os usuários
não sofrerão problemas decorrentes disso, como lentidão ou dificuldade de
acesso.
Essa estrutura de servidores que armazenam microsserviços é chamada de
contêiner. Os contêineres são independentes e podem ser criados
automaticamente à medida que se aumenta a demanda. Isso é gerenciado pelo
Kubernetes, que pode aumentar ou diminuir a capacidade de processamento à
medida que haja aumento ou diminuição da demanda por determinado serviço.
Para facilitar esse processo, o Docker possibilita o empacotamento do
microsserviço dentro de um contêiner, agilizando e facilitando o gerenciamento
de toda a infraestrutura da aplicação.
Esse modelo de arquitetura é potencializado quando a companhia utiliza uma
infraestrutura baseada em computação em nuvem
Capítulo 6 - Arquiteturas de desenvolvimento para computação em nuvem
A computação em nuvem é um tema que permite às empresas desenvolverem
estratégias mais dinâmicas, com maior flexibilidade em termos de ajustar a
infraestrutura à necessidade de negócios. Aplica-se tanto em grandes
empresas que requerem infraestrutura robusta, governança eficiente e alto
grau de segurança como em empresas de pequeno porte e startups que não
desejam fazer grandes investimentos em infraestrutura e sistemas logo no
início de seu negócio.
Temos que olhar a computação em nuvem não somente como infraestrutura,
mas também como um modelo de arquitetura no qual é possível consumir
serviços já existentes e que atuam como aceleradores no desenvolvimento de
qualquer aplicação.
1 Capacidades em nuvem (software, plataforma e infraestrutura como serviço)
Segundo Fernandes e Abreu (2014, p. 283), o gerenciamento da capacidade
[...] assegura que a capacidade de infraestrutura de tecnologia da informação
absorva as demandas evolutivas do negócio de forma eficaz e dentro do custo
previsto, balanceando a oferta de serviços em relação à demanda e otimizando
a infraestrutura necessária à prestação dos serviços de tecnologia da
informação. Nuvem engloba:
• todo o hardware (PCs, servidores, etc.);
• todos os equipamentos de rede (LAN, WAN, bridges, roteador, internet, etc.);
• todos os periféricos (armazenamento, GED, impressoras, etc.);
• todos os softwares (sistemas operacionais, redes, pacotes, sistemas internos,
etc.);
• recursos humanos nas situações em que a falta de recursos humanos pode
resultar no atraso de um tempo de resposta (exemplo: falta de um operador de
backup).
Independentemente do segmento em que a empresa atua, uma das
informações de maior relevância é o quanto e quando seus serviços serão
demandados. Quando se consegue estimar de forma correta a demanda da
empresa, fica mais fácil planejar os recursos que devem ser alocados.
Esse planejamento, a partir das demandas previstas, faz com que a empresa
consiga chegar a um nível adequado de atendimento. Ao entender a demanda,
é possível identificar se há capacidade ociosa ou necessidade de aportar mais
recursos. O grande desafio é alinhar a capacidade com a demanda. O
entendimento da demanda envolve questões de ordem pontual, que acontecem
uma única vez ou durante um período e depois desaparecem, e demandas de
ordem repetitiva. As demandas repetitivas podem ser classificadas em
independentes, sem correlação com outras demandas, e dependentes, ligadas
a outras demandas.
Um gestor pode imaginar o pior cenário possível e adquirir infraestrutura para
suportar esse cenário, entretanto, quando a empresa não consome os
recursos, essa disponibilidade de capacidade é puro desperdício. Por outro
lado, quando o gestor é otimista e adquire infraestrutura considerando
momentos de baixa utilização, corre o risco de não conseguir suportar a
demanda de negócios e de gerar indisponibilidade de serviços.

Ao avaliar o gráfico 1, podemos perceber que o volume de vendas varia a cada

período e a capacidade de processamento é fixa no indicador 10, isso porque a
capacidade de fornecimento de serviços é baseada em uma infraestrutura
definida. O que acontece quando o volume de vendas é superior à capacidade
de processamento? Certamente, a resposta é que clientes não serão atendidos
e, por conseguinte, vendas deixarão de ser realizadas, gerando impactos para
a empresa. Por outro lado, temos uma outra situação: o que acontece quando
o volume de vendas é inferior à capacidade de processamento oferecida? A
resposta é que há ociosidade de capacidade de processamento. Nas duas
situações, ocorrem perdas financeiras.
Para otimizar esse cenário de incertezas, a computação em nuvem pode ser
uma solução, na qual o contratante dos serviços pagará pelo serviço utilizado,
ou seja, quando a capacidade de processamento é ajustada à demanda de
serviços, permitindo ter uma infraestrutura escalável e elástica. Esses
conceitos de escalabilidade e elasticidade são a base da computação em
nuvem.
A escalabilidade permite que as capacidades tecnológicas cresçam de acordo
com as demandas de negócios, e a elasticidade significa que a capacidade é
ajustada à demanda.
Dada a dificuldade de se fazer previsões em um cenário cada vez mais
competitivo, a computação em nuvem surge como alternativa para manter os
custos de acordo a demanda, evitando desperdícios ou falta de capacidade
para atender a demandas não planejadas.
O Olhar Digital define computação em nuvem como sendo “um formato de
computação no qual aplicativos, dados e recursos de TI são disponibilizados
aos usuários como serviço, por meio da internet, e pagos de acordo com o uso”
(OLHAR DIGITAL, 2014).
A comparação de custos entre os modelos tradicionais (adquirir e manter
infraestrutura) e de serviço em nuvem deve ser analisada sobre os prismas de
tempo para adquirir e instalar espaço físico, pessoal, atualização de patches,
monitoramento, entre outras necessidades, além de gerenciamento de serviço
de terceiros, garantindo eficiência e segurança nas informações. É natural que
contratar serviços seja mais rápido do que os adquirir. Além disso, há
mudanças frequentes de negócios, que geram uma pressão muito grande em
tecnologia da informação para adaptação. Esses fatores, alinhados aos riscos,
em ambos os cenários, devem ser avaliados para decidir qual a melhor
alternativa para cada operação.
Por ser um conceito, a computação em nuvem pode ser comprada por meio de
fornecedores, mas também pode ser desenvolvida por uma empresa. Quando
a empresa desenvolve uma estrutura de computação em nuvem totalmente
administrada por ela, isso é chamado de on-premise. Nesse caso, devem ser
avaliados o tempo para implantação, as capacidades a serem adquiridas, os
conhecimentos a serem desenvolvidos, entre outros. Muitas empresas já
contam com servidores virtualizados e técnicas de computação em nuvem, por
isso, quando da introdução de novos serviços, estes conseguem decidir o
melhor modelo. Para o usuário, esse modelo é transparente, e muitas vezes
não importa onde o serviço está sendo executado. Para o cliente, devido aos
critérios de custos e riscos, é importante que estes sejam compartilhados e
discutidos previamente (VERAS, 2011).
As categorias de serviços em nuvem: IaaS, PaaS, SaaS e outras
categorias emergentes
Quando adotamos estratégias para migração para nuvem, devemos considerar
o modelo mais adequado para cada organização e serviço oferecido. Uma
mesma organização pode ter diferentes estratégias, obtendo assim melhores
resultados de acordo com a capacidade de processamento requerida, o tipo de
arquitetura da aplicação, entre outros fatores que normalmente envolvem
negociação com provedores de serviços em nuvem

No modelo on-premise, toda a gestão da infraestrutura é realizada pela própria

equipe da organização. Trata-se de um modelo mais tradicional, no qual boa
parte das aplicações foram construídas e há mais dificuldade em escalar as
aplicações.
No modelo IaaS (infrastructure as a service ou infraestrutura como serviço), os
servidores são instalados em nuvem, mas a aplicação e o middleware são
gerenciados pela própria organização. Com isso, pode-se obter maior
flexibilidade na infraestrutura, garantindo maior celeridade à medida que haja
necessidade de demanda. Por exemplo, se uma determinada aplicação requer
mais memória RAM para ter uma performance melhor, pode-se contratar essa
ampliação na nuvem e, com isso, garantir maior disponibilidade. O ponto a
considerar nesse modelo é que há restrições para o crescimento caso a
aplicação não consiga reconhecer a maior disponibilidade da infraestrutura
contratada.
No modelo PaaS (platform as a service ou plataforma como serviço), os
servidores e o middleware são instalados em nuvem, mas a aplicação é
gerenciada pela própria organização. Nesse modelo, é possível obter maior
flexibilidade na infraestrutura e integrações. O ponto a considerar nesse
modelo é que há restrições para o crescimento caso a aplicação não consiga
reconhecer a maior disponibilidade de infraestrutura contratada.
No modelo SaaS (software as a service ou software como serviço), toda a
aplicação, bem como os dados, os recursos de middleware e a infraestrutura, é
instalada em nuvem. Nesse modelo, é possível obter maior flexibilidade e
escalabilidade em toda a aplicação, ampliando recursos de acordo com a
necessidade, seja na aplicação, no middleware ou na infraestrutura. No SaaS,
é possível também fragmentar a aplicação em contêineres e, com isso, aportar
mais recursos à medida que forem requeridos. O ponto a considerar nesse
modelo é que, à medida que a aplicação cresce, é importante realizar limpezas,
a fim de que não se incorra em custos desnecessários na nuvem.

3 Modelos de entrega de serviços: nuvem pública, privada e híbrida

• Nuvem pública: quando a empresa compartilha os recursos com outras
empresas. Obviamente, tem um custo menor.
• Nuvem privada: quando a empresa não compartilha os recursos com outras
empresas. Obviamente, tem um custo maior.
• Nuvem híbrida: quando a empresa decide adotar tanto a nuvem pública
quanto a nuvem privada. Por exemplo: aplicações críticas ficam em nuvem
privada e aplicações de apoio ficam em nuvem pública.

4 Desenvolvimento de aplicações e serviços para ambiente de

computação em nuvem
Ao considerarmos o desenvolvimento de aplicações em ambiente de
computação em nuvem, uma gama de possibilidades adicionais é apresentada.
Entre elas, a escalabilidade e a elasticidade, além de uma série de serviços
que já são disponibilizados em cada ambiente de computação em nuvem.
Cada provedor de serviços em nuvem, como AWS, Azure, Google, Oracle e
Huawei, oferece serviços distintos, por exemplo, banco de dados, e a
possibilidade de utilizar um banco de dados proprietário, como SQL, Oracle e
HANA.
Por exemplo, podemos desenhar uma aplicação na AWS utilizando o Amazon
Aurora, que é o banco de dados relacional da AWS, ou mesmo o SQL Server
da Microsoft na nuvem AWS. Essa flexibilidade é muito importante quando
você já tem uma aplicação e está migrando-a para a nuvem, mas também
quando a organização tem uma condição comercial com os parceiros que
favoreça esse tipo de transação. De qualquer forma, no momento que o projeto
da aplicação está sendo desenhado e seus serviços estão sendo estruturados,
vale a pena consultar os serviços que já existem na nuvem. Isso pode ser um
acelerador importante em seu projeto e´permitir que ele seja habilitado o mais
cedo possível.

Cabe ao arquiteto conhecer os produtos e traçar uma estratégia que seja a

mais indicada para cada aplicação que se deseja desenvolver em nuvem.

Aula Narrada – IT doesn’t matter, ou TI não importa

Capítulo 7 Aspectos da arquitetura em nuvem
1 A relação entre virtualização e computação
em nuvem
Para compreendermos a virtualização, é importante entender o contexto
organizacional. Quando uma organização deseja desenvolver uma
nova aplicação, ela deve considerar a infraestrutura necessária para
essa aplicação.
Conforme estudamos anteriormente, uma aplicação típica contém:
• banco de dados instalado em um servidor;
• componentes e funcionalidades, como DLL, que ficam em outro
servidor;
• camada visual, ou seja, as telas pelas quais o usuário navega, que
ficam em um terceiro servidor.
Nesse modelo de arquitetura, conforme estudamos anteriormente,
são combinadas questões de independência, flexibilidade, escalabilidade
e segurança.
Para contextualizar o tema sob a ótica da virtualização, relembremos
o modelo típico da arquitetura de três camadas (cliente-servidor).

Ao adotarmos a virtualização, esses servidores podem ser transformados em

servidores virtuais e estarem todos instalados fisicamente em um mesmo
servidor físico, respeitando assim sua necessidade de independência, pois
podemos ter um sistema operacional para o servidor de banco de dados,
distinto do sistema operacional do servidor visual. Como sabemos, em um
servidor físico isso não é possível, pois teríamos que ter apenas um único
sistema operacional

A virtualização desvincula as aplicações e o sistema operacional dos recursos

físicos e acaba por agilizar e permitir o surgimento de uma plataforma virtual.
Servidores virtuais são mais fáceis de serem instalados, gerenciados e
migrados para um novo ambiente. Os ambientes de testes e desenvolvimento,
necessários para as aplicações empresariais, são facilmente montados com a
otimização dos recursos acarretada para virtualização (VERAS, 2016).
Em ambientes nos quais seja necessário oferecer uma alta disponibilidade dos
serviços, como sites de e-commerce e marketplace, a virtualização é um
importante aliado. À medida que a demanda (acessos) aumente
repentinamente e, com isso, seja necessário habilitar novos recursos de
infraestrutura, a virtualização habilitará novos servidores virtuais, adequando a
capacidade de processamento à demanda requerida.
Esses servidores virtualizados permitem a criação de novos servidores virtuais
de maneira rápida, como um simples copiar de arquivos que temos no
Windows Explorer. Em algumas arquiteturas, é possível inclusive habilitar e
desabilitar VMs de forma automatizada, de acordo com a necessidade.
Para implementar a virtualização de servidores, será necessário contar com
softwares específicos, como o VMware, que requer a aquisição de licenças.
Adicionalmente, deve-se considerar que os ambientes virtualizados
requerem os mesmos acordos de licença de software que os ambientes
físicos, por exemplo, licenças de sistema operacional e licenças de banco
de dados.
Como vimos anteriormente, a nuvem oferece a possibilidade de adequar a
infraestrutura à demanda, por isso a virtualização é a tecnologia central da
nuvem, na medida em que permite aperfeiçoar o uso dos recursos e viabilizar o
modelo de computação sob demanda (VERAS, 2016).
2 Definição de nível de serviço e acordo de nível de serviço (SLA)
Os processos de níveis de serviços têm por objetivo melhorar a qualidade dos
serviços de TI por meio de um ciclo contínuo de atividades envolvendo
planejamento, coordenação, elaboração e estabelecimento de um acordo de
metas de desempenho e responsabilidades mútuas, monitoramento e
divulgação de níveis de serviço (em relação aos clientes) e níveis operacionais
(em relação aos fornecedores internos) e contatos de apoio com fornecedores
de serviços externos. Esse processo também é responsável pela elaboração e
manutenção de um plano de melhoria de serviços, um programa com ações
priorizadas de melhoria para os serviços (FERNANDES; ABREU, 2014).
Os acordos de nível de serviço (service level agreements – SLAs) envolvem
uma negociação complexa com todos os envolvidos. É natural que os usuários
queiram um serviço à prova de falhas (100% de disponibilidade), que o cliente
queira um serviço barato e que a área de TI e os fornecedores envolvidos
queiram ter uma certa flexibilidade e operar com níveis que permitam
manutenções programadas e não previstas, uma vez que, em um ambiente em
constante evolução, é normal ter um período de interrupções.
Os acordos de nível de serviço devem ser formalizados e são comumente
encontrados em contratos e dispositivos de serviços. Eles definem os acordos
com as áreas de negócios. Por exemplo, a área de negócios espera que o app
fique disponível 99% do tempo, sete dias na semana. Para que os serviços de
negócios se mantenham disponíveis, a área de TI deve realizar acordos com
fornecedores internos e externos.
Para fornecedores internos, utiliza-se o acordo de nível operacional
(operational level agreement – OLA), enquanto o contrato de apoio
(underpinning contract – UC) é realizado com fornecedores externos,
normalmente com cláusulas específicas de prestação de serviços, uma vez que
a área de TI pode ter que contratar mais de um fornecedor para a realização do
serviço.
Esses acordos de nível de serviço têm por objetivo garantir as metas e
expectativas em relação aos serviços executados pelos prestadores de
serviços externos. Normalmente, os fornecedores oferecem serviços diversos,
e cada um conta com um nível de serviço diferenciado. É necessário mapear
todos os fornecedores da cadeia de fornecimento e verificar se os níveis de
serviço estão alinhados. É muito comum as organizações de TI contratarem
serviços com níveis diferentes ou, ainda, com níveis de serviço não
relacionados, o que pode prejudicar diretamente o nível de serviço esperado
por negócios.

3 Disponibilidade e capacidade
O gerenciamento da capacidade assegura que a capacidade da área de TI
absorva as demandas evolutivas do negócio de forma eficaz e dentro do custo
planejado com as áreas de negócios. Durante o desenho do serviço, deve ser
identificada a capacidade necessária para assegurar a demanda prevista na
estratégia do serviço (FERNANDES; ABREU, 2014).
Na avaliação de capacidade, deve-se observar as demandas atuais, mas,
sempre que for necessário, rever a infraestrutura dos serviços. Devemos
considerar se a capacidade instalada é suficiente; caso contrário, haverá
interrupções nos serviços, afetando diretamente a disponibilidade.
O gerenciamento da disponibilidade permite otimizar o uso dos recursos,
antecipar e avaliar falhas previstas, implementar políticas de segurança e
monitorar os objetivos dos acordos de serviço (FERNANDES; ABREU, 2014).
Ao mesmo tempo em que os avanços tecnológicos permitiram sistemas mais
estáveis e tolerantes a falhas, a interdependência dos processos de negócios e
das operações de TI chegou a tal ponto que, se a tecnologia parar, o negócio
também para. Como principais fatores de qualidade, a disponibilidade e a
confiabilidade de um serviço são elementos decisivos em um mercado
competitivo. Por meio de um gerenciamento da disponibilidade eficaz, é
possível influenciar a satisfação do cliente e, com isso, determinar a vantagem
competitiva do negócio no mercado.
O gerenciamento da continuidade de serviços visa garantir que os recursos de
TI possam ser retomados dentro dos períodos requeridos e acordados com o
negócio. O gerenciamento da continuidade de serviços deve ser planejado de
acordo com as expectativas de negócios e as perdas geradas com a
interrupção de um determinado serviço. Devem ser identificados os processos
de negócios e os riscos de sua interrupção, a partir dessa matriz. Para cada
serviço, deve-se estabelecer o plano de recuperação necessário por meio dos
gatilhos a serem disparados quando da interrupção; por exemplo: ações a
serem tomadas e quem deve ser escalado.
É preciso considerar as pessoas que devem ser informadas para tomar ação
de recuperação dos serviços e as pessoas que devem ser avisadas para traçar
estratégias de comunicação internas e externas. Entre as estratégias mais
comuns de continuidade de negócios, podemos citar backups, sites de
contingência, ambientes de alta disponibilidade, entre outros. Como os custos
podem variar significativamente, é importante que a área de TI busque
alternativas que visem manter a continuidade de negócios, considerando todos
os recursos disponíveis, e não somente a contratação de serviços externos.
É importante refletir que a disponibilidade não se compra. Ela precisa ser
definida, desenhada, implementada, medida e gerenciada. Os objetivos do
gerenciamento da disponibilidade são alcançados pela determinação dos
requisitos de disponibilidade do negócio, relacionando-os com a
capacidade de TI e as áreas de suporte.
O gerenciamento da disponibilidade deve ser aplicado a todos os serviços em
que tenham sido estabelecidos acordos de nível de serviço ou, ainda, em
serviços críticos, mesmo que não haja acordos formais. A disponibilidade
depende de:
• disponibilidade dos componentes;
• resistência a falhas;
• qualidade do serviço de manutenção e suporte;
• qualidade, padrão e abrangência dos processos e procedimentos
operacionais;
• segurança, integridade e disponibilidade de dados.
Segundo Fernandes e Abreu (2014), a estrutura do gerenciamento da
disponibilidade compreende:
• determinar requerimentos;
• definir metas;
• estabelecer métricas e relatórios;
• monitorar e analisar tendências;
• revisar;
• investigar problemas;
• produzir e manter um plano de disponibilidade.
O grau de confiabilidade e resistência de cada componente é peça- -chave do
processo. Uma vez que falhas vão acontecer, o que vai determinar o nível de
satisfação dos clientes e usuários é a capacidade de manter e
restabelecer um determinado serviço. Técnicas que visem à antecipação
de falhas e manutenções preventivas auxiliam a manter os serviços
disponíveis.
Para iniciar, considere analisar as tendências de disponibilidade dos
componentes de TI e o quanto elas estão aderentes aos acordos de nível de
serviço. Reveja os índices que estão abaixo dos acordos e investigue as ações
pelas quais os níveis ficaram abaixo. Pode ser uma implantação de um novo
sistema, uma troca na rede, entre outros fatores que poderiam ter sido
planejados previamente, mas pode também ser alguma falha inesperada, como
um crash de disco que não estava sendo monitorado ou um crescimento
inesperado (pico de demanda). Após entendidas as ações necessárias, estas
devem ser analisadas sobre o prisma de custos e discutidas com as áreas de
negócios, a fim de aportar novos investimentos ou, ainda, rever o nível de
serviço. Esse ponto costuma ser bem sensível, uma vez que a empresa espera
que o profissional de TI ache uma solução rápida para o problema. Entretanto,
ações de contorno se tornarão frequentes e exigirão do profissional de TI maior
dedicação, e, evidentemente, podem causar prejuízos à operação. Por fim, é
preciso criar e manter um plano de disponibilidade que priorize e planeje as
ações de melhorias.
A medição da disponibilidade deve ser feita considerando o prisma de
negócios. Por exemplo: impacto por minuto perdido e impacto por
transação perdida. Esses indicadores são claros para clientes e usuários
e facilitam o estabelecimento de acordos razoáveis.
Existem dois modelos de arquiteturas para serviços:
• Arquitetura em série: quando há dependência entre os diferentes
componentes para entrega de um determinado serviço.
Nesse tipo de arquitetura, quando um dos componentes falha, todo o serviço é
interrompido, até que o reparo seja executado. Uma preocupação adicional
nesse tipo de arquitetura é quando outros serviços também consomem
componentes ou, ainda, quando estes podem sobrecarregar o serviço em si.
Para entender a disponibilidade nesse tipo de serviço, é possível fazer um
cálculo matemático. Por exemplo:
◦ Servidor visual: 90% de disponibilidade.
◦ Servidor de componentes: 85% de disponibilidade.
◦ Servidor de banco de dados: 87% de disponibilidade.
Para apurar a disponibilidade do serviço, multiplicamos os percentuais de
cada componente: 0,9 × 0,85 × 0,87 = 0,6655, ou seja, a disponibilidade
desse serviço será de 66,55%. Caso esse fosse um serviço de vendas on-
line, dificilmente uma empresa aceitaria esse percentual. Para serviços de
vendas on-line, o nível de serviço esperado gira em torno de 95%.
• Arquitetura em paralelo: modelo em que, quando um dos componentes
apresenta falha ou está sobrecarregado, um componente idêntico assume a
operação. Este modelo também é conhecido como “alta disponibilidade”.
Ao adicionar servidores em paralelo, faz-se necessário também adicionar
servidores e outros serviços de controle para distribuição, balanceamento do
processamento e virtualização. Essas ferramentas permitem entender quando
um determinado servidor está falhando ou sobrecarregado e automaticamente
aciona a habilitação de novos servidores. Nesse cenário, as falhas não são
perceptíveis aos usuários finais. Isso é frequente em sites de vendas na
internet, pois, à medida que a demanda aumenta, novos servidores são
adicionados ao processo para garantir a escalabilidade e, à medida que a
demanda diminui, os servidores não necessários são desligados.
Evidentemente, o custo é maior, mas garante maior disponibilidade dos
serviços (VERAS, 2016).
A fórmula para calcular a disponibilidade nesse tipo de arquitetura é baseada
em não disponibilidade. Considerando o exemplo anterior, vamos assumir a
seguinte indisponibilidade:
◦ Conjunto de servidores visuais: 2%.
◦ Conjunto de servidores de componentes: 1%.
◦ Conjunto de servidores de banco de dados: 1%.
Logo: 1 – (0,02 × 0,01 × 0,01) = 99,99%.
Esse nível de disponibilidade compreende apenas paradas não previstas;
normalmente, paradas planejadas não são consideradas como
indisponibilidades.
A questão do paralelismo também pode estar na nuvem, ou, ainda, pode haver
arquiteturas mistas entre paralelismo e em série. Por exemplo: servidores web
e aplicações em paralelo e banco de dados em série com os outros servidores.
Nesse caso, dois cálculos devem ser feitos: em série, para os
componentes em série, e em paralelo, para os componentes em paralelo.
Após a realização dos dois cálculos, deve-se utilizar o cálculo em série
para a junção dos componentes em paralelo e em série, porque, uma vez
que há componentes em série, a disponibilidade do serviço seguirá em
série (VERAS, 2016)
CAPÍTULO 8 – ECOSSISTEMA DE COMPUTAÇÃO EM NUVEM
1 Papéis previstos no ecossistema de computação em nuvem e
respectivas atividades críticas
Segundo Santos (2016, p. 47), entre os integrantes que compõem o
ecossistema da computação em nuvem estão os consumidores de produtos e
serviços, os provedores de serviços, os provedores de infraestrutura, os
fornecedores parceiros, os auditores, entre outros atores envolvidos.
Vamos conhecer cada um deles:
• Consumidores de produtos e serviços: são aqueles responsáveis pela
contratação dos serviços, pela definição de estratégias e pelaintegração entre
os diferentes provedores de serviços.
• Provedores de serviços: são aqueles responsáveis por fornecer os serviços
em nuvem. Por exemplo: Google, AWS, Huawei, Azure, entre outros.
• Provedores de infraestrutura: são aqueles responsáveis pelo fornecimento da
infraestrutura necessária para o funcionamento dos serviços em nuvem, como
internet, fibra ótica e elefonia, e demais itens necessários para a organização
alcançar a nuvem.
• Fornecedores parceiros: são aqueles responsáveis por licenças de softwares,
desenvolvimento de aplicações, definição dos serviços em nuvem (SaaS) a
serem utilizados e manutenção das aplicações.
• Auditores: são aqueles responsáveis pela verificação dos serviços disponíveis
em computação em nuvem, pela segurança da informação, entre outros
aspectos relacionados a avaliações gerais dos serviços.
• Outros atores envolvidos: são aqueles que podem ser envolvidos de acordo
com a estratégia da organização, como especialistas em migração de dados e
segurança da informação, designers, entre outros.
Com o crescimento da utilização da computação em nuvem, novos papéis vêm
surgindo a todo momento, assim como algumas entidades para definição de
padrões e evolução do setor. Uma delas é o National Institute of Standards and
Technology (NIST), baseado nos Estados Unidos. O NIST tem atuado
fortemente em arquiteturas de referência. Segundo o NIST (2019), devemos
considerar também o broker (corretor de nuvem). O broker é responsável por
escolher o provedor de serviços que vai oferecer a melhor condição que os
consumidores de produtos e serviços procuram a partir dos serviços que
desejam executar pela computação em nuvem.
Um outro uso bastante conhecido é o de múltiplas nuvens (multi- -cloud), por
exemplo, quando uma determinada aplicação requer mais recursos para uma
campanha comercial para o Natal. Nesse caso, as informações geradas para a
campanha podem estar em uma nuvem diferente de onde a aplicação principal
esteja hospedada.
Nesse cenário, ainda podemos ter uma aplicação governamental, na qual, à
medida que há um uso mais intenso das aplicações, os serviços podem ser
direcionados em diferentes nuvens, aproveitando as melhores condições
técnicas e financeiras.
Os provedores de serviços oferecem pacotes de serviços que variam de acordo
com volume de dados, tipos de plano (mensal ou sob demanda), quantidade de
servidores, entre outros. Isso pode fazer com que os preços variem bastante,
por isso o broker ganha espaço para ajudar os consumidores de produtos e
serviços na melhor estratégia técnica e financeira.
Essa é uma configuração em alto nível, que visa apresentar um modelo prático
dos papéis mais comuns dentro do ecossistema em nuvem. Certamente, cada
organização pode configurar isso de diferentes formas. Uma outra forma de
fazer a configuração é de acordo com os papéis existentes dentro da empresa.
Por exemplo, um gestor de serviços em nuvem pode estar com o perfil de
editor, e um arquiteto de nuvem pode estar com o perfil de proprietário. Essa é
uma decisão que cada administrador de serviços em nuvem pode tomar,
inclusive concedendo mais ou menos acesso aos demais integrantes dos
serviços em nuvem.
Outros papéis e configurações podem ser adotados de acordo com a estratégia
de cada organização. O mais importante é que cada organização consiga
entender esses papéis e avaliar a melhor forma de atribuir as funções e obter
mais benefícios com essa configuração. Esse é um processo dinâmico, que vai
mudando à medida que a organização ajusta sua estratégia de negócios
técnica e financeira.
2 Tipos de capacidades em nuvem e delimitação de escopo de
responsabilidade das partes
Segundo Santos (2016, p. 49), a responsabilidade do cliente ou provedor de
serviços está diretamente ligada ao nível em que se terceirizou a carga de
trabalho na nuvem.

Na figura 1, os blocos em azul são gerenciados pela organização de

consumidores de produtos e serviços, enquanto os blocos em verde
representam os serviços administrados pelos provedores. Dessa forma, temos
uma visão clara do modelo inicial on-premise, totalmente administrado pela
organização, até o modelo SaaS, no qual a organização faz o monitoramento
da aplicação, define as políticas de segurança e governança e valida os dados
de faturamento. Assim como a Microsoft, o NIST apresenta um modelo de
gestão de nuvem muito parecido, que, ao final, serve como padrão que ajuda
as organizações a estabelecerem limitações de responsabilidades.
Entretanto, além de analisarmos os serviços e as responsabilidades de cada
um, precisamos discutir o acordo nível de serviço. O acordo nível de serviço é
um pré-requisito para a definição da estratégia para a nuvem e dá suporte a
diretivas técnicas que devem ser assumidas e negociadas junto aos
provedores de serviços.
Neste exemplo, foram utilizados indicadores de negócios (funcionais) de alto
nível. Quando estamos estabelecendo os níveis de serviços, precisamos entrar
em detalhes mais específicos. Por exemplo:
• Garantir a disponibilidade, que normalmente é superior a 99,9999%.
• Informar os tempos de manutenção e indisponibilidade com aviso prévio para
adotar medidas de contingência, definindo o prazo para aviso prévio.
• Referência de tempo de performance, que é a relação da expectativa de em
quanto tempo uma determinada transação precisa ser executada; por exemplo:
a geração de um relatório.
• Disponibilidade das estatísticas dos envolvidos com os serviços em nuvem.
• Tempo que o suporte tecnológico tem para resolver problemas. Nuvens
também podem enfrentar problemas técnicos, portanto é importante avaliar o
nível de serviço oferecido por cada provedor de serviços. Certamente, os
preços variam de acordo com o tempo para solução. Quanto menor o tempo
para solução, maior o custo.
• Tempo para o suporte de como utilizar os serviços em nuvem. Também pode
ser definido um modelo de serviços.
• Tempo para habilitar os serviços em nuvem. Praticamente todos os
provedores de serviços habilitam os serviços quase que imediatamente, após
contratados, mas é importante entender se isso está claramente definido dessa
forma.
Outros elementos que devemos considerar nos serviços em nuvem passam por
políticas e processos que, se não forem compreendidos claramente, podem
gerar problemas para a organização, mas, se forem bem compreendidos e
utilizados, geram benefícios importantes para os projetos em nuvem. São eles:
• Políticas de nível de serviço: as unidades de negócios normalmente vão
requerer serviços que sejam disponíveis todo o tempo, mas isso precisa ser
entendido sob a ótica de custos. Cabe ao administrador buscar formas
eficientes de administração. A disponibilidade dos serviços envolve
funcionamento efetivo da aplicação, tempo para realizar as transações dentro
das funcionalidades das aplicações e tarefas tecnológicas, como uploads e
downloads de dados, execução de rotinas batches, entre outros. Ao definir os
modelos de serviços junto aos envolvidos com as aplicações na nuvem, deve-
se buscar calibrar os serviços na nuvem, bem como os custos e o nível de
serviço necessário. É importante ficar atento às penalidades envolvidas e a
como transferir os serviços para outros provedores, principalmente quando isso
envolver um volume de dados significativo.
• Políticas de nível de dados: este tema é crítico dentro de um nível de serviço,
pois envolve diferentes aspectos de como os dados são governados e
protegidos. Um dos fatores que mais atrasou projetos em nuvem no Brasil foi a
falta de confiança na proteção dos dados. Isso inclusive fomentou leis
obrigando os provedores de serviços a estabelecerem datacenters no Brasil, a
fim de que dados sensíveis brasileiros não estivessem fora das legislações
brasileiras e suscetíveis a fraudes e espionagens entre países e empresariais.
Este tema evoluiu bastante, assim como as organizações e os provedores de
serviços, e há um nível considerável de entendimento sobre a proteção de
dados. Em 2020, foi lançada a Lei Geral de Proteção de Dados Pessoais
(LGPD) (BRASIL, 2018), que envolve aspectos inerentes ao controle de dados
pelas organizações, que devem criar rotinas que pedem autorização aos
clientes para armazenar dados sensíveis, como nome, endereço, telefone e
número de cartão de crédito, e, ao armazená-los, devem criar modos eficientes
de protegê-los, como criptografia e anonimização de dados.

• Diferenças entre modelos de deploy e serviços: mesmo que as diferentes

aplicações de uma empresa estejam hospedadas em um mesmo provedor de
serviços, estes podem ter fluxos de deploy (implantações) distintos, e isso
requer níveis de serviço e controles diferentes. Além disso, a utilização de
ambientes distintos entre produção e não produtivos pode requerer modelos
distintos de serviços. Certamente, o mesmo nível de serviço de produção não
precisa ser replicado nos ambientes não produtivos, por isso podem requerer
níveis de serviços distintos.
• Objetivos para desempenho crítico: normalmente os objetivos estão
relacionados a eficiência do nível de serviço. À medida que os serviços são
administrados por um provedor de serviços, é importante definir como será o
monitoramento e a auditoria do desempenho da nuvem. Portanto, é preciso
definir como o monitoramento será realizado e quais tipos de recursos são
necessários. Os serviços em nuvem contam com um catálogo abrangente de
operações para monitoramento de forma eficiente para aplicações SaaS.
• Segurança e privacidade: segurança e privacidade também devem ter níveis
de serviço estabelecidos. Estes não estão relacionados apenas a dados, mas
também a aplicações, funções e processos, e podem ser definidos de acordo
com a criticidade ou a sensibilidade envolvida com as informações.
Cabe entender a viabilidade econômico-financeira de utilizar os provedores de
serviços em nuvem ou desenvolver seus próprios métodos para garantir o nível
de serviço mais adequado para cada projeto.