Vivendo no Limite: Como chegamos aqui

Desenvolvedores e engenheiros que chegaram recentemente ao mundo da computação e dos aplicativos geralmente veem o mundo através das lentes da tecnologia mais recente, mais nova e mais brilhante do mercado. Mais frequentemente, porém, a verdade é que — assim como os amigos de infância de nós, veteranos da indústria de tecnologia — esses conceitos e implementações análogas sempre existiram. Eles simplesmente avançam ou retrocedem ao longo do tempo, à medida que os requisitos comerciais e econômicos convergem e divergem em relação às restrições de implementação e infraestruturas subjacentes. Na verdade, é o ambiente de negócios em constante evolução que impulsiona as necessidades e os requisitos, o que resulta em estratégias tecnológicas específicas que devem ser redescobertas ou deixadas de lado.

Nesse sentido, no próximo conjunto de artigos, falarei sobre algumas das tecnologias relacionadas a aplicativos cuja onda chegará nos próximos anos, especialmente à medida que evoluímos em direção a uma estrutura de entrega de aplicativos mais dispersa e ao papel emergente da borda. Mas primeiro, é útil examinar por que e como chegamos onde estamos hoje.

Etapa 1: A Era do Data Center

Vamos começar nossa jornada cerca de 20 anos atrás, em uma época em que a entrega digital de serviços empresariais (o termo "aplicativos" não estava na linguagem popular na época) era feita por data centers de propriedade e operação privada. Essa estratégia técnica era suficiente e apropriada para aquela época, em grande parte porque, naquele período, apenas as operações comerciais mais críticas eram "digitalizadas".  Alguns exemplos de operações comerciais digitais naquela época foram:

• Um varejista on-line apenas "digitalizaria" a experiência de compra do cliente e talvez o gerenciamento de estoque. 
• Uma companhia aérea apenas “digitalizaria” os sistemas de reserva e pagamento. 
• O governo "digitalizaria" fluxos de trabalho transacionais de alto valor, como pagamentos de impostos.

Dado o fato de que apenas um pequeno número de fluxos de trabalho empresariais — ou seja, os mais importantes — eram entregues digitalmente e considerados no contexto de uma organização empresarial típica naquele período (forças de trabalho verticalmente integradas e geograficamente co-localizadas com controle centralizado da organização e da infraestrutura de TI), era natural que isso fosse refletido organizacionalmente em um data center de propriedade central e gerenciado por TI, executando "aplicativos" monolíticos que eram desenvolvidos principalmente ou inteiramente internamente. Infraestrutura, segurança e aplicativos (também conhecidos como "serviços empresariais") eram uma única pilha verticalmente integrada. Assim, em um sentido muito real, a pilha de tecnologia — centralizada e monolítica — imitava as estruturas organizacionais e empresariais.

Etapa 2: A Era da Nuvem

O próximo passo na evolução dos aplicativos e seu conjunto de tecnologias foi impulsionado pela expansão da "digitalização" para fluxos de trabalho empresariais secundários. Essa próxima etapa ampliou o conjunto de fluxos de trabalho digitais para incluir não apenas fluxos de trabalho voltados para o cliente — que também se tornaram uma mercadoria, como evidenciado pela proliferação de aplicativos em lojas de aplicativos — mas também expandiu o escopo para incluir fluxos de trabalho operacionais internos à organização, frequentemente chamados de parte da tendência de transformação digital empresarial.

Consequentemente, as empresas foram forçadas a repensar suas estratégias organizacionais de negócios. Uma implicação específica foi que uma ênfase maior foi colocada na eficiência de custos e na agilidade, dado o problema empresarial de escala empresarial em rápida mudança. Isso distorceu o modelo de pagamento em direção a um modelo de precificação de serviços públicos, pagando pelo que realmente é usado, em vez de ter que pagar antecipadamente e provisionar uma carga maior possivelmente prevista. Usando terminologia financeira, o modelo de financiamento de infraestrutura de aplicativos migrou cada vez mais do modelo de CapEx inicial para a estratégia de OpEx de pagamento conforme o uso. Outra tendência simultânea no mesmo período, também relacionada à eficiência de custos e agilidade, foi o movimento em direção a uma força de trabalho mais distribuída geograficamente, o que gerou a necessidade de conectividade 24 horas por dia, 7 dias por semana, mais onipresente e confiável do que era necessário no passado.

As repercussões desses requisitos — a digitalização de um número muito maior de fluxos de trabalho de negócios, o desejo pela flexibilidade do modelo de custo OpEx e a exigência de conectividade global 24 horas por dia, 7 dias por semana — naturalmente levaram a um ambiente propício para a criação de uma rede global de data centers virtuais muito grandes e altamente disponíveis, cujo uso foi precificado como um serviço público. E assim nasceu a nuvem pública. 

