No QCon San Francisco, Rafael Schloming em sua apresentação "Service-Oriented Development" explicou que uma organização que migre para microservices deve procurar dividir seus processos monolíticos de desenvolvimento além de tentar dividir a arquitetura do sistema.Tratar novas equipes de microservices como "spin offs" internos fornece limite e incentiva a auto-suficiência e autonomia, e essas equipes devem ser suportadas por ferramentas eficazes para depuração, implantação e acompanhamento de serviços em produção.
Schloming, CTO e Arquiteto Chefe da Datawire, começou a apresentação perguntando ao público quais seriam suas primeiras perguntas quando começassem a migração de uma aplicação monolítica para microservices. As respostas incluíram: "como eu divido meu monolito?", "Como eu arquiteto meu aplicativo com microservices?" e "que infraestrutura preciso ter antes de me beneficiar com microservices?". Com base em sua experiência com o desenvolvimento de uma aplicação de microservices na Datawire em 2013, Schloming argumentou que uma das questões mais importantes - embora muitas vezes ignoradas - para perguntar é "como eu divido meu processo monolítico?", conforme o processo de desenvolvimento que é fundamental para estabelecer e manter a velocidade.
Ao desenvolver um aplicativo ou serviço, o ciclo de vida de entrega abrangente pode ser dividido em três fases: prototipagem, produção e missão crítica. Muitas vezes, é muito mais fácil manter uma alta velocidade de entrega de recursos no estágio de prototipagem, porque a estabilidade é menos importante. À medida que a entrega muda da produção para a missão crítica, a velocidade é muitas vezes sacrificada por maior estabilidade. Usar um único processo de entrega para todos os componentes dentro de um aplicativo é ineficiente, pois isso força a estabilidade vs a velocidade de trade-off.
O desenvolvimento de um aplicativo baseado em microservices permite que múltiplos processos sejam usados: cada equipe de microservice/produto é livre para escolher o processo apropriado de acordo com seu atual estágio no ciclo de vida da entrega. Os microservices podem ser uma arquitetura de desenvolvimento distribuída, mas também permitir um fluxo de trabalho de desenvolvimento distribuído consistindo em muitos processos de desenvolvimento simultâneos com diferentes compensações de velocidade/estabilidade. No entanto, mover-se para esta forma de trabalhar requer mudanças organizacionais e técnicas.
Do ponto de vista organizacional, a criação de equipes de software autônomas, centradas em torno de um produto é altamente benéfico. No entanto, essa mudança de um processo monolítico para um processo de microservice requer formação, comunicação e delegação. Todos dentro de uma equipe de produtos de microservice serão expostos ao ciclo de vida completo do desenvolvimento - desde a codificação local até a implantação do código em produção através de um fluxo de entrega contínua e monitoramento do aplicativo - e isso normalmente requer formação adicional. No fim, essa mudança significa que os especialistas têm a oportunidade de se tornarem generalistas, o que leva à implementação de melhores sistemas e operações holísticas.
As pessoas podem não falar o mesmo idioma entre as equipes de produtos, mas esse conflito pode se tornar uma fonte de colaboração se aproveitado corretamente. Pequenas equipes dentro da organizações podem possuir grandes partes importantes do sistema como um todo, mas essa autonomia é a única maneira de se escalar efetivamente dentro de um ambiente de mercado acelerado. As equipes devem se esforçar para garantir que não precisem depender de outras equipes para alcançar seu objetivo, o que inclui a eliminação da dependência de uma equipe de arquitetura e operações centralizadas (embora uma "equipe de plataforma" que forneça acesso de auto-atendimento à infra-estrutura seja geralmente benéfica).
Schloming argumentou que a melhor maneira de conceituar a mudança organizacional necessária para implementar microservices é pensar em cada equipe de produtos como um spinoff de negócios. Assim como as equipes de desenvolvimento podem consumir serviços de terceiros, como Twilio ou Stripe, as equipes de produtos devem se integrar aos serviços internos usando a mesma abordagem.
Em relação à implementação técnica de microservices, Schloming descreveu os objetivos de cada estágio de ciclo de vida da entrega: protótipo - feedback rápido de ferramentas e usuários; usuários de produção e crescimento - adicione recursos e não perturbe os usuários; e missão crítica - assegure a estabilidade. Isso geralmente resulta na operação de uma única plataforma com fluxos de trabalho paralelos (baseados em microservices) que podem ser transferidos à medida que os produtos amadurecem. Exemplos práticos dos desafios técnicos de cada estágio no ciclo de vida foram apresentados usando o Docker, Kubernetes e o proxy de serviço Envoy como componentes de plataforma subjacentes.
Durante o estágio de prototipagem, pode ser desafiador obter o apoio organizacional para a experimentação em produção (por exemplo, através de testes A/B ou implantação canário, e é tecnicamente desafiador executar microservices localmente). Uma estratégia para superar isso é fornecer provisionamento self-service e desenvolver contêineres que podem ser implantados em um ambiente remoto através de uma fluxo de entrega contínua. Schloming forneceu exemplos usando ferramentas de código aberto que a equipe do Datawire criou, forge.sh - para criar um ambiente de desenvolvimento portátil que seja a única fonte de verdade sobre builds e dependências - e telepresence para proxying em um cluster de Kubernetes remoto - permitindo que uma aplicação seja desenvolvida localmente (e ferramentas de depuração associadas) para interagir com os serviços remotos como se estivessem sendo executados no cluster.
Para os usuários de produção e a fase de crescimento do ciclo de vida da entrega, os principais desafios são medir o impacto do usuário pela experimentação (e reconhecendo o trade off associado entre velocidade e estabilidade) e testar novos recursos e mitigar o impacto de bugs de software. A utilização da implantação de multiversões pode superar essas questões, permitindo a implantação canário de novos recursos ( como novos serviços) e aumentando gradualmente o tráfego à medida que a confiança aumentar nas métricas observadas. O Envoy, um proxy de camada 7(aplicativo) criado e executado em escala por Matt Klein e a equipe de engenharia da Lyft, pode fornecer essa funcionalidade, pois todo o tráfego pode ser encaminhado e controlado por meio desse proxy. Vem ocorrendo um interesse crescente por esse conceito nos últimos seis meses com o surgimento da Istio (que usa o Envoy como o plano de dados de malha do serviço) e outras "malhas de serviço".
Os desafios da fase final - software de missão crítica - giram em torno da prevenção de regressão de funcionalidade e acompanhamento da aplicação. A estratégia para superar isso consiste em definir Objetivos de Nível de Serviço (SLOs) e implementar o acompanhamento da camada 7. A criação de SLOs refoçado através de acordos contratuais de nível de serviço (SLAs), em um esforço de toda a organização. O acompanhamento da camada 7 pode ser implementada via Envoy (ou um proxy equivalente a isso), pois este proxy opera nesta camada da pilha de rede e tem acesso a todo o tráfego de serviço a serviço dentro da rede.
Schloming resumiu sua palestra afirmando que, quando uma organização inicia uma migração para microservices, a atenção deve ser voltada para à ruptura do processo monolítico, além de (em prioridade) romper a arquitetura monolítica. Organizar as equipes de produtos microservices como "spin offs" é benéfico, e as ferramentas devem ser criadas para permitir um desenvolvimento efetivamente orientado a serviços.
Os slides da palestra "Service Oriented Development" de Rafael Schloming (PDF, 2MB) podem ser encontrados no site do QCon SF. O vídeo desta e de todas as palestras serão disponibilizados através do InfoQ nos próximos meses.