API FIRST

No meu último post “O que você precisa saber antes de desenvolver aplicações para a nuvem” apresentei de forma macro os 3 pilares na implantação de aplicativos em um ambiente em nuvem. Neste post o foco é aprofundar no entendimento do conceito de API (Application Programming Interface ou Interface de Programação de Aplicações) e como esse é o início da próxima revolução na tecnologia.

Uma interface de programação de aplicação (“API”) é um conjunto particular de regras (“code”) e especificações que os programas de software pode seguir para se comunicar uns com os outros. Ele serve como uma interface entre os diferentes programas de software e facilita sua interação, semelhante à maneira como a interface de usuário facilita interação entre humanos e computadores. Conceito bacana, mas enfim, o que isso muda em nosso dia a dia?

A resposta é tudo! – API são a nova quebra de paradigma que se desenha no mundo da tecnologia. IoT e Cloud só evoluíram por conta das APIs. Lembra quando se iniciou a revolução da comunicação empresarial, aquele que não possuísse um telefone para comunicar sua empresa com os seus consumidores e fornecedores estava fora do mercado, agora aquele que não conseguir fazer com que seu sistema se comunique com os demais ou quem não conseguir fazer com que sua “coisa” produto se comunique com outros, estará com certeza para trás.

Em um mundo hiperconectado é necessário termos a garantia de uma infraestrutura sólida, uma rede de comunicações evoluídas, uma cultura DevOps avançada, documentação e muito software. Para os sistemas se conversarem e que haja a evolução, você precisa ter acesso a API do seu concorrente. É preciso entender como a construção dos seus parceiros e concorrentes se comunicam e evoluir com eles.

Atualmente há muita discursão sobre desenvolvimento ágil que se preza pela velocidade de entrega do software, no alinhamento com as partes interessadas, no deply continuo etc. Toda essa discussão iniciou em um momento de destruição criativa. Para tal as APIs promove uma nova quebra de cultura nas empresas, onde será necessário um planejamento maior, talvez desenvolver algo mais demorado, mais caro, mais inteligente, mais resiliente….l

Hoje está em alta as APIs e a tecnologia é assim. Você precisa ter determinado recurso para sair na frente de sua concorrência. Amanhã, ela será commoditie. Repense na jornada de olho na indústria 4.0 e na transformação digital. Aprenda o próximo passo da tecnologia por meio de APIs e cultura DevOps.

Grande abraço.

Luiz Eduardo

A criação de uma empresa: Unindo culturas

Estávamos no final de 2010, exatamente no mês de dezembro, quando concluímos após pelo menos um ano de conversas e negociações a aquisição da Diveo.

Nove fundos, liderados pela Goldman Sachs (que detinha a maior participação da empresa), eram os donos da Diveo.Talvez isso por si só já justifique a demora na negociação, além do que se tratava de um grande deal.

Lembro que uma das críticas que o UOL S/A recebia dos analistas e investidores – nesta ocasião estávamos listados na Bovespa – era justamente de não abrirmos a estratégia em detalhes. Com essa aquisição, ficou claro nossa intenção em entrar de forma expressiva no mercado de datacenter e serviços de TI.
Com a aquisição da Diveo, de fato nos tornamos um grande player do setor, e como já havíamos inaugurado outro datacenter “da Glete” (pois localizava-se na Alameda Glete na capital paulista) em março de 2010, somávamos então 26.000m2 de área construída. Assim, administrávamos o maior parque de datacenters do Brasil e da América Latina.
Vários clientes de grande porte estavam sob nossos serviços, dos mais diversos: colocation, hosting, gateway de pagamento, EDI, quality assurance, segurança, integração de sistemas, infraestrutura de datacenter e telecomunicações!

Sim, telecomunicações, a Diveo também possuía uma rede composta, principalmente, por comunicação via Rádio de alta potência. Confesso que tentamos não incluir essa rede no deal por acreditar que telecom não era nosso foco, porém, o vendedor não queria desassociá-la e argumentava que era justamente um diferencial, pois os principais competidores não tinham sua rede e teriam que contratar de terceiros para concluir a solução.

Além disso, a maioria dos clientes de telecom também eram clientes de hosting ou colocation, o que foi confirmado após o due diligence. Hoje esse rede atende por volta de mil clientes.
A Diveo possuía uma carteira muito rica de clientes que mantivemos e ampliamos os serviços até hoje. No mundo financeiro, hospedamos a maior bolsa de valores da América Latina e mais de 140 instituições financeiras, nacionais e internacionais.

Também juntaram-se mais clientes da área de varejo e e-commerce. Podemos afirmar que prestamos serviços atualmente mais de 70% de todo e-commerce brasileiro, o que nos dá muito orgulho e também enorme responsabilidade.
Agora que já tínhamos um portfólio bastante consistente e uma carteira robusta de clientes, chegou a hora de criarmos um brand para essa nova companhia. Estávamos até então, usando dois brands: UOL Host para o serviços de webhosting e UOL Host Corporativo para identificar os serviços customizados para empresas.

A equipe de marketing, sempre muito criativa, apresentou algumas dezenas de nomes. Mas, nos guiamos pela intuição e lógica, onde poderíamos aproveitar toda a presença e história construída pela Diveo desde o ano 2.000 no mercado corporativo e a modernidade e vanguarda associada a marca UOL. Além disso, alguém comentou que ao preservarmos os nomes de empresas adquiridas, contávamos a história de uma forma simples e direta. Assim, decidimos pelo nome UOL Diveo, e em nossos cartões até pouco tempo, mantínhamos uma discreta assinatura da DHC.

Começamos a partir daí uma nova etapa da Companhia, somado ao difícil desafio de juntar a cultura de várias empresas adquiridas até então, e a nova cultura a ser criada a do UOLDIVEO!

Multicloud x Nuvem Híbrida – Entenda as diferenças

