Estratégias de migração de arquiteturas SaaS

O modelo de entrega de software como serviço (SaaS) é muito atraente para muitas organizações. Agilidade, capacidade de resposta ao mercado, custos de infraestrutura compartilhados — todos eles representam uma oportunidade para as empresas transformarem sua abordagem de como constroem, operam e monetizam seus produtos. A realidade, no entanto, é que essas mesmas organizações geralmente têm um investimento significativo em suas ofertas existentes de locatário único. Embora o apelo do SaaS seja intrigante, muitas vezes não é realista esperar que as equipes possam reconstruir completamente seus aplicativos e adotar instantaneamente todos os dogmas e princípios normalmente associados a ambientes multilocatários.

O desafio, então, é que as organizações encontrem maneiras criativas de mover gradualmente suas soluções para um modelo SaaS sem grandes interrupções. Embora os benefícios do SaaS possam ser convidativos, é importante fazer a mudança para o SaaS com cuidado e premeditação. Por fim, você deseja emergir dessa transformação com um produto que herde as melhores características do SaaS e se torne um facilitador para os negócios. Um simples levantamento e deslocamento ou algum tipo de pseudo-SaaS provavelmente prejudicará seus objetivos de longo prazo.

Qualquer discussão sobre migração SaaS deve considerar todo o escopo do que significa construir, entregar, dar suporte e vender em um modelo SaaS. Isso significa que nossa discussão sobre migração deve examinar a influência do SaaS nas dimensões técnica, comercial e operacional da transformação de um aplicativo. A migração deve observar continuamente todas as partes móveis do cenário SaaS para determinar quais séries de movimentos permitirão que você assegure que seu caminho adiante inclua o valor total do SaaS.

Quão multilocatário você é?

Antes de nos aprofundarmos nas estratégias de migração, é importante obter uma base sólida para a discussão sobre multilocação. Aos olhos da maioria dos desenvolvedores, a multilocação equivale a ter todos os inquilinos em execução em uma única área de infraestrutura. Na verdade, muitos dos valores de agilidade associados ao SaaS dependem desse modelo compartilhado. Custo, implantações, gerenciamento e agilidade competitiva — todos eles se beneficiam muito dos méritos de uma infraestrutura compartilhada.

O problema é que essa visão de multilocação não é prática para todas as empresas ou para todos os domínios. Na verdade, existem vários modelos diferentes que são usados ​​para fornecer soluções SaaS bem-sucedidas. Na verdade, para alguns, a mudança para SaaS pode ser simplesmente uma transferência de responsabilidades de gerenciamento para um provedor. Portanto, embora adorássemos ter um destino final e universal para nosso esforço de migração, também é justo presumir que o estado final de destino da multilocação provavelmente varia. Como resultado, nossas estratégias de migração também devem variar.

Dada essa definição fluida de multilocação, nossa revisão das estratégias de migração deve abranger vários tipos de multilocação SaaS. O processo de migração deve permitir modelos SaaS em que parte ou toda a infraestrutura de um locatário pode ser executada isoladamente. Para os provedores e seus locatários, essas soluções não são menos SaaS do que qualquer solução de infraestrutura compartilhada.

A armadilha que você deseja evitar, no entanto, é usar o isolamento como uma muleta de migração. Se seus locatários e sua empresa se beneficiarem de um modelo de infraestrutura compartilhada, esse deve ser seu objetivo final. Não permita que a conveniência do isolamento prejudique sua capacidade de migrar em direção a esse objetivo.

Construindo uma Fundação

As migrações bem-sucedidas, por mais complexas que sejam, dependem da adoção de uma mentalidade incremental em que você tenta esculpir partes do seu sistema e migrá-las peça por peça para um novo modelo. Ao abordar isso de forma incremental, você terá uma oportunidade natural de identificar e apresentar as estruturas que serão essenciais para estabelecer uma base que dará suporte à sua adoção de sistemas de valor técnico e operacional SaaS. Registro em log, configuração de locatário, configuração de serviço, acesso a dados, medição — essas são todas as áreas em que você provavelmente precisará introduzir bibliotecas que abstraem suas políticas e sua percepção de locatário.

