IBM adquire Red Hat, tornando-se o provedor de Cloud híbrida número 1 do mundo!

Olá Leitores,

Hoje a notícia é bem quente, IBM adquire Red Hat, por US $34 bilhões, tornando-se a maior aquisição da gigante de serviços de computação, expandindo assim os serviços baseados em Cloud.

redhat-ibm-one

As notícias já podem ser encontradas nos principais veículos de mídia internacional: NewsRoomIBM, Bloomberg, CNBC, entre outros.

Essa aquisição reúne os melhores provedores de Cloud híbrida da categoria e permitirá que as empresas movam com segurança todos os aplicativos de negócios para a Cloud. As empresas hoje já estão usando várias nuvens. A IBM e a Red Hat estarão fortemente posicionadas para resolver e acelerar a adoção híbrida de várias nuvens. Juntos, eles ajudarão os clientes a criar aplicativos de negócios nativos da Cloud mais rapidamente, proporcionando maior portabilidade e segurança de dados e aplicativos em várias nuvens públicas e privadas, tudo com gerenciamento de Cloud consistente.

Ao fazer isso, eles aproveitarão sua liderança compartilhada em tecnologias essenciais, como Linux, containers, Kubernetes, gerenciamento de várias nuvens e gerenciamento e automação de Cloud.

“The acquisition of Red Hat is a game-changer. It changes everything about the cloud market,” said Ginni Rometty, IBM Chairman, President and Chief Executive Officer. “IBM will become the world’s #1 hybrid cloud provider, offering companies the only open cloud solution that will unlock the full value of the cloud for their businesses.

Em posts anteriores eu já havía sinalizado que a parceria entre IBM e RedHat estava bem fortalecida e cumpria grande fatores de entrega FULL STACK para todos os clientes.
Em pensar que a junção da IBM e RedHat trará aos clientes a possibilidade de trabalharmos do “DataCenter” passando por Hypervisor, Sistema Operacional, OpenShift, ICP (IBM Cloud Private) e chegando até o IBM Middleware .. será um espetáculo !!!

Vale lembrar aqui também que o tema “Open Source”  tem sido o maior tema em tecnologia este ano. Antes da aquisição da Red Hat pela IBM, dois dos maiores acordos de tecnologia do ano foram a compra de US$7,5 bilhões da Microsoft pelo GitHub, e também no início deste mês, os grandes rivais Cloudera e Hortonworks concordaram em se unir em um negócio de US$5,2 bilhões.

Outro tema que fortalece essa parceira é a liderança compartilhada em tecnologias essenciais, como Linux, containers e Kubernetes.

E por fim e matador eu vejo que a adoção de Cloud continua a ser facilitada aos clientes,  tornando o IBM Cloud, o único provedor de nuvem capaz de oferecer aos clientes uma arquitetura de nuvem abrangendo privada, pública e híbrida para atender às suas necessidades de flexibilidade, escalabilidade e portabilidade, sem bloqueio.

A RedHat se tornará uma unidade da divisão Hybrid Cloud da IBM, com Jim Whitehurst, CEO da Red Hat, se juntando à equipe de gerenciamento sênior da IBM e se reportando à CEO Ginni Rometty.

Com essa aquisição IBM e a Red Hat se tornarão a principal empresa Hybrid multi-Cloud do mundo.  UOU !!!! Seja bem vinda REDHAT !!!

As principais perguntas e respostas para a parceria podem ser encontradas abaixo:
News Room IBM – Q/A

ibm_redhat

Obrigado e abraços,


Thiago Viola
Cloud Digital Sales Executive
MBA Cloud Computing Teacher

E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola

Anúncios

Automação para Containers – Você conhece RANCHER ?

Olá Leitores,

Realizamos 03 posts destinados a containers e seus respectivos produtos de orquestração que visam cada vez mais trazer agilidade, conforto e economia para aquelas empresas que possuem a utilização de containers.

Neste post abordamos um produto chamado RANCHER, o qual vocês perceram que irá tocar todos os temas previamente postados, containers, orquestradores e os principais provedores de Cloud Pública.

 

rancher-logo-horiz-full-color

É …

uma plataforma Open Source que permite às organizações executarem e gerenciarem o containers (Docker e Kubernetes) em produção. Com o Rancher, as organizações não precisam construir uma plataforma de serviços de container a partir do zero usando um conjunto distinto de tecnologias de open source. Através dele é possível administrar todos os pontos de seu ambiente Docker, incluindo: Orquestração, Loadbalance, volumes e rede.

Arquitetura

A figura abaixo demonstra claramente a capacidade do RANCHER em automatizar e criar vinculos com diversos provedores de Cloud, a escolha de um provedor de orquestração de container e ainda um catalago com os principais produtos os quais você poderá utilizar em containers.