No universo de TI, especialmente em Cloud Computing, constantemente nos deparamos com novas tecnologias, tendências e também novos termos e definições. Há muita confusão no mercado e algumas vezes é difícil entender as diferenças entre definições e termos que parecem ser a mesma coisa, mas não são.

Ao comparar Multicloud com nuvem híbrida, as diferenças podem parecer insignificantes, e muitos profissionais, incluindo aqueles que sabem o que estão falando, usam os termos de forma ambígua, gerando ainda mais confusão e incerteza.

Para assegurar que sua equipe está recebendo a solução de nuvem que melhor se adapte às suas necessidades, é importante compreender que enquanto uma solução de nuvem híbrida pode envolver uma estratégia Multicloud (e vice-versa), os dois termos significam coisas muito diferentes.

Parece complicado? Mas não é. Vamos começar com as definições para ajudar a compreender as diferenças.

O que Multicloud significa?

Multicloud é literalmente o que diz a palavra, ou seja, envolve o uso de múltiplos serviços em nuvem, mas não é só isso.

Multicloud é a combinação de tecnologia, proximidade com o negócio do cliente e pessoas.

Com o incremento da adoção de nuvem, as empresas buscam maneiras inovadoras para alavancar a tecnologia e começamos então a perceber que diferentes nuvens são mais adequadas para diferentes necessidades.

Nos últimos anos, empresas com características tipicamente digitais estão modificando os mercados tradicionais, proporcionando novas experiências aos clientes.

Ao mesmo tempo, organizações convivem com o desafio de manter sistemas e processos legados ao mesmo tempo em que são desafiadas a transformação digital buscando inovação e agilidade. Para isso é importante ter em mente que diferentes aplicações têm diferentes requisitos de nuvem e algumas aplicações não funcionam adequadamente em ambiente de nuvem. E aí que a abordagem Multicloud se faz efetiva, permitindo que empresas utilizem nuvens com tecnologias e características diferentes.

Muitas dessas empresas já entenderam que as nuvens não são iguais e utilizam várias soluções de nuvem para maximizar os benefícios que poderiam obter com a tecnologia. Outras adotam uma solução Multicloud para minimizar sua dependência de um fornecedor específico e garantir que não está presa a um contrato único.

Uma estratégia Multicloud pode contar com soluções de Nuvens  Públicas, privadas ou híbridas, dependendo dos requisitos de cada organização. Basicamente, as empresas que utilizam Multicloud podem estar usando nuvem híbrida em muitos casos, mas Multicloud não significa a utilização de nuvem híbrida obrigatoriamente.

Esclarecendo, Nuvem híbrida refere-se ao serviço orquestrado com base em políticas de provisionamento, utilização e gestão através de uma mistura de serviços em nuvem internos e externos. Em uma Nuvem Híbrida, pode-se utilizar uma Private Cloud para atender a requisitos específicos, controle e maior segurança juntamente com uma Nuvem Pública para escala sob demada. Outras soluções híbridas ainda podem utilizar servidores dedicados para workloads ainda mais específicos. O grande brilho do híbrido é a diversidade de opções para escolher.

Nuvem Híbrida ainda se parece com Multicloud para você ?

Tenha em mente que uma solução Multicloud é aquela em que diferentes nuvens, de diferentes fornecedores, são utilizadas para tarefas separadas enquanto nuvem híbrida se parece mais com a criação de uma solução que contém mais de uma opção de nuvem.

No quesito tecnologia, podemos dizer que em nuvem híbrida, as cargas de trabalho utilizam dois tipos de infraestrutura de hospedagem diferentes, enquanto em Multicloud você está usando várias nuvens.

Apesar disto, o que é preciso ter em mente é que Multicloud não se trata apenas de tecnologia. Como citado acima, Multicloud é a combinação de tecnologia, proximidade com o negócio do cliente e pessoas.

O que é melhor?

Não se trata de melhor ou pior e sim diferente. Empresas que utilizam Multicloud também podem utilizar soluções de Nuvem Híbrida, mas entenda que a principal vantagem de uma abordagem Multicloud é permitir que empresas utilizem nuvens com tecnologias e características diferentes de diferentes fornecedores.

Há diversas maneiras de utilizar Multicloud e nuvem híbrida em sua estratégia de TI.

Nós do UOLDIVEO acreditamos numa estratégia Multicloud próxima ao seu negócio, com uma equipe altamente especializada em serviços de gestão de múltiplas núvens, oferecendo vantagens de nosso acordo de parceria em alto volume com os principais players de Cloud Computing, possibilitando liberdade de escolha e ganho de escala .

Você está preparado para os novos desafios da TI Bimodal?

Precisamos repensar no modelo de gestão tradicional porque não atende mais as necessidades e a velocidade que os negócios precisam.

O novo modelo é desafiador, imprevisível, clama por inovação e rapidez na entrega e claro, não podemos esquecer da excelência.

A TI tradicional, que visa estabilidade e segurança precisa coexistir com o modelo digital que exige agilidade e flexibilidade, agregando valor ao negócio seja ele de qual segmento for.

Neste cenário surge TI Bimodal, mas você sabe do que se trata?

Leia Mais

Você está atento a estes problemas de segurança?

Dicas para monitorar e garantir a segurança virtual da sua empresa:

Segurança da informação já deixou há muito tempo de ser modismo para ser necessidade em qualquer tamanho de empresa. A presença da internet flexibiliza, amplia e concebe um universo de oportunidades para qualquer estratégia de negócio, mas também interliga uma variável relativamente nova chamada de atacante digital.

Na década de 90, era muito comum encontrarmos o atante digital dentro das organizações. Vivíamos momentos com a presença de viroses limitadas a contaminação de disquetes como o vírus ping-pong. Bons momentos, onde era possível fazer uma pausa no texto digitado e observar o símbolo de uma pequena bola sendo arremessada contra os cantos da tela.