É importante observar que não se trata de levar meses para criar ferramentas e estruturas. É simplesmente perceber que esses conceitos fundamentais precisam emergir e fazer parte do seu processo de pensamento enquanto você entrega as primeiras peças do seu sistema em seu novo modelo.

O ponto de partida

Claramente, existem muitos tipos de design de aplicativo para propor um ponto de partida comum. Ao mesmo tempo, definitivamente existem padrões de arquitetura que ocorrem com muita frequência. Estruturas, ferramentas e orientações gerais levaram muitos desenvolvedores ao caminho do desenvolvimento de n camadas.

Com essa arquitetura, temos essencialmente uma camada da web que é usada para gerenciar e entregar os ativos de seu aplicativo. Essa camada é liderada por um balanceador de carga que distribui o tráfego para servidores da web. A lógica de negócios do aplicativo reside na camada do aplicativo que acessa o banco de dados do seu aplicativo (geralmente por meio de alguma camada de acesso a dados).

Os provedores hospedarão ou oferecerão uma solução local onde essa arquitetura é replicada e personalizada com base nas necessidades de cada cliente. Esses ambientes tendem a funcionar em completo isolamento e podem frequentemente executar diferentes versões de aplicativos. Cada instalação assume que está atendendo às necessidades de um único inquilino, e em nenhum lugar do projeto ou da arquitetura existe qualquer noção de multilocação.

Você também notará que as unidades de escala neste modelo são bastante grosseiras. Você tem servidores web e servidores de aplicativos. Se algum subconjunto de funcionalidade em um servidor de aplicativos estiver causando um gargalo, sua única maneira de lidar com isso é adicionar mais servidores de aplicativos. Você realmente não pode combinar a escala e o perfil de nossos recursos de computação (instâncias) com os elementos mais granulares da funcionalidade de nosso aplicativo.

Embora existam variantes desse modelo de arquitetura, os fundamentos são compartilhados por muitas soluções existentes. Você pode ver mais a camada de aplicativo separada em famílias de serviços que visam funções de negócios específicas (processo em lote, armazenamento em cache e assim por diante). Você pode ver uma camada formal de acesso a dados introduzida. Mesmo com essas nuances, o modelo básico e a abordagem permanecem praticamente inalterados.

Temas de Migração Minimamente Invasivos

Dada a arquitetura descrita acima, a verdadeira questão é como começar a migrar ambientes dessa natureza para um modelo SaaS sem alterar fundamentalmente o design ou a arquitetura de nosso aplicativo existente. Como começamos a introduzir a multilocação sem exigir a reescrita de toda a solução? Como abordamos a automação de implantação e outros princípios de agilidade de SaaS como parte de nosso esforço de migração? Esses são os desafios que as organizações enfrentam quando tentam montar seus roteiros de migração.

Embora certamente existam várias maneiras de atacar esse problema, alguns padrões são mais prevalentes do que outros. A lista de modelos de migração que exploraremos neste post inclui:

• Silo Migration Model — apresenta infraestrutura separada para cada inquilino, apresentando a experiência com uma única experiência de integração e autenticação
• Modelo de migração em camadas — as camadas de um aplicativo são migradas de forma incremental para um modelo multilocatário
• Modelo de migração de dados — os modelos de armazenamento são migrados para um modelo multilocatário, enquanto o restante do aplicativo permanece em uma infraestrutura de locatário em silos

As seções a seguir examinarão cada um dos temas de migração minimamente invasiva e explorarão algumas das principais considerações que acompanham cada modelo. Também é importante observar que essas soluções não são mutuamente exclusivas.

Modelo de Migração de Silo

Para muitas organizações, o modelo de silo representa a maneira mais natural e atraente de lidar com a migração. A ideia por trás do modelo de silo é o reconhecimento de que um modelo de infraestrutura compartilhada pode ser demais para ser engolido no início.

