Considerações para atualizar uma solução multilocatária

Um dos benefícios da tecnologia cloud é a melhoria e evolução contínuas. Como provedor de serviços, você precisa aplicar atualizações à sua solução. Talvez seja necessário fazer alterações no código do aplicativo, na infraestrutura do Azure, nos esquemas de banco de dados ou em qualquer outro componente. É importante planejar como você atualiza seus ambientes. Em uma solução multilocatário, é especialmente importante ser claro sobre sua política de atualização, porque alguns de seus locatários podem estar relutantes em permitir alterações em seus ambientes ou podem ter requisitos que limitam as condições sob as quais você pode atualizar seu serviço.

Ao planejar uma estratégia para atualizar sua solução, você precisa:

• Identifique os requisitos dos seus inquilinos.
• Esclareça os seus próprios requisitos para operar o seu serviço.
• Encontre um equilíbrio que você e seus inquilinos possam aceitar.
• Comunique a sua estratégia de forma clara aos seus inquilinos e outras partes interessadas.

Este artigo fornece orientações para os tomadores de decisão técnica sobre abordagens para atualizar o software do locatário e as compensações envolvidas.

Requisitos dos seus clientes

Os clientes geralmente têm requisitos explícitos ou implícitos que podem afetar a forma como seu sistema é atualizado. Considere os seguintes aspetos para construir uma imagem de quaisquer pontos de preocupação que os clientes possam levantar:

• Expectativas e requisitos: Descubra quaisquer expectativas ou requisitos que os clientes possam ter sobre quando sua solução pode ser atualizada. Essas expectativas ou requisitos podem ser formalmente comunicados a você em contratos ou acordos de nível de serviço, ou podem ser informais.

• Janelas de manutenção: Entenda se seus clientes esperam janelas de manutenção definidas pelo serviço ou autodefinidas. Eles podem precisar se comunicar com seus usuários sobre possíveis interrupções. Eles também podem esperar testar aspetos importantes do seu serviço após a conclusão da atualização.

• Regulamentos: Esclareça se os clientes têm alguma preocupação regulatória que exija aprovação extra antes que as atualizações possam ser aplicadas. Por exemplo, se forneceres uma solução de saúde que inclua componentes de IoT, talvez seja necessário obter a aprovação da Administração de Alimentos e Medicamentos (FDA) dos Estados Unidos antes de efetuares uma atualização.

• Sensibilidade: Entenda se algum de seus clientes é particularmente sensível ou resistente a ter atualizações aplicadas. Se estiverem, tente perceber porquê. Por exemplo, se eles administram uma loja física ou um site de varejo, eles podem querer evitar atualizações em torno da Black Friday, porque os riscos são maiores do que os benefícios potenciais.

• História: Analise seu próprio histórico de conclusão bem-sucedida de atualizações sem qualquer impacto para seus clientes. Você deve seguir boas práticas de DevOps, teste, implantação e monitoramento para reduzir a probabilidade de interrupções e garantir que você identifique rapidamente quaisquer problemas introduzidos pelas atualizações. Se seus clientes souberem que você pode atualizar seus ambientes sem problemas, é menos provável que eles se oponham.

• Reversão: Considere se os clientes desejam reverter atualizações se houver uma alteração crítica e quem inicia essa solicitação de reversão.

Os seus requisitos

Você também precisa considerar as seguintes perguntas de sua própria perspetiva:

• Controle que você está disposto a fornecer: É razoável que seus clientes tenham controle sobre quando as atualizações são aplicadas? Se você estiver criando uma solução usada por clientes de grandes empresas, a resposta pode ser sim. No entanto, se você estiver criando uma solução focada no consumidor, é improvável que você dê qualquer controle sobre como atualizar ou operar sua solução.

• Versões: Quantas versões da sua solução você pode razoavelmente manter ao mesmo tempo? Se você encontrar um bug ou vulnerabilidade de segurança e precisar aplicar um hotfix, talvez seja necessário aplicá-lo a todas as versões atualmente em uso.