Vivemos momentos onde os ataques são altamente sofisticados com estratégias customizadas para cada empresa alvo, orientada por campanhas de e-mails, ataques usando criptografia SSL, furtos de informações pela camada Web ou indisponibilizar a infraestrutura de maneira parcial ou total. Vamos neste texto analisar alguns desafios ligados a Segurança da Informação e identificar como empresas como o UOLDIVEO podem ajudá-lo a resolver cada um destes desafios para que você tenha diferenciais significativos para a sua empresa.

Fraude nos e-mails estão mais agressivas e frequentes

O primeiro elemento que gostaria de abordar é muito comum em qualquer organização. São os e-mails recebidos e identificados como Spams e Phishing. Este último pode ser encontrado em uma versão mais devastadora chamada de Spear Phishing.

Precisamos ter em mente que enquanto o Spam foca-se em um e-mail visando promover a venda de um produto, seja ele legal ou não, o phishing tem o objetivo direcionar a vítima para um site que vai furtar informações pessoais, cartões de crédito, informações bancárias e qualquer coisa que o atacante considere importante. O Spear Phishing estuda todas as características do destinatário do e-mail, indo desde o departamento trabalhado, nomes dos seus superiores e gostos pessoais. Tudo é customizado em um e-mail que ilude o destinatário a instalar um programa em seu computador ou a fazer algo que seja benéfico para o atacante.

Grande parte dos e-mails acompanham campanhas publicitárias e direcionam para sites clonados causando danos financeiros a marca de uma empresa, forçando o envolvimento do departamento jurídico com ações de clientes que foram enganados pelos atacantes ou ainda forçando o investimento em estratégias para refazer a credibilidade de uma marca no mercado. O site clonado pode estar presente nas redes sociais, em blogs ou em ambientes de cloud pública dentro ou fora do Brasil. O processo de desativação deste site pode ser muito complexo e custoso. É necessário o monitoramento de e-mails, redes sociais ou mídias sociais 24 horas por dia por especialistas que tenham experiência neste modelo de operação. Como definir um plano que realmente funcione contra estes ataques?

Ataques criptografados se destacam nas previsões do Gartner

Segundo o Gartner, o tráfego criptografado cresce 20% ao ano e 80% das empresas não inspecionam seus tráfegos Web. Existem centenas de justificativas para esta ausência de inspeção, mas podemos dizer que a principal é a sobrecarga em processamento que gera nos hardwares de firewalls ou equipamentos de IPS (Intrusion Prevention Systems), por exemplo.  Infelizmente percebe-se que o uso de ataques envolvendo criptografia se elevam a cada ano, seja para a comunicação de malware ou para ataques a servidores Web. O resultado final é sempre a perda financeira, seja por dano diretos ou indiretos à imagem, perda de vendas devido a sites invadidos ou furto de informações pertencentes a clientes. Ter a informação furtada é sem dúvida um grande problema, mas tê-la divulgada é um problema maior ainda. É importante ter um plano de ação que inclua o corpo diretor e a equipe de operação envolvida e treinada.

Note que um erro muito comum é ter um plano de ação de segurança de várias páginas e não ter a equipe treinada para responder a um evento guiado por um ataque digital. Mais importante do que comunicar é como comunicar um incidente de segurança. Ter uma assessoria de imprensa que não está preparada ou que não tem o apoio para responder tecnicamente aos questionamentos é pior do que não comunicar.

Uma estratégia usada com sucesso por empresas internacionais é minimizar o aparecimento na mídia e limitar a uma única reunião para apresentar esclarecimentos aos investidores e a imprensa. Outro ponto importante aderente a qualquer empresa é testar periodicamente o plano de resposta a incidentes de segurança.

Com os ataques se tornando mais complexos e mais frequentes, torna-se necessário criar uma cultura de segurança mais transparente, preparando e concebendo as aplicações de maneira diferenciada, juntamente com os elementos que a protegem. Ver-se que elementos de uso simples e de baixo custo não usados por muitas empresas. Um exemplo disto é o certificado SSL. Apesar dos benefícios da criptografia em sites Web serem claros e muito vantajosos, possibilitando não só a elevação da confiança dos usuários, mas também elevando a prioridade nas listas de pesquisa do Google, vê-se que poucas empresas fazem usos desta vantagem, deixando um farto oceano de oportunidades para os atacantes digitais. Os certificados digitais podem e devem ser usados por qualquer tipo de aplicação Web.

Bom lembrarmos que segundo o HIPAA (Health Insurance Portability and Accountability Act), PCI Security Standards Council e PII Laws (Personally Identifiable Information), deve-se manter criptografadas todas as informações referentes a dados pessoais, elementos financeiros e informações envolvendo empresas de saúde. Não obedecer a estas indicações pode acarretar em implicações graves.

Novamente devemos nos perguntar o que fazer? Que estratégia devemos seguir para elevar a proteção?

Cloud são seguras, mas você está usando-as corretamente?

Muitas vezes imagina-se que um ambiente de Cloud é inseguro e que projetos usando plataformas de virtualização dentro das empresas formam ambientes de segurança superiores. Primeiramente é importante o entendimento que existem tipos distintos de Cloud, e estes tipos são aderentes ao grau de maturidade da aplicação analisada. Saber se uma Cloud pública em OpenStack, AWS, Microsoft Azure, Google ou ainda uma Cloud Privada é mais adequada a maturidade da sua aplicação é um elemento de sobrevivência indispensável para qualquer empresa.

Observe que não é uma questão de saber qual é a Cloud mais barata para o portal Web da campanha do mês de novembro, mas saber onde a aplicação vai ter uma melhor performance ou onde vai apresentar melhores requisitos de segurança para o projeto proposto. Observe as Clouds Públicas, o uso de controles em seu ambiente são elementos mais rígidos do que muitos projetos dentro das corporações. Este fator é certamente influenciado pelo compartilhamento físico dos servidores. Note que o nível de segurança é muito maior do que os usados tradicionalmente e que a invasão de um cliente por outro é praticamente impossível.

