Depois do serverless, chegou a vez do codeless

Fernando Wosniak Steler * 

Publicada em 18 de junho de 2017 no site CIO 

Já faz algum tempo que o conceito “no stack startup” está virando padrão entre as empresas de tecnologia que atingem sucesso. Em vez de tentarem ser ótimas em várias coisas, as companhias passaram a apenas se concentrar no valor intrínseco que fornecem aos seus clientes, com foco na única coisa em que realmente possam se diferenciar de qualquer outra empresa no mercado.

As startups sempre estiveram repletas de engenheiros ávidos por desenvolver a próxima tecnologia. O novo padrão de mercado. Foi assim com o Google, que criou o  Google File System, cujas implementações técnicas posteriormente deram viabilidade ao Open Source HDFS ( Hadoop File System), atualmente o sistema padrão de mercado para solucionar problemas de big data e bases distribuídas. Se o Google não o fizesse, suas buscas em trilhões de registros não seriam instantâneas. Foi assim também com o Facebook, que desenvolveu um banco de dados NoSQL chamado Cassandra. Essa foi também a realidade de várias outras empresas de tecnologia, que tiveram que reescrever do zero sistemas para entregar experiências diferenciadas aos seus clientes.

Há mais de uma década, quando essas startups de tecnologia começaram, foram obrigadas a literalmente desenvolver toda a sua pilha de tecnologia, pensando em novos paradigmas de infraestrutura e desenvolvimento, pois (aquilo que existia disponível no mercado e que havia sido arquitetado pelas empresas líderes) estavam entregando péssimas experiências aos seus clientes.

As preocupações da época eram bem conhecidas:

• . Gerenciamento de infraestrutura extremamente complexa e cara;
• . Informações transmitidas em lotes ao invés de tempo real;
• . Lentidão visível aos usuários;
• . Alta complexidade no controle de acesso às aplicações;
• . Predefinições sistêmicas que dificultavam as alterações a partir de novas demandas de mercado;
• . Dimensionamento muito fragilizado;
• . Pouca segurança, disponibilidade e resiliência dos sistemas;
• . Pouco paralelismo computacional;
• . Alta complexidade na realização de testes integrados;
• . Alta dependência externa;
• . Pouco uso de APIs, etc.

Enfim, nada funcionava a contento e ainda assim tudo era complexo, lento e caro.

Há mais de uma década, se você quisesse romper com o estabelecido no mercado de tecnologia para passar a oferecer uma experiência totalmente nova e diferente na usabilidade do seu produto, você seria obrigado a contratar ótimos engenheiros que deveriam começar sua startup desenvolvendo uma infraestrutura própria, por mais que estivesse hospedada na nuvem. Por exemplo, se o seu produto tivesse a necessidade de escalar absurdamente, sua equipe teria que criar seu próprio sistema de banco de dados NoSQL. Aliás, na época, a cada nova startup que aparecia no mercado, um novo banco de dados NoSQL era anunciado: Google com LevelDB e BigTable, Facebook com Cassandra, LinkedIn com Voldemort, Twitter com FlockDB, entre vários outros exemplos conhecidos.

Naquela época era muito mais caro lançar uma startup. Boa parte dos investimentos iam diretamente para o desenvolvimento do conceito “full stack”. A nuvem era, majoritariamente, utilizada como IaaS  ( infraestrutura como serviço) e o PaaS (plataforma como serviço) ainda estava engatinhando nas empresas de tecnologia que forneciam software como serviço (SaaS).

O conceito de “no stack startup” era uma realidade bem distante dos empreendedores.

Reescreva a sua empresa

O fundador e CEO da Box, Aaron Levie, disse a seguinte frase: “Don’t rewrite your software. Rewrite your company”, em que aconselha os empreendedores a não reescreverem seus softwares, mas sim suas empresas ou as suas ideias.

Em artigo escrito no ano passado, intitulado “Software is still eating the world”, Jeetu Patel, também executivo da Box, aponta que o “tempo é tudo” em companhias de software. E continua explicando que o Uber não é um apenas um aplicativo, mas sim uma empresa, que tem como foco principal fornecer a melhor experiência possível aos seus usuários.

