A jornada para nuvem, assunto ainda muito atual nas áreas de TI de todas as empresas que nasceram com sistemas on-premise, pode ter diferentes níveis de complexidade. Para empresas recentes, com um número de aplicações reduzido, os projetos costumam ser mais simples. Já para empresas com grande histórico de existência, é comum que ocorram projetos de mais de um ano de duração, somente para migrar as aplicações e rotinas.
Quando se fala em modernizar as aplicações para usufruir das vantagens de estar na nuvem, este prazo é ainda maior. Em ambos os cenários, uma série de aspectos precisam ser analisados, observados e monitorados para que o sucesso seja garantido, como:
Como na maioria das invasões e ataques a sistemas, a engenharia social aplicada no contexto da cloud é a maior preocupação da maioria dos profissionais de segurança consultados. Senhas fracas e falta de cuidado ao definir as políticas de quais usuários possuem acesso a quais tipos de ações no ambiente são os principais problemas. Portanto, crie políticas claras de acessos e responsabilidades para cada usuário, que deverá deve ter permissão para fazer estritamente aquilo que lhe é atribuído. Os usuários superadmins são para uma ou duas pessoas na companhia inteira, que possuam confiança e maturidade para orquestrar todo o time.
Outro aspecto importante da segurança na cloud é a definição, junto ao time de desenvolvimento e arquitetos principalmente, das políticas de acesso às APIs da empresa. Uma API que tenha capacidade de alterar dados sensíveis da companhia deve possuir acesso, protocolos e segurança restritos à sua finalidade.
Em projetos de migração de dados, como bancos de dados, ou arquivos de quaisquer tipos, seja com finalidade de manter backup, alta disponibilidade ou performance, validações precisam ser executadas para garantir a integridade do que foi migrado e também eliminar risco de perda de grandes quantidades de informações.
Para migrações de grandes volumes, como TB de dados, é importante verificar se a quantidade de arquivos na origem é igual a do destino e se o tamanho total é idêntico nas duas pontas. Já para bancos de dados, a mesma verificação é válida e útil em um primeiro momento, porém, como provavelmente haverá alteração para funcionar no novo ambiente, as validações da integridade e funcionamento da aplicação em si são indispensáveis e devem ser efetuadas por pessoas com profundo conhecimento do funcionamento da mesma.
A legislação coloca pé no freio de migrações governamentais há anos e afeta diretamente o negócio de empresas do setor financeiro, por obrigar que os dados sejam armazenados fisicamente em território brasileiro. Mesmo com a existência de datacenters no Brasil, as migrações, às vezes, não são possíveis, pois os cloud providers mantêm replicação automática dos dados e não há como garantir que eles ficarão somente na região selecionada.
Para outras aplicações, não relacionadas ao governo e setor financeiro, o marco civil da internet garante que boa parte das empresas estejam livres destas restrições, e é um bom ponto de partida para consulta e tirar dúvidas.
Transferir aplicações do cenário on-premise para a nuvem em formato AS-IS é uma alternativa quando as restrições do negócio relacionam o tempo envolvido diretamente. Porém, simplesmente transferir a localização de um servidor não resolverá problemas relacionados à arquitetura da aplicação, tais como performance, escalabilidade, estabilidade, telemetria, etc.
Quando a jornada para nuvem começa a abranger a forma como as aplicações foram desenvolvidas, vários novos benefícios podem ser explorados, como:
Arquitetura: Acoplamento/Lock-in – usar serviços autogerenciados ou não? Serviços como AWS Lambda, Amazon RDS, Google App Engine, Google Cloud Spanner, entre outros, trazem excelentes benefícios: mais velocidade ao time de desenvolvimento; tempo de desenvolvimento investido para conectar uma aplicação a este serviço; redução de custos – a abstração criada pelos cloud providers sobre cada um destes serviços, que faz com que não seja transparente a forma como cada um deles opera. A estratégia de execução dos serviços fica a cargo do cloud provider, que usará os recursos de hardware e software da melhor maneira possível, pois detém conhecimento de todo o seu parque.
Estes e outros pontos devem ser avaliados e levados em consideração, tendo ciência de um importante trade-off: o acoplamento. Quanto mais serviços autogerenciados forem usados, maior será a dependência daquela aplicação e, consequentemente, o lock-in com aquele cloud provider.
Arquitetura: Custos – Entender o funcionamento da aplicação e definir o melhor serviço a ser usado para resolver determinado problema é uma forma de reduzir custos significativamente. Um exemplo facilmente tangível é o uso de hardware da nuvem com automatizações, disponíveis a nível de console de administrador, ou ainda via APIs que permitem alterações em nível de código, para reduzir custos com hardware daquela aplicação.
A maioria das aplicações possuem picos de consumo. A arquitetura e planejamento da aplicação permitirão a elasticidade da quantidade de hardware usado para prover as funcionalidades de acordo com a janela de tempo necessária.
Arquitetura: Telemetria – é necessária quando as aplicações começam a crescer, e a quantidade de hardware e recursos envolvidos na operação se torna maior. Por exemplo: uma aplicação que possua 10 microsserviços, e cada um está distribuído em até 5 máquinas físicas – se um problema ocorre, é inviável acessar cada uma das 50 máquinas procurando por onde aquela falha ocorreu. Para solucionar tal problema, podem ser tomadas ações proativas e reativas.
Arquitetura: Latência – sempre que há um movimento para nuvem e o assunto latência é amplamente discutido. Ela sempre existirá. Mas é necessário verificar a aderência do negócio e eventuais maneiras de impedir que a latência afete, de forma relevante, o funcionamento de sistemas:
Latência entre pedido e resposta do usuário, para migrações AS-IS: para sistemas que somente distribuem informações, a configuração de CDN pode ser a solução completa. Para sistemas que possuem situações transacionais, talvez seja necessário mantê-los em datacenters fisicamente próximos, ou ainda avaliar práticas de arquitetura;
Latência dentro da própria aplicação: caso hajam muitos microsserviços disponíveis, em muitas máquinas, bancos de dados diferentes com as informações descentralizadas, e ainda mais de uma cloud envolvida, além da latência cliente-servidor, haverá latência internamente na aplicação, que precisa ser trabalhada por meio de práticas de arquitetura, como cache, filas, etc, para prevenir que isto impacte o usuário final.
*Guilherme Sesterheim é líder de área de desenvolvimento de software na ilegra e mestre em computação aplicada
