Racionalização de nuvem

A racionalização na nuvem é o processo de avaliação de ativos para identificar a melhor maneira de migrar ou modernizar cada ativo na nuvem. Para obter mais informações sobre o processo de racionalização, consulte O que é uma propriedade digital.

Contexto de racionalização

Os cinco Rs de racionalização listados neste artigo ajudam a identificar um estado futuro possível de cargas de trabalho consideradas candidatas na nuvem. Coloque esse processo de rotulagem no contexto correto antes de tentar racionalizar um ambiente. Para fornecer esse contexto, examine os seguintes mitos:

Mito: é fácil tomar decisões de racionalização no início do processo

Uma boa racionalização requer um profundo conhecimento da carga de trabalho e dos ativos associados, como aplicativos, infraestrutura e dados. O mais importante é que as boas decisões de racionalização levam tempo. Recomendamos que você use um processo de racionalização incremental.

Mito: a adoção da nuvem precisa aguardar que todas as cargas de trabalho sejam racionalizadas

Quando um portfólio de TI inteiro ou até mesmo um único datacenter é racionalizado, ele pode atrasar a realização do valor comercial por meses ou até anos. Evite a racionalização completa quando puder. Em vez disso, use a Abordagem da Potência de 10 para o planejamento de liberação para tomar decisões inteligentes sobre as próximas 10 cargas de trabalho destinadas à adoção da nuvem.

Mito: a justificativa comercial precisa esperar que todas as cargas de trabalho sejam racionalizadas

Para desenvolver uma justificativa comercial para um esforço de adoção de nuvem, faça algumas suposições básicas no nível do portfólio. Quando as motivações estão alinhadas à inovação, suponha a rearquitetura. Se elas estão alinhadas à migração, suponha a re-hospedagem. Essas suposições podem acelerar o processo de justificativa comercial. Durante a fase de avaliação do ciclo de adoção de cada carga de trabalho, as suposições são então desafiadas e os orçamentos são refinados.

Agora examine os cinco Rs de racionalização a seguir para se familiarizar com o processo de longo prazo. Ao desenvolver seu plano de adoção de nuvem, escolha a opção mais compatível com suas motivações, resultados de negócios e ambiente de estado atual. A meta da racionalização de propriedade digital é definir uma linha de base, e não racionalizar cada carga de trabalho.

Os cinco Rs de racionalização

Os cinco Rs de racionalização a seguir descrevem as opções mais comuns para racionalização.

Hospedar novamente

Também conhecido como migração lift-and-shift , um esforço de hospedagem move um ativo de estado atual para o provedor de nuvem escolhido com alteração mínima para a arquitetura geral.

Drivers comuns podem ser:

• Reduza gastos de capital.
• Libere espaço no datacenter.
• Obtenha rápido retorno sobre o investimento na nuvem.

Os fatores de análise quantitativa são:

• Tamanho da VM, incluindo CPU, memória e armazenamento.
• Dependências, como o tráfego de rede.
• Compatibilidade de ativos.

Os fatores de análise qualitativa são:

• Tolerância à alteração.
• Prioridades de negócios.
• Eventos comerciais críticos.
• Processar dependências.

Refatoração

As opções de PaaS (plataforma como serviço) podem reduzir os custos operacionais associados a vários aplicativos. É uma boa ideia refatorar um pouco um aplicativo para ajustá-lo a um modelo baseado em PaaS.

Refatorar também se refere ao processo de desenvolvimento de aplicativo de refatoração de código, para permitir que um aplicativo possibilite novas oportunidades de negócios.

Os motivadores comuns podem incluir:

• Atualizações mais rápidas e mais curtas.
• Portabilidade do código.
• Maior eficiência na nuvem para melhorar recursos, velocidade, custo e operações gerenciadas.

Os fatores de análise quantitativa são:

• Tamanho do ativo do aplicativo, como CPU, memória e armazenamento.
• Dependências, como o tráfego de rede.
• Tráfego do usuário, como exibições de página, hora na página e tempos de carregamento.
• Plataformas de desenvolvimento, como linguagens, plataformas de dados e serviços de camada intermediária.
• Banco de dados que inclui CPU, memória, armazenamento e versão.