O modelo de silo cria uma pilha de infraestrutura separada para cada inquilino. Na medida do possível, as migrações desse tipo tentarão limitar as alterações no design existente e simplesmente aproveitar os serviços e as construções da AWS onde fizerem mais sentido. Por exemplo, as camadas da web e do aplicativo da arquitetura serão implantadas em grupos de Auto Scaling que abrangem várias zonas de disponibilidade. Embora cada locatário seja dimensionado independentemente, você ainda pode aplicar elasticidade à infraestrutura em silos e dimensionar dinamicamente o número de servidores Web e de aplicativos com base nas cargas do locatário.

As migrações de silo geralmente incluem uma mudança para um dos serviços de armazenamento da AWS. Se, por exemplo, você estiver executando inquilinos em um banco de dados do SQL Server, provavelmente considerará o uso do Amazon Relational Database Service (Amazon RDS) para atender às suas necessidades de armazenamento. Isso permitirá que você transfira mais responsabilidades operacionais e de disponibilidade para a AWS e que sua equipe de operações aproveite as várias opções que o RDS oferece para otimizar a escala e a disponibilidade.

O modelo de silo apresenta algumas novidades quando se trata de integrar novos inquilinos. Idealmente, mesmo em um ambiente isolado, você ainda gostaria de tornar a integração o mais simples possível. Isso significa apresentar aos seus inquilinos uma interface do usuário e um processo de inscrição que imita o mesmo modelo que vemos em outros ambientes SaaS, com provisionamento totalmente automatizado de novos inquilinos.

Mudar para o provisionamento automatizado e cercar sua infraestrutura de locatário com ferramentas será o foco de seu esforço inicial de migração. O investimento que você faz aqui representa uma oportunidade de avançar em uma direção mais ágil, promovendo a centralização e a automação de qualquer necessidade de configuração exclusiva do locatário. Quanto mais você puder morder aqui, melhor posicionado estará para avançar continuamente em seu design e arquitetura.

Felizmente, a automação desse ciclo de vida está no centro das ferramentas de DevOps com suporte da AWS e seu ecossistema. Essas ferramentas irão equipá-lo com todos os blocos de construção necessários para construir um pipeline de entrega contínuo e robusto que impulsionará a repetibilidade e a estabilidade do seu sistema.

Modelo de Migração em Camadas

Com o modelo de migração em camadas, a ênfase está em encontrar oportunidades para mover camadas de sua solução para multilocação. A chave para essa abordagem é criar camadas que possam se mover gradualmente em direção a um modelo compartilhado de vários locatários, ao mesmo tempo em que permite que partes da solução mantenham seu design de locatário único.

Embora a camada da Web seja compartilhada neste diagrama, você também notará que cada inquilino tem sua própria camada de aplicativo distinta. As camadas da web mapeiam seu tráfego para a camada de aplicativo do inquilino apropriado com base em seu contexto de inquilino.

O apelo desse modelo é que ele nos permite obter mais conceitos compartilhados sem enfrentar todo o problema de vários inquilinos. Na verdade, a camada escolhida não precisava ser a camada do aplicativo. Você pode escolher qualquer camada em seu ambiente e migrá-la para um modelo multilocatário. Então, como achar melhor, corte lentamente as camadas restantes.

Assim como o silo e o modelo de migração de dados, o modelo em camadas depende de uma migração paralela para o provisionamento automatizado. A principal diferença aqui é que o escopo do que deve ser provisionado agora muda. A camada da Web pode permanecer um tanto constante, enquanto novas camadas de aplicativos serão necessárias para cada nova implantação de locatário.

Modelo de migração de dados

A mudança para representações de dados multilocatário pode ser um dos aspectos mais desafiadores da adoção de SaaS. O código do aplicativo geralmente está fortemente interligado com a estrutura e a tecnologia usadas para armazenar os dados. Apesar desse acoplamento, a camada de dados também representa um limite muito claro em sua arquitetura que pode ser um alvo natural para migração.

Em muitos aspectos, a migração para dados multilocatário é simplesmente outra variação do modelo de migração em camadas descrito acima. No entanto, esse modelo de migração tende a parecer mais uma estratégia de baixo para cima, na qual você primeiro resolve os desafios dos dados multilocatários antes de mover a pilha para os detalhes do design do aplicativo.