• Consequências das versões antigas: Qual é o impacto de permitir que os clientes fiquem muito atrás da versão atual? Se você lançar novos recursos regularmente, as versões antigas se tornam obsoletas rapidamente? Além disso, dependendo da sua estratégia de atualização e dos tipos de alterações, talvez seja necessário manter infraestruturas separadas para cada versão da sua solução. Portanto, pode haver custos operacionais e financeiros, já que você mantém o suporte para versões mais antigas.

• Reversão: A sua estratégia de implementação pode suportar reversões para versões anteriores? Deseja habilitar esse recurso?

Encontre um equilíbrio

Se você deixar a cadência de suas atualizações de serviço inteiramente a critério de seus locatários, eles podem optar por nunca atualizar. É importante permitir-se atualizar sua solução, considerando quaisquer preocupações ou restrições razoáveis que seus clientes possam ter. Por exemplo, se um cliente for particularmente sensível a atualizações em uma sexta-feira porque esse é o dia mais movimentado da semana, considere se você pode adiar as atualizações para segunda-feira com a mesma facilidade sem afetar sua solução.

Uma abordagem que pode funcionar bem é implantar atualizações em uma base de locatário por locatário usando uma das estratégias de implantação. Notifique seus clientes sobre atualizações planejadas. Permitir que os clientes possam recusar temporariamente, mas não permanentemente. Defina um limite razoável para quando requer que a atualização seja aplicada.

Considere permitir-se a capacidade de implantar patches de segurança ou outros hotfixes críticos, com aviso prévio mínimo ou nenhum. Garantir que os inquilinos compreendem esta prática e a sua importância na salvaguarda dos seus dados.

Outra abordagem pode ser permitir que os locatários iniciem suas próprias atualizações durante um período que escolherem. Novamente, deverá fornecer um prazo, momento em que aplicará a atualização em nome deles.

Independentemente do que você faça, certifique-se de ter um processo para monitorar a saúde dos seus inquilinos, especialmente antes e depois que as atualizações sejam aplicadas. Incidentes críticos de produção, também conhecidos como incidentes no local ao vivo, geralmente ocorrem após alterações no código ou na configuração. Como resultado, é importante monitorar e responder proativamente a quaisquer problemas para manter a confiança do cliente. Para obter mais informações, consulte Gerenciamento de incidentes para cargas de trabalho SaaS no Azure.

Comunique-se com seus clientes

Uma comunicação clara é fundamental para construir a confiança dos seus clientes. É importante explicar os benefícios das atualizações regulares, incluindo novos recursos, correções de bugs, resolução de vulnerabilidades de segurança e melhorias de desempenho. Um dos benefícios de uma solução moderna hospedada na nuvem é a entrega contínua de recursos e atualizações.

Considere as perguntas seguintes:

• Você notificará os clientes sobre as próximas atualizações?

• Se o fizer, solicitará implicitamente permissão ao estabelecer um processo de não participação, e quais são os limites para essa não participação?

• Você tem uma janela de manutenção programada que usa quando aplica atualizações?

• O que acontece se você tiver uma atualização de emergência, como um patch de segurança crítico? Você pode forçar atualizações nessas situações?

• Se você não puder notificar proativamente o cliente sobre atualizações futuras, poderá fornecer notificações retrospetivas? Por exemplo, você pode atualizar uma página em seu site com a lista de atualizações que você aplicou?

• Quantas versões separadas do seu sistema você manterá em produção?

Comunique-se com sua equipe de suporte ao cliente

É importante que sua própria equipe de suporte tenha visibilidade total das atualizações que foram aplicadas à infraestrutura de cada locatário. Os representantes de suporte ao cliente devem ser capazes de responder facilmente às seguintes perguntas:

• As atualizações foram aplicadas recentemente à infraestrutura de um locatário ou a componentes compartilhados?

• Qual foi a natureza dessas atualizações?

• Qual era a versão anterior?