Screen Shot 2017-10-21 at 14.45.39

Características

– Rapidamente tenha containers em produção aproveitando o conjunto mais completo de orquestração de containers e capacidades de gerenciamento de infraestrutura;

– Automatize a implantação e operações de containers com uma distribuição robusta e totalmente suportada de Kubernetes.

– Inovar com recipientes sem comprometer a flexibilidade ao capacitar os desenvolvedores com acesso rápido às ferramentas mais recentes;

 

Como funciona ?

 

 

 

Obrigado e abraços,


Thiago Viola
Head of Watson and Cloud Digital Sales Brazil
SoftLayer Subject Matter Expert

E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola

Webinar – Sua empresa irá Inovar? Saiba como Infraestrutura e Plataforma podem ser combinadas.

Olá Leitores, Bom Dia.

O mundo de infraestrutura em Cloud por muitas vezes pode ser encarado como comodite e a passagem para Plataforma como inovação. Quel tal fazer ambos co-existirem e equalizar o uso de tecnologia em sua empresa ?

Eu(Thiago Viola) e meu amigo Gerson Itiro (Dono do Canal do Youtube: Future Cloud) seremos os responsáveis por essa apresentação.

Contamos com a sua presença!

Participe!  01 de novembro, às 10h!

Inscreva-se: https://engage.vevent.com/index.jsp?eid=556&seid=91790

Screen Shot 2017-10-21 at 10.59.22

Obrigado e abraços,


Thiago Viola
Head of Watson and Cloud Digital Sales Brazil
SoftLayer Subject Matter Expert

E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola

Orquestratação de Containers – Parte 2: O que escolher ? Kubernetes vs. Docker Swarm vs. Apache Mesos ?

Olá Leitores,

No post número 01 sobre Orquestração de containers abordamos as atuais e principais soluções de gerenciamento no mercado que são: Kubernetes | Docker Swarm |Apache Mesos, onde demonstramos as características e arquitetura básica de cada um.

Para este segundo post vamos abordar o comparativo entre cada uma delas e tendo como fundamento funcionalidades cada vez mais necessárias como por exemplo: failover, balanceamento de carga e, em geral, clusterização de serviços. Vamos a eles:

 Kubernetes  dockerswarm MESOS
Instalação do Cluster Parcialmente complexo para configurar. Uso extensivo de arquivos YAML para definir todos os serviços no cluster. YAML é exclusivo para Kubernetes. Instalação e configuração fácil. Todos os componentes são principalmente baseados no docker, e podem ser integrados dentro do “systemd”. Geralmente fácil de instalar e configurar com pequenos clusters, mas consideravelmente mais complexo com configurações maiores
Deployment do Container YAML como base para a implementação de todos os componentes  (pods, serviços e controladores de replicação). Completamente baseado em Docker e muito fácil de configurar. Completamente nativo do Docker. Baseado em JSON. Todas as definições de aplicativos vão dentro de um arquivo JSON que é passado para a API RESOS.
Tamanho Mínimo (Cluster) Um servidor para Master e um servidor para Node. Nas configurações de produção, os serviços de descoberta e os Serviços Mestres devem ser agrupados com pelo menos 3 servidores em cada camada, e tantos minions como sua infra-estrutura requerem. Em ambientes práticos de produção, os serviços de descoberta e gerentes precisam estar em configurações altamente disponíveis com pelo menos dois servidores em cada camada. Vários trabalhadores também são necessários para distribuição e replicação de serviços. Um Master e um Slave. Em ambientes de produção prática, pelo menos 3 master e vários slave conforme necessário.
Escalabilidade Clusters de médio a grande porte. Muito adequado para aplicações complexas com muitos containers dentro dos ‘pods’. Este é um ponto em desenvolvimento no Swarm. Considere o Swarm para configurações de pequena a média escala. Clusters grandes a muito grandes. Melhor escolha se quiser combinar containers e aplicações normais no mesmo cluster.
Maturidade Muito maduro. Descendente direto da plataforma interna do Google BORG. Maduro, mas ainda está evoluindo. Muito maduro, especialmente para clusters muito grandes contando com milhares de servidores.
Melhores características Melhores recursos de agendamento PODS quando aplicativos complexos são necessários para serem implantados. Fácil de usar, e mais nativo do Docker. Escala nos milhares e recursos de restrições baseados em rack / host disponíveis para afinar onde implantar aplicativos.

Obrigado e abraços,


Thiago Viola
Head of Watson and Cloud Digital Sales Brazil
SoftLayer Subject Matter Expert

E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola

Nota

Orquestratação de Containers – Parte 1: Conheça Kubernetes | Docker Swarm |Apache Mesos.

