Evitando problemas, TI é o negócio

7 pontos de atenção na jornada para nuvem

novembro 4, 2017

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 1 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 possa ser garantido. Abaixo listo 7 importantes pontos para ajudar no planejamento destes projetos:

 

Segurança: definir políticas e proteger aplicações

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 que tipo de ações no ambiente são os principais problemas. Portanto, crie políticas claras de acessos e responsabilidades para cada usuário que terá acesso ao ambiente. Cada usuário 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 do time de desenvolvimento e arquitetos principalmente, as 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 exclusivamente.

 

Validação para impedir perda de informações

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 à do destino e se o tamanho total (em granularidade de bytes) é idêntico nas duas pontas, para cada um deles. Já para bancos de dados, a mesma verificação é válida e útil em primeiro momento, porém como o banco provavelmente será alterado para funcionar no novo ambiente (seja mudando para um serviço auto-gerenciado ou não), a validação da integridade e funcionamento da aplicação em si são indispensáveis, e devem ser efetuadas por pessoas com profundo conhecimento no funcionamento da mesma.

 

Legislação: verificar aderência com o negócio

A legislação coloca pé-no-freio de migrações governamentais há anos. Ela também 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 têm como garantir que eles ficarão somente na região selecionada.

Para outras aplicações, não relacionadas a 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.

 

Arquitetura

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:

 

Arquitetura: Acoplamento/Lock-in – usar serviços auto-gerenciados ou não?

Uma alternativa cada vez mais avaliada em planejamentos de projetos de software é o uso de serviços auto-gerenciados. Serviços como AWS Lambda, Amazon RDS, Google App Engine, Google Cloud Spanner, entre outros, trazem de maneira muito forte dois excelentes benefícios:

  • Mais velocidade ao time de desenvolvimento: usando o Amazon RDS como exemplo, o tempo de desenvolvimento investido para conectar uma aplicação a este serviço em vez de a um banco instalado de forma nativa em uma instância virtual, é reduzido drasticamente. Isto é possibilitado pelas funcionalidades nativas oferecidas pelo serviço. Alguns exemplos: backup automático, rápida substituição e restauração do serviço em caso de falha de hardware, replicação automática e etc. Todos estes aspectos não precisarão ser desenvolvidos pelo time do projeto, pois já estão disponíveis nativamente, e acessíveis através de simples configurações.
  • 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, permite que o custo de operação seja reduzido significativamente. 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 auto-gerenciados forem usados, maior será a dependência daquela aplicação e consequentemente o lock-in com aquele cloud provider. A empresa dona da aplicação deve ter estes estados mapeados para saber que, em uma eventual necessidade de mover a aplicação para outro local, o tempo investido será maior pois um movimento AS-IS não será possível.

 

Arquitetura: Custos – entender a aplicação e encontrar o melhor serviço para aquela necessidade de negócio

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.

Como mostrado na imagem acima, a grande 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.

Outro exemplo muito útil é a utilização de mais de uma nuvem para uma mesma aplicação ou serviço. Podemos encontrar benefícios de provisionar máquinas na AWS, através de serviços já disponíveis e que reduzem muito o tempo de desenvolvimento, e fazer com que esta aplicação consuma APIs de Machine Learning disponíveis na Google para análise de imagens. Este conceito de cloud híbrida deve ser sempre avaliado com o objetivo de encontrar o melhor resultado do trade-off entre custo e as necessidades do negócio.

 

 

Arquitetura: Telemetria – ter tudo registrado e se possível automatizado para entender onde está cada aplicação e manter rastreabilidade;

Quando as aplicações começam a crescer, e a quantidade de hardware e recursos envolvidos na operação se torna maior, a necessidade de práticas de telemetria se torna obrigatória. Por exemplo: uma aplicação que possua 10 microserviços, e cada um está distribuído em até 5 máquinas físicas, e 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 pró-ativas e reativas. Abaixo alguns exemplos:

  • Reativo: programaticamente fazer com que a aplicação detecte o problema e registre um ticket para o time de DBAs analisar;
  • Pró-ativo: programaticamente fazer com que a aplicação detecte uma falha no software e tome ações para resolvê-lo. Por exemplo: checar a saúde dos serviços que compõem um maior, e detalhar o problema até descobrir que a raiz é um banco de dados que parou de responder. Reiniciar este banco de dados, junto da criação de um registro para análise mais profunda por um humano, pode ser algo automático.
  • Reativo: registrar, em um local centralizado, todos os logs a aplicação. Desta forma, quando for necessário envolver um engenheiro de software para investigar o problema, ele acessará somente um local, e não mais cada uma das 50 instâncias.
  • Reativo: identificar que o uso de hardware de determinado serviço está além das médias regulares e alertar sobre um possível ataque.

 

Arquitetura: Latência

 

Sempre que há um movimento para nuvem, 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 microserviç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. Esta latência precisa ser trabalhada através de práticas de arquitetura, como cache, filas, etc, para prevenir que isto impacte o usuário final.

You Might Also Like

No Comments

Leave a Reply