Ora, não é à toa que o Uber roda em infraestrutura fornecida pela AWS, para que seus funcionários não tenham que se preocupar com alta disponibilidade, resiliência e velocidade de suas aplicações. O Uber também executa a sua tecnologia de mapeamento em cima das APIs do Google Maps, para sempre mostra aos seus usuários as rotas mais rápidas e atualizadas, fornecidas por especialistas. As suas mensagens, tanto de texto quanto de voz, são fornecidas pelas APIs do Twilio, e os serviços de e-mail, para envio de recibos e avisos, rodam em cima das APIs do SendGrid, com pagamentos executados pela Braintree-PayPal, conforme a ilustração abaixo.

De acordo com Ryan McKillen, engenheiro e empregado número 3 do Uber, “nunca tive que pensar em escalar pagamentos  —  e isso deve significar que você está fazendo o seu trabalho!”.

FaaS -  Função na nuvem e a aplicação sem Servidor

Uma função ou “function” está por trás de uma arquitetura feita para rodar uma aplicação sem servidor ou “serverless”. A arquitetura serverless está no limite da fronteira da utilização eficiente da computação em nuvem, em que um pequeno pedaço do código de uma aplicação pode ser executado e gerenciado em alguma instância da nuvem como um micro serviço, utilizando um protocolo sem estado (stateless), que considera cada requisição como uma transação independente, sem a complexidade de construir e manter a infraestrutura normalmente associada. Function as a Service (FaaS) ou função como serviço é uma categoria de serviços de computação em nuvem que fornece toda essa facilidade para os desenvolvedores, por uma fração do custo conhecido.

A utilização de plataforma como serviço, que ficou amplamente popularizada por empresas como Salesforce, Heroku, AWS Elastic Beanstalk e Microsoft Azure, simplificou bastante a implementação de aplicativos e microsserviços. E a arquitetura serverless baseada em FaaS é o próximo grande passo nessa direção.

Depois do DevOps, que automatiza e facilita aos desenvolvedores a integração e a utilização de infraestrutura sob demanda, vem o NoOps, onde a infraestrutura se torna invisível e totalmente abstraída da camada de aplicação, tirando qualquer que seja a carga de gestão que os desenvolvedores ou mesmo os engenheiros de infraestrutura possuem ao gerenciar recursos computacionais da nuvem.

O que está em jogo na decisão por uma arquitetura FaaS para desenvolvimento de SaaS são os conceitos mais básicos de negócio: a busca da máxima eficiência na gestão dos recursos, ao mesmo tempo em que se diminui a estratégia de lançamento e go to market.

Chegar antes no mercado, gastando menos, é na maioria das vezes uma ótima estratégia para obtenção de vantagem competitiva frente a concorrência.

Funções e microsserviços

Parece mentira (ou mágica), que em termos práticos, uma aplicação possa funcionar sem servidores. E aí que entra a quebra de paradigma. Na verdade, o servidor existe, mas não se sabe onde, como e por que. Nesse momento, começam os questionamentos e o desapego a algumas situações de controle da infraestrutura.

Pioneiramente, em novembro de 2014, a AWS fez o seguinte release para o lançamento de uma nova funcionalidade em sua plataforma de nuvem, chamada AWS Lambda:

“AWS Lambda é um serviço de computação que executa seu código em resposta a eventos e administra automaticamente os recursos de computação para você, facilitando a criação de aplicativos que respondam rapidamente a novas informações. AWS Lambda começa a executar seu código de um evento em milissegundos, como um upload de imagem, atividade no aplicativo, clique no site ou saída de um dispositivo conectado. Você também pode usar o AWS Lambda para criar novos serviços de back-end onde os recursos de computação são ativados automaticamente com base em solicitações personalizadas. Com o Amazon Lambda, você paga apenas pelos pedidos atendidos e o tempo de computação necessário para executar seu código. O faturamento é medido em incrementos de 100 milissegundos, tornando-o econômico e de fácil dimensionamento automatizado, podendo saltar de alguns pedidos por dia para milhares por segundo.”

Desbravando uma nova forma de utilização de serviços na sua nuvem, AWS lançou o seguinte discurso de vendas: “Execute códigos sem pensar sobre os servidores. Pague apenas pelo tempo de computação que você utilizar”.