Outra visão importante aborda a relação Compliance e Ambiente em Cloud. Devemos entender que mesmo contratando um provedor em nuvem que possui uma certificação em segurança, isto não faz com que a aplicação de uma empresa hospedada e exposta para a internet esteja segura ou seja resistente a qualquer tipo de ataque digital. A proteção contra este modelo de atacante é um projeto adicional que faz uso de diferentes camadas de defesa, indo desde do desenvolvimento do código-fonte, passando pelo projeto de camadas de defesa e terminando com a escalabilidade e flexibilidade do ambiente usado.

Os ataques direcionados a aplicações em nuvem não são diferentes dos ataques direcionados para os ambientes fora dela. A abordagem buscando por erros humanos continua a mesma, a busca por falhas na aplicação ou no modelo de acesso ao ambiente de gestão continua a mesma. O questionamento também continua o mesmo: o que pode ser feito para elevar a proteção do negócio?

Quais lições podem ser aprendidas?

Os ataques digitais não vão reduzir de intensidade. A realidade mostra que teremos volumetrias bem superiores e muito mais agressivas a tudo que vemos hoje. Olhando somente para os dispositivos móveis, encontraremos previsões indicando que 70% da população mundial estará fazendo uso de algum tipo de dispositivo móvel conectado à internet em 2020 e isto representa 5,5 bilhões de pessoas. Só para o Brasil estima-se que terá mais de 182,1 milhões de usuários móveis e nem aprofundamos as análises envolvendo IoT (Internet das Coisas).

O segredo é como estaremos preparados para estes ataques. Ter um comitê de segurança multidisciplinar é importante, mesmo para as pequenas empresas. Treinar a equipe técnica, juntamente com este comitê vai ser inevitável para responder de maneira clara e objetiva a um atacante digital.

Outro ponto importante é que não podemos construir toda defesa eletrônica em uma tecnologia apenas ou em um processo de gestão que não opera 24×7. Ter o apoio de uma equipe experiente é questão de sobrevivência. Um exemplo claro deste tema é representado pelos ataques DDoS (Distributed Denial of Service), que hoje atinge valores superiores a 500Gbps de pico. Tenha em mente que a defesa contra um ataque DDoS não se faz só, sendo necessária a presença intensa do provedor de acesso bloqueando e identificando o atacante internacional e nacional.

Para concluir, tenha em mente que a defesa digital é uma equação que precisa ser equalizada entre três variáveis importantes representadas por processos, pessoas e tecnologia, independente se lidamos com um ambiente em Cloud ou não.

 

Denis Souza

 

Boas Práticas com Docker

No post sobre DevOps foram citadas inúmeras ferramentas que facilitam e permitem cultivar uma cultura DevOps. Minha escolha para iniciar esta jornada foi o Docker. Em vez de convencer que o Docker é bom ou explicar como instalar e subir o primeiro container, vou focar em questões da nossa experiência com o Docker. Questões simples mas importantes acabam passando desapercebidas e geram problemas em produção.

Se você está iniciando em Docker, recomendo começar pela documentação oficial, que melhorou bastante nos últimos tempos. Se você ainda está em dúvida para onde as coisas caminham, dê uma olhada neste gráfico. Containers já são uma realidade.

Entendendo Problemas de Consistência

Com todo o hype em torno de containers, é natural que existam sentimentos do tipo “precisamos usar Docker porque todo mundo está usando” ou “vamos usar Docker porque é legal”. Docker, como qualquer ferramenta, tem seus principais valores. E no caso, posso resumir o valor do Docker em uma palavra: consistência. É importante entender o que isso significa para implantar a ferramenta de forma adequada em seu ciclo produtivo.

Pré-Puppet (ou Chef, Ansible…)

Vamos supor que você precisa subir uma aplicação nova. Máquina provisionada, SO instalado, você loga na máquina e:

  • Atualiza o sistema operacional.
  • Instala os pacotes da sua aplicação (apt, yum, zip (!!) etc).
  • Edita os arquivos de configuração.
  • Coloca o serviço no boot.
  • Reboot.

Este fluxo representa a maioria dos casos, e é um bom exemplo.

Agora solicitaram subir mais máquinas idênticas… será tedioso.

Mecanizando o Processo

De posse de ferramentas de gestão de configuração, você escreve o código que mecaniza todo o processo. Maravilha! Máquinas novas provisionadas para produção em segundos!

Porém, saem novas versões da aplicação o tempo todo, problemas aparecem em produção e a únia solução é “formatar” a máquina…

Gerenciando Alterações

Vamos entender onde o problema ocorre. Você recebe a máquina M1, apenas com o SO (BareMetal):

M1 > BareMetal

Então, aplica a sua automação, v1, em cima:

M1 > BareMetal > v1

E leva a máquina para produção, na versão v1. Mas claro, vem a v2 da automação, e você aplica:

M1 > BareMetal > v1 > v2

Agora você adiciona uma nova máquina M2, para suportar a v3:

M1 > BareMetal > v1 > v2 > v3

M2 > BareMetal > v3

E de repente, a M1 funciona, mas a M2 não! Claramente, M1 foi submetida a um fluxo (v1 > v2 > v3) totalmente diferente da M2 (v3), e fatalmente o estado real e final da M2 não é o mesmo da M1, mesmo que ambas foram submetidas à mesma receita v3. Uma causa comum por exemplo, é que a v2 instala uma dependência, que a v3 não pede.

Para resolver o problema, só começando do zero.

Entregando Com Consistência

Achado o bug, criamos uma v4, e entregamos em uma máquina M3:

M3 > v4

Isso funciona porque o fluxo é mais consistente. Pra fechar a questão, matamos as máquinas M1 e M2, e provisionamos as máquinas M4 e M5, no mesmo fluxo da M3:

M4 > v4

M5 > v4

Maravilha! Um mês depois, você provisiona a M6, para suportar a carga crescente:

M6 > v4

