No post anterior falamos sobre a migração para Cloud http://www.marcelosincic.com.br/post/Azure-Virtual-Datacenter-(VDC)-Parte-I-Migracao-AS-IS-e-TO-BE.aspx 

Neste post vamos entender os conceitos básicos, que são representados por esse diagrama:

Cada parte representa um dos pilares que sustentam um Datacenter Virtual:

• Encriptação – Todos os dados trafegados dentro de um datacenter onde vários clientes se hospedam precisam ser protegidos de forma que um não tenha acesso aos dados de outros. Isso envolve criptografia de comunicação, discos e trafégo
• Identity – Um modelo consistente de identidade onde os clientes consigam se logar e ver seus objetos com todos os recursos disponiveis. No caso do Azure isso é feito pelo Active Directory multi-tenant (multi locatário). Como já conhecido no mercado sistemas de diretório permitem que multiplas empresas estejam hospedadas e compartilhem o modelo de banco de dados e autenticação com total isolamento
• Software-Defined Networks – Como hospedar vários clientes se todos querem ter o mesmo range de IP e se comunicam pelos mesmos conjuntos de cabos?
  Esse é o desafio das SDNs, permitir trafego isolado. No passado faziamos isso com o recurso de VLAN mas era limitado a 65535. Hoje isso é feito de forma lógica por usar recursos como o NVRE e outros onde os pacotes de rede são tageados (marcados) a quem pertence, similar ao que a VLAN fazia mas sem o limite de 32 bits.
  Isso permite que multiplos clientes tenha o mesmo range de IP 10.0.0.0/24, já que cada rede virtual recebe um diferente TAG nos pacotes, com a criptografia e identidade garantindo a confiabilidade na entrega dos pacotes de dados
• Compliance – De nada adiantaria se ao migrar para um datacenter público você ficasse preso a padrões que só funcionam lá. As clouds publicas precisam adotar os padrões de mercado para as redes se comunicarem. Isso não quer dizer que a forma como o Machine Learning da Microsoft é codificado é igual ao Machine Learning da AWS, mas sim que a parte básica segue padrões de interoperabilidade.
  Por exemplo, uma VMs na AWS pode se comunicar por IP com uma VM no Azure ou no Google Cloud, pois todas usam os mesmos protocolos, mesmo que um provedor tenha serviços agregados diferentes.
  O mesmo vale para uma aplicação em Moodle ou SAP, se está no Azure ou AWS não importa pois seguem os padrões de rede e comunicação (interchange) identicos.
  Por conta do compliance que posso deixar metade dos meus servidores local e os outros espalhados em 3 diferentes datacenter publicos e todos se comunicando normalmente.
• Logging, Audit e Report – Ao migrar de uma nuvem privada (local) para uma pública preciso saber os custos e ter certeza que meus dados estão seguros e acessados só pelos meus usuários.
  Aqui não estamos tratando de log, auditoria e reports para o cliente e sim a infra interna para que o provedor tenha certeza que não há vazamento de dados, quem fez cada operação e reportar isso quando necessário.
  Por isso os cockpits de provedores de cloud pública são gigantescos. Precisam controlar e serem capazas de se refazer em qualquer tipo de falha que ocorra.
  Os primeiros datacenters surgiram do conceito de hosting, ou seja você tirava os servidores do seu rack em casa para levar ao provedor onde a eletrica, links e segurança fisica ficam por conta deles. Nesse modelo toda a responsabilidade de comunicação, segurança lógica e relatórios é sua.
  No modelo público uma boa parte dos recursos são alocados para controlar os recursos, por exemplo ao criar o antigo Microsoft Azure Pack (atualmente descontinuado) várias VMs eram criadas com o objetivo de fornecer os itens de controle.

Conclusão

Nesse segundo post falamos sobre os componentes básicos que formam uma cloud pública.

Sinta-se seguro ao colocar seus dados nesses provedores, eles são preparados para garantir o isolamento e segurança dos seus dados.

Agora já disponivel na maior parte dos paises do mundo onde a Microsoft possui Datacenters, o Azure Stack passou a ser um tema constante.

Mas primeiro é preciso entender o foco e composição da solução.

Como é composto?

O Azure Stack é um rack de servidores com tamanhos e configuraçoes pre-determinados, hoje disponivel pela Dell, HP, Lenovo e Cisco.

O HW de cada fabricante foi homologado e padronizado, o que garante updates diretamente do Azure Stack tanto para o software quanto para hardware.

Isso quer dizer que não posso utilizar minhas próprias configurações?  Exatamente, para garantir que o sistema fique atualizado e a hiperconvergencia funcione os drivers tem que ser homologados e testados.

É importante entender que todo o Azure Stack é baseado no modelo de hiperconvergencia, ou seja são utilizadas as tecnologias de SDN (Software Defined Network) e SDS (Software Defined Storage) ou SDx em geral como são chamadas.

