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, é particularmente 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 o 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.

Neste artigo, fornecemos orientações para os tomadores de decisão técnica sobre as abordagens que você pode considerar para atualizar o software de seus locatários 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. Estes podem ser-lhe formalmente comunicados 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 até mesmo autodefinidas. Eles podem precisar se comunicar com seus usuários sobre possíveis interrupções ou podem precisar 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 adicional antes que as atualizações possam ser aplicadas. Por exemplo, se você fornecer uma solução de integridade que inclua componentes de IoT, talvez seja necessário obter a aprovação da Food and Drug Administration (FDA) dos Estados Unidos antes de aplicar 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órico: 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 de quebra e quem acionaria 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? Lembre-se de que, se você encontrar um bug e precisar corrigi-lo, talvez seja necessário aplicar o hotfix a todas as versões 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 tornarão 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: sua estratégia de implantação pode suportar reversões para versões anteriores? Isso é algo que você quer habilitar?

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 é particularmente sensível a atualizações em uma sexta-feira porque esse é o dia mais movimentado da semana, você pode adiar as atualizações para segundas-feiras 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 abordagens descritas abaixo. Notifique o seu cliente das atualizações planeadas. Permitir que os clientes optem por não participar temporariamente, mas não para sempre; Coloque um limite razoável sobre quando você exigirá que a atualização seja aplicada.

Além disso, 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, no momento de sua escolha. Novamente, você deve fornecer um prazo, momento em que você aplica a atualização em seu nome.

Faça o que fizer, certifique-se de que tem um processo para monitorizar a saúde dos seus inquilinos, especialmente antes e depois de as atualizações serem aplicadas. Muitas vezes, incidentes críticos de produção (também chamados de incidentes no local ao vivo) acontecem após atualizações no código ou na configuração. Portanto, é importante que você monitore e responda proativamente a quaisquer problemas para manter a confiança do cliente. Para obter mais informações sobre monitoramento, consulte Recomendações para projetar e criar um sistema de monitoramento.

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 fornecendo um processo de opt-out, e quais são os limites para opt-out?
• 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ê implantará atualizações em sua infraestrutura. Isso é fortemente influenciado pelo 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 ter relatórios e visibilidade suficientes, para saber em que versão de infraestrutura, software ou recurso cada locatário está, para que eles estão qualificados para migrar e quaisquer dados relacionados ao tempo associados a esses estados.

Padrão de selos de implantação

Muitos aplicativos multilocatários são uma boa opção para o padrão de Carimbos de Implantação, no qual 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, porque você pode distribuir atualizações progressivamente entre selos, sem afetar outras pessoas.

Marcas de funcionalidades

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 uma destas situações 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.

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 de canário inclui seus próprios locatários de teste e clientes que desejam ter atualizações assim que estiverem disponíveis, com o entendimento de que eles podem receber atualizações mais frequentes e que as atualizações podem não ter passado por um processo de validação tão abrangente quanto nas outras coisas.
• Early adopter: Um anel de early adopter contém inquilinos que são ligeiramente mais avessos ao risco, mas que ainda estão preparados para receber atualizações regulares.
• Usuários: a maioria dos seus locatários pertencerá ao anel de usuários , 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 quebrar as alterações em 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

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• John Downs - Brasil | Engenheiro de Software Principal

Outros contribuidores:

• Chade Kittel - Brasil | Engenheiro de Software Principal
• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximo passo

Considere quando você mapearia solicitações para locatários, em uma solução multilocatário.