Como Justificar uma Arquitetura Baseada em Cloud?

Começar a usar uma nova tecnologia nunca é fácil. Além da evidente dificuldade que equipes de desenvolvimento de software enfrentam quando inserem novos "ingredientes" em suas estratégias de implementação, existem as barreiras culturais, econômicas e políticas que a decisão de trazer uma nova forma de fazer as coisas pode acarretar. Trabalhei como arquiteto de software numa grande fábrica de software durante quatro anos e meio, e este foi o período da minha vida onde aprendi bastante sobre tecnologia, mas acima de tudo, sobre como justificar o emprego de novas tecnologias nos projetos que eu estive alocado. A cada vez que começava um projeto e introduzia uma nova tecnologia, precisava desprender várias horas discutindo e convencendo meus gerentes de projeto e meus clientes sobre a decisão de uso da tecnologia. Fábricas de software são empreendimentos interessantes sobre como produzir software em larga escala, e segundo estudos do SEI documentados no livro Software Product Lines: Practices and Patterns, um ingrediente chave sobre como criar softwares em massa garantindo previsibilidade de prazos, custos e escopo, é o uso repetido e controlado de arquiteturas pré-testadas, provadas e que as equipes das fábricas tenham experiência, afinidade e agilidade.

Quando você e sua equipe decidem inserir uma nova tecnologia ou estilo arquitetural para desenvolver um novo projeto, você está, segundo a ótica de fábricas de software ou mesmo de organizações que estejam investindo na elaboração de algum software, inserindo uma chance grande de fazer com que o projeto tenha seus principais atributos de medição e qualidade (a saber, prazo, escopo e custo) comprometidos. E isso deixa-os bastante preocupados. É sempre bom, ao ser argumentado negativamente sobre suas decisões, se colocar no lugar da pessoa que o está argumentando e tentar entender suas motivações. Em grande parte dos casos, a argumentação negativa será resultado de FUD. É seu papel saber justificar o emprego de mudanças no jeito de fazer as coisas, e balancear claramente as vantagens e desvantagens dessa decisão. A introdução não comprometida de novas "complexidades" em projetos de software é um erro grave e deve, em minha opnião, ser reflexo sim de insatisfação por parte de seus gerentes, líderes ou clientes. Na visão deles, você está usando o dinheiro deles pra brincar com novas tecnologias, e isso não soa muito bem se você olhar com mais cuidado. Você deve mostrar que o uso da tecnologia possui razões responsáveis e bem pensadas, e que esteja engajado ao máximo na resolução dos requisitos do projeto.

O que fazer então nesses casos? A boa prática de arquitetura de software diz que você deve justificar suas decisões de uso de tecnologias e estilos arquiteturais baseado na avaliação minuciosa de requisitos funcionais e não-funcionais. Esses deverão ser os principais fios condutores que deverão ser usados para delinear sua arquitetura de software, conforme documentado no livro Evaluating Software Architectures: Methods and Case Studies. Jamais use uma tecnologia apenas por achá-la interessante ou porque será legal tê-la em seu currículo. Lembre-se: Alguém está pagando seu salário ou bônus para que você faça o que você está fazendo. O trabalho de elaboração de uma arquitetura de software começa com a elicitação explícita dos requisitos funcionais e não-funcionais de um projeto a ser desenvolvido. Para cada requisito elicitado, você deve associar um mecanismo de análise apropriado que resolva claramente aquele requisito. A partir deste mecanismo de análise, você deve criar ou associar um mecanismo de desenho que resolva tecnicamente o mecanismo de análise (que origianalmente apenas endereça o escopo do requisito) e, por fim, crie ou associe um mecanismo de implementação que satisfaça usando pilhas de software o que foi acordado no mecanismo de desenho. A figura abaixo, retirada do excelente artigo Capturing Architecture Requirements da IBM, mostra as relações e dependências sobre requisitos de software e suas estratégias de implementação.

Cloud Computing é uma abordagem relativamente nova (na verdade, com maior relevância e evidência nos dias de hoje) que promete resolver diversas das complexidades encontradas no desenvolvimento, implantação e execução dos softwares atuais. Mas tal como qualquer outro paradigma, estilo arquitetural ou nova tecnologia, você precisará se armar de bons argumentos na hora de justificar a sua introdução numa organização ou na elaboração de um software funcional que um cliente demande. Agora que você sabe como funciona a cabeça das pessoas que pagam seu salário para que você crie soluções usando software, e sabe também quais são as técnicas usadas em arquiteturas de software para propor mecanismos de implementação (ou seja, as tecnologias) que resolvam os requisitos de um projeto, você precisará entender quais são as vantagens e motivadores que uma arquitetura baseada em Cloud pode trazer para seus clientes e às organizações. Sem dúvida, elas são muitas, mas é necessário que você as compreenda claramente e saiba também quais são suas implicações de uso, pois como toda tecnologia, ela trás consigo diversas vantagens como também a introdução de novos problemas. Cabe à você, arquiteto de software, balancear adequadamente os pontos positivos e negativos e tomar uma sábia decisão.