Além disso, quando as sementes da nuvem pública estavam presentes, um ciclo de feedback positivo auto-reforçador foi criado. À medida que a nuvem pública amadureceu como uma plataforma de aplicativos, ela começou a absorver grande parte da infraestrutura de rede de nível inferior que antes era gerenciada pela TI empresarial tradicional. Consequentemente, o escopo das equipes de Operações de Rede diminuiu em muitas empresas, com as empresas voltando seu foco para Implantação e Entrega de Aplicativos (também conhecida como "DevOps") e Segurança de Aplicativos (também conhecida como "SecOps"). Claro, isso não era universal; provedores de serviços e grandes empresas tinham a necessidade e a capacidade de fazer NetOps internamente para seus fluxos de trabalho mais críticos ou sensíveis.

Esta história representou a primeira fase da Era da Nuvem, na qual a nuvem pública podia ser vista como uma forma de data center terceirizado, com tempo e recursos compartilhados. Em outras palavras, a abstração da nuvem pública era uma de Infraestrutura como Serviço (IaaS).

A próxima fase da Era da Nuvem foi impulsionada por dois insights empresariais emergentes diferentes, ambos exigindo o paradigma da Fase 1/IaaS como pré-requisito. A primeira dessas realizações comerciais foi possibilitada pela capacidade de isolar a entrega do valor comercial da implementação que forneceu o fluxo de trabalho digital. Mais especificamente, as empresas agora poderiam começar a imaginar uma estratégia de execução onde os níveis mais baixos da infraestrutura de tecnologia — que agora eram gerenciados como um serviço fornecido pela nuvem pública — poderiam ser dissociados das principais preocupações dos líderes empresariais, que giravam em torno da proposta de valor da empresa e dos diferenciais competitivos. 

A segunda observação empresarial foi que, à medida que mais fluxos de trabalho tradicionais se tornaram digitais e automatizados, os processos empresariais de nível superior puderam ser ajustados e otimizados em escalas de tempo muito mais curtas. Um artigo separado discute esse efeito com mais detalhes, elaborando sobre como os fluxos de trabalho digitais evoluem da simples automação de tarefas para a otimização digital (também conhecida como "expansão digital") e, eventualmente, terminam em Aumentos de Negócios Assistidos por IA. Como exemplos dessa tendência, fluxos de trabalho tão diversos quanto ajuste de preços, programação de tempo de funcionários e gerenciamento de estoque se beneficiaram da rápida adaptabilidade, e o termo "agilidade empresarial" foi cunhado. 

Essas duas percepções resultaram em uma epifania empresarial, pois as empresas perceberam que muitas vezes era mais econômico terceirizar áreas que não eram as principais competências do negócio. Isso, por sua vez, levou a um acordo comercial vantajoso para todos entre a empresa e seus parceiros provedores de nuvem, onde ambos os lados foram motivados a aprimorar ainda mais os serviços oferecidos pela nuvem pública, aliviando assim a sobrecarga tecnológica adicional da empresa. Esse conceito foi então estendido pela nuvem pública para disponibilizar recursos de plataforma de nível superior, como bancos de dados, sistemas de arquivos, gateways de API e plataformas de computação sem servidor, novamente como serviços na nuvem pública. Além disso, os provedores de nuvem pública também se ofereceram para integrar serviços over-the-top, mais comumente nas áreas de gerenciamento de desempenho e segurança.

O resultado foi que, à medida que a era da nuvem amadureceu além do modelo IaaS da Fase 1, ela deu início aos paradigmas da Fase 2 da Nuvem de Plataforma como Serviço (PaaS) e Software como Serviço (SaaS). Com a Fase 2 da Nuvem, a maior parte, se não toda, da infraestrutura necessária para dar suporte a um aplicativo poderia ser terceirizada da empresa para provedores de nuvem, que poderiam otimizar a infraestrutura em escala e trazer uma equipe maior de especialistas para se concentrar em qualquer serviço de aplicativo amplamente necessário. Embora isso tenha liberado a empresa para concentrar seu orçamento de tecnologia na lógica principal do negócio, muitas vezes causava um efeito colateral indesejável (da perspectiva da empresa) de "bloqueio" em um fornecedor de nuvem específico. Para mitigar esse efeito, as empresas se esforçaram para definir e codificar a expressão do valor de seu negócio principal usando tecnologias independentes de fornecedores, especialmente nas principais áreas de APIs e modelos de computação, e foram implementadas usando a tecnologia REST e gRPC API, apoiadas por um modelo de computação virtualizado e em contêineres — Kubernetes. 

Etapa 3: Digitalização de coisas e processos físicos

