Depois do serverless, chegou a vez do codeless

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 24×7 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