Quando iniciar sua discussão sobre justificar arquiteturas baseadas em Cloud, comece realizando as perguntas abaixo. Estas perguntas deverão ser feitas para que seus stakeholders comecem a refletir sobre os benefícios (principalmente os financeiros) da abordagem. Depois disso, comece a discorrer como a arquitetura baseada em Cloud irá endereçar seus requisitos funcionais e não-funcionais.

Pergunta 1: Como você lida com o aumento da capacidade e necessidade de mais hardware?

Capacity planning é sem dúvida um assunto muito importante na arquitetura de qualquer sistema que depende de recursos de hardware. Mas quando você prefere utilizar seu próprio hardware para rodar suas aplicações, você passa a enfrentar dois problemas clássicos. Primeiro, o que acontece se você estimar pra mais ou pra menos a quantidade de hardware necessária para acomodar seu sistema? Isso pode implicar em perda de capital ou em insuficiência de recursos para execução do sistema. Outro ponto importante é sobre a previsão de orçamento para hardware. E se você não tiver recursos monetários suficientes para comprar novo hardware e servidores assim que eles se fizerem necessários?

Quando você resolve usar sua própria infraestrutura de hardware, você deve ter capital em caixa para poder adquirir cada novo Storage Area Network (SAN) ou cada novo servidor que você precisar. E o ponto é, você nunca vai saber exatamente quando isso vai acontecer, pois isso é algo ditado pela velocidade e temperatura do seu negócio. Além disso, mesmo que você tenha capital para compra de novos recursos, você precisará de um tempo para poder tornar tais recursos operacionais dentro de sua infraestrutura, afinal de contas, o recurso precisa ser instalado, configurado e suas aplicações precisam ser instaladas ou configuradas pra ele.

Pergunta 2: O que acontece quando ocorre um problema em sua infraestrutura?

Uma prática comum utilizada ao longos dos anos é a redundância de servidores. Todo bom servidor possui uma cópia escrava que é utilizada em casos onde o servidor principal apresenta problemas. Mas o servidor é uma grande caixa que possui outros recursos internos dentro. Se um destes recursos falha, como por exemplo, um dos discos de um array RAID, você precisará de alguem técnico para poder fazer a troca do disco defeituoso por um novo. E este técnico (recurso humano) possui um custo mensal. Claro, existem hoje infraestruturas inteligentes que fazem esse tipo de coisa automática, robôs inteiros que podem substituir estes recursos humanos, mas isso implica em um custo atualmente muito alto. E pra quê ter esse tipo de automação quando você nunca vai saber quando eles serão realmente utilizados. Você pode usufruir deste alto investimento apenas uma vez no ano.

Pergunta 3: O que acontece quando ocorre um desastre?

Se um servidor inteiro falha, a não ser que você tenha uma infraestrututura de alta-disponibilidade, você acabará com um desastre em mãos e seu time deverá correr para se recuperar daquele desastre. Com muita sorte, se você estiver com seus backups em dia, você poderá sua infraestrutura pronta e operacional o mais rápido possível. Porém este processo é quase certo que seja 100% manual, e, portanto, levará um certo tempo. Além disso, a cobertura de incidentes como desastres de servidores pode acarretar em custos altos com mão de obra e horas extras dos seus técnicos em plantões. Estes custos indiretos também devem ser considerados quando você preferir gerir sua própria infraestrutura.

Pergunta 4: E quando você não precisar mais de um servidor?

Pode ser que mesmo que você tenha acertado a mão no seu capacity planning e investido nos recursos certos necessários para uma dada carga e demanda, você não tenha essa carga e demanda, pois, mais uma vez, isso depende da velocidade e temperatura do seu negócio. Neste caso, você poderá acabar com servidores que estarão inutilizados. Mesmo que você doe os servidores para servidor à outras aplicações, esses servidores precisarão de um tempo até serem preparados para novo uso, implicando portanto no aumento do tempo de preparação dos servidores. Pior ainda, se você não tiver onde usar aquele grupo de servidores, você terá um conjunto de capital investido e parado dentro da sua organização, tornado-a portanto, ineficiente e cara quanto a utilização de seus recursos capitais.

