Ah, sim. Isso está acontecendo. Considere incluir isso em sua estratégia geral de nuvem para tornar o processo menos complicado.
O que os itens a seguir têm em comum? Salmões, gansos-canadenses, borboletas-monarca e aplicações.
Se você respondeu que todas essas coisas migram de um lugar para outro, pode se dar os parabéns.
Normalmente, quando falamos em migração para a nuvem, estamos falando da transição de uma infraestrutura local para uma externa. E há bons motivos para isso. Há muitos dados (inclusive os nossos) que indicam um aumento na adoção da nuvem pública. O que quase nunca discutimos é a migração no sentido inverso. Já consigo ouvir os gritos de “Heresia!”, mas sejamos realistas: isso acontece, e com mais frequência do que você imagina.
Por exemplo:
42% dos entrevistados que adotaram uma IaaS pública em produção indicaram que “pretendem migrar da estratégia atual, seja nos próximos quatro anos ou como um processo contínuo”. Desses, 70% “previam migrar para uma nuvem híbrida em vez de adotar exclusivamente uma solução de nuvem privada”.
O motivo? O fator mais comum foi a redução de custos (67%), seguido por segurança e estabilidade. Isso é corroborado por relatos como este sobre a migração da Pubmatic da nuvem pública para a privada. Os custos foram um dos principais fatores.
Mas outros estão migrando na direção oposta, como todos nós já ouvimos. E muito. 57% dos que usam uma plataforma de IaaS privada “pretendem migrar para uma nuvem pública ou híbrida, sendo que 77% desses entrevistados indicaram que planejam adotar uma abordagem híbrida.”
A justificativa? Escalabilidade (71%), seguida de perto pela flexibilidade. Os custos ficaram em terceiro lugar, mencionados por 50% dos entrevistados.
A escalabilidade leva as pessoas à nuvem pública, enquanto os custos de longo prazo parecem trazê-las de volta para uma nuvem privada.
A realidade é que a maioria das organizações não opera exclusivamente em uma “nuvem pública” nem apenas em uma “nuvem privada”. Elas adotam uma estratégia de multicloud, mesmo depois de migrarem aplicativos de um ambiente para outro. Isso pode ser comprovado ao analisarmos as tendências de desenvolvimento, como as apresentadas pela Cap Gemini em seu relatório “Cloud Native Comes of Age” que observou que “Um sexto (15%) dos novos aplicativos das empresas dos entrevistados é desenvolvido atualmente em um ambiente nativo da nuvem.”
Agora, se 15% são nativos da nuvem, isso significa que os outros 85% não são. Isso provavelmente inclui mainframes. E aplicações cliente-servidor. E aplicações web de três camadas. Ah, e também microsserviços em ambientes conteinerizados.
A organização empresarial moderna não é apenas multicloud; ela também abrange várias gerações de arquiteturas de aplicações.
Isso significa que há uma boa chance de você migrar algum tipo de aplicativo de um ambiente local (privado) para um ambiente externo (público), ou vice-versa, pois há mais aplicativos desse tipo do que aplicativos nativos da nuvem. Portanto, é importante incorporar essa premissa à sua estratégia de nuvem. Em outras palavras, você precisa entender o que pode fazer desde o início para tornar esse processo (talvez inevitável) menos trabalhoso.
Preparação para a migração entre nuvens
Uma das primeiras coisas a considerar é a vida útil prevista do aplicativo que você está migrando. Se ele for de longo prazo, será um candidato a uma futura migração de nuvem para nuvem. Caso contrário — por ser promocional, voltado para marketing ou vinculado a um evento —, você pode ir direto para o final desta lista e fazer a implantação.
Agora que você determinou que o aplicativo terá uma vida útil mais longa, deve pensar em como vai dimensioná-lo e protegê-lo.
SEGURANÇA BARRA LATERAL DE OPINIÃO Mesmo que o aplicativo não aceite entradas nem acesse dados, ele ainda precisa de algum nível de segurança. A segurança de aplicativos é composta por várias camadas, e há plataformas e protocolos que podem deixar você vulnerável a ataques se ambos não estiverem protegidos. Ataques de manipulação de metadados (aqueles direcionados a cabeçalhos HTTP) são tão perigosos quanto as vulnerabilidades causadas por código personalizado (talvez até mais). Todos os aplicativos são críticos quando se trata de segurança. |
A resposta rápida (e fácil), se o aplicativo for nativo da nuvem, é: “usaremos os serviços do provedor de nuvem”. Essa é uma opção válida, assim como “usaremos o que sempre usamos” também é uma opção válida se o aplicativo for executado em uma nuvem privada local. No entanto, ambas as opções envolvem possíveis riscos futuros de não ser possível migrar facilmente os serviços e/ou as políticas de uma nuvem para outra. É hora de analisar com atenção o que você usa atualmente para escalabilidade e segurança e determinar se esses serviços de aplicação podem ser migrados junto com o aplicativo — nos dois sentidos.

Considerando que as empresas usam, em média, 16 serviços de aplicativos para disponibilizar e proteger seus aplicativos, essa é uma área que pode prejudicar significativamente sua capacidade de oferecer suporte a aplicativos que venham a ser migrados, quanto mais em um ambiente multinuvem. Vale observar que alguns desses 16 serviços precisarão ser nativos da nuvem. Basicamente, se você considerar que o caminho dos dados é composto por serviços de aplicativos corporativos e compartilhados, além de serviços específicos de cada aplicativo, começará a perceber que a divisão arquitetônica corresponde, em grande parte, à linha traçada pelos provedores de nuvem pública na camada de infraestrutura. Não é uma divisão perfeita, mas oferece uma separação lógica que ajuda a determinar quais serviços precisam ser “multinuvem” e para quais você pode contar com serviços nativos da nuvem ou de data centers tradicionais.
Quanto maior for a consistência dos serviços de aplicação usados nas diferentes nuvens, mais fácil será migrar entre duas delas (ou três, quatro ou mais), pois haverá menos fatores limitantes. Essa abordagem também oferece o benefício adicional de estender as iniciativas de automação à nuvem pública e, no mínimo, reduzir os custos operacionais da empresa associados à manutenção de equipes e procedimentos operacionais distintos.
A nuvem era inevitável. A multicloud também é. Isso significa que, no fim das contas, haverá migração entre elas. Estar atento às dependências e usar serviços de aplicações entre nuvens antes de tomar a decisão inicial sobre onde o aplicativo deve ser implantado pode tornar o processo menos trabalhoso.
Inclua, pelo menos, a possibilidade de migração entre nuvens em sua estratégia de nuvem de alto nível. Estar preparado pode evitar uma migração dolorosa (e cara) no futuro.
Sobre o autor

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.
Mais publicações de Lori Mac VittiePublicações relacionadas no blog

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.
Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.
As-Code: a pilha de TI contínua
Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.
O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.
DevOps Summit: onde a rede foi convidada para a festa
No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...
F5 e Nutanix convergem em infraestrutura no .NEXT
Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...