E novamente, problemas! Como pode? M4 e M5 foram submetidas ao mesmo fluxo do M6! Fatalmente é algum fator externo, como por exemplo updates do SO que estão na receita. Alguma versão mais nova de dependência que está presente somente na M6 está gerando problemas.

“Que maravilha!”, você pensa. Agora vamos à estaca zero para versionar TODOS os pacotes do sistema operacional, repositórios, etc…. não vai ter fim.

Containers Para a Salvação!

Bem, é exatamente todo esse stress que containers evitam. Fazendo uma analogia, containers são como um snapshot de uma VM em um estado confiável. Este snapshot pode ser utilizado para instanciar quantas VMs forem preciso, de forma confiável. Na terminologia do Docker, os snapshots se chamam imagens e as VMs containers:

Dockerfile > Image > Containers

Uma vez com a imagem pronta, você pode instanciar quantos containers forem precisos, onde for preciso, rapidamente e com confiança!

Além do Ambiente de Produção

 

Um container é algo tão leve e rápido, que consegue ser utilizado na máquina do desenvolvedor e também no servidor em produção, com fidelidade altíssima entre os ambientes. Além disso, o Docker Registry resolve o problema de se compartilhar imagens. Imaginem que eu como desenvolvedor preciso fazer o QA do meu sistema, que tem dependência de um sistema terceiro. Eu posso simplesmente utilizar a imagem do container de produção deste sistema! Nada mais de “o QA está fora”, ou “o orçamento para máquinas de QA está alto”.

 

Docker traz assertividade, confiabilidade e redução de custos, levando para o início do ciclo de desenvolvimento a mesma tecnologia e performance que existem no ambiente de produção.

Pontos de Atenção Com Docker

Criar um Dockerfile e subir o primeiro container é quase trivial. Entretanto,alguns pontos importantes, triviais de se implementar, muitas vezes são esquecidos. Em especial, no Docker Hub, há imagens prontas para praticamente qualquer coisa. Entretanto, a maturidade e qualidade delas varia grotescamente. Olhe as imagens e valide se os Dockerfiles seguem bons princípios. Somente então as utilize.

 

Alguns dos pontos levantados aqui são parte do http://12factor.net/, vale a leitura complementar.

Não Executar Como root

Um dos anti-patterns mais comuns com o Docker é executar os processos do container como root. Há uma certa argumentação válida de que a kernel já garante isolamento entre containers, mesmo eles sendo executados como root. Vou dar crédito para isso. Porém, há uma série de abusos que podem ser feitos dentro do container, como sobrescrever binários, arquivos de configuração etc… Pense assim: para quê rodar como root? O único caso que consigo pensar é executar um container privilegiado, que por si só é algo tão fora do padrão, que pode ser até considerado um anti-pattern.

Logs Fora do Container

Apesar de não haver nada proibindo você de gravar logs dentro do container, isso fatalmente irá te causar problemas. Na próxima atualização, quando for entregue um novo container, TODO o conteúdo dos logs antigos será perdido. As opções são:

  • Mapear o diretório de logs para um volume que será persistente, e anexado a novas versões do container.
  • Enviar os logs para outra ferramenta externa (ex: Elastic Search, Splunk).
  • Enviar logs para o STDOUT / STDERR.

Este último é a boa prática com Docker, utilize se possível. É trivial configurar o Docker Engine para que os logs de TODOS os containers sejam redirecionados para algum local externo. Cuidado com esta configuração e garanta que os logs estão sendo devidamente rotacionados, e os antigos apagados.

Volumes de Dados

Pelo mesmo motivo dos logs, dados importantes persistidos pela aplicação devem sair do container (ex: /var/lib/mysql). Caso contrário serão perdidos quando o container for destruído.

 

Este ponto é melhor compreendido se olharmos para uma arquitetura completa:

Web Tier > App Tier > BD

Apenas a camada de BD persiste dados, logo deve ser a única elegível para utilizar volume de dados (sujeito a backup). Pense nas demais camadas como “imutáveis”: os containers nela devem poder ser destruídos sem qualquer tipo de prejuízo, a qualquer momento. Isso facilita bastante a administração e acaba sendo um requisito importante se você está pensando em qualquer tipo de auto-scaling.

Configurações Através de Variáveis de Ambiente

Outro anti-pattern comum é colocar um grande volume de configurações no container, em arquivos. Não há nada de errado nisso, mas você tem dois pontos a considerar:

  • O que muda do container de produção para o de QA?
  • A mesma imagem pode ser utilizada para criar containers em ambientes distintos (eg: Apache como proxy para 2 sistemas)?

O que for identificado como necessário para que a mesma imagem atenda mais de um cenário deve ser informado via variáveis de ambiente na criação do container (ver –env)! O seu ENTRYPOINT deve ser responsável por interpretar estas variáveis e fazer os ajustes necessários. Uma opção comum é colocar no ENTRYPOINT um shell script que lê as variáveis de ambiente (tipicamente usuário e senha), gera o arquivo de configuração adequado e depois executa o processo do container.

 

Permitir “reciclar” a mesma imagem em mais de um cenário tem sempre que estar em mente. Minimamente produção e QA acabarão existindo. Tome cuidado para não abusar deste modelo. Uma coisa é colocar os certificados HTTPS em variável (um pattern que já vi algumas vezes) e outra é colocar TODO o httpd.conf do Apache em uma variável de ambiente. Ambos funcionam, mas claramente há um pouco de bom senso nisso. A regra do dia a dia é: se é algo que muda entre cada ambiente, vai para variável de ambiente, caso contrário vai para o container diretamente.

Operating System updates

Já pensou o como corrigir o próximo bug nojento do OpenSSL em todos os seus containers em produção? A resposta é simples: não se corrige. Pense em containers como algo imutável. Se você precisa atualizar algo, inclua no seu Dockerfile um comando pra atualizar o SO e o que mais for necessário e entregue a nova versão do container. Tecnicamente é possível entrar em um container e atualizar o SO, mas faz pouco sentido pois viola o princípio da imutabilidade.

