Imagem

Cloud IBM Lite: USE A VONTADE – Sem necessidade de cartão de crédito e sem data de expiração.

Olá Leitores,

E se você tivesse acesso a um provedor de Cloud com tempo ilimitado para explorar um  ecossistema de serviços para construir seus aplicativos? E se você pudesse fazê-lo sem nenhum custo?

Chega de 30 dias free, chega de limitação por período, a IBM está tornando possível, com o IBM® Cloud Lite – uma conta gratuita que nunca expira.


O que está incluído em uma conta Lite?

  • 256 MB de Memória de tempo de execução instantânea da Cloud Foundry, mais 2 GB com Clusters Kubernetes.
  • Acesse o uso de planos fechados para serviços selecionados, como API Connect, Watson Conversation, Watson Discovery, Internet of Things Platform, Data Science Experience e muito mais. Confira a lista completa dos serviços disponíveis.
  • Rastreamento de uso e alertas de cobertura que o notificam quando você está se aproximando de seus limites de dados.

 

Screen Shot 2017-11-05 at 21.58.10

Quer experimentar?
Faça o acesso no link: https://console.bluemix.net/registration/free

Referência e maiores detalhes:
https://www.ibm.com/blogs/nordic-msp/announcing-ibm-cloud-lite/

 

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

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

Pensando SAP em Cloud ? Conheça as plataformas certificadas.

Olá Leitores, Bom Dia.

O tema SAP em CLOUD vem ganhando força devido ao número de provedores atualmente testados e certificados para a execução de HANA ou NetWeaver, simplificando assim o uso de Cloud e aproveitando toda a relação e boa relação custo-benefício para aumentar a capacidade e obter escalabilidade horizontal.

As empresas estão muito mais distribuídas do que costumavam ser e grande parte dos serviços agora estão hospedados em algum lugar da Cloud,e SAP tende a seguir o mesmo passo. Podemos pontuar alguns ítens que influenciam a favor para uso:

  • Opções de SAP HANA e SAP NetWeaver;
  • Nenhum compromisso CapEx ou de longo prazo;
  • Escalabilidade global. Sem latência.
  • Implemente rapidamente;

Ao buscarmos por todos as plataformas de IaaS Cloud certificadas vemos uma variedade de empresas como Alibaba Cloud, AWS, Google Cloud, IBM BlueMix e Azure.

A diferença entre cada um deles é a quantidade de RAM suportada, suporte a cluster e cenários suportados.

 

Screen Shot 2017-09-16 at 18.58.29

 

Link: https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/iaas.html

 

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

Vídeo

IBM Cloud Platform agora com Elastic Load Balancer, Security Groups, CDN Akamai e novos flavors de Virtual Machines !!!

Olá Leitores,

NOTÍCIAS BOAS NO AR !!!

A cerca de alguns meses a Cloud IBM vem passando por grandes transformações e melhorias relacionadas a funcionalidades e características que visam o aprimoramento e uso de diversos recursos para sua infraestrutura. Hoje, eu tenho a oportunidade de poder anunciar que estas funcionalidades estão disponíveis para uso.

  • Novos flavors de Virtual Machines;
  • Security Groups;
  • Elastic Load Balancer;
  • CDN Akamai;

Cada uma dessas novas funcionalidades dará a você usuário final a possibilidade de trabalhar de maneira mais integrada, simples e flexível quando tocada a parte técnica e comercial de algum projeto de Infraestrutura.

Este post será destinado a mostrar as características e também um Hands-On para que vocês possam acompanhar o funcionamento prática de cada ítem.

Caso você queira ver na prática como funciona assista ao vídeo abaixo e para maiores detalhes continue a leitura do post.


Como funciona na prática ?

Assista ao vídeo abaixo.:

 



Novos flavors de Virtual Machine:

Pensando em provisionamento de Servidor Virtual ?  — Que tal se você pudesse escolher a melhor máquina virtual que melhor se encaixa em seu workload e pagar por isso .

A Cloud IBM agora conta com 04 opções no provisionamento de um servidor virtual:

Balanced – Ideal para workloads em Cloud que requerem um equilíbrio de desempenho.

Balanced Local Storage – SSD – Ideal para grandes workloads de banco de dados que requerem alto desempenho de I/O e baixo desempenho de latência com SSD.

Compute – Ideal para workloads que exigem muita CPU.

Memory – Ideal para cargas de trabalho que exigem muita memória.

Acesse o painel de controle da Cloud IBM e no menu clique em DEVICES > DEVICE LIST > ORDER DEVICES. Na próxima tela estará as opções de servidores a serem criados (Físicos, virtuais, por hora, por mês, etc.) – escolha sua opção por Virtual Machine, logo você verá a tela a seguir.:

Screen Shot 2017-09-22 at 23.34.09

 


Security Groups:

Agora na Cloud IBM há um recurso de segurança que será muito utilizado, os Security Groups. Os Security Groups funcionam de forma muito semelhante aos firewalls, como o iptables ou o Firewall do Windows, restringindo o acesso aos nossos servidores em determinadas portas e/ou protocolos.

A configuração dos grupos de segurança é feito dentro do portal da Cloud IBM na seção de SECURITY > NETWORK SECURITY > SECURITY GROUPS.

Screen Shot 2017-09-22 at 23.52.41

 

Screen Shot 2017-09-22 at 23.55.02

É importante saber quais as configurações de cada grupo de segurança e gerenciá-los de forma independente.



Elastic Load Balancer:

Agora na Cloud IBM também o recurso de Elastic Load Balancer está disponível.

O Elastic Load Balancer distribui o tráfego de entrada da aplicação por várias virtual machines, aumentando a tolerância a falhas dos seu ambiente.  O load balancer atua como ponto de contato para os clientes, o que aumenta a disponibilidade da sua aplicação.

É totalmente possível adicionar e remover virtual machines do load balancer conforme mudarem suas necessidades, sem perturbar o fluxo geral de solicitações para seu aplicativo.

O Elastic Load Balancer também escala à medida que o tráfego para sua aplicação muda com o aumento ou diminuição de consumo de workloads.

A configuração dos grupos de segurança é feito dentro do portal da Cloud IBM na seção de NETWORK > LOAD BALANCING > LOCAL.

 

Screen Shot 2017-09-23 at 00.00.47


 

CDN – Akamai

E por último também temos agora na Cloud IBM — CDN com AKAMAI.

Os CDNs são amplamente utilizados na Internet de hoje, melhorando a entrega de uma porcentagem significativa de todo o tráfego da Internet em todo o mundo.

Na prática a CDN é uma rede de entrega de conteúdo é uma plataforma altamente distribuída de servidores que responde diretamente aos pedidos de usuários finais para conteúdo da web.

A configuração dos grupos de segurança é feito dentro do portal da Cloud IBM na seção de NETWORK > CDN.

Screen Shot 2017-09-23 at 00.03.37

 

Screen Shot 2017-09-23 at 00.07.36.png

 

Nos próximos posts estaremos apresentando mais novidades e funcionalidades.

 

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