A migração de seus dados fica muito mais fácil se seu aplicativo já tiver introduzido uma camada de acesso a dados. Essa camada geralmente abstrai os detalhes e limita a vinculação a uma API ou tecnologia de armazenamento. Se essa camada de dados existir, você estará em uma posição muito melhor para migrar normalmente seus dados para um modelo multilocatário. O objetivo aqui seria limitar o impacto nos clientes da camada de acesso a dados enquanto trocava a implementação subjacente de acesso a dados por algo que incluísse reconhecimento e particionamento de locatários.

Você também pode usar esse tempo para reavaliar as tecnologias de armazenamento do seu aplicativo. Você pode, por exemplo, considerar uma mudança de um modelo relacional para NoSQL. No entanto, um movimento desta natureza é muitas vezes visto como muito invasivo para enfrentar nos estágios iniciais da migração. Posteriormente, se você decidir decompor seu aplicativo em serviços menores, estará em melhor posição para selecionar modelos de armazenamento que se alinhem com as necessidades de cada serviço.

Seja qual for o caminho que você selecionar, a AWS tem um rico conjunto de opções de armazenamento que você pode escolher. Se estiver migrando de um modelo relacional, por exemplo, você pode escolher qualquer uma das soluções relacionais que fazem parte do Amazon RDS (Aurora, MySQL, SQL Server e assim por diante). Amazon DynamoDB (NoSQL), Amazon Redshift (armazenamento de dados) e Amazon ElastiCache também podem ser incluídos em sua estratégia de migração de armazenamento. Ao optar pelas soluções de armazenamento da AWS, você também pode considerar o uso do AWS Database Migration Service e da AWS Schema Conversion Tool para gerenciar a migração de seus dados existentes.

Alterar a representação de seus dados também significa migrar seus dados existentes para a nova representação multilocatário. Uma prática comum aqui é mover os inquilinos um por um para reduzir o risco e tornar o processo mais gerenciável. Você também pode usar essa abordagem para obter informações em tempo real sobre o desempenho do seu sistema à medida que cada inquilino é movido para a nova estrutura. Isso lhe dará a chance de ajustar e refinar sua configuração de armazenamento antes que todos os locatários tenham sido migrados para o novo ambiente.

Essa migração de dados em estágios também pode ser alinhada com a migração de locatários de uma solução local para a AWS. A conversão dos dados do locatário é aplicada à medida que cada locatário é provisionado e implantado no ambiente da AWS.

A migração para um serviço de armazenamento da AWS também cria uma oportunidade de incluir as métricas do AWS Identity and Access Management (IAM) e do Amazon CloudWatch . Com o IAM, você pode controlar o acesso ao seu armazenamento e garantir ainda mais que os locatários não tenham permissão para acessar nenhum dado fora de seu domínio. O CloudWatch pode ser usado para exibir métricas sobre sua atividade de armazenamento e fornecer mais pontos de dados que aprimoram sua experiência de gerenciamento e monitoramento.

Migração de gerenciamento e monitoramento

O gerenciamento e o monitoramento se aplicam universalmente a cada modelo de migração que descrevemos. Como estamos discutindo a migração de uma solução existente, é provável que você já tenha algum nível de ferramentas de gerenciamento e monitoramento em vigor. Por exemplo, a maioria das soluções já possui mecanismos para agregar e analisar informações de log junto com algumas ferramentas para permitir uma visualização da integridade do sistema. Ainda assim, como parte de sua migração, você deve pensar em como essas ferramentas precisam evoluir à medida que você começa a adotar um sistema de valor mais focado em SaaS.

Mesmo que alguns aspectos de suas soluções permaneçam de locatário único, você deve considerar a criação de uma experiência de gerenciamento e monitoramento que agregue sua atividade de locatário em uma visão única e consolidada da integridade do sistema. A agilidade de SaaS depende de ter informações de integridade detalhadas na ponta dos dedos, o que permite capturar e responder proativamente a eventos de integridade que, em alguns casos, podem abranger vários locatários. Essa experiência também deve fornecer uma visão da atividade e integridade de um único inquilino. Essa visão específica do inquilino é essencial para dar suporte aos inquilinos que podem estar enfrentando problemas funcionais ou de desempenho.