Nomes das Tags

Uma consequência de atualizar o SO diretamente do Dockerfile (ex: apt-get upgrade) é que um mesmo Dockerfile, utilizado para criar imagens em dois momentos distintos, gera duas imagens distintas. Isso ocorre devido a dependências externas na criação do container, que mudam com o tempo (ex: versão do OpenSSL). Uma opção seria controlar também a versão dos pacotes no repositório do SO porém uma solução mais simples, seria adotar um padrão para a tag de cada imagem:

[git tag]_[data]

Ex:

V1.0.10_2016-07-07_18-36

Apesar de um pouco extenso, o node permitirá melhor gestão. Ex: você só precisa atualizar o SO do container, mas a versão da aplicação é a mesma. Sem problemas. Fica claro pelo nome que é a mesma versão da aplicação, mas dependências externas são diferentes.

 

Utilizar a tag “latest”, além da tag específica, também é uma prática comum para indicar qual a versão de produção.

Pacotes de SO / Prateleira

Se você vai executar uma aplicação que não foi feita para ser executada em container, tenha os seguintes pontos em mente:

  • Os scripts de start / stop do SO não foram feitos para serem executados em container.
    • Eles irão fazer fork() do daemon, e você verá uma morte prematura do container.
    • Você deve invocar o binário do daemon diretamente no ENTRYPOINT do container.
  • Rotação e purga de logs geralmente funcionam via cron, porém não há cron no container.
    • Tente redirecionar os logs do daemon para stdout / stderr.
    • Se não por possível, a alternativa é usar um entrypoint que suba o cron no container, e depois execute o daemon.

Um Processo por Container

Esse é um mantra comum na comunidade Docker, mas é bastante mal compreendido. Pense em um Apache MPM, que abre diversos processos para atender requisições. Ele viola o princípio do Docker? Bem… não. Uma melhor formulação do mantra seria “uma aplicação por container”. Exemplo: se você tem um Apache e um Jetty para subir, coloque cada um em seu container. Este artigo explora o cenário de mais de um processo por container.

Tecnicamente, você pode rodar o init em um container, e “subir o SO do zero”. Nada te impede disso. Porém isso vai contra a mentalidade de containers serem leves, auto-contidos e descartáveis. Um SO completo sobe uma variedade de serviços que sua aplicação no container não precisa… inclusive o próprio init.

Conclusão

Não pense em Docker / containers como uma opção, mas sim como algo inevitável. Quanto antes você estiver nesta onda, melhor. Mas compreenda bem a mentalidade por trás e use a ferramenta certa, da maneira certa, para o problema certo. Não somente “siga o hype” cegamente.

Inovação: Reinventando a organização

Peter Thiel começa seu livro Zero to One com a seguinte citação: “Cada momento nos negócios acontece uma só vez”.
Agora, pense nisso por alguns instantes.

Aqui no Blog, já conversamos com você sobre transformação digital e como isso deve mudar o comportamento das organizações. Tudo aquilo que era considerado o estado da arte tende a ficar obsoleto rapidamente.
Não estamos falando simplesmente de uma transformação de TI, mas sim de uma transformação cultural. A maneira como a organização passa a gerar valor para seus clientes está intimamente ligada em como ela compreende seu ecossistema e consegue antecipar tendências.

Tecnologia é uma arte. A arte de prover soluções para problemas de qualquer natureza.
Gosto de pensar desta forma e trazer para presente, onde as organizações já pensam TI em suas mais váriadas formas: sustentação, algumas vezes o próprio negócio ou o impulso que vai reinventar a própria Organização. Quem sabe até o Mercado!

Naturalmente vamos falar mais e mais de convergência e automação de todas as camadas, de como as empresas vão ver seus dados como um recurso a ser explorado para obter insights, inovação, gerar novas oportunidades e também o lucro. Tudo isso sustentado por um modelo de inteligência e detecção de ameaças ou mesmo tendências, que só vão acelerando na medida que novos padrões são desenvolvidos.

E neste espaço já apresentamos algumas ferramentas e métodos que entre outras ganhos vão promover uma adequada gestão do conhecimento, afinal, somente com conhecimento que se consegue identificar se os processos e tecnologias estão alinhados com os objetivos da organização, ou se estão terrivelmente longe (assunto para outro post).
Então ser digital também é ter um olhar tecnológico e crítico para as estratégias de negócio.

E como estimular este potencial? Pessoas, cultura e ambiente.

Sua estratégia de transformação passa pelas pessoas. São elas que vão apoiar sua decisão de tecnologia, promovendo o engajamento necessário para este processo de transformação. Em outras palavras, a gestão destas mudança e comunicação adequada vai te ajudar a reduzir riscos nos processos que afetam os negócios e tecnologia.
Comunique seus objetivos de forma clara, estimule o time a pensar diferente.
Entenda que toda organização é única. É um sistema complexo, mas que vai se adaptar ao que você promover internamente. Mova as peças chaves. Quebre o paradigma de que apenas manter os sistemas funcionando é o único papel da TI.

Agregue, promova. Coloque os talentos para interagir.

Desenvolva a cultura de colaboração. Estimule a cocriação e a exploração de métodos e outros mercados.
Relembrando como iniciamos, “Cada momento nos negócios acontece uma só vez”. Tenha em mente que agir no momento certo, é o que define o futuro da maioria das organizações. E isso será crucial para qualquer time de TI.

Causa Raiz – da Inexistência à solução

Quando falamos em tecnologia todos sabem que por mais preparado, moderno e controlado que seja o ambiente, em algum momento este pode sofrer uma interrupção, seja ela de pequeno impacto a indisponibilidade de grande proporção, e que após a recuperação do ambiente teremos o famoso e temido “RCA” (Root Cause Analysis).

