Do desenvolvimento à produção de soluções distribuídas

Tecnologia e negócios sempre estiveram intimamente relacionados e, muitas vezes, é praticamente impossível distinguir um do outro. Empresas, organizações e governos se tornam cada vez mais tecnológicas; com isso, o desenvolvimento de soluções digitais precisa ser cada vez mais robusto, refinado e adequado ao seu propósito negocial.

Quando se fala sobre soluções digitais robustas, podem-se destacar duas fases: a de desenvolvimento e a de produção.

Embora as fases coexistam ao longo de quase todo ciclo de vida da solução digital, desde a ideação, ambas têm particularidades que precisam de cuidados específicos, objetivando uma solução de alta disponibilidade e confiabilidade.

A primeira, de desenvolvimento do software ou de aplicações distribuídas – um composto de vários servidores, serviços e componentes se comunicando através de protocolos em determinada rede –, demanda uma abordagem adequada desde o design até a entrega em produção.

Aplicações (ou softwares) distribuídas são desenvolvidas para atender a um elevado número de acessos de modo sazonal com a rapidez necessária, sem atrasos e que funcionem da maneira esperada: com confiabilidade.

As razões para projetar uma solução distribuída passam por disponibilidade, escalabilidade, confiabilidade e transparência. Vejamos:

· Disponibilidade: o sistema precisa estar disponível para os clientes em qualquer momento desejado. É, portanto, necessário que esteja preparado para ser imediatamente recuperado caso algum problema o torne indisponível.

· Escalabilidade: ao longo do tempo, a aplicação atenderá a um volume de uso variado. Quanto maior for o número de usuários da aplicação, maior a necessidade de aumento dos serviços utilizados pela solução.

· Confiabilidade: os usuários precisam confiar na resposta e nos dados fornecidos pelo sistema.

· Transparência: os usuários finais não precisam conhecer os detalhes técnicos que fazem toda a solução funcionar. Precisam somente usar a aplicação.

Ademais, ao se adotar um desenvolvimento de solução distribuída, alguns pontos de preocupação precisam ser observados ainda na fase de desenvolvimento, como a complexidade na solução de eventuais problemas que podem ocorrer. Para tanto, é necessário observar:

· Conhecimento do time: soluções (ou aplicações) distribuídas exigem muitas áreas de conhecimento. O time deve ter as habilidades e competências necessárias para solucionar problemas de todos os serviços usados na solução, desde o desenvolvimento até o monitoramento adequado de todos os serviços utilizados e que proporcionam o desempenho da aplicação em produção.

· Dimensionamento: quando se trata de aplicações monolíticas, a escala é bidimensional. Nessa perspectiva, uma aplicação consiste, geralmente, em um grupo de servidores de aplicação e servidores de banco de dados. Da perspectiva de aplicações distribuídas, a complexidade aumenta exponencialmente nos quesitos problemas e desempenho. Cada serviço que compõe a solução tem sua própria latência e seu próprio suporte.

· Antipadrão no design: assim como o antipadrão no código, os antipadrões no design são uma causa comum de desempenho ruim em ambientes produtivos. Além de dificultar a manutenção da solução.

Uma vez que a aplicação está minimamente desenvolvida e há uma primeira versão pronta para ser publicada em produção, é hora de pensar nas questões que englobam o todo do sistema produtivo.

Quando se fala em ambiente produtivo, a disponibilidade de serviços e aplicações é um dos pilares mais importantes para a continuidade do negócio e para a capacidade da empresa em gerar valor.

Falar sobre disponibilidade nos remete também a conceitos de engenharia de confiabilidade (também conhecido como SRE, Site Reliability Engineering). Esses conceitos e padrões de engenharia de confiabilidade têm o objetivo de aumentar a disponibilidade; o desempenho e a resiliência do produto; e, consequentemente, a satisfação do usuário.

Grandes investimentos são realizados para garantir a confiabilidade das aplicações que suportam a geração de receita para a empresa. Uma premissa indispensável para confiabilidade em ambiente distribuído é a de que falhas acontecerão inevitavelmente. Em vez de se tentar preveni-las, é desejado que se planejem e desenvolvam soluções de aplicação que atenuem seus efeitos.

Existem algumas técnicas utilizadas tanto pela equipe de desenvolvimento quanto pela a equipe de sustentação que têm como intuito atenuar os efeitos das falhas. A engenharia do caos (Chaos Engineering), por exemplo, é muito utilizada, a fim de estimular falhas em sistemas e, consequentemente, criar soluções. Assim, ela testa a resiliência dos sistemas ao conduzir experimentos que induzem a falha simulando situações reais.

Além da metodologia da engenharia do caos, em ambientes produtivos é preciso definir alguns critérios de negócio, como o Acordo de Nível de Serviço (SLA Service Layer Agreement) e Objetivo de Nível de Serviço (SLO, Service Layer Objective), juntamente com objetivos de recuperação de falhas, como Objetivo de Tempo de Recuperação (RTO, Recover Time Objective) e Objetivo de Ponto de Recuperação (RPO, Recover Point Objective).

Essas definições orientam o nível de investimento em capacidades de resiliência e disponibilidade do sistema. Um sistema extremamente crítico, com SLA e SLO elevados, requer mais investimento para a recuperação de falhas e o desenvolvimento de aplicações que respondam automaticamente a esses eventos. Essas aplicações exigem mais planejamento e desenvolvimento para que se recuperem de forma transparente, empregando conceitos como self-healing ou aplicações com capacidade de remediação automática.

Como se vê, o processo de adoção de uma nova tecnologia é longo e específico, demandando planejamento, know-how e competência de todo o time, assim como definições claras de seus objetivos de negócio e, especialmente, de investimento para garantir confiabilidade das aplicações.

* Rafael Mendonça é CTO na 4intelligence, startup de soluções que apoiam a tomada de decisão por meio da análise de dados.