Nota

Transient Instances na IBM Cloud – Você conhece ?

Olá Leitores,

A sequencia de lançamentos de funcionalidades para IBM Cloud continua, e agora é a vez de testarmos o modelo de instância virtual chamada: Transient Instance.

A oferta de IBM Cloud Virtual Servers Transient é uma boa opção se você tiver cargas de trabalho flexíveis e quiser economizar custos. Você economizará dinheiro executando sua carga de trabalho em um servidor virtual temporário. Instâncias transitórias são provisionadas quando há capacidade não utilizada disponível.

No entanto, fique ligado ! Quando os recursos do DataCenter são necessários para contas completas sob demanda, você também pode perder esses recursos. As instâncias transitórias são desprovisionadas quando esses recursos precisam ser recuperados.

Fazendo um paralelo para quem já está ligado no mundo de Cloud e utiliza por exemplo recursos da AWS (Amazon), podemos dizer que as transient instances é equivalente ao modelo de instancia SPOT.

Os servidores virtuais transientes também trazem na bagagem as novas funcionalidades de IBM Cloud e oferecem a seguinte flexibilidade:

  • Disponibilidade global: A oferta de servidores virtuais transientes está disponível em Datacenters de todo o mundo.

  • Redução de custos: Servidores virtuais transientes são ideais para cargas de trabalho que não são de produção. Por exemplo, você pode usar uma instância transitória para testar e desenvolver aplicativos ou testar a escalabilidade em ambientes que não exigem tempo de atividade constante.

Considerações antes de provisionar servidores virtuais transientes.:

  1. Instâncias transitórias são instâncias públicas que usam SAN-backed storage.
  2. Instâncias transitórias não podem ser atualizadas ou desatualizadas.
  3. Recursos podem ser recuperados a qualquer momento, sem notificação.
  4. Instâncias transitórias não podem usar armazenamento local.
  5. Instâncias transitórias usam somente armazenamento suportado por SAN (balanceado, computação, memória).
  6. Instâncias transitórias não podem usar tipos baseados em GPU.

 

Quer saber como provisionar ? Vamos ao step by step.:

  1. Acesse o Painel de Controle da IBM Cloud com suas credenciais (https://console.bluemix.net/catalog/) e clique sobre a opção de Compute > Virtual Server.

    Screen Shot 2018-07-23 at 08.43.15

  2. No próximo passo na tela de Virtual Server, basicamente escolha o modelo de Public Virtual Server e clique no botão Create.

    Screen Shot 2018-07-23 at 08.45.28

  3. Você chegará na tela da criação do Virtual Server e aqui onde deverá ter atenção para escolher a opção de Transient Server. No exemplo eu escolhi configurações básicas de recursos computacionais e sistema Operacional (CentOS). E por fim, clique no botão em azul “Provision”.

    Screen Shot 2018-07-23 at 08.49.19

  4. Ele ficará na tela ‘Provisioning in progress’ durante alguns segundos e logo após trará a tela de provisionamento da instância, com seus respectivos status.:

    ZScreen Shot 2018-07-23 at 08.54.08

    Screen Shot 2018-07-23 at 08.54.48

  5. Pronto! Após alguns minutos a instância está provisionada e pronta para ser utilizada. Observe o custo da instância U$0.01 (Hum centavo de dolar por hora).

    Screen Shot 2018-07-23 at 09.00.07

    Screen Shot 2018-07-23 at 08.58.41

 

O provisionamento das instância transientes também podem ser realizadas através de APIs REST. O step by step está disponível no link abaixo.:
https://console.bluemix.net/docs/vsi/vsi_provision_api.html#api-rest-transient

Screen Shot 2018-07-23 at 08.34.08

 

Obrigado e abraços,


Thiago Viola
Head of Watson & Cloud Platform Sales Brazil
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
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

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

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

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

Serverless Computing ajudará na redução de custos da TI

Olá Leitores,

No começo deste ano fiz um post sobre como Serverless Computing pode facilitar a automatização de sua TI , onde abordei os benefícios que essa tecnologia traz e que realmente possibilitará empresas terem seus ambientes automatizado sem a necessidade de grandes investimentos de dinheiro e tempo.

Para quem não conhece ainda o tema vale a pena ver o post acima, mas ressalto que a grande sacada em Serverless Computing” é justamente ser utilizado sem a necessidade de comprar, alugar ou provisionar servidores ou máquinas virtuais para o código de back-end executar.

Que tal usar um conjunto de microserviços e serem ativados por eventos específicos (como o registro de usuário, uma autenticação, performance, etc) ou ser configurado para ser executado atrás de uma plataforma de gerenciamento de API.

network-2402637_1280
Mas por que serveless reduzirão os custos de TI ?

De acordo com a análise mais recente da 451 Research para a maioria das novas aplicações, uma solução serverless oferece um menor custo total de propriedade (TCO) do que as máquinas virtuais (VMs) ou containers.

Na prática o TCO de serverless tende a ser menor que VMs, porque não há necessidade dos desenvolvedores provisionar, configurar e gerenciar a infraestrutura.

Por exemplo, quando uma função serverless está ativa por apenas três quartos do mês, ele só precisa de uma economia de 10 minutos na sobrecarga operacional para máquinas virtuais sem servidor para bater em TCO.

A pesquisa indica que, mesmo sem as economias no tempo de desenvolvimento, a capacidade de aumentar a utilização de serverless significa que é mais barato do que usar VMs quando o código é executado menos de 500.000 vezes por mês.
perf

A pesquisa descobre que a IBM é menos dispendiosa para scripts de duração de 0,1 segundos e o Azure é o mais barato para scripts de 10 segundos – assumindo que os requisitos de memória correspondem a alocações de tamanho predeterminadas.

Além disso, a IBM oferece uma vantagem de custo distinta ao permitir que os usuários escolham requisitos de memória exatos, enquanto outros provedores de serviços da nuvem arredondam os números, resultando em usuários que normalmente pagam pela capacidade não utilizada.

As ofertas de Freemium serverless já estão alimentando o crescimento de novos serviços, estimulando a experimentação e ajudando as empresas a adquirir habilidades.

A adoção de serverless – ou FaaS (funções como serviço) – para continuará crescendo nos próximos anos., em 2016, 37 por cento dos decisores de TI pesquisados ​​já estavam usando tecnologia serverless.

Pense e repense sua arquitetura para que não enfrentem a complexidade típica de incompatiblidade ou mal funcionamento de uma aplicação serverless.

Para quem quiser aprofundar os conhecimentos a pesquisa em forma integral está no link a seguir. : https://451research.com/report-long?icid=4406

Obrigado e abraços,


Thiago Viola
Head of 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

Link

Watson Brazil Developer Summit 2017: Temos vagas – Você não pode perder.

Screen Shot 2017-06-07 at 12.21.06 AM

 

Inscrições através do link: http://www.millgpj.com/ibm/wds2017/M00011295.html

 

Obrigado e abraços,


Thiago Viola
Head of 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