O editor desta newsletter tem defendido em várias oportunidades que o mundo inteiro já está dominando as metodologias e incentivos à geração de empresas emergentes (marcadamente de base tecnológica), ou startups; a questão que ainda permanece em aberto é a de como, e quão rápido, elas escalam e crescem.
No mundo inteiro as empresas em geral estão descobrindo que há uma profunda diferença entre, de um lado, utilizar tecnologia para operar a companhia, e, de outro lado, alavancar tecnologia para ofertar seus produtos e serviços diretamente para seus clientes. Isso explica porque há tantas iniciativas hoje em dia de “transformação de tecnologia” em tantas companhias.
Tal transformação representa uma mudança na organização, nas pessoas, nos processos, especialmente na cultura, e a escalabilidade está no centro dessa transformação, de forma a ser possível:
• Escalar de dezenas ou centenas de empregados usando sua tecnologia, para milhões de consumidores dependendo de sua tecnologia;
• Escalar de um pequeno time de centro de custo de TI servindo seus colegas em finanças e marketing, para um substantivo time de centro de tecnologia servindo seus consumidores;
• Mais genericamente, escalar seu pessoal, processos e tecnologia para fazer face às demandas de um moderno negócio baseado em tecnologia.
Pensando nisso, a AKF Partners desenvolveu o Scale Cube (Cubo de Escalagem), que é um modelo para construir arquiteturas resilientes e escaláveis usando padrões e práticas que se aplicam amplamente para qualquer indústria e todas soluções. A empresa inventou o Scale Cube em 2007, publicando-o online em seu blog, e subsequentemente no primeiro livro de seus sócios fundadores (Martin L. Abbott e Michael T. Fisher), intitulado The Art of Scalability, e no segundo livro Scalability Rules.
O Scale Cube (algumas vezes chamado de AKF Scale Cube, ou AKF Cube) compreende 3 (três) eixos: o eixo X (denominado Duplicação ou Clonagem Horizontal), o eixo Y (denominado Decomposição e Segmentação Funcional), e o eixo Z (denominado Particionamento de Dados Horizontal), como mostrado na Figura 1 à frente.
O Scale Cube ajuda times a manterem dimensões críticas do sistema de escalagem em mente quando soluções são projetadas, e quando sistemas existentes estão sendo melhorados.
A maioria dos produtos possibilitados pela Internet começa sua vida como uma aplicação simples rodando em um appserver ou combinação appserver/webserver e, certamente, comunica-se com um banco de dados. Este projeto monolítico funcionará bem para aplicações relativamente pequenas que recebem baixos níveis de tráfego de clientes. No entanto, essa arquitetura monolítica um “beijo de morte” para aplicações complexas.
Uma grande aplicação monolítica pode ser difícil para os desenvolvedores entenderem e manterem. É também um obstáculo para frequentes empregos. Para empreender mudanças em um componente da aplicação é necessário construir e operar o monolítico inteiro, o que pode ser algo complexo, arriscado e consumidor de tempo, requerendo a coordenação de muitos desenvolvedores, resultando em longos ciclos de testes. Consequentemente, você está frequentemente preso diante das escolhas de tecnologia que você fez no início do projeto. Em outras palavras, a arquitetura monolítica não escala para dar suporte à aplicações grandes e duradouras.
A Figura 2 à frente, mostra como o cubo pode ser empregado em uma moderna arquitetura de decomposição de serviços (algumas vezes chamada arquitetura de microsserviços), de serviços clonados e fontes de dados, e de segmentação de objetos similares, como consumidores, em “pods”.
Escalando Soluções com o Eixo X do Scale Cube
Os autores do Scale Cube defendem que o enfoque mais comumente usado para escalar uma solução é rodar múltiplas cópias idênticas da aplicação por trás de um load balancer, também conhecido como X-axis scaling (escalagem do eixo X). Isto é uma grande maneira de melhorar a capacidade e disponibilidade de uma aplicação.
Ao usar o X-axis scaling cada servidor roda uma cópia idêntica do serviço (se desagregado) ou monolítico. Um benefício do eixo X é que ele é tipicamente fácil de implementar, e ele escala bem numa perspectiva de transação. A Figura 3 à frente explica os prós e contras da escalabilidade do eixo X, e caminha através de uma arquitetura de 3 camadas para explicar como ela é implementada.
Escalando Soluções com o Eixo Y do Scale Cube
A escalagem no eixo Y (pense em arquitetura orientada a serviços, microsserviços ou decomposição funcional de um monolítico) foca em separar serviços e dados ao longo de fronteiras de nomes ou verbos. Essas quebras são dessemelhantes umas das outras. Exemplos em soluções de comércio devem ser separações de buscas do browse, checkout from add-to-cart, login from account status, etc. Ao implementar as separações, a escalagem do eixo Y separa uma aplicação monolítica em um conjunto de serviços. Cada serviço implementa um conjunto de funcionalidades relacionadas, tais como order management, customer management, inventory, etc.
Além do mais, cada serviço deve ter seus próprios dados não-compartilhados para assegurar alta disponibilidade e isolamento de falhas. A escalagem do eixo Y compartilha o benefício de aumentar a escalabilidade da transação como todos os eixos do cubo. E mais ainda, pelo fato do eixo Y permitir segmentação de times e propriedade de código e dados, a escalabilidade organizacional é aumentada. A Figura 4 explica os prós e contras da escalabilidade do eixo Y, e mostra exemplos de serviços isolados de falhas, cada um dos quais tendo seus próprios armazenamento de dados para os propósitos de isolamento de falhas.
Escalando Soluções com o Eixo Z do Scale Cube
Enquanto o eixo Y endereça a separação de coisas dissimilares, o eixo Z endereça segmentação de coisas similares. Exemplos podem incluir separação de consumidores ao longo de um unbiased modulus of customer_id, ou ao longo de algo como um biased (but beneficial for response time) geographical boundary. Catálogos de produtos podem ser separados por SKU, e conteúdo pode ser separado por content_id. A escalagem do eixo Z, como todos os eixos, melhora a escalabilidade transacional da solução e, se isolado de falhas, sua disponibilidade. A Figura 5 à frente explica os prós e contras da escalabilidade do eixo Z, e mostra uma estrutura pod isolada de falha com 2 únicos pods de consumidores nos EUA, e 2 na European Union.
Em resumo, como os autores finalizam sua demonstração: “Como na história de Goldilocks e dos três ursos (ver significado aqui), a meta da decomposição não é ter serviços que sejam muito pequenos, ou serviços que sejam muito grandes, mas sim que assegurem que o sistema seja “just right” (certo o suficiente) ao longo das dimensões de escala, custo, disponibilidade, time to market, e tempos de respostas”.
Eis aí uma metodologia simples, e que vem sendo adotada especialmente pelos principais especialistas em escalagem de negócios através de arquiteturas de microsserviços (no que diz respeito a este conceito, ver a newsletter de 20/11/2016).
Se sua empresa, organização ou instituição deseja saber mais sobre escalagem, não hesite em nos contatar!