Pergunta 5: E quanto ao gerenciamento e uso de energia elétrica?

Quando você prefere utilizar sua própria infraestrutura (ou que você tenha um ou mais racks dentro de um data center), você poderá estar tendo um custo com eletricidade que efetivamente não reflete as reais necessidades. Em grande parte das vezes, você pode estar tendo um custo com eletricidade que poderia ser muito mais otimizado se você tivesse seus servidores virtualizados e utilizados sob demanda, ou seja, somente na hora em que estes fossem utilizados.

Faça-os pensar sobre como lidar positivamente com as situações usando Cloud

Usando arquiteturas baseadas em Cloud, você pode adicionar maior capacidade em sua infraestrutura a medida que você precisar, quando você precisar, e não, antes que você realmente precise. Neste caso, você não precisa de capital associado a recursos de hardware. Você não precisará planejar orçamento para infraestrutura de aplicações, uma vez que os recursos em uma arquitetura baseada em Cloud são utilizados sob demanda, assim que eles se tornam necessários. Quando eles não são mais necessários, os recursos não serão mais cobrados, e você não precisará lidar com situações de capital parado ou recursos inutilizados. Acima de tudo, você terá sempre os recursos no momento que você precisar, em questão de minutos e não horas.

Outro ponto muito importante sobre arquiteturas baseadas em Cloud é que, você nunca precisará se preocupar com que tipo de plataforma ou sistema que sustenta sua infraestrutura. Você não precisa saber a marca do storage, a versão do sistema operacional, o tipo de gerenciamento de disco utilizado, e com isso, você também não precisara ter times capacitados em determinadas tecnologias. Na verdade, você não precisará ter times capacitados nem presentes, pois este custo com pessoas será de responsabilidade do provedor do seu Cloud. E mesmo que você seja seu próprio provedor (No caso de optar por Cloud's privadas), isso pode ser perfeitamente terceirizado por uma empresa parceira ou um departamento isolado.

Licensiamento de softwares também costuma ser outro ponto positivo com arquiteturas baseadas em Cloud. Ao invés de ter que ter contratos de licenças ou subscrições de software, você pode apenas usar seu cartão de crédito corporativo e comprar o serviço do software a medida que você precisar. Isso se torna mais atraente ainda quando você precisa atualizar seu software. E quando sair novas versões, você precisa ter contratos de manutenção ativos pra isso? Utilizado o software como um serviço (SaaS), você embute este custo de atualização em seu investimento.

Finalmente, é importante considerar as implicações financeiras do uso de arquiteturas baseadas em Cloud. Esta na verdade é a meu ver o maior ponto positivo do Cloud Computing. A abordagem "Pagar a medida que você utilizar" é realmente bem atraente para qualquer organização que deseja escalar seu negócio a patamares mais ousados e nunca vislumbrados. Financeiramente falando, arquiteturas baseadas em Cloud permite que você tenha menos gastos com CAPEX, sigla em inglês para Capital Expenditures ou simplesmente, despesas de capital.

Despesas de capital é todo investimento financeiro que você faz antes mesmo que esse investimento entre em operação. Se você compra um servidor, isso é uma despesa de capital pois você deve pagar adiantado e ter os benefícios deste investimento em um tempo que vai de dois a três anos. Pegue o exemplo da compra de um servidor que custa R$ 50.000,00 e gasta R$ 4.000,00 para configurar e colocar este servidor em operação. R$ 50.000,00 é uma despesa de capital e R$ 4.000,00 é o custo sob demanda. Do ponto de vista contábil, R$ 50.000,00 é um valor que sai de uma conta com ativo a uma outra conta de ativo, ou seja, você está movendo capital que representa apenas ativos fixos. Da mesma forma, contábilmente falando, R$ 4.000,00 é um valor que representa um investimento direto em sua rentabilidade financeira, não sendo considerado portanto, um ativo. Neste caso, o servidor, do ponto de vista contábil, é um ativo depreciável. O que isso significa? Que a medida que esse servidor é utilizado, ele perde seu valor original (Ele não vai mais custar R$ 50.000,00) e tende a ser um fardo financeiro.

Num próximo artigo, irei explorar as implicações técnicas de se investir em arquiteturas baseadas em Cloud, em especial, sobre como desenvolver aplicações que estejam prontas para Cloud. Até mais!