O terceiro estágio, atualmente emergente, na progressão de "aplicativos" está sendo impulsionado pela digitalização das atividades cotidianas que dificilmente consideramos fluxos de trabalho. Ao contrário dos Estágios 1 e 2, onde principalmente os processos de negócios e um pequeno conjunto de fluxos de trabalho transacionais do consumidor foram colocados online, este estágio visa criar experiências digitais que sejam onipresentes e perfeitamente integradas às nossas ações cotidianas da "vida humana". O conjunto completo de casos de uso ainda está em desenvolvimento, mas já vemos vislumbres do caminho rico e multifacetado à frente em casos de uso emergentes que alavancam tecnologias como realidade aumentada, sistemas automatizados de vigilância residencial e gerenciamento de energia em nível de rede. As soluções interagem notavelmente com o mundo físico real, muitas vezes usando dispositivos inteligentes — veículos autônomos, assistentes digitais, câmeras e toda a variedade de eletrodomésticos inteligentes. 

Da perspectiva empresarial, essa próxima transição dará uma ênfase muito maior à experiência do usuário digital. Esse foco na experiência do usuário, somado à observação de que os dispositivos, e não os humanos, constituirão a maioria dos clientes diretos do processo digital, significa que os requisitos de experiência do usuário do consumidor digital serão muito mais diversos do que eram nos estágios anteriores da evolução digital. A próxima transição, do Estágio 2 para o Estágio 3, será diferente da anterior (Estágio 1 para o Estágio 2). Especificamente, este próximo passo não será uma simples progressão extrapolada das métricas usuais de experiência digital (por exemplo, "torná-lo mais rápido e com menor latência"), mas sim dar ao "aplicativo" um conjunto muito mais amplo de opções sobre como fazer compensações na entrega do aplicativo, permitindo que a experiência seja adaptada aos requisitos do consumidor digital no contexto do caso de uso que está sendo abordado.

Da perspectiva de um tecnólogo, a implicação dos requisitos de negócios é que a maior diversidade de requisitos de experiência de consumo resultará na necessidade de construir um meio correspondentemente flexível e adaptável para compensar, especificar e otimizar métricas comuns de entrega de aplicativos: latência, largura de banda, confiabilidade e disponibilidade. Por exemplo, um sistema de experiência de realidade aumentada pode exigir latência muito baixa e alta largura de banda, mas ser mais tolerante à perda de uma pequena fração do tráfego de rede. Por outro lado, uma câmera doméstica usada em um sistema de alarme pode exigir alta largura de banda, mas tolerar latência (relativamente) maior, da ordem de segundos. Um medidor inteligente pode tolerar latência longa e baixa largura de banda, mas pode exigir altos níveis de confiabilidade eventual, se não oportuna, para que todo o uso de energia seja registrado.

O design e a arquitetura de um sistema que seja flexível e adaptável o suficiente para atender às necessidades deste próximo estágio de "digitalização" exigirão um mecanismo em que os muitos componentes que compõem a entrega de uma experiência digital possam ser facilmente dispersos e migrados quando necessário, por vários locais no caminho de entrega do aplicativo. A distribuição desses componentes de aplicativo precisará ser adaptada às necessidades de entrega — latência, largura de banda, confiabilidade — orientadas pelos requisitos de experiência do usuário, e os sistemas precisarão se adaptar continuamente conforme o ambiente e a carga mudam. Por último, mas não menos importante, as preocupações com a segurança do aplicativo — gerenciamento de identidade, proteção contra malware, detecção de violações — precisarão acompanhar perfeitamente os componentes do aplicativo conforme eles mudam no caminho de entrega do aplicativo.

Inclinando-se em direção à estrada à frente

Então, mais concretamente, o que isso significa, em relação a onde estamos hoje?  O que significa é isto:

• Primeiro, como a maioria dos consumidores de experiência digital serão outros aplicativos e serviços digitais, o papel das APIs e do gerenciamento de APIs assumirá ainda mais o centro das atenções.
• Em segundo lugar, o conjunto de locais de entrega de aplicativos que temos hoje — o data center, a nuvem e os serviços entregues pela nuvem — não será suficiente para atender às necessidades do futuro. Mais especificamente, para oferecer experiências mais ricas ao cliente, precisaremos ser capazes de entregar aspectos da experiência do aplicativo digital mais próximos do usuário final, usando tecnologias como a borda inteligente, serviços de computação e conteúdo do caminho de entrega e SDWAN no caminho de entrega. Podemos até precisar estender o caminho de entrega do aplicativo para usar tecnologias de sandbox do lado do cliente.  
• Terceiro, a borda será cada vez mais o ponto de "entrada" na entrega da experiência digital e, portanto, a borda assumirá mais importância como o principal ponto de orquestração da entrega.
• Por fim, quando se trata de segurança, ela não só deve ser inata e generalizada, como também deve ser independente de como os componentes do aplicativo são dispersos ao longo do caminho de entrega do aplicativo.

Esses três últimos tópicos serão o foco dos próximos artigos desta série, onde falaremos sobre o "Edge" e para onde ele está indo e, depois, como seria uma visão de segurança verdadeiramente independente de localização.