A princípio, os líderes técnicos e a comunidade de desenvolvedores torceram o nariz e não aderiram, já que a mudança de paradigma era grande e as pessoas precisavam digerir melhor aquela nova ideia. Quase dois anos depois da AWS, a Microsoft anunciou o lançamento do Azure Functions, que já estava em versão de preview desde março de 2016.

Da mesma forma que a AWS, os gerentes de produto da Azure posicionaram o serviço da seguinte forma: “Funções do Azure  —  Processe eventos com uma arquitetura de código sem servidor. Uma experiência de computação sem servidor, baseada em eventos, para acelerar seu desenvolvimento. Dimensione sob demanda e pague apenas pelos recursos que consome”.

A Microsoft, como importante player no fornecimento de cloud computing, deixou claro seu direcionamento, por meio do CEO Satya Nadella, no último Build, evento anual da empresa: “Serverless será o núcleo do futuro da computação distribuída”.

Não obstante, o Google foi pelo mesmo caminho ao anunciar modestamente em setembro de 2016 o serviço Google Cloud Functions, que ainda está em beta, dentro do Google Cloud Platform, vendendo da seguinte forma: “Google Cloud Functions: Um ambiente sem servidor para criar e conectar serviços na nuvem”.

FaaS: uma evolução dentro do PaaS

A principal diferença entre FaaS e PaaS está na abstração e na simplificação da infraestrutura. Os benefícios de computação sem servidor, baseada em functions as a service, que possibilita que as empresas abstraiam a necessidade direta de gerenciar recursos de infraestrutura, também podem ser alcançadas, em parte, na utilização de platform as a service. Na arquitetura PaaS, os serviços possuem implicações diretas na escalabilidade da aplicação, que executa continuamente pelo menos um processo de servidor, onde mesmo com a utilização de escala automática ligada, processos de execução são adicionados ou removidos, trazendo o problema e a gestão do crescimento ou do decrescimento  — conhecido na estatística como burstiness, mais visível para as equipes de desenvolvedores e infraestrutura.

Em sistemas baseados em FaaS, as chamadas de funções começam em milissegundos para permitir um tratamento individual de eventos. Já no sistema PaaS, pelo contrário, geralmente há um segmento de aplicativo que fica sendo executado por um período maior de tempo, lidando com múltiplas solicitações de eventos.

Essa diferença é principalmente visível nos custos, tanto diretos, quanto indiretos: os serviços FaaS cobram por tempo de execução da função, enquanto os serviços PaaS cobram por tempo de execução do segmento em que o aplicativo do servidor está sendo executado. No PaaS, um servidor é mais visível e precisa de cuidados e atenção. Já no FaaS, o servidor é abstraído da sua operação, tornando-se invisível.

Nova forma e seus trade-offs

De acordo com a Lei de Conway (Conway’s Law), existe uma ligação entre a estrutura organizacional de uma empresa e o software que ela cria. Muitas vezes, na arquitetura de um produto e na forma como ele é pensado por dentro, fica evidenciado como é a cultura e o organograma da empresa que o criou. Empresas mais tradicionais, inchadas e cheias de gente preocupada com o poder e pelo controle que exercem, que não abrem mão de cuidar de tudo e de todos, acabam ficando lentas, quase paralisadas e são passadas para trás. Podemos dizer que não inovam. O reflexo dessa cultura na arquitetura e no código de um software transformam suas aplicações monolíticas, que é o oposto de uma aplicação decomposta, aberta por APIs e baseada em micro serviços.

O que está em questão é a troca do controle total pela abstração da operação sem servidores. Partimos do princípio que você já superou aquela fase do questionamento se deve ou não ir para a nuvem, e claro, já foi. Mesmo assim, ainda existem alguns passos rumo a utilização eficiente do cloud computing, a saber:

Fase 1 —  VMs: Se a sua empresa usa a nuvem para rodar aplicações hospedadas em máquinas virtuais, ou seja, VMs em cima de IaaS. Você deve saber bem que a sua equipe possui todo o controle da “máquina”, porém, sabe também que o problema e as preocupações do gerenciamento da operação ficam latentes e caros. Sua equipe deverá estar presente e preocupada 24x7 com os grandes problemas de missão crítica da operação, que provavelmente não é o foco do seu negócio, e provavelmente, nem a sua especialidade.