Ou seja, não existe um storage dedicado. Cada servidor possui uma parte de discos SAS de 15k e discos SSD, com o Storage Space Direct (S2D) habilitado. Isso permite que os servidores tenham seus armazenamentos somados ao compartilhar os volumes entre sí.

A garantia de dados com o S2D é garantida pela distribuição de dados entre os servidores, como já faz o vSAM da VMWare ou o Nutanix.

Para quem se destina?

Diferente do que muitos pensam, o Azure Stack não visa o cliente que acha o Microsoft Azure caro e sim os que tem limitações em relação a nuvens públicas.

Por exemplo, alguns cases no Ignite foram da Swisscom e a KPMG da Suécia.

A KPMG o cenário foi a legislação e a exigencia de alguns clientes que não queriam seus dados de auditoria disponiveis em nuvem pública por mais que tente se justificar a segurança do dado. A solução foi o Azure Stack onde a KPMG teria os mesmos serviços utilizados por outras filiais no mundo, mas on-premisse.

Já o case da Swisscom foi o de ser um Datacenter local, já que o Azure não tem um DC no pais. Assim, aqueles clientes que querem utilizar serviços de nuvem pública podem utilizar a nuvem privada do Azure Stack para hospedar seus serviços localmente.

Ou seja, os principais clientes são, entre outros:

• Paises onde existem restrições legais quanto a armazenar dados em outros paises
• Datacenters interessados em fornecer serviços a seu usuário a mesma interface do Azure, mas localmente, por exemplo no Brasil só temos um DC Microsoft Azure e um provedor tradicional poderia usar o Azure Stack como ponto de Avaliability Group
• Empresas com alto uso de recursos computacionais baseados em IaaS e que possuem Datacenter próprios
• Empresas com tradição on-premisse que não querem ver seus dados fora do ambiente, mas desejam utilizar o modelo de Cloud Publica “in-loco” com facil manutenção e suporte de alto nivel

E aquele cliente que acha o Azure caro, vale a pena usar o Stack?   Na ponta do lapis não, pois precisamos lembrar que é um rack e precisa de refrigeração, energia, piso elevado e todos os outros custos envolvidos em um DC fisico.

Quanto custa o Azure Stack?

Primeiro é necessário ver o custo do Hardware que pode ser vendido diferente por cada um dos atuais 4 fabricantes.

Por exemplo no caso da Dell as configuraçoes começam em 4 servidores de 20 CORE e 4.1TB, podendo chegar a doze servidores por rack, sendo a capacidade máxima de 4 Racks com 12 servidores cada um.

Alem disso, temos os servidores Low, Mid e High profille, onde um rack com os 12 servidores High Profile a capacidade é 336 Core, 6.1TB RAM, 138TB cache, 1.2PB de disco!!!!

Agora vamos falar do custo de Software. É importante lembrar que o Azure Stack não tem custo de software, ou seja ele é bilhetado como um serviço, que inclui:

• Atualizações do Software Stack
• Atualizaçoes de Drivers e componentes lógicos
• Disponibilização e pré-configuração dos componentes e templates
• Suporte Microsoft do Azure é o mesmo que atende Azure Stack

Ou seja, o Azure Stack tem um custo pelo consumo, não com licenciamento, na modalidade “Pay-As-You-Use”, baseado na tabela abaixo:

Referencia: https://azure.microsoft.com/pt-br/overview/azure-stack/how-to-buy/

Baseado nisso, temos como exemplo uma VM A2 que custa U$ 130/mês no Microsoft Azure, no Azure Stack sai por U$ 40/mês.

Claro que deve-se incluir no TCO a infra do Datacenter, garantia e suporte do HW, administração e energia elétrica que no Microsoft Azure não temos.

Mesmo assim, grandes ambientes que já contam com Datacenter a opção passa a ser vantajosa por já incluir muitos destes custos embutidos.

E se o cliente não quiser pagar por consumo?

Tambem é possivel adquirir o custo por CORE, mas pessoalmente não vejo vantagem pois o custo aumenta pelos seguintes motivos:

• No modelo variável “Pay-As-You-Use” a escalabilidade tambem reflete no preço quando diminuir a carga
• No modelo desconectado é necessário pagar em separado o licenciamento de Windows e SQL que no modelo “Pay-As-You-Use” está embutido
• No modelo desconectado o pagamento é anual e upfront

Todos os Serviços do Azure Estão Disponiveis no Azure Stack?

Ainda não. Como pode-se ver na tabela de preços os mais importantes sim.

Por exemplo, alguns tipos de VMs como G não poderiam rodar no Stack e o mesmo com alguns serviços de alta capacidade como Machine Learning e Cognitive Services.

É possivel criar planos e juntar diferentes soluções para criar workloads complexos, como documentado em https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-offer-services-overview

Conclusão

Azure se tornou o principal produto da Microsoft e com o Stack a integração entre as nuvens pública e privada realmente se torna uma experiencia unica!

Acesse o link da documentação e saiba detalhes do produto: https://docs.microsoft.com/en-us/azure/azure-stack/