Ao atacar o gerenciamento e o monitoramento nas fases iniciais de sua migração, você se colocará em uma posição muito melhor para dar suporte a mais conceitos multilocatários à medida que seu ambiente evolui. Esse investimento inicial também permitirá que você incorpore mais dados de métricas da AWS em sua visualização de gerenciamento e monitoramento. Você certamente desejará extrair métricas e eventos do CloudWatch para avaliar o estado de seus ambientes. Você também pode introduzir métricas personalizadas do CloudWatch para exibir detalhes exclusivos do seu aplicativo.

No geral, sua migração para SaaS representa uma oportunidade para reavaliar sua estratégia de gerenciamento e monitoramento. Você deve usar esse momento para olhar além de suas ferramentas atuais e determinar qual combinação de soluções se alinha melhor com o sistema de valor SaaS que você está adotando.

A AWS e os parceiros do ecossistema AWS Partner Network (APN) têm soluções que podem ser usadas para atender a muitas de suas necessidades de monitoramento. Essas soluções permitem que você construa várias exibições de atividade que geralmente são essenciais para oferecer suporte a ambientes multilocatários complexos.

Migração de operações

Grande parte do esforço de migração é focada no design e na arquitetura do aplicativo que muitas vezes negligenciamos os aspectos operacionais da migração. Ao mover uma solução para a AWS — em qualquer modelo de migração SaaS — você deve observar como pode simplificar e automatizar a pegada de suas operações.

A AWS e seu ecossistema fornecem um rico conjunto de ferramentas que você pode usar para construir e aprimorar o perfil operacional de sua oferta de SaaS. A adoção dessas ferramentas e dos princípios que as acompanham deve ser um elemento-chave de qualquer esforço de migração de SaaS. Se sua organização ainda não adotou o DevOps, sua migração para SaaS representa uma excelente oportunidade para lançar sua transformação técnica e cultural para uma mentalidade de DevOps. Em muitos aspectos, a mudança para DevOps estará no centro de sua migração para a agilidade e para uma nova cultura SaaS que oferece suporte à evolução contínua e rápida de seu produto.

Colocar essa automação em prática antecipadamente ajudará você a criar uma base que simplifica a evolução do design e da arquitetura de seu aplicativo. Uma vez estabelecido o modelo de automação, torna-se mais simples aplicar esses mecanismos a novas áreas do sistema.

O investimento inicial em DevOps e automação pode ser alto para algumas organizações, mas os conceitos são fundamentais demais para o SaaS adiar. Tornar o DevOps uma prioridade também revela áreas em que as equipes podem exigir novas estruturas e relacionamentos organizacionais.

A pilha da AWS inclui várias ferramentas que podem ajudar na migração do DevOps. AWS CloudFormation , AWS Elastic Beanstalk e AWS OpsWorks podem ser usados ​​para provisionar infraestrutura e automatizar implantações. A AWS também fornece ferramentas como AWS CodeCommit , AWS CodePipeline e AWS CodeDeploypara oferecer suporte à orquestração de implantação contínua. Essas soluções são frequentemente usadas em conexão com ferramentas de automação DevOps que foram criadas pelo ecossistema da AWS. Você pode, por exemplo, usar o AWS CloudFormation para automatizar a configuração e o provisionamento de sua infraestrutura. Uma combinação de AWS CodePipeline e AWS CodeDeploy pode ser usada para construir sua solução de entrega contínua. Dê uma olhada na página AWS DevOps para saber mais sobre DevOps na AWS.

É importante observar que os padrões de migração descritos acima geralmente adicionam uma camada adicional de configuração ao seu ambiente SaaS. Onde quer que você tenha uma infraestrutura de locatário isolada, você também pode ter configurações exclusivas para esses locatários. Essas variações de configuração precisam ser capturadas, controladas por versão e armazenadas em um repositório que possa ser referenciado por seu ciclo de vida DevOps. Isso é essencial para garantir que seu ambiente SaaS seja implantado com um processo repetível e confiável.

No próximo post, falaremos sobre Cálculo de custos de locatários em ambientes SaaS.

SaaS Factory (A série) — Como construir soluções de Software como Serviço na AWS

Até o próximo post!