Apesar deste fato ser conhecido e as empresas cada vez darem maior importância a análise de causa raiz, muitos casos a metodologia não é seguida e/ou implementada com sucesso.

Afinal de constas porque o RCA não funciona?

Este post propõe-se a expor experiências de como melhorar a análise de causa RAIZ para ser solução, e não um novo problema. Vamos debater o tema e passar experiências como:

  • Metodologia de investigação (Processo)
  • Como aplicar a metodologia (Técnico)

Todos já ouviram falar de “Sherlock Holmes”,  este trecho abaixo tive a oportunidade de conhecer em pesquisas de análise de Causa Raiz e vou usar como “CASE”, vou comentar cada item e falarmos das regras básicas para o sucesso. Nesta ficção temos o maior exemplo de método cientifico de análise e solução de problemas, veja o que ela nos ensina:

Sherlock Holmes tinha paixão pelo conhecimento exato e preciso, ou seja, os dados devem ser coletados para provar a hipótese antes de determinar a causa raiz em uma análise.

Regra número 1: Nada deve ser concluído sem “FATO”. Devemos sempre provar a análise.

Sherlock Holmes acreditava que investigando vários crimes (1000) teria informação suficiente para solucionar o 1001º crime. Examine dados de eventos similares pois estes ajudarão a aprimorar o processo de análise.

Regra número 2: A experiência de vários casos ajuda o próximo. Tenha um sistema de base de conhecimento, seja ele qual for.

Sherlock Holmes acreditava que o mundo está repleto de coisas óbvias que ninguém, por qualquer motivo, observa.– Isto implica em não aceitar a primeira explicação, sem atentar para todos os detalhes.

Regra número 3: Aqui está um item que sempre devemos levar para o time, podemos resolver muitos casos com o obvio. Mas nunca devemos esquecer que a riqueza da informação leva a certeza.

Algumas frases do nosso professor “Sherlock Holmes”:

 “É um erro capital teorizar antes de se ter os dados. Insensivelmente, começa-se a distorcer os fatos para adaptá-los às teorias, em vez de fazer com que as teorias se adaptem aos fatos.”

  “Dados! Dados! Preciso de dados! Não posso fazer tijolos sem barro!”

  “Jamais arrisco um palpite. Isso é um hábito chocante… fatal para a capacidade de raciocinar logicamente.”

Regra número 4: Nunca arriscar palpite ou teorizar

Após as regras estarem definidas precisamos definir as fases da análise, cada empresa ou profissional pode ajustar conforme a necessidade, mas vou colocar aqui as que podemos chamar de “obrigatórias”, que atendem inclusive processos de certificação.

  1. Definir o problema
  2. Identificar as possíveis falhas
  3. Verificar a real causa
  4. Propor a solução
  5. Implantação e acompanhamento dos resultados

Bom pessoal, para não ficar um blog maçante vou parar por aqui e nos vemos a semana que vem onde vamos falar de, como definir o problema, identificação das falhas e real causa. Não perca.

“Porque escolher OpenStack” A primeira pergunta que você deveria saber responder

“Porque escolher OpenStack?”: A primeira pergunta que você deveria saber responder

“OpenStack. Ok… é uma tecnologia de nuvem. E?”

Foi essa minha reação quando ouvi falar na mais famosa plataforma Open Source de orquestração de nuvem pela primeira vez.

Naquele momento, o principal ponto para mim era entender o valor do OpenStack para empresas, altos executivos, gestores e quem lida no dia a dia com infraestrutura e desenvolvimento.

Não demorou para entender o valor por trás da tecnologia, mas uma dúvida ainda continuava:

Será que todo profissional de TI sabe o real valor do OpenStack? E se todo mundo ainda tiver um “E?” na cabeça?

Para entender o valor, primeiro é preciso pensar na transformação que estamos passando.

O mundo cria 2,5 quintilhões de bytes de dados diários.
90% dos dados no mundo de hoje foram criados nos últimos dois anos!

Este volume de informações vai continuar a aumentar e os motivos são muito claros: mobile, social, IoT.
Pessoas conectadas. Objetos conectados. O mundo girando em torno de dados.

E olhando para o mundo das empresas, as oportunidades para este novo momento que estamos vivendo são inúmeras. Quem tem mais agilidade para se adaptar a este mundo de dados para criar novos negócios e modificar a maneira que as coisas são feitas tem uma vantagem competitiva fundamental.

Nota mental: Agilidade

A área de TI das empresas precisa ter capacidade de escala para enfrentar os desafios de volumes crescentes de dados, mas ao mesmo tempo precisam garantir que as informações estão seguras e facilmente acessíveis.

Para manterem-se competitivas, as empresas devem usar tecnologias que entreguem agilidade e capacidade de uso rápido e OpenStack oferece isto.

Não à toa, Yahoo, Cisco WebEx, Mercadolibre, Red Hat, PayPal e American Express usam OpenStack. E mais: existe uma comunidade global de mais de 40.000 usuários e mais de 500 empresas contribuindo ativamente com ele.

E onde está o valor do OpenStack frente às outras nuvens?

Comecemos pelas nuvens privadas.

Existem ótimas plataformas de cloud computing que podem ser usadas para construção de nuvem privada, mas junto com a maioria delas vem a condição de estar sujeito às regras de financeiras e de uso do fornecedor; e isto pode justamente levar a empresa a não atingir seus objetivos de agilidade.

O OpenStack cobre esta lacuna, como o Linux fez no passado. O valor está no serviço e não no produto. A empresa passa a ter liberdade para decidir.

Nota mental: Liberdade

É estratégico construir a nuvem por conta própria? Ok.
É estratégico usar o know-how de um fornecedor especializado para acelerar o projeto e reduzir riscos? Ok.
Deseja alterar a forma como o OpenStack funciona para atender uma característica do negócio? Ok também.

A decisão é da empresa e pode ser mudada a qualquer momento.

Mas e a nuvem pública em OpenStack?

O mundo muda o tempo todo e com os negócios não é diferente.