Os fatores de análise qualitativa são:

• Investimentos empresariais contínuos.
• Opções de intermitência ou linhas do tempo.
• Dependências do processo empresarial.

Recriação da arquitetura

Alguns aplicativos antigos não são compatíveis com provedores de nuvem. Essa incompatibilidade é devido às decisões de arquitetura que foram tomadas quando o aplicativo foi criado. Nesses casos, o aplicativo pode precisar ser rearquitetado antes da transformação.

Em outros casos, os aplicativos que são compatíveis com a nuvem, mas que não são nativos da nuvem podem gerar eficiências de custo e operacionais ao serem rearquitetados como aplicativos nativos da nuvem.

Os motivadores comuns podem incluir:

• Agilidade e escala do aplicativo.
• Facilidade da adoção de novos recursos de nuvem.
• Combinação de pilhas de tecnologia.

Os fatores de análise quantitativa são:

• Tamanho do ativo do aplicativo, como CPU, memória e armazenamento.
• Dependências, como o tráfego de rede.
• Tráfego do usuário, como exibições de página, hora na página e tempos de carregamento.
• Plataformas de desenvolvimento, como linguagens, plataformas de dados e serviços de camada intermediária.
• Banco de dados que inclui CPU, memória, armazenamento e versão.

Os fatores de análise qualitativa são:

• Para aumentar os investimentos empresariais.
• Custos operacionais.
• Possíveis loops de comentários e investimentos de DevOps.

Recompilar

Em alguns cenários, o delta que deve ser superado para carregar um aplicativo pode ser muito grande para justificar um investimento adicional. Esse problema acontece principalmente com aplicativos que antes atendiam às necessidades de uma empresa, mas que não têm mais suporte para os processos de negócios atuais. Para resolver isso, crie uma nova base de código para se ajustar a uma abordagem nativa de nuvem.

Drivers comuns podem ser:

• Acelere a inovação.
• Crie aplicativos com mais rapidez.
• Reduza o custo operacional.

Os fatores de análise quantitativa são:

• Tamanho do ativo do aplicativo, como CPU, memória e armazenamento.
• Dependências, como o tráfego de rede.
• Tráfego do usuário, como exibições de página, hora na página e tempos de carregamento.
• Plataformas de desenvolvimento, como linguagens, plataformas de dados e serviços de camada intermediária.
• Banco de dados que inclui CPU, memória, armazenamento e versão.

Os fatores de análise qualitativa são:

• Diminuindo a satisfação do usuário final.
• Processos de negócios limitados pela funcionalidade.
• Custo potencial, experiência ou ganhos de receita.

Substitua

As soluções são normalmente implementadas usando a melhor tecnologia e abordagem disponíveis no momento. Às vezes, aplicativos SaaS (software como serviço) podem fornecer toda a funcionalidade necessária para o aplicativo hospedado. Nesses cenários, uma carga de trabalho pode ser agendada para substituição futura, o que a remove do esforço de transformação.

Os drivers comuns podem ser:

• Faça a padronização com base nas práticas recomendadas do setor.
• Acelere a adoção de abordagens orientadas a processos de negócios.
• Realoque os investimentos em desenvolvimento para os aplicativos que criam vantagens ou diferenciais com relação à concorrência.

Os fatores de análise quantitativa são:

• Reduções gerais de custo operacional.
• Tamanho da VM, incluindo CPU, memória e armazenamento.
• Dependências, como tráfego de rede.
• Ativos a serem desativados.
• Banco de dados que inclui CPU, memória, armazenamento e versão.

Os fatores de análise qualitativa são:

• Análise de custo-benefício da arquitetura atual versus uma solução de SaaS.
• Mapas de processos empresariais.
• Esquemas de dados.
• Processos personalizados ou automatizados.

Próximas etapas

Você pode aplicar esses cinco Rs de racionalização a um patrimônio digital para ajudá-lo a tomar decisões de racionalização sobre o estado futuro de cada aplicativo.