Olá Leitores,

O atual crescimento da popularidade e uso de containers faz com que a necessidade de orquestração também acompanhe e assim a utilização de funcionalidades específicas começam a se tornar cada vez mais necessárias como por exemplo: failover, balanceamento de carga e, em geral, clusterização de serviços.

Teremos 03 artigos abordando exatamente a evolução divididos em conceitos, comparativos e ferramentas de automação.

Exclusivamente neste artigo, teremos as principais soluções de orquestração de container, como elas se comparam e uma sugestão de ambiente para usar cada opção.

06c82a_b35f2798e6fa492897b5cd7bb1386c0c-mv2


 

dockerswarm

Docker Swarm é uma solução de orquestração in-house do Docker. Sendo projetado pela própria Docker a qual incluí os principais recursos do Docker onde claramente podemos argumentar que o Swarm é a maneira mais compatível e natural de orquestrar infraestruturas de containers.

Como muitas outras soluções de orquestração (por exemplo: OpenStack), o Swarm inclui uma camada de controle chamada “Managers e uma camada de trabalho chamada “Workers”. Todos os serviços executados em ambas as camadas são executados dentro de containers.

Também incluída como uma parte muito importante de toda a solução de orquestração é a camada de “Discovery Layer”, com base em container também e executando uma solução de valor-chave como “etcd”. Esta camada de “Discovery Layer” é a parte do registro da solução (podemos compará-la ao OpenStack Keystone ou AWS IAM), esta camada sabe onde os serviços baseados em contêiner estão sendo executados.

Basicamente, estas são suas referências na infra-estrutura de orquestração, fornecendo estado e descoberta para o seu cluster.

Finalmente, você tem “Services e “Tasks”. Os serviços são conjuntos de Docker containers que funcionam em toda a sua infra-estrutura Swarm. Esses serviços são compostos por tarefas, os quais são seus containers Docker podem receber comandos individuais e também comandos específicos para todos os contêineres.

docker swarm

Resumo:

Managers: Camada de controle. Essa camada deve ser redundante em sua arquitetura. Normalmente, cada gerente é implantado em um nó independente.

Discovery: Camada de descoberta de estado e serviço. Você pode configurar seus serviços de descoberta nos mesmos nós gerenciadores ou em um conjunto independente de nós. Sempre faça-os redundantes.

Worker: Camada de trabalho (operacional). Todos os seus serviços finais serão executados ao longo de seus nós de trabalho. Esta camada deverá ter quantos workers você precisar. Pensar em crescimento horizontal aqui é uma ótima alternativa.

Services: Serviço implantado final composto por tarefas.

Tasks: Comandos dentro de um serviço.

Observação.: Caso queira, você pode começar o uso do Swarm com uma configuração “all-in-one setup”, executando tudo em um único servidor e depois crescer.


 

Kubernetes

Kubernetes é um gerenciador open-source o qual tem como objectivo automatizar implantar, dimensionar e gerenciar containers.

O primeiro componente de uma configuração Kubernetes é o MASTER. O MASTER é a  camada de controle, que executa uma “API” a qual controla todo o orquestrador.

Enquanto um único MASTER pode controlar a configuração completa, em ambientes de produção, vários MASTER são recomendados. O MASTER executa muitos serviços dentro de containers, cada um com uma função muito específica. Em soluções grandes uma solução de balanceador de carga é necessária na frente dos MASTER, a fim de ter alta disponibilidade e balanceamento de carga nos servidores.

Novamente, uma camada de descoberta é necessária sendo “etc.d” este responsável. A camada etcd deve ser executada dentro de seus próprios nós, com pelo menos dois servidores em um cluster etcd para fornecer redundância ou você pode executar etcd dentro dos contêineres, ou ainda diretamente no sistema operacional do host.

Soluções Linux como o CoreOS já incluem o formato etcd em seus principais pacotes. Como no Swarm, etcd manterá um registro do que está sendo executado e onde está sendo executado em toda a infraestrutura Kubernetes.

O próximo componente é o “NODE”. Os NODES ou, conhecidos também como nós e antigamente conhecidos como “minions”, executam todos os nossos serviços finais, sob a forma de “pods” (outro conceito de Kubernetes).  Para quem conhece você pode comparar os NODES com um Computer Node do OpenStack.

Um POD é um conjunto de contêineres (ou um único) que é encapsulado com seus próprios recursos de armazenamento e endereço IP. Se você quiser um exemplo disso, pense em um serviço LAMP, ou neste caso, um pod LAMP que é executado dentro do pod, um contêiner com Apache e PHP, e outro com o banco de dados MySQL / MariaDB.