Fase 2 —  Contêineres: Na medida em que sua empresa avança na utilização dos serviços de nuvem rumo a uma maior eficiência, você descobre que o primeiro passo é trocar suas VMs por contêineres baseados em dockers, que nada mais são do que máquinas virtuais, só que bem menores, que compartilham diversos recursos. Você vai perceber que as coisas começam a ficar um pouco mais fáceis, mais baratas e mais eficientes, porém nem tanto.

Fase 3 —  PaaS: Avançando mais um pouco, outro passo em direção na utilização eficiente dos serviços de nuvem, é passar a consumir PaaS, que é o uso de instâncias de processamento na nuvem em cima de plataforma, como os já citados Azure Cloud Services, Azure Web Sites, AWS Elastic Beanstalk, Google App Engine, Salesforce Heroku, etc. As coisas começam a ficar mais fáceis, mais baratas e mais eficientes, porém nem tanto.

Fase 4  —  FaaS: Soa estranho dizer, mas o próximo passo seria consumir “serviços como serviço na nuvem”, ou podemos dizer em consumir serviços por eventos, somente quando eles acontecem (event-driven service). Neste caso, temos que fazer uma análise de todos os seus trade-offs, a começar pelo fato de você não precisar mais de um servidor, ou que o seu servidor é a própria nuvem em si. Graças ao caráter de idempotência de uma função, não importa se você precisa fazer uma requisição ou mesmo um bilhão de requisições, o trabalho será praticamente o mesmo e os custos serão cobrados somente sob demanda. As coisas começam a ficar bem mais fáceis, bem mais baratas e bem mais eficientes.

Depois do serverless, vem o codeless

Uma empresa não nasce para desenvolver linhas de código. Ela nasce com um grande propósito, que independentemente de qual seja, em última instância, precisa gerar valor aos acionistas. A companhia precisa ter os clientes mais satisfeitos do planeta e seu foco deve estar na experiência de cada um deles.

Sabemos que um desenvolvedor ruim faz várias linhas de código para resolver um problema extremamente simples. Um bom desenvolvedor faz poucas linhas de código para desenvolver um sistema complexo. Já um ótimo desenvolvedor não faz nenhuma linha de código, pois entende que, se já existe algo pronto fora do seu foco, sendo open source ou não, vale a pena dar uma olhada antes. Claro que existirá o trabalho de implementar e integrar, mas não de refazer. E nós já sabemos disso desde a invenção da roda.

Parece óbvio, mas as empresas que estão sendo transformadas digitalmente precisam ter em seu management, especialmente para aqueles com cargo que possuem a última palavra, executivos que possam compreender questões de tecnologia. CEOs e diretores das companhias são desafiados a todo momento a repensarem a forma de fazer os negócios e, infelizmente, esta responsabilidade nem sempre pode ser delegada, afinal de contas, tecnologia e estratégia andam de mão dadas.

O problema é que, quando conseguimos colocar na prática uma arquitetura completa de micro serviços sem servidor na nuvem e passamos a entender na prática como tirar o maior proveito disso, as coisas insistem em mudar. Um exemplo bem atual: agora temos que estudar como o Blockchain vai transformar a computação em algo extremamente distribuído e descentralizado. Nem absorvemos direito uma arquitetura e já está chegando outra que pode mudar tudo.

Por isso, parafraseio aqui o fundador da Intel, Andy Grove: “O sucesso gera complacência. Complacência gera falha. Somente os paranóicos sobrevivem”. Afinal, precisamos nos atentar que a inércia frente às novas tecnologias pode levar as empresas ao fracasso. Então, tomar a dianteira o mais cedo possível é uma ótima forma de sobrevivência no mercado.

(*) Fernando Wosniak Steler é empreendedor Endeavor, fundador e CEO da Direct.One - See more at: http://cio.com.br/tecnologia/2017/06/18/depois-do-serverless-chegou-a-vez-do-codeless/#sthash.4sSmHfFy.dpuf