• Com que frequência as atualizações são aplicadas a este locatário?

Se um dos seus clientes tiver um problema devido a uma atualização, você precisa garantir que sua equipe de suporte ao cliente tenha as informações necessárias para entender o que mudou.

Estratégias de implantação para dar suporte a atualizações

Considere como você implanta atualizações em sua infraestrutura. Sua estratégia de atualização depende muito do modelo de locação que você usa. Três abordagens comuns para implantar atualizações são selos de implantação, sinalizadores de recursos e anéis de implantação. Você pode usar essas abordagens de forma independente ou combiná-las para atender a requisitos mais complexos.

Em todos os casos, certifique-se de que tem relatórios e visibilidade suficientes. Você precisa saber qual versão de infraestrutura, software ou recurso cada locatário usa, para o que eles estão elegíveis para migrar, e quaisquer dados temporais relacionados com esses estados. Rastrear essas informações é muitas vezes uma das responsabilidades de um plano de controlo.

Padrão de selos de implantação

Muitos aplicativos multilocatários são adequados para o padrão de Carimbos de Implantação. Nesse padrão, você implanta várias cópias do seu aplicativo e de outros componentes. Dependendo dos seus requisitos de isolamento, você pode implantar um carimbo para cada locatário ou carimbos compartilhados que executam cargas de trabalho de vários locatários.

Os selos são uma ótima maneira de proporcionar isolamento entre inquilinos. Eles também oferecem flexibilidade para seu processo de atualização, pois você pode distribuir atualizações progressivamente entre selos sem afetar outras pessoas.

Marcadores de funcionalidade

Os sinalizadores de recursos permitem que você adicione funcionalidade à sua solução, expondo essa funcionalidade apenas a um subconjunto de seus clientes ou locatários.

Considere o uso de sinalizadores de recursos se qualquer um destes cenários se aplicar a você:

• Você implanta atualizações regularmente, mas deseja evitar mostrar novas funcionalidades até que elas sejam totalmente implementadas.

• Você deseja evitar a aplicação de alterações no comportamento até que um cliente opte por participar.

Você pode incorporar o suporte ao sinalizador de recursos em seu aplicativo escrevendo código você mesmo ou usando um serviço como a Configuração de Aplicativo do Azure.

Anéis de implantação

Os anéis de implantação permitem que você distribua progressivamente atualizações em um conjunto de locatários ou carimbos de implantação. Você pode atribuir um subconjunto de locatários a cada anel na sequência de distribuição.

Você pode determinar quantos anéis criar e o que cada anel significa para sua própria solução. Comumente, as organizações usam os seguintes anéis:

• Canário: Um anel canário inclui seus próprios locatários de teste e clientes que desejam receber atualizações assim que estiverem disponíveis. Qualquer pessoa no anel canário deve entender que eles podem receber atualizações mais frequentes. Essas atualizações podem não ter passado por um processo de validação tão abrangente quanto as atualizações em outros anéis.

• Early adopter: Um anel de adoção antecipada contém inquilinos que são um pouco mais avessos ao risco, mas ainda estão preparados para receber atualizações regulares.

• Utilizadores: A maioria dos seus inquilinos pertence ao anel de utilizadores , que recebe atualizações menos frequentes e mais testadas.

Versões da API

Se o seu serviço expõe uma API externa, considere que quaisquer atualizações que você aplicar podem afetar a maneira como os clientes ou parceiros se integram à sua plataforma. Em particular, você precisa estar ciente de alterações disruptivas nas suas APIs. Considere o uso de uma estratégia de controle de versão de API para reduzir o risco de atualizações para sua API.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• John Downs | Engenheiro de Software Principal, Azure Patterns & Practices

Outros contribuidores:

• Chad Kittel | Engenheiro de Software Principal, Azure Patterns & Practices
• Daniel Scott-Raynsford | Estrategista de Tecnologia de Parceiros
• Arsen Vladimirskiy | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Recurso relacionado

• Mapear solicitações para locatários em uma solução multilocatária