? bastante curioso que, ap¨®s mais de uma d¨¦cada de experi¨ºncia com migra??o para nuvem na ind¨²stria, ainda sentimos que ¨¦ necess¨¢rio chamar aten??o para a pr¨¢tica de lift and shift para nuvem ; na qual a nuvem ¨¦ vista simplesmente como uma solu??o de hospedagem, e a arquitetura existente, pr¨¢ticas de seguran?a e modelos operacionais de TI s?o simplesmente replicados na nuvem. Isso n?o cumpre as promessas de agilidade e inova??o digital da nuvem. Uma migra??o para nuvem requer uma mudan?a intencional em v¨¢rios eixos em dire??o a um estado nativo da nuvem. Dependendo das circunst?ncias ¨²nicas da migra??o, cada organiza??o pode acabar em algum lugar do espectro: desde lift and shift at¨¦ estruturas nativas de nuvem. A arquitetura de sistemas, por exemplo, ¨¦ um dos pilares da agilidade na entrega e geralmente requer mudan?as. A tenta??o de simplesmente fazer para a nuvem pode ser forte. Embora essa t¨¢tica possa acelerar a migra??o para a nuvem, ela deixa a desejar na cria??o de agilidade e entrega de funcionalidades e valor. A seguran?a corporativa na nuvem ¨¦ fundamentalmente diferente da seguran?a tradicional baseada em per¨ªmetro por meio de firewalls e zoneamento, e exige uma jornada em dire??o ¨¤ arquitetura de confian?a zero. O modelo operacional de TI tamb¨¦m precisa ser reformulado para fornecer servi?os de nuvem com seguran?a por meio de plataformas automatizadas de autoatendimento e para capacitar os times a assumirem mais responsabilidades operacionais e ganharem autonomia. Por ¨²ltimo, mas n?o menos importante, as organiza??es devem criar uma base para permitir mudan?as cont¨ªnuas, como a cria??o de pipelines com testes cont¨ªnuos de aplica??es e infraestrutura como parte da migra??o. Isso ajudar¨¢ o processo de migra??o, resultar¨¢ em um sistema mais robusto e bem estruturado e dar¨¢ ¨¤s organiza??es uma maneira de continuar evoluindo e melhorando seus sistemas.
As more organizations are choosing to deploy applications in the cloud, we're regularly finding IT groups that are wastefully trying to replicate their existing data center management and security approaches in the cloud. This often comes in the form of firewalls, load balancers, network proxies, access control, security appliances and services that are extended into the cloud with minimal rethinking. We've seen organizations build their own orchestration APIs in front of the cloud providers to constrain the services that can be utilized by teams. In most cases these layers serve only to cripple the capability, taking away most of the intended benefits of moving to the cloud. In this edition of the Radar, we've chosen to rehighlight cloud lift and shift as a technique to avoid. Organizations should instead look more deeply at the intent of their existing security and operational controls, and look for alternative controls that work in the cloud without creating unnecessary constraints. Many of those controls will already exist for mature cloud providers, and teams that adopt the cloud can use native APIs for self-serve provisioning and operations.
As cloud adoption grows we are unfortunately seeing a trend to treat the cloud as just another hosting provider. Cloud lift and shift is unfortunately being encouraged by large vendors re-branding existing hosting offerings as "cloud." Few of these offer any real flexibility or pay-as-you-use pricing. If you think you can move to the cloud without re-architecting, you are probably not doing it right.
