Es algo curioso, que luego de una d¨¦cada de experiencia de la industria con migraciones a la nube, que siga siendo necesario manifestarse frente a la idea de simplemente trasladarse (lift-and-shift) a la nube; donde la nube es vista simplemente como una soluci¨®n de alojamiento, y la arquitectura existente, las pr¨¢cticas de seguridad, los modelos de tecnolog¨ªa son simplemente replicados en la nube. Esto no cumple con las promesas de agilismo e innovaci¨®n digital. Una verdadera migraci¨®n a la nube requiere cambios intencionales en m¨²ltiples ejes para alcanzar un estado nativo de la nube, y dependiendo de circunstancias espec¨ªficas de los procesos de migraci¨®n, cada organizaci¨®n puede terminar en alg¨²n lugar en el espectro entre ¡°traslado a la nube¡± y ¡°nativo en la nube¡±. La arquitectura de sistemas, por ejemplo, es uno de los pilares de la entrega ¨¢gil y a menudo requiere ser cambiada. La tentaci¨®n de simplemente puede ser muy fuerte. A¨²n cuando esta estrategia puede acelerar la migraci¨®n a la nube, se queda corta cuando se trata de crear agilismo y entregar funcionalidades y valor. La seguridad empresarial en la nube es fundamentalmente diferente a la tradicional (seguridad basada en per¨ªmetros, t¨ªpicamente compuesta de zonas y cortafuegos) y exige una transici¨®n hac¨ªa arquitecturas de cero confianza. Los modelos operacionales de tecnolog¨ªa tienen que ser renovados para proveer con seguridad servicios en la nube a trav¨¦s de plataformas de autoservicio automatizadas y empoderar a los equipos a tomar m¨¢s de las responsabilidades operacionales y ganar autonom¨ªa. Y ¨²ltimo, pero no menos importante, las organizaciones deben construir las bases para habilitar cambios continuos, tales como pipelines con pruebas continuas a las aplicaciones e infraestructuras como parte de la migraci¨®n. Esto ayudar¨¢ al proceso y tendr¨¢ como resultado un sistema m¨¢s robusto y mejor estructurado, y dar¨¢ a las organizaciones una forma para continuar evolucionando y mejorando sus 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.