Labels, é outro conceito muito importante em Kubernetes. As etiquetas são pares de valores-chave (bem como tags AWS) que você pode anexar a qualquer objeto em sua infra-estrutura baseada em Kubernets. Um exemplo clássico é definir etiquetas para seus Pods para organizá-los, por exemplo, ambientes (produção, desenvolvimento), camadas de aplicativos (frontend, backend) e outros usos semelhantes ao que você faz normalmente com tags em Cloud.

Selectors: os seletores são usados ​​para pesquisar um grupo de objetos que compartilham etiquetas específicas.

Replication Controllers: É a base dos recursos de alta redundância oferecidos pelo Kubernetes. Os controladores de replicação garantem que um número específico de instâncias do pod (ou réplicas do pod) esteja sendo executado em um determinado momento. Se um nó que contenha alguns dos seus pods diminua, os controladores de replicação garantirão que novos pods sejam iniciados ou mais precisamente agendados em qualquer um dos nós sobreviventes.

Services: Os serviços são o frontend (e camada de balanceamento de carga) para nossos pods, especialmente aqueles que são replicados. Normalmente, você precisa acessar seus pods através de um único ponto final, especialmente quando você possui vários pods executando o mesmo conjunto de aplicativos.

kubernets console

Resumo

MASTER: Base do seu orquestrador. O MASTER (ou Mestre) executa e expõe a API Kubernetes. Todas as funções de gerenciamento passam por esta API.

Discovery Layer: Sua central de chaves / valor baseada em etcd, onde todos os seus componentes se registrarão.

NODES: Onde a carga de trabalho. Todos os seus serviços e pods finais serão executados dentro de seus muitos nós.

Labels and Selectors: Organizador para seus objetos e a forma como os controladores de replicação e os conjuntos de réplicas sabem qual conjunto específico de pods para gerenciar.

Replication controllers / replica sets: Base de sua alta redundância e remodelação de vagens quando ocorrem falhas.

Services: Ponto de extremidade de serviço e camada de balanceamento de carga.

Observação.: Nota: Kubernetes foi projetado para implantações de médio a grande. No mínimo, você precisará de um servidor para o MESTRE e outro para o NODE. Se você quer uma configuração altamente disponível, você precisará pelo menos duas vezes os servidores (dois Masters e dois Nodes).


 

MESOS


Apache Mesos
  é uma plataforma que gerencia clusters de servidores usando o Cgroups de Linux para fornecer recursos de CPU, I/O, sistema de arquivos e memória. O Mesos é descrito como um kernel de sistemas distribuídos, ou em termos mais simples, uma plataforma de cluster que fornece recursos de computação para frameworks.

Já o Marathon é uma estrutura que usa Mesos para orquestrar contêineres Docker. Conceitos básicos para o combinado Marathon / Mesos:

MASTERS: Camada de controle que inclui zookeeper para controlar o estado. Em um ambiente altamente disponível em cluster, no mínimo três servidores é a norma para a camada de serviço dos masters. A alta disponibilidade é baseada em quórum nos masters. Um “líder” é eleito para garantir 100% de tempo de atividade.

SLAVES: A carga de trabalho está aqui. Os SLAVES executam todas as suas tarefas, passaram e controlam a camada de estrutura.

Descoberta do serviço: Marathon usa o serviço Mesos-DNS para todas as funções relacionadas com a descoberta de serviços. Com o uso inteligente de registros DNS SRV, Mesos registra todas as tarefas e instâncias de aplicativos no banco de dados de registro DNS.

Load Balacing: o balanceador de carga Marathon fornece serviços de porta via HAproxy. O Marathon-lb é baseado no docker e também pode fornecer a camada de descoberta do serviço se não quisermos usar o Mesos-DNS.

mesosconsole

Resumo

MASTER: Nossa camada de controle.
SLAVES: Carga de trabalho. Todos os serviços (e pods) são implantados aqui.
Descoberta de serviço: usando Mesos-DNS ou Marathon-lb.
Balanceamento de carga: balanceador de carga baseado em Marathon-lb.
Restrições: uma maneira de controlar a maneira como os aplicativos são implantados. Métricas: monitorando informações disponíveis através da API REST para componentes de terceiros.

 

No próximo post faremos uma comparação 1:1 de cada ítem dos 3 orquestradores.

 

Obrigado e abraços,


Thiago Viola
Head of Watson and Cloud Digital Sales Brazil
SoftLayer Subject Matter Expert

E-mail: thiagoviola@yahoo.com.br
LinkedIn: br.linkedin.com/in/thiagoviola
Blog: https://thiagoviola.wordpress.com/
Twitter: @ThiViola
YouTube Channel: https://www.youtube.com/user/tviola87
Slide Share: http://www.slideshare.net/ThiagoViola