A Weaveworks, criadora da solução de rede virtual Weave Docker, lançou uma versão pré-alpha do Weave Scope, uma ferramenta de monitoramento de containers focada em desenvolvimento de código aberto. O Scope gera automaticamente uma mapa de containers, permitindo que os desenvolvedores visualizem, monitorem e controlem as aplicações utilizando informações expostas para conduzir o desenvolvimento e decisões operacionais. A Weaveworks está solicitando feedback e colaboração da comunidade, a fim de impulsionar o desenvolvimento do Scope.
O post no blog da Weaveworks anunciando o lançamento do Scope, propõe que as soluções de aplicações e monitoramento de infraestrutura, estão destinadas principalmente aos operadores e não abordam os requisitos dos desenvolvedores. Com a ascensão da DevOps e a filosofia "você escreve", "você roda", agora existe uma necessidade de monitoramento focada no desenvolvedor de ferramentas. O Scope busca fornecer monitoramento de aplicações de forma que possa ser compreendidos por ambos desenvolvedores e operadores, com foco principal em implementações baseadas no Docker.
O Weave Scope, baseia-se no produto já existente Weave da Weaveworks, que oferece uma rede definida por software de duas camadas (layer-2), mais conhecida como SDN (software defined network), que liga containers Docker que estão potencialmente implantados em vários hosts e fornece a descoberta automatizada. As aplicações que estão executando dentro de containers Docker, utilizam a rede como se estivessem ligados dentro do mesmo switch de rede, sem requisitos para configurar mapeamentos de porta, ligações de container, etc. O blog da Weaveworks sugere que um dos principais casos para usar o Weave é ajudar os clientes a construírem aplicações na "nuvem nativa", que são tipicamente pacotes de containers, dinamicamente programados e orientados a microservices.
A ideia é que as aplicações de microservice de nuvem "nativa", possam melhorar a produtividade do desenvolvedor e obtenção de grandes reduções de custos. Os ganhos de eficiência vêm da automação e de ter aplicações mais flexíveis em relação aos recursos.
O blog da Weaveworks, propõe duas razões principais para que mais organizações não estejam adotando o desenvolvimento de aplicações de nuvem nativas. A primeira é o desafio operacional, por exemplo: a garantia que os serviços da aplicação estejam saudáveis, a coleta de dados para o planejamento de capacidade e gerenciamento de infraestrutura. O segundo desafio refere-se à escala, tais como, a falta de capacidade para lidar com a aplicação e elasticidade da infraestrutura. A Weaveworks acredita que sua experiência anterior com o desenvolvimento Weave permitirá a entrega de uma solução de monitoramento que possa superar os problemas citados anteriormente.
Weave Scope é executado através de um processo de sonda (probe, em inglês) com privilégios elevados para cada host físico que possa ser monitorado, como: "sudo probe". Uma aplicação Scope pode então ser executada no host, e configurada para conversar com as sondas, por exemplo: "app-probes="probe-host-1:4030, probe-host-2:4030".
As interfaces de um usuário Scope, podem ser visualizadas na aplicação web em execução através de um navegador pela porta 4040 no host Scope, por exemplo: http://scope-host:4040. Um exemplo de gráfico de monitoramento de aplicação/container pode ser visto a seguir:
O código do Weave Scope, pode ser encontrado no repositório associado ao Github da Weaveworks, e está no processo de ser integrado dentro do Weave. O blog da Weaveworks afirma que isso deve ser concluído ao longo das próximas semanas. Atualmente nenhuma outra implementação é suportada pela Weave Scope, mas a equipe da Weaveworks está procurando por contribuições:
Se é um fornecedor SDN ou está utilizando alguma outra rede que não seja Weave, não se desespere. Adoraríamos que utilizasse Scope também e não temos planos de tornar isso estranho. Então, comece ou entre em contato. Com a crescente adoção do Weave entre os desenvolvedores Docker e as funcionalidades amigáveis como o descobrimento de serviço automatizado e alocação de endereço, é uma maneira ideal de combinar sua rede favorita com o desenvolvimento de aplicação em nuvem nativa.
A InfoQ americana conversou com Alexis Richardson, fundador e CEO da Weaveworks e fez várias perguntas sobre o lançamento do Weave Scope.
InfoQ.com: No post do blog da Weave anunciando Weave Scope, há uma observação interessante que muitas soluções de monitoramento não são destinadas a desenvolvedores. Com o aumento da colaboração entre desenvolvedores e operações (a'la DevOps), acha que isso ainda é um problema? E quais são as implicações?
Richardson: Sim, absolutamente isso ainda é um problema. Ser um desenvolvedor amigável é fundamental. O Scope permite que os desenvolvedores de aplicações, peguem uma aplicação existente, que utiliza container, e então monitorá-la e visualizá-la.
Quanto ao DevOps: uma importante parte dele é que: os desenvolvedores assumam mais responsabilidades Ops (o nome vem de Operações) e integrem ações Ops em seu fluxo de trabalho. Mas, isso não quer dizer que o pessoal Ops comece a pensar em aplicações da mesma maneira que fazem os desenvolvedores, ou que todos os produtos de monitoramento venham se tornar amigável ao desenvolvedor.
Nosso objetivo é permitir um diálogo entre "dev" (desenvolvimento) e "ops" (operações). Vamos chamar isso de "monitoramento devops": uma combinação de tecnologia e prática. Considere o exemplo prático: são duas horas da manhã e os Ops estão tentando resolver um problema por várias horas. Talvez os desenvolvedores são mais qualificados para entender e solucionar o problema, então são chamados. Nesse ponto eles são frustados por ferramentas existentes que refletem uma visão fundamentalmente de sua infraestrutura, e com diferentes idiomas. Com o Scope, pretendemos fazer a ponte entre a visão lógica do desenvolvedor da aplicação e a visão física do operador de infraestrutura. Achamos que podemos construir algo que seja útil para ambos!
InfoQ.com: Existem algumas empresas de serviço de monitoramento emergindo agora, como Dataloop.IO. Sua ferramenta irá completá-las ou elas são concorrentes?
Richardson: Vemos Weave Scope principalmente como complemento, mas com alguns aspectos competitivos devido à sua abordagem inovadora. Também acreditamos que organizações se beneficiarão de produtos de monitoramento autônomos, como InfluxDB e Prometheus.
Nesse contexto, Weave Scope pode gerar novos feeds para essas ferramentas de monitoramento existentes (Datadog, etc.), para consumir e processar, em conjunto com todo o portfólio de aplicações. Em outras palavras, essas ferramentas serão agregadoras, puxando múltiplas fontes de dados para permitir correlação, discernimento e decisão. Então nesse sentido, Weave é complementar.
Ao mesmo tempo, estamos tentando fazer algo novo, e nesse sentido estamos competindo com uma série de hipóteses sobre os limites de monitoramento. Temos a intenção de colocar essas premissas à prova.
InfoQ.com: Adrian Cockcroft da Battery Ventures (e ex Netflix/eBay/Sun) está fazendo um trabalho interessante com a visualização de microservices em sua aplicação spigo/simianviz, cuja saída é similar ao Weave Scope. O que acha do trabalho de Cockcroft?
Richardson: Admiramos muito a análise dos microservices de Cockcroft e a maneira como se relaciona à adoção de DevOps. Se está interessado nisso, recomendo o vídeo de sua palestra na Dockercon Amsterdan 2014, além da palestra anterior do CIO da ING. O último é simplesmente um fantástico exemplo de como a adoção corporativa pode beneficiar uma empresa além de métricas tecnológicas como "velocidade".
Uma diferença importante entre Scope e Spigo deve ser entendida. Como mencionado anteriormente, Scope permite que os desenvolvedores de visualizem e monitorem as aplicações, que utilizam containers. Isso é feito sem alterar sua aplicação, o Scope apenas o descobre. Considerando que no Spigo, são utilizadas ferramentas para simular aplicações que (ainda) não existem, modelando-os como uma interação de agentes e protocolos associados.
InfoQ.com: Várias organizações estão afirmando agora publicamente que estão construindo plataformas de microservice em cima de agendamento de cluster e tecnologia de orquestração, como Mesos e Kubernetes, que muitas vezes contém monitoramento básico embutido e controle de eficácia. Acha que Weave Scope ainda agregará valor aqui?
Richardson: Sim, pensamos que a adição do Weave Scope seria obviamente uma vitória para usuários e desenvolvedores do Mesos e Kubernetes. Notem, por favor, que é difícil comparar nosso produto com coisas que ainda não existem. Muito ainda está para acontecer. Contudo se outros adotam Weave ou fazem alguma outra coisa, temos ideias para levar o que achamos ser genuinamente novo e claro muito valioso. Alguns exemplos são mencionados no post do nosso blog.
InfoQ.com: Seu blog contém vários pontos sobre a falta de suporte das ferramentas de desenvolvimento para a construção de aplicações de microservices. Isso é um indício de que o Weave está prestes a oferecer somente aplicações relacionada em rede, ao invés de incluir uma vasta gama de ferramentas para os desenvolvedores?
Richardson: "Sim e não".
Sim - sempre quisemos fazer monitoramento como acreditamos que é fundamental para entender aplicações em um ambiente dinâmico. Queremos oferecer outros recursos que ajudem os desenvolvedores a ter sucesso aqui.
Mas, não - não queremos fazer isso oferecendo a eles "construa aplicações" como orquestração de frameworks e plataformas. O valor de cada ferramenta vem aumentando a produtividade do desenvolvedor apoiando um determinado modelo ou "opinião", de como uma aplicação deve ser construído. Como: o Heroku tornou fácil a construção de aplicações web no EC2, se quer construir aplicações web no EC2 utilizando abordagem do 12-factor. Porém, não queremos que Weave seja prescritivo dessa maneira.
Resumindo - Acreditamos que os desenvolvedores já sabem como escrever aplicações, e nossas ferramentas devem funcionar para qualquer aplicação, em qualquer lugar.
InfoQ.com: No final do post de seu blog, menciona que Weave gostaria de encorajar o suporte ao Weave Scope para ser capaz de monitorar outras soluções fornecedoras de rede. Isso é algo que está sendo conduzindo, ou encorajará a comunidade de desenvolvimento conduzir?
Richardson: É muito fácil implementar suporte ao Weave Scope, e assim encorajamos a comunidade (e outros fornecedores) a se envolver. Não acreditamos em oferecer ferramentas "monolíticas" fortemente acopladas, preferimos fortemente a filosofia "Unix". Isso quer dizer que qualquer desenvolvedor deve ser capaz, de preferência, utilizar livremente qualquer parte Weave, de forma útil e rápida. Nenhum desenvolvedor deve ser obrigado ou forçado a utilizar os recursos que oferecemos. Então, o Weave em si, está tentando ser o mais próximo do ideal de "microservices".
InfoQ.com: Finalmente, a Docker Inc, anunciou recentemente sua aquisição estratégica da Socketplane para melhorar o networking em seu container de plataforma de ofertas. CoreOs também tem falado recentemente sobre ganhar apoio de outros fornecedores para o desenvolvimento de seu App Container Spec e implementação rkt - considera juntar-se ao CoreOs para ajudar o avanço na condução desse trabalho?
Richardson: Não podemos fazer tudo, e nossos clientes estão gritando por suporte / integração Docker. Temos trabalhado muito com a equipe antiga da Socketplane, agora equipe da rede Docker. Tem sido muito positivo e a Docker está fazendo o seu melhor para permitir uma "plataforma aberta".
Com appc: Seria bem-vindo o estreitamento de laços entre a especificação Docker e appc spec. Pensamos que o mercado quer mais padronização, ao invés de dois ou mais adicionamentos de padrões como .deb e .rpm, mas para containers. Indiscutivelmente, uma única especificação para containers é melhor do que várias especificações técnicas. Se há uma especificação container padrão, então não será necessariamente múltiplas implementações que irão competir. Certamente isso é saudável desde que nenhuma implementação possa ser de "tamanho único".
Sobre a rkt: Atualmente "a concorrência é a implementação mais importante da especificação de um container", é o que está acontecendo com appc e rkt. Isso é para ambas appc e rkt, e poderia criar ameaças para Docker. Atualmente Docker é a única e principal implementação de sua especificação, o que só é sustentável se puder trazer o mercado e o ecossistema com ele. Poderíamos argumentar portanto, que em um mundo de somente uma especificação, o Docker faz melhor do que um mundo "bilateral" de duas especificações. O Docker seria claramente o líder neste cenário se vários competidores tiverem que brigar pelo segundo lugar ou ocupar nichos.
O README.md do repositório Github da Weaveworks Scope, afirma que a versão atual é a pré-alpha, e os usuários não devem se surpreender com bugs ou ausência de funcionalidades. Os usuários são encorajados a experimentar o Weave Scope e levantar questões via Github ou e-mail.