FinOps é uma pratica de Cloud Financial Management que vem sendo adotada por empresas, com o objetivo de melhorar os custos na nuvem. Com isso, ter mais controle e previsibilidade no uso de serviços na nuvem.
O senso de ownership é uma mudança essencial para os times, utilizarem seus serviços otimizados na nuvem com o uso de boas praticas, geralmente definidas pelo CCoE (Cloud Cost Center of Excellence). Ademais, deve haver uma boa interação entre áreas da empresa (IT, Finance, Business, etc.) para representar as oportunidades de alavancagem de negócio e financeiro.
Por que FinOps?
Há inúmeros estudos que comprovam o movimento de empresas de on-premise para nuvem, seja por migração ou modernização, existe um grande investimento sendo feito pelas empresas nessa jornada de adoção Cloud.
Fonte: McKinsey
Outro aspecto é o nível de maturidade da empresa nos estágios de adoção de nuvem. Há muitas empresas que ainda estão em “Foundation” e precisam de apoio para otimizar seus custos na nuvem. FinOps é um bom conceito para ser introduzido nesses casos.
1. Informar Nessa etapa, os times iniciam a gestão financeira da nuvem, provendo visibilidade dos custos e alocação de budget apropriado para o uso de serviços.
E assim, adotar a estratégia de tags para facilitar o gerenciamento, busca e filtro dos recursos utilizados. Definir o forecasting de custos com esses recursos. Criar dashboards para acompanhamento dos custos.
2. Otimizar Com a adoção da nuvem e controle financeiro estabelecido, o foco passa a ser na otimização de custos, configurando os recursos para serem utilizamos da melhor forma.
Identificar potenciais savings e cost avoidance com o uso de automações e outrar praticas, tais como:
Tipos de instância EC2: escolher de acordo com a sua necessidade (On-demand | Spot | Reserved | Dedicated) – você possui comprometimento de longo prazo? Já possui previsão na demanda de uso? As instâncias não podem ser interrompidas?
Savings Plans: oferece preços mais baixos (comparado ao on-demand), mas precisa de um comprometimento maior (período de um ou três anos)
Re-architecture ou Re-factoring: evoluir a arquitetura, ou refatorar pode trazer benefícios financeiros
Levers: elasticity, right-sizing, entre outros que vão ajudar a provisionar, monitorar e otimizar o uso dos serviços
“Pay for what you use” para “Pay for what you need”
3. Operar A fase Operar representa a continuidade das praticas estabelecidas na empresa para manter o gerenciamento financeiro e otimização de custos na nuvem.
Também evoluir em obtenção de economia na compra de licenças, taxas, pre-purchase e volume discounts.
Considerações finais
A colaboração (encorajamento e ownership) dos times é essencial para que FinOps tenha bons resultados na empresa. Um time centralizado (geralmente o CCoE) pode direcionar os times, ajudando em aspectos que permitam utilizar as praticas em escala. Medir é essencial para verificar as vantagens obtidas com a otimização de custos na nuvem.
Quantas empresas já não vimos terem dificuldade em manter seus sistemas legados funcionando? Em muitos deles estão os serviços mais rentáveis da empresa, que por sua vez cresceu ou passou algum tempo sem evoluir apropriadamente seus recursos. Como consequência, muita dificuldade em criar novas features e disponbilizá-la aos clientes.
Entre alguns dos ofensores estão problemas na arquitetura (como o alto acoplamento dos componentes), na gestão dos processos ou uso inapropriado de tecnologia. E como melhorar essa abordagem? Muitos casos de modernização falham justamente por ter uma área de TI direcionada a reduzir custos (quando há um alto custo de esforço na modernização), enquanto outros stakeholders estão mais focados no valor para o negócio, porém falta foco.
Abordagem Business Centric
A abordagem de modernização não deve ser IT-centric, e sim considerar value streams e business capabilities para maximizar o impacto dos esforços. A análise top-down com processos de negócios impulsionando a modernização, ajuda a conectar a estratégia do negócio com as tecnologias habilitadoras e um conjunto muito menor de aplicações que precisam ser incluídos business case. Alguns pontos a serem considerados:
Modernização de business capabilitiescríticos. Não coloque o foco da migração em custo ou obsolescência de aplicações em TI.
Utilizar a abordagem business-centric (outside-in). Fica mais claro o retorno do negócio ou problema a ser resolvido.
Gestão dos ciclos de vida de produto ao invés de projetos. Essa visão permite conectar a estratégia da empresa com a contínua evolução das aplicações.
O ideal é ter o budget de modernização por meio de abordagem contínua, dentro de algum produto ou programa, mesmo que seja mais provável de acontecer por meio de algum programa de modenização maior. O Lean Budget é o recomendado por SAFe na gestão de portfolios e criação de business solutions. O budget do portfolio é então direcionado a value streams (não mais a projetos) que oferece uma ou mais soluções de negócios.
Gartner relaciona seis drivers comuns em modernização de aplicações:
■ Business fit ■ Business value ■ Agility ■ Complexity ■ Risk ■ Cost
A organização em torno de business processes apoia o mapeamento de aplicações & base de dados utilizadas nesse contexto de negócios e permitir a modernização em ondas menores. No exemplo abaixo, o fluxo (bem resumido) de um processo de vendas e a interação com as tecnologias habilitadoras.
Estratégia de migração 6Rs
Uma das estratégias mais recomendadas para migração de aplicações em Cloud é o 6R’s da AWS. A complexidade de migração varia, enquanto uma arquitetura orientada a serviços possui baixa complexidade, um mainframe monolítico certamente trará uma alta complexidade. Os critérios de decisão da estratégia de migração devem ser baseados nas necessidades de negócio e técnicas. Veja mais sobre os 6R’s nesse post.
O principal objetivo das empresas que buscam Migração e/ou Modernização de aplicações é reduzir o time to value. A Migração é uma jornada de três fases – Assess, Mobilize e Migrate & Modernize, conforme recomendado pela AWS. A Modernização começa também pelo Assess, seguido de PoC/Piloto para provar o valor e colocar as mudanças em produção.
Assess: avalia o ambiente atual e a prontidão de migração. Ajuda a construir o case para a mudança.
Mobilize: mobilização de workstreams para construir os capabilities e experiência de migração.
Migrate & Modernize: continuidade da migração em ondas e operação / otimização dos ambientes e aplicações. A modernização, em geral, inclui a implementação de microsserviços, containers, DevOps e mainframe modernization.
O plano de migração deve compreender os detalhes do ambiente atual, os dados de aplicações / operacionais e como eles são usados e acessados. As ferramentasde migração consideram análise de Inventário, Business Case, Discovery & Planning, Mapeamento de dependência, Migração e validação de workloads – workloads de SO, Database, Storage, VMWare, SAP e Mainframe são os principais no processo de migração.
Ferramentas
Há ferramentas que apoiam cada fase (Assess, Mobilize e Migrate & Modernize) da jornada de migração. O Migration Evaluator é utilizado no Assess para análise de inventário e do business case. O ADS (Application Discovery Service) no planejamento e deep discovery do Mobilize, e o Cloud Endure para migração de workloads, na fase de Migrate & Modernize.
Benefícios
Há diferentes motivadores para as empresas iniciarem sua jornada de migração Cloud. Os principais benefícios esperados pelas organizações são:
Com o movimento das organizações que iniciaram sua Jornada Cloud, a tecnologia definitivamente não tem sido o maior desafio das transformações. Em busca de agilidade, cost saving, foco em inovação, melhoria em segurança, time to market, escala global, operating model, etc., o maior desafio enfrentado pelas empresas ainda são os problemas culturais e na transformação do negócio, necessárias para maximizar os resultados da adoção Cloud.
Quais são os principais blockers e inflection points nessa jornada? A Forbes Insights indica as cinco principais razões as quais a estratégia organizacional falha na entrega de resultados (no contexto geral, não somente Cloud Journey):
Situações externas não previstas
Falta de entendimento no desenvolvimento da estratégia
A estratégia em si é falha
Pouco match entre estratégia e competências essenciais
Falta de accountability ou de responsabilização da equipe
O Migration Readiness é prescrito pela AWS (Amazon Web Services) para avaliar sob as perspectivas do CAF (Cloud Adoption Framework) a prontidão organizacional de migração para Cloud. O outcome irá apoiar a empresa a estruturar um programa de migração massiva e adoção Cloud.
Business
A estratégia é alinhada para suportar os resultados de negócio. Inclui IT Finance, Strategy, Benefits Realization e Business Risk Management.
Common blockers: governança distribuida (dificuldade de coordenação dos workloads de migração), commitment para migração (business case, TCO e suporte dos key stakeholders) e falha na estratégia de criação de produtos.
Os quatro estágios de adoção Cloud são: Project, Foundation, Migration e Optimization. No estágio 1 utiliza-se experimentação em POCs, análise TCO/ROI e preparação a riscos/segurança para provar valor do modelo e remover os blockers.
People
Apoia na preparação dos times, skills e a processos organizacionais para incluir as competências necessárias de Cloud. Inclui a gestão de pessoas, incentivos, carreira, treinamentos e mudança organizacional.
Common blockers: falta de definição ou clareza nas roles e responsibilities, competências necessárias e change management ineficaz (no engajamento dos objetivos, benefícios, prioridades, etc.).
O conceito de two pizza teamda AWS sugere a adequação do tamanho dos times “if you can’t feed a team with two pizzas, it’s too large“. E assim, permite maior interação entre os membros do time, facilita a comunicação e o senso de ownership (maior clareza no trabalho e outcomes esperados).
Governance
Provê boas práticas de Governança em TI, suportando processos de negócio e tecnologia. Inclui a gestão de portfólio, programa e projeto, licenças e as métricas de performance do negócio.
Common blockers: falta de repositório confiável das aplicações, gestão de serviços (SLA’s e OLA’s bem definidas), estrutura projetizada x produtizada, imaturidade em metodologias, excesso de processos manuais.
A organização objetiva então o Business Agility, que tem como essencial a gestão da dependência entre os times, criação da value stream, gestão estratégica de portfólio e transição ágil (flight levels existentes na organização).
Plataforma
Ajuda a definir os principios, ferramentas e políticas a serem usadas na infraestrutura AWS. Inclui a arquitetura da solução e sistemas, desenvolvimento de aplicações e o provisionamento (rede, base de dados, armazenamento e processamento).
Common blockers: falta de padrão de arquitetura; não utiliza práticas DevOps, gestão de contas e segurança inaproriada.
Identificar as dependências entre os sistemas, Well-Architected Framework e a integração com os legados.
Segurança
Ajuda a estruturar e implementar controles. Inclui IAM (Identity and Access Management), segurança da infraestrutura, detective control, proteção aos dados e resposta a incidentes.
Common blockers: não há políticas de segurança atualizadas, frameworks de risco e controle, ausência de liderança em segurança da informação (como o CISO), governança de Security, Risk and Compliance (SRC) inapropriada, ausência de testes de segurança.
Operações
Além da operação de workloads, também apoia em monitoramento de serviços, performance de aplicação, inventário de recursos, catálogo de serviços, gestão de mudanças e releases, business continuity e disaster recovery.
Common blockers: má gestão de runbooks, patchs e testes operacionais, abordagem BCP/DR não é considerada, processo informal de gestão de incidentes, manual deployments, monitoramento e logging inexistentes.
Distribui automaticamente o tráfego de entrada de aplicativos entre diversos destinos, como instâncias do Amazon EC2, contêineres, endereços IP e funções Lambda. O serviço pode lidar com a carga variável de tráfego dos aplicativos em uma única zona de disponibilidade ou em diversas zonas de disponibilidade.
O Elastic Load Balancing oferece três tipos de load balancers, todos eles com a alta disponibilidade, a escalabilidade automática e a segurança robusta necessárias para tornar os aplicativos tolerantes a falhas
Application Load Balancer (ALB): atua na camada 7 e roteia conexões com base no conteúdo da solicitação. Processam o tráfego no nível HTTP, HTTPS (camada 7).
Network Load Balancer (NLB): atua na camada 4 e roteia conexões com base nos dados do protocolo IP. Os Processam o tráfego no nível TCP (camada 4).
Classic Load Balancer (CLB): fornece balanceamento de carga básico nas camadas 4 e 7. Processam o tráfego nos níveis TCP, SSL, HTTP e HTTPS (camadas 4 e 7)
O ELB pode distribuir o tráfego recebido pelas instâncias do Amazon EC2 em uma única AZ ou em várias AZs, mas não entre regiões. É usado para distribuir a carga e introduzir tolerância a falhas distribuindo conexões entre instâncias do EC2.
3.2. Auto scaling
Ajuda a garantir o número correto de instâncias do EC2 disponíveis para processar a carga dos aplicativos. Permite adicionar e remover instâncias de acordo com as condições especificadas.
A Escalabilidade é para garantir que os workloads tenham recursos suficientes do EC2 p/ atender a requisitos dinâmicos de performance
A Automação é para dimensionar o provisionamento de recursos do EC2 para que ocorra sob demanda
Os componentes do Auto Scaling são:
No Auto Scaling dinâmico, pode criar alarmes no CloudWatch, com base nas informações de performance de suas instâncias EC2 ou de um load balancer.
Scaling vertically: através do aumento de um recurso individual, por exemplo, atualizando um servidor com um disco rígido maior ou uma CPU mais rápida.
Scaling horizontal: através do aumento no número de recursos, por exemplo, adicionando mais discos rígidos a uma array de armazenamento ou mais servidores para suportar um aplicativo).
3.3. Network: Route 53
É um serviço de DNS projetado para rotear usuários finais a endpoints (que pode ser uma aplicação que precisa converter o nome de domínio em IP).
Entre as principais funções do Route 53: registro de domínio, DNS global e altamente disponível, health checking (availability monitoring), vários algoritmos de roteamento (traffic management), IPv4 e IPv6, integrado a outros serviços AWS.
As principais routing policies são Simple, Weighted, Latency based, Failover, Geo-location, Geo-Proximity, Multi-Value e Traffic Flow.
3.4. Database RDS (Relational Database Service)
É um serviço gerenciado que configura e opera um BD relacionalna nuvem. Permite que você se concentre em performance, alta disponibilidade, segurança e compatibilidade necessárias.
Entre os principais desafios em manter um BD relacional: manutenção do servidor e energia, instalação do software e patches, backups, alta disponibilidade, limites de escalabilidade, segurança de dados, instalação de SO e patches.
Você pode executar uma instância de BD usando o Amazon VPC. Ao usar VPC, você tem controle do seu ambiente de rede virtual (intervalo de endereços IP, sub-redes, roteamento e listas de controle de acesso).
Dois conceitos importantes de RDS:
Alta disponibilidade com Multi-AZ: gera uma cópia stand by da instância do BD em outra availability zone (dentro da mesma VPC). Os dados são replicados de forma sincrona. Ajuda na manutenção e falhas nas instâncias de BD.
Réplicas de leitura: método de replicação assíncrona, onde são descarregadas consultas de leitura da instância de dados mestra. Ideal para cargas de trabalho do BD com uso intensivo de leitura.
Os principais benefíciosdo RDS: altamente escalável, alta performance, fácil de administrar (console de gerenciamento AWS, CLI ou chamadas API), disponível e durável, seguro e compatível (controle e segurança via VPC ou não).
3.5. Compute: Lambda
É um serviço que permite executar código sem provisionar ou gerenciar recursos (serverless). Executa seu código somente quando necessário (orientada a eventos) e dimensiona automaticamente as solicitações.
O AWS Lambda está em uma infraestrutura altamente disponível (inclui manutenção de servidor e SO), com provisionamento de capacidade, Auto Scaling, monitoramento e registro de log. Oferece suporte a diversas linguagens de programação: Node .JS, Java, C# e Python. O CloudWatch Events é onde configura os triggers.
O AWS Lambda pode ser usado em diversos aplicativos, tais como backup automatizados, objetos de processamento enviados para o S3, IoT, etc.
3.6. Elastic Beanstalk
É um PaaS, ou seja, você possui toda a infraestutura e plataforma criada para você, de modo a colocar o código da aplicação, conforme necessário. Permite a implementação rápida de seus aplicativos e reduz a complexidade de gerenciamento.
Basta fazer o upload de seu código e o Elastic Beanstalk se encarrega automaticamente da implementação, desde o provisionamento de capacidade, o balanceamento de carga e a escalabilidade automática até o monitoramento da saúde do aplicativo.
AWS Elastic Beanstalk can be used to quickly deploy and manage applications in the AWS Cloud. However, you do still need to deploy within a VPC so more AWS expertise is required
3.7. Simple Notification Service (SNS)
É um serviço de mensagens e comunicações móveis de publicação / assinatura (pub/sub) flexível e totalmente gerenciado. Também coordena a entrega de mensagens para endpoints e clientes assinantes.
Permite desacolpar e ajustar a escala de microsserviços, sistemas distribuidos e aplicativos serverless. Eventos que disparam e-mail ao administrador, microsserviços que se comunicam entre si, etc.
Os principais conceitos do SNS são:
Topics: como rotula e agrupa diferentes pontos de extremidade para os quais envia mensagens.
Subscriptions: os pontos de extremidade para os quais um tópico envia mensagens.
Publishers: a pessoa / alarme / evento que envia ao SNS a msg a ser enviada.
3.8. Management: Amazon CloudWatch
Monitora seus recursos AWS e os aplicativos que você executa em tempo real (métricas como utlização de CPU, transferência de dados, etc.). O CloudWatch fornece dados e insights para monitorar aplicativos, responder às alterações de performance em todo o sistema, otimizar a utilização de recursos e obter uma visualização unificada da integridade operacional.
O CloudWatch coleta dados de monitoramento e operações na forma de logs, métricas e eventos, oferecendo uma visualização unificada dos recursos, dos aplicativos e dos serviços da AWS executados na AWS e em servidores locais. Você pode usar o CloudWatch para detectar comportamento anômalo em seus ambientes, definir alarmes, visualizar logs e métricas lado a lado, executar ações automatizadas, resolver problemas e descobrir insights para manter seus aplicativos em perfeita execução.
A capacidade de automaticamente reagir às mudanças é o principal recurso do CloudWatch. Os principais componentes do CloudWatch são: métricas, alarmes, eventos, logs e dashboards.
3.9. Amazon CloudTrail
É um serviço que possibilita governança, conformidade, auditoria e de riscos em sua conta da AWS. Permite registrar, monitorar continuamente e reter a atividade da conta relacionada às ações executadas na infraestrutura da AWS.
Disponibiliza o histórico de eventos da atividade da conta AWS (inclusive ações via Console, SDKs, CLIs e de outros Serviços da AWS). É usado para simplificar as auditorias de compatibilidade ao registrar e armazenar automaticamente logs de evento de ações executadas em sua conta da AWS.
Qual é a diferença entre o CloudWatch Events e o AWS CloudTrail?
Com o CloudWatch, você pode definir regras para monitorar eventos específicos e executar ações de maneira automática. O AWS CloudTrail é um serviço que registra chamadas de API / atividades da conta e entrega arquivos de log contendo chamadas de API para seu bucket do Amazon S3 ou um grupo de log do CloudWatch Logs, com o intuito de conformidade, auditoria e gestão de riscos.
3.10. AWS Artifact
Portal gratuito de autoatendimento para acesso sob demanda aos relatórios de conformidade da AWS. Os relatórios de System & Organization Control (SOC) da AWS são relatórios de exame de terceiros independentes que demonstram como a AWS atende aos principais controles e objetivos de conformidade. O propósito desses relatórios é ajudar você e os seus auditores a entenderem os controles estabelecidos na AWS para apoiar as operações e a conformidade.
O relatório SOC 1 e SOC 2 da AWS estão disponível para clientes da AWS por meio do AWS Artifact. Relatório de segurança, disponibilidade e confidencialidade SOC 3 da AWS, disponível publicamente como um whitepaper.
É uma rede de entrega de conteúdo. Ao utilizar o CloudFront, você aproveita diversos edge locations espalhados pelo mundo para entregar conteúdo, garantido baixa latência na interação com os usuários através do uso de caches.
Está integrado a outros serviços AWS, tais como AWS WAF (Web Application Firewall), Route 53, etc. Pode ser usado para conteúdos estáticos e dinâmicos.
Casos de uso: armazenamento em cache de ativos estáticos, streaming de vídeo ao vivo e sob demanda, segurança e proteção contra DDoS e conteúdo dinâmico.
3.12. Management: Amazon CloudFormation
Simplifica a tarefa de criar grupos de recursos relacionados a seus aplicativos. O foco é a automação do provisionamento de recursos.
O CloudFormation lê o arquivo modelo (JSON ou YAML) e o output é o provisionamento de recursos (conhecido como pilha). Você pode criar, atualizar e excluir pilhas (stacks).
Segurança: IAM, controles de detecção, resposta a incidentes, proteção de infraestrutura e dados. Aplica o princípio de privilégio mínimo e segurança em todas as camadas. Com o modelo de responsabilidade compartilhada, você foca na proteção dos dados da aplicação e SO (e a AWS oferece infraestrutura e serviços seguros).
Confiabilidade: recuperar problemas/falhas (automaticamente), gerenciamento de alterações, previsão, resposta e prevenção de falhas.
Eficiência de performance: selecionar soluções personalizáveis para inovar continuamente (tecnologias avançadas, alcance global em minutos, arquitetura serverless, etc.) .
Otimização de custos: refinamento e aprimoramento contínuo dos sistemas. Usar recursos econômicos, combinar oferta e demanda, conscientização sobre despesas e otimizar ao longo do tempo.
Excelência operacional: gerenciar e automatizar alterações, responder a eventos e definir os padrões.
Tolerância a falhas
Capacidade de um sistema permanecer operacional
Redundância integrada do componente de um aplicativo
Os mecanismos de Disaster Recovery: o mais rápido é o Multi Site; o mais lento é Backup & Restore.
Os 5 pilares AWS Well-Architected Framework são:
Operational Excellence: perform operations as code, annotate documentation, make frequent, small and reversible changes, refine operations procedures frequently, anticipate failure e learn from all operational failures
Security: implement a strong identity foundation, enable traceability, apply security at all layers, automate security best practices, protect data in transit and at rest e prepare for security events
Reliability: test recovery procedures, automatically recover from failure, scale horizontally to increase aggregate system availability, stop guessing capacity e manage change in automation
Performance Efficiency: democratize advanced technologies, go global in minutes, use serverless architectures, experiment more often e mechanical sympathy
Cost Optimization: adopt a consumption model, measure overall efficiency, stop spending money on data center operations, analyze and attribute expenditure e use managed services to reduce cost of ownership
Uma infraestrutura resiliente, projetada para alta segurança e proteções fortes (safe guards) para ajudar a proteger a privacidade dos clientes.
Atenda aos requisitos de conformidade (automação centralizada, controle de segurança e supervisão adicional)
Modelo de responsabilidade compartilhada: herde controles de segurança na AWS. Coloque em camadas seus controles
Segurança de rede: firewalls integrados, criptografia em trânsito, conexões privadas/dedicadas, mitigação de DDoS.
Gerenciamento de inventário e configuração: ferramentas de definição e gerenciamento de modelos
Criptografia de dados: recursos de criptografia, gerenciamento e armazenamento de chaves
Monitoramento e registro em log
AWS Marketplace: parceiros qualificados que se integram com os controles
O AWS Key Management Service (KMS) facilita a criação e gerenciamento de chaves criptográficas e o seu uso em serviços AWS e em aplicativos. Já o AWS CloudHSM é um Hardware Security Module (HSM) baseado na nuvem que permite gerar e usar facilmente suas próprias chaves de criptografia na Nuvem.
O Amazon GuardDuty oferece detecção de ameaças e monitoramento de segurança contínuo de comportamentos mal-intencionados ou não autorizados para ajudar a proteger suas contas e cargas de trabalho AWS.
Os security groups são stateful; portanto, se você permitir a passagem do tráfego, o tráfego de retorno será automaticamente permitido, mesmo que nenhuma regra corresponda ao tráfego. Os security groups podem ser configurados em uma VPC, EC2 etc.
Os security groups facilitam o agrupamento de recursos usando as tags atribuídas a eles. Você pode agrupar recursos que compartilham uma ou mais tags. Os grupos de recursos facilitam o gerenciamento e automatizam as tarefas em grandes números de recursos de uma vez.
5.1. Modelo de responsabilidade compartilhada
User Data
Chave de acesso e métodos de criptografia são criados pelo cliente
Cliente
Application
AWS não controla a sua aplicação
Cliente
Guest OS
AWS não interfere na escolha. Pode ser windows, linux, etc.
Cliente
Hypervisor
AWS usa Hypervisor baseado em Xex. É seguro e escalável
AWS
Network
Protocolos de rede proprietários (VPC, etc.) para prover segurança
AWS
Physical
Gerenciamento físico (acesso restrito a DCs, etc.)
AWS
Os clientes que implantam uma instância do EC2 são responsáveis pelo gerenciamento do SO convidado (o que inclui atualizações e patches de segurança), por qualquer utilitário ou software de aplicativo instalado pelo cliente nas instâncias, bem como pela configuração do firewall disponibilizado pela AWS (chamado de grupo de segurança) em cada instância.
A AWS é responsável pela “segurança da nuvem”. Isso inclui a proteção da infraestrutura que executa todos os serviços oferecidos na nuvem da AWS. Essa infraestrutura é composta pelo hardware, software, rede e instalações que executam os serviços da AWS Cloud.
O cliente é responsável pela “segurança na nuvem”. A responsabilidade do cliente depende do serviço consumido, mas inclui aspectos como o IAM, criptografia de dados, proteção do tráfego de rede e sistema operacional, configuração de rede e firewall.
5.2. IAM (Identity and Access Management)
É um recurso gratuito que permite gerenciar com segurança o acesso aos serviços e recursos da AWS. Usando o IAM, você pode criar e gerenciar usuários e grupos da AWS e usar permissões para conceder e negar acesso a recursos da AWS.
Trabalha com os conceitos de Group – User (credenciais permanentes; pode ser usuário e senha, chave de acesso, chave secreta, etc.) – Role (método de autenticação; não são permissões).
A permissão ocorre na Policy Docs que é um objeto separado. Esse JSON pode ser anexado a um grupo, usuário ou role. Cada ação ocorrida em APIs (maioria dos serviços é utilizada por APIs) é registrada no CloudTrail.
IAM – casos de uso:
Controle de acesso aos recursos AWS (APIs de serviços e recursos específicos). Permite adicionar condições (horário de uso para um usuário, seu IP de origem, se estão usando SSL ou MFA).
MFA (Multi factor authentication)
Analisar o acesso
Integração ao diretório corporativo (como o MSFT AD)
Gerencie permissões com grupo; configure uma política de senha forte
Com a IAMRoles, você pode delegar permissões a recursos para usuários e serviços sem usar credenciais permanentes (por exemplo, nome de usuário e senha).
Uma IAM policy é um documento de política usado para definir permissões que podem ser aplicadas a usuários, grupos e roles. Você não aplica a política ao serviço, aplica-a à função. A role é usada para atribuir permissões ao serviço da AWS.
5.3. Amazon Inspector
É um serviço de avaliação de segurança automatizado. Avalia vulnerabilidades e desvios das melhores práticas. Produz relatórios com descobertas de segurança e etapas priorizadas para a correção. É baseado em agentes e orientado por API.
5.4. AWS Shield
É um serviço gerenciado contra DDoS que protege aplicações em execução na AWS. Protege outros recursos da AWS:
Route 53: proteção zonas hospedadas do Route 53 contra DDoS ataques – inundações, ataques de reflexão,etc.
CloudFront: proteções nas camadas 3 e 4 de infraestrutura, usando engenharia de tráfego
VPC
5.5. Segurança e conformidade
AWS compartilha informações de segurança: obtenções de certificado do setor, publicação de práticas de segurança e controle, relatórios de conformidade.
Programas de garantia – a AWS fornece informações e recursos de conformidade para suporte jurídico/normativo, certificações/declarações e alinhamentos/estruturas.
A AWS permite que as entidades cobertas e seus associados comerciais sujeitos à lei Health Insurance Portability and Accountability Act (HIPAA – Lei de portabilidade e responsabilidade de provedores de saúde) de 1996 dos EUA se beneficiem do ambiente seguro da AWS para processamento, manutenção e armazenamento de informações protegidas relacionadas à saúde.
E também CJIS (Serviço de Informação da Justiça Criminal), CSA (Cloud Security Alliance), FERPA (Family Educational Rights and Privacy) e MPAA (Motion Picture Association of America).
5.6. AWS Personal Health Dashboard
Fornece alertas e orientações de remediação quando a AWS enfrenta eventos que podem afetá-lo. Há uma exibição personalizada do desempenho e da disponibilidade dos serviços da AWS subjacentes aos seus recursos da AWS. O painel exibe informações relevantes e oportunas para ajudar a gerenciar eventos em andamento e fornece notificações proativas para ajudar a planejar atividades programadas.
AWS Service Health Dashboard exibe o status dos serviços (service availability) no Dashboard.
5.7. AWS Config
É um serviço que permite acessar, auditar e avaliar as configurações dos recursos da AWS. O Config monitora e grava continuamente registros das configurações de recursos da AWS e lhe permite automatizar a avaliação das configurações registradas com base nas configurações desejadas.
Com o Config, você pode analisar alterações feitas nas configurações e relacionamentos entre os recursos da AWS, aprofundar-se de forma detalhada no histórico de configuração de recursos e determinar a conformidade geral em relação às configurações especificadas em suas diretrizes internas. Dessa forma, você pode simplificar a auditoria de conformidade, a análise de segurança, o gerenciamento de mudanças e a solução de problemas operacionais.
Pay as you go: serviços pagos conforme o uso (sem penalização de saída)
Capacidade reservada: pode economizar até 75% em relação à capacidade sob demanda equivalente. Estão disponíveis em três opções: AURI (tudo adiantado), PURI (parcialmente adiantado) e NURI (nenhum pagamento adiantado). Quanto maior o pagamento adiantado, maior será o desconto.
Sua organização pode minimizar riscos, gerenciar orçamentos de forma mais previsível e cumprir políticas que exigem compromissos a longo prazo. Serviços como EC2 e RDS podem utilizar capacidade reservada.
Pague por:
Capacidade computacional
Armazenamento
Transferência de dados de saída (agregada)
Não há cobrança para:
Transferência de dados de entrada
Capacidade reservada
As instâncias reservadas proporcionam um desconto significativo (até 75%) em comparação com a definição de preço das instâncias por demanda e podem ser compradas por um período de 1 ou 3 anos. Ao serem atribuidas a uma zona de disponibilidade específica, elas disponibilizam uma reserva de capacidade, podendo executar instâncias quando for necessário.
Os clientes têm a flexibilidade de alterar a zona de disponibilidade, o tamanho da instância e o tipo de rede de suas instâncias reservadas padrão. O nível gratuito da AWS inclui 750 horas de instâncias t2.micro Linux e Windows por mês por um ano.
Compre instâncias reservadas conversíveis se precisar de flexibilidade adicional, como SO, famílias de instâncias, ou locações diferentes durante o período de vigência. As instâncias reservadas conversíveis oferecem um desconto considerável (até 54%) em comparação às instâncias sob demanda e podem ser compradas por um período de vigência de 1 ou 3 anos.
Há três tipos de instâncias reservadas: Standard RIs, Convertible RIs e Scheduled RIs.
As três opções de reserva que a AWS oferece:
All Upfront: o cliente opta por pagar pelo custo total da instância em uma única vez de acordo com o período escolhido (1 ano ou 3 anos). O custo é à vista e englobará o valor total do período, não haverá cobranças mensais adicionais sobre a instância reservada. Nesse modelo o desconto pode chegar à 60%.
Partial Upfront: o cliente opta por pagar um valor menor à vista (se compararmos ao modelo All Upfront) e as cobranças mensais terão um grande desconto. No geral, o desconto gira em torno de 35%.
No Upfront: o cliente não pagará nenhum valor à vista, porém o desconto será aplicado da mesma forma nas cobranças mensais. Lembre-se que ao efetuarmos uma reservas estamos fechando um contrato com AWS e as cobranças mensais pela instância serão realizadas nos meses decorrentes do contrato. Nesse modelo, o desconto gira em torno de 30%.
Fatores de Custo
EC2: faturamento por segundo/hora (cobrança quando as instâncias estão em execução). A definição de preço varia de acordo com a região, SO, tipo e tamanho da instância.
S3: preço baseado em solicitações (número e tipo) e transferência de dados (dados transferidos para fora da região S3).
EBS: cobrança baseada na quantidade de volumes provisionada por mês. Transferência de dados de saída tem cobrança (dados de entrada não); também GB adicional de dados armazenados em Snapshots.
RDS: faturamento por hora e GB/mês adicional de backup ; pode haver modelo de cobrança sob demanda ou instâncias reservadas.
CloudFront: definição de preço com base em solicitações e transferência de dados para fora
AWS Cost Explorer: permite uma análise detalhada dos dados de custos e uso para identificar tendências, indicar os fatores determinantes dos custos e detectar anomalias. Também criar relatórios de uso e custos (ambos em um nível mais resumido) ou para solicitações altamente específicas.
AWS Budgets: permite definir orçamentos personalizados que enviam alertas quando o uso ou os custos excedem (ou tendem a exceder) o valor orçado. Também pode ser usado para definir metas de utilização ou cobertura de reservas e receber alertas quando a utilização cair abaixo do limite definido.
Os preços da Amazon incluem opções de pay-as-you-go, save when you reserve and pay less by using more. A Amazon não oferece ELAs, descontos fora do horário de pico ou descontos de uso global.
6.2. Trusted Advisor
É uma ferramenta que fornece orientações em tempo real para ajudar a provisionar recursos de acordo com as melhores práticas da AWS (que podem ser usadas em novos fluxos de trabalho, desenvolver aplicativos, aprimoramentos contínuos, etc.).
Casos indicam que o Trusted Advisor ajudou ao destacar: Instâncias do EC2 não utilizadas, Instâncias reservadas do Amazon EC2, volumes não utilizados do Amazon EBS, etc.
6.3. AWS Support
O suporte é fornecido para:
Testar com a AWS
Usar a AWS em produção
Usar essencialmente para os negócios da AWS
Orientações proativas (gerente técnico de conta – TAM)
As calculadoras de TCO permitem estimar a redução de custo ao usar a AWS e oferecem um conjunto de relatórios detalhados (server hw, network hw, hw maintenance, power and cooling, data center space, personnal/staff and aws instances). As calculadoras também permitem modificar as suposições de acordo com suas necessidades empresariais.
To estimate a bill, use the AWS Pricing Calculator. Enter your planned resources by service, and the AWS Pricing Calculator provides an estimated cost per month.
To forecast your costs, use the AWS Cost Explorer. Use cost allocation tags to divide your resources into groups, and then estimate the costs for each group.
Uma tag é um rótulo (chave e um valor) que você ou a AWS atribui a um recurso da AWS. Pode ser usada para organizar os recursos e tags de alocação de custos para acompanhar os custos da AWS em um nível detalhado. Depois de ativar as tags de alocação de custos, a AWS as utiliza para organizar seus custos de recursos no cost allocation report, facilitando a categorização e o controle dos custos da AWS.
6.5. Consolidated billing for AWS Organizations
Usado para consolidar o faturamento e o pagamento de várias contas da AWS. Todas as organizações possuem uma conta mestra (pagante) que paga as cobranças de todas as contas-membro (vinculadas). O uso em conjunto permite compartilhar os descontos de preçospor volume, de instância reservada e os Savings Plans.
Isso pode resultar em um custo mais baixo para o seu projeto, departamento ou empresa do que com contas independentes individuais. O faturamento consolidado é oferecido sem qualquer custo adicional.
Fargate: é um mecanismo serverless para contêineres que funciona com o Amazon Elastic Container Service (ECS) e com o Amazon Elastic Kubernetes Service (EKS). O Fargate elimina a necessidade de provisionar e gerenciar servidores, permite que você pague pelos recursos por aplicativo. Executa cada tarefa ou pod no próprio kernel do serviço.
7.2. Database
DynamoDB (noSQL): é um BD de chave-valor e documento que oferece desempenho de milissegundos com um dígito em qualquer escala. Se estende por várias regiões e armazenamento em cache na memória para aplicativos em escala.
Aurora: é um BD relacional compatível com MySQL e PostgreSQL e criado para a nuvem que combina a performance e a disponibilidade de BD comerciais com a simplicidade e a economia de BD open source. É até cinco vezes mais rápido que bancos de dados MySQL padrão e três vezes mais rápido que bancos de dados PostgreSQL padrão. Oferece um sistema de armazenamento distribuído, tolerante a falhas e com recuperação automática que escala automaticamente para até 64 TB por instância de banco de dados. O Amazon Aurora é gerenciado pelo Amazon Relational Database Service (RDS).
MariaDB: é um BD relacional de open source, que foi criado pelos desenvolvedores originais do MySQL. O Amazon RDS facilita a configuração, a operação e a escalabilidade de implantações do servidor MariaDB na nuvem. Com o Amazon RDS, você pode implantar bancos de dados na nuvem escaláveis do MariaDB em minutos, com capacidade de hardware redimensionável e econômica.
Redshift: é um produto de DW que faz parte da AWS. Com o Redshift, você pode consultar petabytes de dados estruturados e semiestruturados em DW e data lakes usando SQL padrão. O Redshift permite salvar facilmente os resultados das consultas de volta no data lake do S3 usando formatos abertos, como o Apache Parquet, para análises adicionais de outros serviços analíticos como Amazon EMR, Amazon Athena e Amazon SageMaker.
DMS (migração): ajuda você a migrar BD para a AWS de modo rápido e seguro. O BD de origem permanece totalmente operacional durante a migração, minimizando o tempo de inatividade de aplicativos que dependem do BD. O DMS viabiliza migrações homogêneas, como de Oracle para Oracle, além de migrações heterogêneas entre plataformas de BD diferentes, como de Oracle ou de Microsoft SQL Server para Amazon Aurora. Ao migrar BD para o Amazon Aurora, o Amazon Redshift, o Amazon DynamoDB ou o Amazon DocumentDB (com compatibilidade com o MongoDB), você pode usar o DMS grátis por seis meses.
(DB2 não é suportado na AWS)
7.3. Security & Identity
WAF (Web Application Firewall): é um firewall que ajuda a proteger os aplicativos ou APIs contra exploits comuns na web. Fornece controle sobre como o tráfego atinge seus aplicativos, permitindo criar regras de segurança que bloqueiam padrões de ataque comuns, como injeção de SQL ou scripts entre sites, e regras que filtram padrões de tráfego específicos. As Regras gerenciadas do WAF abordam questões como os 10 principais riscos de segurança da OWASP.
7.4. Analytics
EMR (Elastic Map Reduce): é a plataforma de big data em Cloud para processar grandes quantidades de dados usando ferramentas de código aberto, como Apache Spark, Apache Hive, Apache HBase, Apache Flink, Apache Hudi e Presto. Com o EMR, você pode executar análises em escala de Petabytes a menos da metade do custo das soluções tradicionais locais e 3x mais rápido que o Apache Spark padrão.
Kinesis: permite consumir dados em tempo real como vídeo, áudio, logs de aplicativos, clickstreams de sites e dados de telemetria de IoT para machine learning, análises e outros aplicativos. Ainda processar e analisar dados assim recebidos e responder instantaneamente, em vez de aguardar a conclusão da coleta de dados para poder iniciar o processamento.
7.5. Application Services
API Gateway: é um serviço gerenciado que permite que desenvolvedores criem, publiquem, mantenham, monitorem e protejam APIs em qualquer escala com facilidade. Usando o API Gateway, você pode criar APIs do RESTful e APIs do WebSocket que habilitam aplicativos de comunicação bidirecionais em tempo real. O API Gateway dá suporte a cargas de trabalho conteinerizadas e sem servidor, além de aplicativos da web.
SQS (Simple Queue Service): é um serviço de filas de mensagens gerenciado que permite o desacoplamento e a escalabilidade de microsserviços, sistemas distribuídos e aplicativos sem servidor. O SQS elimina a complexidade e a sobrecarga associadas ao gerenciamento e à operação de middleware orientado a mensagens, além de permitir que os desenvolvedores se dediquem a criar diferenciais.
7.6. Enterprise Applications
Workspaces: é uma solução de desktop como serviço (DaaS) gerenciada e segura. Provisiona desktops Windows ou Linux em minutos e escala rapidamente para oferecer milhares de desktops a funcionários em todo o mundo. O pagamento pode ser feito mensalmente ou por hora e apenas pelos WorkSpaces executados, ajudando você a economizar dinheiro em comparação aos desktops tradicionais e às soluções de Virtual Desktop Infrastructure (VDI – Infraestrutura de desktop virtual) no local.
7.7. Artificial Intelligence
O Amazon SageMaker é o serviço de ML para criar, treinar e implantar modelos de ML rapidamente. Ele remove a complexidade que atrapalha a implementação bem-sucedida do ML desde a execução de modelos para detecção de fraudes em tempo real, passando pela análise virtual de impactos biológicos de medicamentos em potencial, até a previsão de êxito no roubo de bases no baseball.
7.8. AWS Developer Tool
CodePipeline: automatize pipelines de CI/CD para oferecer atualizações rápidas e confiáveis. CodeCommit: hospede com segurança repositórios Git privados altamente escaláveis.
CodeBuild: compile e teste código com escalabilidade contínua. CodeDeploy: automatize implantações de código para manter a disponibilidade dos aplicativos.
X-ray: analise e depure aplicações distribuídas em produção. Codestar: desenvolva, crie e implante aplicativos na AWS. Com o AWS CodeStar, é possível configurar toda a sua cadeia de ferramentas de entrega contínua, possibilitando que você comece o lançamento de códigos mais rapidamente.
OpsWorks: é um serviço de gerenciamento de configurações que oferece instâncias gerenciadas do Chef e do Puppet, permitindo automatizar a forma como os servidores são configurados, implantados e gerenciados em instâncias do Amazon EC2 ou ambientes de computação no local. O OpsWorks tem três ofertas, AWS OpsWorks for Chef Automate, AWS OpsWorks for Puppet Enterprise e AWS OpsWorks Stacks.
Esse é um resumo do conteúdo para o exame AWS Certified Cloud Practitioner. Não é nenhum conteúdo oficial, apenas uma orientação dos principais conceitos de Cloud concepts, Security and compliance, Technology e Billing and Pricing.
Antes de seguir adiante nessa leitura, sugiro acessar o post AWS CLOUD PRACTITIONER – PREPARAÇÃO PARA O EXAME E SIMULADOS para entender melhor o formato do exame e o que será abordado. E assim, esse resumo está dividido em: Introdução a nuvem AWS, Core Services, Integrated Services, Arquitetura, Segurança, Definição de preço e suporte, outros serviços.
Abordagem de alterações de gerenciamento, testes, confiabilidade e planejamento de capacidade é mais ágil e eficiente. A AWS é uma plataforma que oferece soluções em cloud flexíveis, confiáveis, escaláveis, fáceis de usar e econômicas.
Reduzir riscos:
Por ser capaz de aprender e adaptar-se rapidamente as mudanças (reduz o custo da mudança)
Riscos de segurança por permitir testar com frequência e efetuar correções rápidas
Escalabilidade
Redimensionar seus recursos conforme necessário
Confiabilidade
Capacidade de um sistema se recuperar de falhas de infraestrutura ou serviço
Capaz de adquirir recursos computacionais para atender à demanda e mitigar interrupções
Data Centers em todo o mundo (AWS Regions) que estão em locais isolados (Availability Zones)
Availability Zones são DCs separados com alimentação redudante, redes e conectividade
Segurança dos dados
Clientes mantém propriedade total sobre seus dados (incluindo região que os armazena, como lida com criptografia e quem mantém as chaves de criptografia)
Interfaces AWS Os usuários AWS podem criar e gerenciar recursos de três maneiras:
Console de Gerenciamento AWS: interface gráfica para acessar recursos da AWS
Interface de linha de comando (CLI): permite controlar os serviços da AWS
SDKs: permite acessar AWS utilizando linguagens de programação
Os três utilizam como referência a API da AWS. Com as Interfaces AWS, há mais flexibilidade de criar e acessar os recursos em qualquer lugar.
The 6 advantages of cloud are:
Trade capital expense for variable expense
Benefit from massive economies of scale
Stop guessing about capacity
Increase speed and agility
Stop spending money running and maintaining data centers
É um serviço que disponibiliza capacidade computacional segura e redimensionável na nuvem. A interface permite que você obtenha e configure a capacidade com o mínimo de esforço. Ele oferece controle total de seus recursos e permite trabalhar no ambiente das AWS. No EC2, o cliente gerencia a infraestrutura virtual das VMs (configuração do SO, patchs de segurança e rede).
Instâncias do EC2 são Pay as you go (pelas instâncias em execução). Ampla seleção de hw/sw e hospedagem global. Um Host dedicado do EC2 é um servidor físico com a capacidade de instância do EC2 totalmente dedicada a seu uso. Hosts dedicados permite que você use suas licenças de software existentes por soquete, por núcleo ou por VM, incluindo o Windows Server, o Microsoft SQL Server, o SUSE e o Linux Enterprise Server.
Host dedicado
Instâncias dedicadas
Faturamento
Faturamento por host
Faturamento por instância
Visibilidade de soquetes, núcleos e ID de host
Fornece visibilidade do número de soquetes e núcleos físicos
Sem visibilidade
Afinidade de hosts e instâncias
Permite implantar de forma consistente suas instâncias no mesmo servidor físico com o momento
Sem suporte
As instâncias spot do Amazon EC2 permitem aproveitar a capacidade não utilizada do EC2 na Nuvem AWS. Em comparação com a definição de preço sob demanda, as instâncias spot oferecem descontos de até 90%. Elas podem ser usadas para vários aplicativos stateless, tolerantes a falhas e flexíveis como big data, cargas de trabalho conteinerizadas, CI/CD, servidores web, computação de alta performance e outras cargas de trabalho de teste e desenvolvimento.
Como as instâncias spot são estreitamente integradas a outros serviços da AWS como Auto Scaling, EMR, ECS, CloudFormation, Data Pipeline e AWS Batch, você pode escolher como iniciar e manter os aplicativos em execução nas instâncias spot.
Além disso, você pode combinar facilmente instâncias spot com instâncias sob demanda e reservadas para otimizar ainda mais o custo e a performance das cargas de trabalho. Você também tem a opção de hibernar, parar ou encerrar as instâncias spot quando o EC2 solicitar a devolução da capacidade, com dois minutos de aviso prévio. Somente a AWS oferece acesso à capacidade computacional não utilizada em uma escala tão massiva, e com um desconto de até 90%.
Diferenças entre Spot Instances x On-Demand Instances
Spot Instances
On-Demand Instances
Launch time
Can only be launched immediately if the Spot Request is active and capacity is available.
Can only be launched immediately if you make a manual launch request and capacity is available.
Available capacity
If capacity is not available, the Spot Request continues to automatically make the launch request until capacity becomes available.
If capacity is not available when you make a launch request, you get an insufficient capacity error (ICE).
Hourly price
The hourly price for Spot Instances varies based on demand.
The hourly price for On-Demand Instances is static.
Instance interruption
You can stop and start an Amazon EBS-backed Spot Instance. In addition, the Amazon EC2 Spot service can interrupt an individual Spot Instance if capacity is no longer available, the Spot price exceeds your maximum price, or demand for Spot Instances increases.
You determine when an On-Demand Instance is interrupted (stopped, hibernated, or terminated).
Para usar Instâncias spot, crie uma solicitação de Instância Spot que pode incluir o preço máximo que você está disposto a pagar por hora por instância (o padrão é o preço sob demanda) e outras limitações como o tipo de instância e a zona de disponibilidade. As instâncias spot são executadas até que você as interrompa ou encerre, ou até que o EC2 as interrompa.
Quando usar Instâncias spot, você deverá estar preparado parainterrupções. O EC2 poderá interromper a Instância spot quando o preço spot exceder o preço máximo, quando a demanda por Instâncias spot aumentar ou quando a oferta de Instâncias spot diminuir. Quando o EC2 interrompe uma Instância spot, ele fornece um aviso de interrupção de Instância spot, enviando à instância um aviso de dois minutos antes que o Amazon EC2 a interrompa.
Spot instances: are good for short term requirements as they can be very economical. However, you may find that the instance is terminated if the spot market price moves
On-Demand: is the best choice for this situation as it is the most economical option that will ensure no interruptions. Also when you want low cost and flexibility of EC2 without any up-front payment or long-term commitment.
Reserved instances: are good for long-term, static requirements as you must lock-in for 1 or 3 years in return for a decent discount (applications with steady state or predictable usage).
Dedicated instances: are EC2 instances that run on hardware dedicated to a single customer
Uma AMI (Amazon Machine Image) fornece as informações necessárias para iniciar uma instância. Pode ser considerado um snapshot para recriação de instância. O EC2 Snapshot é o ponto para novos volumes ou backup. Existem três categorias de AMIs:
Community AMIs– generally you just select the operating system you want. It’s free to use.
AWS Marketplace AMIs– pay to use, generally come packaged with additional, licensed software.
My AMIs– AMIs that you create yourself.
2.2. Compute: ECS (Elastic Container Service)
É um serviço de gerenciamento de contêineres altamente dimensionável e rápido que facilita a execução, a interrupção e o gerenciamento de contêineres do Docker em um cluster. Você pode hospedar seu cluster em uma infraestrutura sem servidor gerenciada pelo ECS ao iniciar seus serviços ou tarefas usando o tipo de inicialização Fargate. Para obter mais controle, você pode hospedar suas tarefas em um cluster de instâncias do EC2 gerenciado usando o tipo de inicialização EC2.
2.3. Storage: EBS (Elastic Block Store)
É um serviço de armazenamento de blocos de alta performance, projetado para o uso com as instâncias do EC2, para workloads com alta taxa de transferência de dados e com transações em qualquer escala. EBS é o armazenamento utilizável somente com EC2.
Workloads como BD relacionais e não relacionais, aplicativos corporativos, aplicativos em contêiner, mecanismos de análise de big data, sistemas de arquivos e fluxos de trabalho de mídia são amplamente empregados no Amazon EBS. Você pode escolher entre quatro tipos de volume diferentes para equilibrar preço e desempenho ideais:
Latência abaixo de 10 ms para workloads de BD de alta performance, como o SAP HANA.
Transferência de dados de 1 GB/s para workloads sequenciais grandes, como o Hadoop.
Alterar os tipos de volume (com suporte a SSD incluem um volume projetado para aplicativos de alta performance e um volume de uso geral; com suporte a HDD são projetados para grandes workloads sequenciais como mecanismos de análise de big data DW).
Ajustar a performance ou aumentar o tamanho do volume sem interromper seus aplicativos essenciais, assim terá armazenamento econômico quando precisar.
Os volumes EBS são replicados em uma zona de disponibilidade (AZ) e podem ser facilmente escalonados para petabytes de dados. Além disso, é possível usar o EBS Snapshots com políticas de ciclo de vida automatizadas para fazer backup de seus volumes no Amazon S3 e, ao mesmo tempo, garantir a proteção geográfica de seus dados e da continuidade de negócios.
2.4. Storage: Amazon S3 (Simple Storage Service)
É um serviço gerenciado de armazenamento na nuvem que utiliza APIs (ou endpoints de VPCs) para armazenar e recuperar dados. Armazena um número praticamente ilimitado de objetos (imagens, vídeos, logs, etc.). Também oferece acesso de baixa latência por HTTP ou HTTPS.
O S3 pode ser acessado pelo Console, CLI e SDKs da AWS. O uso mais comum do S3 é para armazenamento de ativos de aplicativos, hospedagem de sites estáticos, recuperação de desastre e backup (possui alta durabilidade) e área de preparação para Big Data (pelo armazenamento escalável e performance do S3).
Os pontos de acesso do S3 simplificam o gerenciamento do acesso de dados para aplicativos que usam conjuntos de dados compartilhados no S3. Os pontos de acesso fornecem um caminho personalizado em um bucket, com um hostname e uma política e acesso únicos, que aplica as permissões e os controles de rede específicos para qualquer solicitação feita por meio do ponto de acesso.
O S3 é um armazenamento de objetos, você cria objetos, não arquivos. Também pode criar pastas dentro de buckets e também pode fazer upload de objetos. Existe o S3 Standard-IA e o S3 One Zone-IA.
O S3 usa um espaço para nome global , porém ao criar os buckets em uma região, os dados nunca saem dessa região, a menos que sejam explicitamente configurados com o CRR (Cross-region replication). Com o lifecycle management, você pode definir regras para transferir objetos entre classes de armazenamento em intervalos de tempo definidos.
2.5. Storage: S3 Glacier
O Amazon S3 Glacier e o S3 Glacier Deep Archive são classes de armazenamento em nuvem do Amazon S3 seguro, resiliente e de custo extremamente baixo para arquivamento de dados e backups de longa duração. Essas classes foram projetadas para oferecer resiliência de 99,999999999% e disponibilizar recursos abrangentes de segurança e conformidade que podem ajudar a cumprir até mesmo os requisitos normativos mais rigorosos.
A classe de armazenamento Amazon S3 Glacier disponibiliza três opções de recuperação:
Recuperações aceleradas: retornam dados em 1 a 5 minutos; excelentes p/ arquivamento ativo.
Recuperações padrão: são concluídas em 3 a 5 horas e funcionam bem para atividades em que o tempo não é tão crucial, como dados de backup, edição de mídia ou análises de longo prazo.
Recuperações em massa: são a opção de recuperação mais barata, e retornam grandes quantidades de dados em 5 a 12 horas.
O S3 Glacier Deep Archive oferece armazenamento de objetos seguro e durável para retenção de dados no longo prazo, acessados uma ou duas vezes por ano. É ideal para fornecer proteção offline dos ativos de dados mais importantes da sua empresa ou quando a retenção de dados no longo prazo é necessária para requisitos de política corporativa, contratuais ou de conformidade regulamentar.
2.6. Storage: EFS (Elastic File System)
Fornece um sistema de arquivos NFS (Network File System) elástico, simples, escalável e totalmente gerenciado para uso com os serviços de nuvem AWS e os recursos local. Ele foi desenvolvido para escalar sob demanda até petabytes sem interromper os aplicativos, aumentando e diminuindo automaticamente à medida que você adiciona e remove arquivos, eliminando a necessidade de provisionar e gerenciar a capacidade com base no crescimento. Em NFS não pode ser instalado SO (sistema operacional).
O Amazon EFS oferece duas classes de armazenamento:
Standard
Infrequent Access (EFS IA): fornece preço/performance com custo otimizado para arquivos que não são acessados todos os dias.
Amazon EFS usa o NFS e é um sistema de armazenamento de arquivos. O Amazon EBS armazena em nível de bloco (para instâncias do EC2). E o S3 é um sistema de armazenamento de objetos.
O Amazon EFS foi criado para fornecer acesso compartilhado massivamente paralelo para milhares de instâncias do Amazon EC2, permitindo que seus aplicativos alcancem altos níveis em taxas de transferências agregadas e IOPS com latências baixas e consistentes.
2.7. Storage: AWS Storage Gateway
É um serviço de armazenamento na nuvem híbrida que oferece acesso local a armazenamento na nuvem praticamente ilimitado. Os clientes usam o Storage Gateway para simplificar o gerenciamento de armazenamento e reduzir os custos de armazenamento na nuvem híbrida.
A mudança de backups de fita para a nuvem
A redução do armazenamento local com compartilhamentos de arquivo baseados na nuvem
A disponibilização de acesso de baixa latência a dados na AWS para aplicativos locais
Migração, arquivamento, processamento e recuperação de desastres.
Para oferecer suporte a esses casos de uso, o serviço oferece três tipos diferentes de gateway: gateway de fitas, gateway de arquivos e gateway de volumes. Esses gateways conectam de forma transparente aplicativos locais ao armazenamento na nuvem, armazenando dados em caches locais para oferecer acesso de baixa latência.
A Gateway Virtual Tape Library pode ser usada com softwares de backup populares, como NetBackup, Backup Exec e Veeam. Usa um trocador de mídia virtual e unidades de fita.
2.8. Infra Global AWS
AWS Regions São regiões que hospedam uma ou mais Availability Zones. Ao escolher região, considere latência, minimizar custos e cumprir requisitos normativos. Pode ser implementado recursos em várias regiões (para melhor atender a sua empresa).
Exemplo: servidor de deploy em uma região e base de clientes em outra. Ou os mesmos recursos em várias regiões, permitindo uma experiência global consistente (independente da localização do cliente).
As regiões são entidades completamente separadas. Os recursos em uma região não são replicados automaticamente a outras (e nem todos os serviços estão disponíveis em todas as regiões).
Availability Zones Conjunto de DCs dentro de uma região. São isoladas uma da outra, mas conectadas por uma rede rápida e de baixa latência. Cada uma possui sua própria infraestrutura (alimentação, geradores de backup, redes e conectividade). O isolamento das zonas garante proteção de falhas em outras zonas (alta disponibilidade e redundância de dados em uma região).
Edge locations Hospedam CDNs (redes de entrega de conteúdos) – Amazon Cloudfront, que é utilizado para entregar conteúdo aos clientes, através de roteamentos ao ponto de presença mais próximo.
2.9. Network: VPC (Virtual Private Cloud)
O VPC permite provisionar uma seção da Nuvem AWS isolada logicamente na qual é possível executar recursos da AWS em uma rede virtual que você mesmo define. Você tem controle total sobre seu ambiente de redes virtuais, incluindo a seleção do seu próprio intervalo de endereços IP, a criação de sub-redes e a configuração de tabelas de rotas e gateways de rede. Você pode usar IPv4 e IPv6 na VPC para acessar recursos e aplicativos com segurança e facilidade.
Boa parte da complexidade da configuração de uma rede foi abstraida sem prejudicar o controle, a segurança e a usabilidade
Clientes podem definir itens de configuração de rede, endereço IP, sub-redes e tabelas roteamento
Personalizar regras de roteamento e controle de tráfego de e/s
Há vários produtos AWS que herdam e aproveitam a segurança incorporadas a VPC
Amazon VPC é um serviço fundamental e se integra a vários serviços da AWS. Por exemplo, instâncias EC2 são implantadas na VPC.
E possui as seguintes configurações:
Uma lista de controle de acesso (ACL) à rede é uma camada de segurança opcional para sua VPC que funciona como firewall para controlar o tráfego de entrada e saída de uma ou mais sub-redes. Você pode configurar Network ACLs com regras semelhantes às dos grupos de segurança a fim de adicionar uma camada extra de segurança à sua VPC. Opera no nível da subnet.
2.10. Network: AWS Direct Connect
Permite conectar o ambiente AWS ao DC (ou escritório local) através de uma conexão dedicada de alta velocidade e baixa latência, que bypass os provedores de serviços de Internet em seu caminho de rede.
Um local do AWS Direct Connect fornece acesso ao AWS na região à qual está associado e também a outras regiões dos EUA. Permite particionar logicamente as conexões de fibra ótica em várias conexões lógicas chamadas VLAN (Virtual Local Area Networks).
Benefits:
Reduce cost when using large volumes of traffic
Increase reliability (predictable performance)
Increase bandwidth (predictable bandwidth)
Decrease latency
2.11. Segurança AWS
Os grupos de segurança funcionam como um firewall integrado para seus servidores virtuais. Com isso, você tem total controle sobre o nível de acesso das suas instâncias.
Método para filtrar o tráfego das suas instâncias
As instâncias podem ser totalmente privada até totalmente pública
Para quem tiver interesse em fazer o exame AWS Certified Cloud Practitioner (CLF-C01), sugiro começar a leitura pelo Cloud Practitioner Learning Path para entender o caminho de aprendizagem em relação a Cloud AWS. Em seguida, acessar a AWS Certification que explica como as certificações podem ajudar na carreira, os benefícios e a aplicabilidade em diferentes níveis (Foundational, Associate, Professional e Specialty).
Cloud AWS, serviços (core / integrated services) e infra global
Proposta de valor e princípios de arquitetura
Definição de preço e suporte
Segurança da conta e conformidade
Características para implantação e operação Cloud AWS
A AWS recomenda essa certificação a candidatos que tenham pelo menos seis meses de experiência com a nuvem da AWS (em qualquer função) e entendimento básico dos serviços de TI e seu uso na plataforma AWS Cloud. Alguns exemplos de perguntas que são abordadas no exame:
Which of the following is an AWS responsibility under the AWS shared responsibility model?
Which service would be used to send alerts based on Amazon CloudWatch alarms?
Why is AWS more economical than traditional data centers for applications with varying compute workloads?
Detalhes do exame
Formato: 65 questões de múltipla escolha, múltiplas respostas (mínimo de 70% de acerto para aprovação) Duração: 90 minutos Método de apresentação: Centro de testes ou exame supervisionado online Custo: 100 USD Idioma: disponível em inglês, japonês, coreano e chinês simplificado https://aws.amazon.com/pt/certification/certified-cloud-practitioner/
Conteúdo do exame
O exame está dividido em quatro domínios principais, onde 26% das questões serão de Cloud concepts, 25% em Security and compliance, 33% em Technology (a maior parte) e 16% sobre Billing and Pricing:
O AWS Cloud Practitioner Essentials é um curso gratuito (online) e possui 6 horas de duração. É muito recomendado para quem vai fazer a prova de certificação.
Aborda conceitos de Cloud, serviços, segurança, arquitetura, definição de preço e suporte da AWS.
Simulados
Após a realização do curso e a leitura dos conteúdos (mencionados acima), uma boa dica é fazer os simulados para ajudar a entender o formato das questões e o conhecimento esperado no exame. Compartilho aqui três links com simulados bem próximos ao conteúdo e formato do exame:
O exame pode ser feito na sua própria casa (com verificação de alguns requisitos) ou em locais autorizados. O link para mais informações e agendar o exame é AWS Certified Cloud Practitioner (CLF-C01).
Voltando ao contexto da transformação digital, onde os modelos de negócio (business agility,inovação, etc.) e tecnologias são utilizados para alavancar o desempenho da empresa e a experiência do cliente, um enabler imprescindível nessa jornada (a ser abordado nesse post) é Cloud e por isso, tem sido a “fundação” que habilita a transformação do negócio e o foco estratégico (cloud-first) de muitas organização -avançar o uso de Cloud Services.
A estratégia cloud-first deve ser compreendida pela organização toda (não somente TI) e assim, buscar a obtenção dos benefícios de negócio, tais como redução do custo operacional, time to market e melhora na escalabilidade e segurança das aplicações. O objetivo das empresas pode variar, onde algumas buscam a migração completa de seus data centers, já outras apenas alguns subsets de aplicações para Cloud pública. Por isso, cloud-first não significa cloud-always.
Uma boa vantagem em utilizar Cloud Services é o uso sob demanda (otimização de recursos, sem grandes investimentos para começar a usar e sem desperdícios), escalabilidade e segurança, pois os recursos são gerenciados pelo provedor. O desenho abaixo representa os principais Cloud Services que a AWS oferece:
Inovação – Build, Buy e Borrow
Em geral, continuar com o recursos que você já domina, ampliando o uso da tecnologia existente é uma das opções consideradas. Evite a armadilha do resume-driven development, deixando as pessoas escolherem as tecnologias boas para o seu próprio currículo, e não para o problema.
Caso não seja possível ampliar o uso da tecnologia existente, então utilize os serviços do tipo pay-as-you-go. Esses serviços gerenciados (ou SaaS) reduzem a carga de trabalho em configuração e gestão de itens de infraestrutura, dedicando mais tempo a inovação e publicação de novas releases. A decisão build para novas tecnologias in-house pode gerar desperdício de custo, tempo e oportunidade. Avalie bem, pois o produto criado, em geral, é o diferencial competitivo, e não a tecnologia construída.
Alguns elementos críticos para a inovação: cultura e pessoas, processos e organização, produtos e tecnologia. A estratégia Build, Buy or Borrow pode ser utilizada nesse contexto, e resumida da seguinte forma:
Build: quando já possui a expertise na empresa, core business, propriedade intelectual / patente ou pioneira no segmento.
Buy: quando é atividade core ao negócio, tem relação estratégia de mercado ou tempo crítico para lançamento.
Borrow: reduzir o risco, aumentar o time to market e customização em mercados específicos.
Ao decidir a migração para Cloud Services, alguns benefícios comumente obtidos são:
Redução de riscos: capacidade de adaptar-se rapidamente as mudanças (por permitir testar com frequência e efetuar correções rápidas).
Escalabilidade: redimensionar seus recursos conforme necessário.
Confiabilidade: capacidade do sistema se recuperar de falhas de infraestrutura ou serviço ou adquirir recursos para atender à demanda e mitigar interrupções.
Segurança dos dados: propriedade total sobre seus dados.
Estratégias de migração Cloud
Uma das estratégias mais recomendadas para migração de aplicações em Cloud é o 6R’s da AWS, baseada no 5R’s de Gartner. Essa discussão, em geral, ocorre na segunda fase (Portfolio Discovery and Planning) do processo de migração, onde são determinados os ambientes, interdependências e o que será priorizado na migração.
A complexidade de migração varia, dependendo muito da arquitetura e do licenciamento existente. Enquanto uma arquitetura orientada a serviços possui baixa complexidade, um mainframe monolítico certamente trará uma alta complexidade. A figura abaixo resume os 6R’s:
Rehosting (“lift-and-shift”): não há mudanças na arquitetura. É a reimplantação do aplicativo em um ambiente de hardware diferente (em cloud). Isso altera a configuração da infraestrutura do aplicativo.
Replatforming: a arquitetura ainda não sofre alterações, mas há otimizações em Cloud para obter benefícios. Por exemplo, a migração do banco de dados para uma plataforma de banco de dados como serviço, como Amazon RDS.
Repurchasing : mudança para um produto diferente (geralmente em SaaS), tal como um CRM para SFDC.
Refactoring / Re-architecting: alterações nas práticas de desenvolvimento e arquitetura, usando recursos nativos em Cloud, que provê a infraestrutura para a execução do seu aplicativo.
Retire: descobrir o que não é mais utilizado em seu ambiente e que pode ser desativado, e assim, focar a atenção da equipe em aplicações que trazem benefícios ao negócio.
Revisit: não fazer nada (por enquanto). Isso acontece em aplicativos que foram atualizados recentemente ou que não fazem sentido migrar por enquanto.
Estágios de adoção
A AWS possui um conjunto de estágios que descrevem a postura associada as organizações na adoção Cloud. São quatro estágios:
Stage 1 – Project: inicia com alguns projetos para entender como a nuvem vai atender as necessidades do negócio. Utiliza experimentação em projetos early cloud, POCs, análise TCO/ROI e preparação a riscos/segurança.
Stage 2 – Foundation: com a percepção dos benefícios iniciais, a empresa pode escalar a adoção em toda a organização. A recomendação é criar um CCoE (Cloud Center of Excellence), responsável pelo treinamento/capacitação dos colaboradores, gestão de custos e ativos, estratégia de arquitetura híbrida, arquitetura de referência, entre outros.
Stage 3 – Migration: define-se então a estratégia de migração, geralmente iniciada com o processo de descoberta de aplicativos e um business case, seguido por migrações individuais (em várias estratégias de migração diferentes).
Stage 4 – Optimization: muitas empresas acham mais fácil otimizar seus aplicativos depois de migrá-los para a nuvem. Nesse estágio há infraestrutura automatizada e gestão própria do stack de soluções.
A preparação e o planejamento para migração envolve work streams que atuam nas áreas de Landing Zone, Modelo Operacional, Governança, Security & Compliance, Pessoas (skills), Application Portfolio, Processo de Migração e Business Case.
Com o uso de metodologia, processos, ferramentas e recursos, define-se um objetivo de migração, geralmente avaliado em 3 à 4 meses de trabalho (estruturado em Sprints). Durante essa fase, as equipes realizam migrações iniciais para criar experiência e confiança através de quick wins. Os principais deliverables de preparação a migração são:
Landing Zones: configuração de ambiente seguro de várias contas.
CCoE (Cloud Center of Excellence) / Cloud Operations Model: treinamento e capacitação adequada aos times. Determinar as práticas operacionais para maximizar os benefícios de negócio.
Security and Compliance: resolução de gaps e implementação de práticas de segurança e compliance.
Portfolio Discovery and Migration: sequenciamento e planejamento das migrações.
Conclusão
Como vimos acima, a utilização de Cloud Services é um enabler muito estratégico a ser considerado no seu plano de transformação digital ou estratégia digital. Há diversas estratégias de migração, pois sabemos da dificuldade em manter os serviços core (nem sempre criados com as melhores práticas) em funcionamento e o custo que essa decisão pode acarretar na criação de novos produtos para a empresa.
A escolha de um bom parceiro é essencial para apoiar a jornada de adoção Cloud. Essa jornada exige skills especializados, tanto no conhecimento do negócio e aplicações da própria empresa, quanto em tecnologias Cloud. Além disso, uma boa governança é fundamental para habilitar o plano de migração e readiness e garantir em conjunto com a equipe que os objetivos serão atingidos.
Por fim, verifique os benefícios e aplicabilidade real em seu ambiente. As análises financeiras, tal como o TCO (Total cost of ownership), também são importantes para apoiar suas decisões. Quais são os custos de oportunidade e operacionais em manter aplicações ou serviços no ambiente atual? É possível ser inovador nesse cenário? Já avaliou alguma PoC? As features que mais geram receita para o negócio estão bem dimensionadas (custo x retorno)? Há insights com o uso de dados coletados? E o monitoramento e segurança das aplicações?
Após a introdução do Value Streams Mapping e seus benefícios, veremos aqui as etapas de criação, sequenciando as atividades que a empresa realiza para atender as demandas do cliente. O fluxo de valor percorre todas as áreas da organização, rompendo silos (entre áreas), em busca de oportunidades de melhoria e redução de desperdícios.
O mapeamento, em geral, envolve colaboradores experientes (e de áreas chaves) por ser um processo complexo e multifuncional. O cliente é a principal razão de acontecer o VSM. Por isso, verifique os benefícios e melhorias que podem ser feitas para os clientes. Quais os problemas que estamos resolvendo? Estamos melhorando a nossa capacidade de entregar valor e remover desperdícios?
O VSM é mais aplicável a processos repetíveis, especialmente quando houver handoffs (tempo de espera) entre os times, que é onde a maioria das demoras e desperdícios se encontram. O mapeamento possui três principais etapas: current state(estado atual; identificar os processos core business), future state (onde devemos estar em alguns dias com os recursos atuais) e next future state(visão estratégica “ideal” de onde poderia estar com recursos e automações ainda não disponíveis).
Um exemplo clássico, representado no desenho abaixo, demonstra todas as etapas de um processo para concluir a entrega do cliente. O value added time é tempo gasto em atividades que agregam valor ao produto. E o Lead Time é a soma de todos os tempos, do início ao fim do processo (inclui os tempos de espera entre as etapas). Percebe-se então a presença de gargalos no fluxo, devido a somente 15 minutos em atividades que agregam valor ao produto, e 68 dias para concluir o processo.
Entre as principais métricas consideradas no VSM que ajudam a compreender os fluxos de entrega ao cliente estão:
Lead Time: tempo decorrido entre o pedido e a entrega, medindo seu processo de produção da perspectiva do cliente.
Cycle Time: considera entre o tempo de inicio do trabalho e termina quando está pronto para entrega.
Takt Time: é a taxa de demanda do mercado (o ritmo do mercado), ou seja, o que precisa ser cumprido para atender à demanda do cliente.
Current state O desenho abaixo é um exemplo real de como era o ciclo de desenvolvimento em uma empresa, onde o Lead Time era de 19 horas – tempo médio entre o recebimento de uma demanda (via abertura de ticket) e o deploy em produção. Por questões de compliance, a empresa precisava de algumas aprovações e documentos durante o processo.
Foram identificados alguns gargalos nesse fluxo:
Tempo de espera alto para validação do usuário e aprovação da mudança (change management). Causa: documentos preenchidos manualmente durante o processo geravam um checklist demorado.
Deploy manual demandava tempo de preenchimento do documento de publicação e do publicador em seguir as etapas.
A fase inicial (planning e design) exigia a preparação de documentos que seriam utilizados no decorrer das etapas.
Future state
Ao reunir os colaboradores para discutir o future state do fluxo de valor, lembre-se de seguir alguns princípios Lean, tais como a criação do Flow (fluxo), processos vinculados aos clientes, eliminar os desperdícios, evitar super produção (seguir o takt time) e lotes grandes.
Existem diversas ferramentas que ajudam a mapear o fluxo de valor. O desenho abaixo é somente para ilustrar o fluxo to be com as principais mudanças (sem o uso de uma ferramenta específica para VSM), automatizando o deploy e simplificando o registro das informações das RDMs. Essas ações reduziram significativamente os tempos de espera entre trabalhos e o tempo que era gasto com preenchimento manual de documentos (documento de teste técnico, homologação e publicação).
VSM Symbols
Para conhecer melhor os símbolos que podem ser utilizados no VSM, recomendo assistir esse vídeo abaixo:
Playbook Após ver todos esses conceitos importantes no VSM, como você planeja reunir as pessoas e conseguir mapear os fluxos de valor da sua organização? Um Workshop de VSM (2-3 dias) seria muito apropriado para isso, desde que considere alguns pontos:
Identificar um facilitador com experiência em VSM.
Identificar e priorizar Value Streams que tenham impacto no cliente e na estratégia organizacional. Escolha a que mais atenda a necessidade da empresa.
Envolver um Sponsor (ou champions) comprometido com o future state.
Empoderamento do time para realização das mudanças.
Na dinâmica, considerar o uso de Charter para discutir escopo, declaração do problema, objetivos e métricas.
Considerar a visão idealfuture state (de longo prazo) com tecnologias e automações que ainda não estão disponíveis, mas que a visão estratégica deseja ter.
Levantar oportunidades e atribuir owners para as implementações.
Governança para acompanhamento das ações e planejamento de melhorias.
Também acordar uma reunião com o Sponsor e stakeholders para revisar os objetivos do Workshop, treinamentos (caso seja necessário), atividades Pre Workshop, facilities e a logística dos colaboradores.
Outcomes Os resultados esperados com o VSM incluem melhorias nos tempos de entrega e percepção do cliente (lead time e cycle time), da qualidade e experiência de uso, além da redução de desperdícios no processo. Após a execução da agenda citada acima, os outcomes gerados são:
Mapa do fluxo current state
Mapa do fluxo future state (e ideal future state)
Métricas de performance
Plano de transformação para atingir o future state
No contexto do Business Agility, onde as empresas precisam se adaptar rapidamente ao mercado e ao ambiente, a gestão das Value Streams é fundamental para otimizar a entrega contínua de valor ao cliente. Sem o value stream thinking, as empresas falham em organizar os objetivos Lean e fornecer o valor máximo ao cliente, assim como não são Customer-Centricity.
A técnica VSM (Value Stream Mapping) é oriunda do Lean Six-Sigma (roteiro DMAIC) e já é utilizada há muitos anos na indústria. Atualmente, também é amplamente utilizado em Agilidade e DevOps para apoiar os times a construir o fluxo de valor, que concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente.
Veja uma comparação rápida entre a gestão funcional e gestão do fluxo de valor:
Gestão funcional (clássica)
Gestão do fluxo de valor
Informação restrita a poucos (silos)
Informação compartilhada (interfaces)
Foco maior em departamentos
Foco nos objetivos dos processos
Comunicação vertical
Comunicação transversal
Metas departamentais
Objetivos organizacionais
Pouco foco no cliente dos processos
Foco total nos clientes dos processos
Delegação de autoridade limitada
Alto grau de empoderamento
Processos podem não agregar valor
Melhoria contínua nos processos
Estruturado nas habilitações e poderes
Estruturado no modo de fazer o trabalho
O que é
Value Streams (ou fluxos de valor) são as etapas que ocorrem para prover serviços ou produtos aos clientes. Por isso, o SAFe (Scaled Agile Framework) identifica como a construção primária para entendimento, organização e entrega de valor.
Um trigger inicia o fluxo de valor, e ao final, há alguma forma de monetização ou valor entregue. As etapas intermediárias são as atividades usadas para desenvolver ou entregar o valor.
Operational value streams: são as pessoas e as etapas usadas para fornecer bens ou serviços a um cliente.
Development value streams: são as pessoas e as etapas envolvidas no desenvolvimento de novos produtos, soluções e serviços. Esses são os fluxos de valor que constituem um portfólio SAFe.
Em Identifying Value Streams and ARTs, você encontra um artigo adicional e bem completo para ajudar a identificar as Value Streams na sua organização. O Development Value Stream Canvas ajuda no entendimento junto aos stakeholders em relação as pessoas, fronteiras, entregáveis e outras informações da value stream.
Benefícios
O fluxode valor deve delinear tudo entre a concepção do produto à implantação. Crie seu diagrama usando as principais métricas para determinar como você define e mede o sucesso, melhorando continuamente.
Entre os principais motivos pelo qual as equipes devem utilizar VSM (ValueStreamMapping):
Ajuda a identificar gargalos, desperdícios e handoffs
Permite acelerar o aprendizado e reduzir o time to market
Elimina processos redundantes e desnecessários
Promove a colaboração multifuncional e a entrega de valor (ao invés de projetos com foco em concluir tarefas)
Contribuem para melhorias na qualidade e produtividade
Melhora o feedback integrado e mais rápido
Outros
Após essa abordagem inicial que tivemos sobre as value streams, recomendo também a compreensão de outros conceitos, que são importantes, mas que não serão explicados com profundidade nesse artigo:
Lean Budgets: após a definição das value streams, o Lean Portfolio Management (LPM) gerencia os respectivos budgets, com base nos princípios Lean-Agil budgeting, acelerando ainda mais o fluxo.
KPIs: os indicadores são utilizados para avaliar os investimentos realizados nas value streams.
Coordenação: por mais que a estrutura em value streams empoderem decisões descentralizadas (e com maior independência), a coordenação é necessária para garantir alinhamento das value streams com os objetivos da empresa e do portfólio.
ARTs (Agile Release Trains): após identificar as value streams, o passo seguinte é entender como realizá-los. Os ARTs possuem as pessoas e recursos necessários para aprimorar o fluxo de valor.
VSM (Value Stream Mapping): a ferramenta ajuda a identificar os desperdícios e atuar nas restrições. Em DevOps, o fluxo de valor concretiza uma necessidade em um produto ou serviço para entrega de valor ao cliente.
O MLOps (Machine Learning e Operations), de forma similar ao DevOps, é a combinação de práticas e ferramentas que permitem aos times de Data Science e Operações melhorar a implementação de modelos, através da governança de modelos de ML (Machine Learning) e IA, monitoramento, validação, colaboração e comunicação.
Isso porque segundo Gartner, muitas empresas estão desenvolvendo modelos de Machine Learning, mas apenas 47% deles são publicados em produção. E ainda 88% das iniciativas de IA possuem dificuldades para passar do estágio de teste.
O Azure ML é composto de interfaces web e SDK que faz o treinamento e deploy do modelo. O processo (figura abaixo) envolve a gestão dos dados, limpeza dos dados, escrevendo e executando experimentos, publicando os modelos para coletar os dados reais (em produção) e aplicar melhorias nos modelos.
Experiment: os cientistas de dados realizam diversos experimentos, evoluindo e coletando dados, a procura de respostas para as necessidades do negócio. Fundamento nos conceitos de DevOps e da Engenharia de Software, o MLOps sugere práticas para evitar a promoção de modelos mal escritos a outros ambientes.
Develop: o treinamento dos algoritmos (Azure ML Training Services), ETL (Data pipelines) e as práticas de CI/CD para criação dos Pipelines (Azure DevOps Pipelines) de deploy dos experimentos construídos de ML.
Operate: inference, monitoramento (com uso de analyse/profile, app telemetry, etc.), testes automatizados e data feedback loop para aprendizado com os dados que levam a melhorias nos modelos.
Vantagens
Com os times trabalhando juntos (cientistas de dados e operações), encorajam as operações de negócio data-driven, reduzindo o gap entre a descoberta de insights e ações de implementação. Algumas das vantagens são:
Reprodutibilidade e auditabilidade: a criação dos modelos em pipelines específicos e reproduzíveis, possibilitando rollbacks (em caso de erros) e auditorias, caso seja necessário algum rastreamento.
Validação: herda conceitos de DevOps como validações automáticas, testes, profiling e gestão de ambientes.
Habilita automação e observabilidade ao realizar novas implementações. Permite a comparação entre predicted x expected performance. Coleta as informações que servem de treinamentos aos modelos para melhorias futuras.
Fases do MLOps
O framework DevOps para soluções AI no Azure pode ser macro representado dessa forma:
E compreende quatro principais fases entre a criação até a implantação dos modelos:
Criação e treinamento dos modelos: use o treinamento com pipelines de aprendizado para criar pipelines reproduzíveis, reunindo todas as etapas (da preparação de dados à avaliação do modelo).
Implantação de modelos: empacotamos o modelo para implantação e a criação de perfil para ajudar a configurar memória, CPU e validar os modelos.
Automatizar o aprendizado E2E: atualizar frequentemente os modelos com Azure Machine Learning e GitHub, testar e implementar continuamente com outros aplicativos e serviços.
Trilha de auditoria: coletar os dados de ponta a ponta para estabelecer uma trilha de auditoria. Por exemplo: dados do publicador dos modelos, data de implementação, uso em produção, etc.
![Reaching Cloud Velocity: A Leader's Guide to Success in the AWS Cloud (English Edition) por [Jonathan Allen, Thomas Blood, Werner Vogels, Adrian Cockcroft, Mark Schwartz]](https://m.media-amazon.com/images/I/41Kayh2LPcL.jpg)
![AWS Certified Cloud Practitioner Practice Tests 2020: 390 AWS Practice Exam Questions with Answers, Links & detailed Explanations (English Edition) por [Neal Davis]](https://m.media-amazon.com/images/I/51B6GAXkwSL.jpg)
![Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation (English Edition) por [Karen Martin, Mike Osterling]](https://m.media-amazon.com/images/I/51FnevxdJsL.jpg)
Figura: 
Figura: 
Digital Strategy and IT Innovation 