Além da agilidade, flexibilidade e elasticidade proporcionada pelas nuvens públicas, a liberdade também faz parte do cenário. Liberdade de levar as cargas de trabalho de um provedor de serviços para outro a qualquer momento. Liberdade para levar cargas de trabalho para a nuvem privada em tecnologia OpenStack, sem grandes esforços e investimentos. Liberdade para integrar a nuvem pública e privada. Liberdade.

Além disto, a gigantesca comunidade OpenStack contribui todos os dias com melhorias, novidades e solução de problemas à uma velocidade incomparável com qualquer outra empresa do mundo. O resultado disto é rapidez para atingir a maturidade da solução.

Nota mental: Maturidade.

É “cool” usar OpenStack pela novidade e pela liberdade, mas acima de tudo, a possibilidade de usar e gerir infraestrutura se aproveitando da maturidade já obtida, olhando para o futuro e para onde a plataforma está caminhando faz do OpenStack uma plataforma a ser considerada na estratégia de adoção de nuvem pelas empresas.

Por fim, é importante ter em mente aquilo que grandes institutos de pesquisa de tecnologia tem repetido constantemente: não existe uma nuvem ideal para todas as aplicações e nem toda aplicação funciona adequadamente em qualquer nuvem.

Uma estratégia multicloud, onde a decisão das nuvens a serem usadas passa pela análise das características das aplicações e seus requisitos de negocio é fundamental para o sucesso da adoção massiva de cloud computing.

O UOLDIVEO tem ajudado empresas na escolha, construção, gestão e melhoria de nuvens públicas, privadas e híbridas e por isso recomendo conhecer nossos serviços e falar com um de nossos especialistas em nuvem.

Site: uoldiveo.com.br
Contato: 11 3092 6161

DevOps – Colaboração é a chave da questão

Em ambientes com cada vez mais necessidade de mudanças e atualizações constantes, os times de tecnologia enfrentam desafios entre a agilidade das entregas para atender demandas de negócios e a estabilidade dos ambientes operacionais.

A falta de cooperação entre os grupos de tecnologia resultam em conflitos e ineficiências e precisamos criar uma ponte entre as necessidades de desenvolvimento ágil e os requisitos técnicos dos ambientes de produção.

Um ponto importante da mudança de filosofia é acabar com os silos e a cultura do “finger point” e investir de forma séria em automação.

Ao buscar oportunidades para automação do ciclo de desenvolvimento e operações podemos olhar para itens como por exemplo:

  • Builds
  • Tenting
  • Monitoring
  • Deployments
  • System Configuration

A necessidade por simplificar processos entre os grupos e garantir a eficiências das entregas é pauta constante na agenda dos profissionais de tecnologia.

Normalmente todo fluxo de evolução de produtos e soluções dependem de tecnologia e sistemas complexos e com diversas partes dependentes, essa realidade introduz desafios de comunicação entre os times e deixa claro que para atender ao novo mundo precisamos de mudanças e novos modelos mentais.

Times de tecnologia devem ser cada vez mais responsáveis pelo sucesso dos seus grupos e ter o contexto claro do seu papel no sucesso dos negócios.

Todos os envolvidos existem por um motivo principal, viabilizar o negócio.

Velocidade no processo de entregas de novas funcionalidades e ambientes é uma necessidade e requisito básico para atingir os resultados, porém esse ponto não é mais importante que a segurança e a disponibilidade dos ambientes.

As mudanças não devem representar “incêndios” e dias intermináveis de crises e instabilidades.

Diminuir a distância entre os times que desenvolvem software e as equipes operacionais requer uma mudança de cultura. Uma abordagem muito mais colaborativa , com liberdade , times capacitados e grande responsabilidade.

Nessa cultura, a comunicação, transparência e as relações humanas são indispensáveis.

Para facilitar a vida dos times de desenvolvimento e operações existem diversas categorias de soluções que devem ser consideradas, entre elas podemos citar:

  • Source Control
  • Continuous Integration
  • Deployment
  • Cloud / Iaas / Paas
  • Monitoring & Data visualization
  • Database lifecycle management
  • Repository Management
  • Provisioning / Configuration Management
  • Release Management
  • Logging
  • Build
  • Testing
  • Containerization
  • Collaboration
  • Security

Diversas ferramentas também apoiam nessa jornada, entre elas:

Source Control

  • Git
  • GitHub

Continuous Integration

  • Jenkins
  • Continuum
  • Hudson

Deployment

  • Jenkins
  • Chef
  • Capistrano

Cloud / Iaas / Paas

Monitoring & Data visualization

  • Kibana
  • Graphite
  • Splunk
  • Nagios
  • Zabbix
  • Grafana
  • Elasticsearch

Database lifecycle management

  • DBmaestro
  • Datical
  • Liquibase

Repository Management

  • Artifactory
  • Nexus
  • Archiva
  • NuGet
  • npm
  • Docker Hub

Provisioning / Configuration Management

  • Chef
  • Ansible
  • Puppet
  • Consul

Release Management

  • Continuum

Logging

  • Splunk
  • Logstash
  • Graylog
  • Loggly

Build

  • Continuum
  • Maven
  • ANT
  • Hudson
  • Broccoli
  • Make

Testing

  • Cucumber
  • Selenium
  • Gatling
  • JUnit
  • TestNG
  • JMeter

Containerization

  • Docker
  • Kubernetes
  • Mesos
  • Linux Containers
  • Swarm
  • Marathon
  • OpenVZ

Collaboration

  • Jira
  • Trello
  • Slack
  • HipChat

Security

  • Snort
  • Cyberark
  • Tripwire
  • Fortify
  • Vault
  • SecureAssist

 

Tabela de DevOps

 

Um ponto fundamental dessa revolução é entender que não é apenas um conjunto de ferramentas é uma mudança de cultura , onde novas formas de trabalho são buscadas, testadas , discartadas ou adotadas.