Nos últimos anos, houve uma explosão de tecnologias e termos voltados a apoiar o novo paradigma da “sociedade digital”, que consome cada vez mais serviços sob demanda e com um alto nível de personalização.
O cliente quer ter controle sobre os próprios dados e espera que os serviços digitais facilitem diferentes situações do dia a dia pelo menor custo possível ou até gratuitamente. Ele exige rapidez, serviços de qualidade e informações em tempo real que contribuam para melhorar sua qualidade de vida.
Mas o que acontece com nossos funcionários e serviços internos de gestão? Se colocamos o cliente no centro de todos os serviços que oferecemos, em busca da tão desejada #omnicanalidade no varejo, toda a organização precisa estar preparada para responder a esse novo modelo.
A maioria dos #varejistas acredita que essas mudanças afetam apenas sua loja virtual. Por isso, acaba dedicando um esforço enorme a um serviço que, em muitos casos, representa um investimento sem retorno, pois esse canal corresponde a uma parcela muito pequena das vendas realizadas nas lojas físicas. Para que o investimento gere retorno, é essencial digitalizar a maior parte dos serviços que oferecemos aos clientes, independentemente do canal utilizado.
Para se adaptar a esse novo paradigma, tanto as tecnologias quanto as plataformas cloud evoluíram para oferecer uma variedade de serviços que permitam aos diferentes setores disponibilizar soluções para seus clientes, funcionários, fornecedores e parceiros.
A questão é quais tecnologias escolher e como garantir segurança e escalabilidade com custos reduzidos, tanto em sistemas quanto em profissionais especializados. Foi para responder a esse desafio que surgiram o conceito de #DevOps e os processos de integração e entrega contínuas (CI/CD).
É aqui que começam os termos técnicos. Não se preocupe: tentaremos “traduzi-los” para quem ainda não está familiarizado com esses conceitos.
DevOps e CI/CD (integração contínua/entrega contínua)
Simplificando bastante o conceito, o DevOps surgiu como um conjunto de práticas que reúne tarefas de desenvolvimento e operações de sistemas para acelerar a criação de novas versões das aplicações. Todo software desenvolvido é armazenado em algum lugar na forma de código-fonte. A partir desse código, são gerados os arquivos executáveis, realizados os testes e implantados os executáveis nos servidores, para que sejam utilizados em ambientes de homologação e produção.
Esses processos são conhecidos como CI (continuous integration/integração contínua) e CD (continuous delivery/entrega contínua).
Para afirmar que o DevOps está implantado, essas tarefas precisam estar totalmente automatizadas.
Implantando #microsserviços, #minisserviços, #serverless e #monolitos
Dando continuidade ao conceito de DevOps, veremos agora as principais formas pelas quais as aplicações são “entregues/implantadas” aos usuários como produto final desse processo.
Uma aplicação monolítica reúne todos os processos principais no mesmo pacote de aplicação ou arquivo executável. Normalmente, inclui a interface do usuário, a lógica de negócio e a camada de acesso ao banco de dados.
Os microsserviços são aplicações que normalmente contêm uma única funcionalidade de um processo de negócio e se conectam a outros microsserviços por meio de uma API. Incluem a lógica de negócio e, opcionalmente, a camada de acesso ao banco de dados.
Os minisserviços são aplicações que reúnem diferentes funcionalidades de um mesmo processo de negócio. Podem funcionar de forma independente ou se conectar a outros mini ou microsserviços por meio de uma API. Incluem a lógica de negócio e, opcionalmente, a camada de acesso ao banco de dados.
Os serviços com arquitetura serverless implantam pequenas funções ou processos que são executados em resposta a um evento específico, como uma solicitação a determinada URL. Isso permite que o serviço seja executado apenas sob demanda, sem que a aplicação consuma recursos enquanto estiver inativa. Dependendo da plataforma cloud utilizada, também não é necessário administrar servidores.
Amazon, Netflix e Uber já erraram ao escolher essas tecnologias. O que podemos aprender com elas?
A Amazon é uma das principais defensoras e pioneiras das tecnologias serverless e de microsserviços.
Quando a Amazon Prime Video foi criada, a empresa utilizou tecnologia serverless para atender aos clientes. À medida que a demanda cresceu, começaram a surgir gargalos devido ao grande volume de tráfego e de mudanças de estado das transações por segundo, o que provocou um aumento expressivo no consumo de recursos. Isso obrigou a empresa a migrar de uma arquitetura serverless para minisserviços, um modelo que alguns consideram muito próximo do monolítico, reduzindo em 90% o custo da plataforma. O relatório produzido pelos engenheiros concluiu que microsserviços, minisserviços e arquiteturas serverless funcionam em grande escala, mas que cada caso precisa ser analisado para definir a tecnologia mais adequada.
Algo semelhante aconteceu com a Amazon Marketplace, que reúne milhares de microsserviços. A empresa criou duas regras para tentar evitar o caos:
- A regra da “equipe de duas pizzas”. Se a equipe responsável por um microsserviço não puder ser alimentada com duas pizzas, ela é grande demais. Uma equipe com menos de dez pessoas não precisa de reuniões longas para se manter alinhada. Cada integrante sabe o que fazer e toda a equipe se torna mais produtiva.
- A regra do “você cria, você executa”. A equipe é totalmente responsável pelos serviços que cria, desde a funcionalidade até a implantação, abrangendo todo o processo de DevOps.
Em 2008, a Netflix sofreu uma interrupção que durou vários dias. A empresa migrou de um modelo monolítico para microsserviços, cerca de 700, o que permitiu aumentar a escalabilidade e reduzir os tempos de desenvolvimento e entrada em produção nos diferentes países em que opera.
A Uber também migrou de um ambiente monolítico para microsserviços e minisserviços. Nesse caso, a mudança não foi motivada por um problema de escalabilidade como nos exemplos anteriores, mas pela necessidade de lançar novos serviços no menor tempo possível. Esta foi a conclusão publicada pela equipe de engenharia da Uber em seu blog:
“Adicionar novas funcionalidades, corrigir erros e esclarecer dúvidas técnicas se tornou extremamente difícil. Era necessário ter um conhecimento profundo dos serviços antes de tentar uma única alteração. Somente os desenvolvedores que trabalhavam na Uber havia muito tempo conseguiam realizá-la.”
Como conclusão, todas essas empresas aprenderam com seus erros e optaram por uma abordagem prática. Passaram a se concentrar mais no negócio e na produtividade do que na própria tecnologia.
Precisamos acertar o alvo ou chegar o mais perto possível. É preciso mirar bem
Neste ponto, fica claro que, antes de propor uma solução integral, precisamos selecionar dois grupos de ferramentas. O primeiro deve permitir a execução do processo de DevOps, incluindo o armazenamento e o controle do código-fonte e sua entrega ou implantação. O segundo reúne as plataformas cloud e on-premises necessárias para executar e monitorar as aplicações com o menor custo e a maior escalabilidade possíveis.
Tudo isso deve ser definido antes de escrever a primeira linha de código ou até mesmo de selecionar a linguagem ou as linguagens de programação que serão utilizadas.
Os profissionais de tecnologia tendem a apostar rapidamente em uma tecnologia simplesmente porque gostam dela ou porque já a utilizaram em outro projeto. Isso pode nos fazer perder o foco e levar ao uso de tecnologias em processos para os quais elas não foram criadas. Nem toda tecnologia é adequada a todo processo de negócio. Por isso, precisamos ser mais seletivos e, acima de tudo, práticos.
Para isso, devemos avaliar um conjunto de “requisitos mínimos” para cada tecnologia sob uma perspectiva prática e de negócio, incluindo time to market, equipes disponíveis e velocidade das mudanças. Esses requisitos também precisam abranger outras áreas essenciais, como monitoramento dos serviços, escalabilidade e segurança.
Se há algo que aprendemos com os erros cometidos por Amazon, Netflix e Uber, é que o software precisa ser construído de modo que os serviços possam ser adaptados da forma mais versátil e ágil possível. Para isso, é necessário aplicar um design #composable.
Aplicação no #varejo
Composability: a chave está na modularidade e na criação de um ecossistema composable
Dividir para vencer. O #varejo possui processos de negócio claramente definidos e, por isso, eles representam nosso melhor ponto de partida. Essa deve ser a base da construção, independentemente das tecnologias utilizadas.
O primeiro passo é criar os módulos ou bibliotecas que contêm os processos e as regras de negócio. Cada módulo deve se diferenciar de acordo com seu objetivo. Pode ser um módulo que ofereça uma experiência de usuário aos clientes, por meio de customer journeys, que dê suporte a processos completos de negócio ou que forneça dados a outros processos, módulos ou bibliotecas.
O segundo passo é criar os “pacotes” por meio dos quais os serviços serão disponibilizados, por exemplo, no formato de uma #API. Neles, incluiremos um ou vários módulos ou bibliotecas de acordo com as necessidades de implantação, segurança e escopo. Um serviço visível apenas em nossa intranet exige uma segurança diferente daquela necessária para um serviço publicado na internet.
O terceiro passo é criar as aplicações que contenham um ou mais pacotes. Isso nos permite desenvolver aplicações no formato de microsserviços ou minisserviços, ou um serviço serverless com as funcionalidades necessárias. Se o caso exigir, também podemos criar uma aplicação monolítica. Em resumo, podemos adaptar componentes previamente desenvolvidos às diferentes estratégias de implantação.
Essa abordagem permite alterar a arquitetura de acordo com as necessidades, reutilizando toda a base já construída.
Já temos a receita. Agora só falta cozinhar
Para aplicar tudo o que vimos até agora, utilizaremos termos do universo da cozinha para simplificar a mensagem.
Já temos a receita, mas, para obter o prato final, podemos utilizar um robô de cozinha ou contratar um chef.
Contratar um chef, sem falar em vários, pode ser uma tarefa difícil e cara, pois esse é um perfil muito procurado. Além disso, ele terá especialização em um tipo de cozinha, que em nosso contexto representa determinadas tecnologias ou setores, que talvez não corresponda às nossas necessidades. O prato resultante da receita original pode não se parecer em nada com o que esperávamos, demorar muito para ficar pronto ou, pior ainda, ter um custo impossível de ser assumido por nossos clientes. Isso sem contar que será necessária uma equipe de profissionais especializados, como sous-chef, auxiliares e ajudantes, além de uma cozinha totalmente equipada com todos os tipos de utensílios.
Tudo se complica ainda mais se precisarmos alterar a receita durante o preparo porque o mercado assim exige. Depois de duas mudanças seguidas na receita, é bem possível que o chef jogue uma frigideira em nossa direção.
Se utilizarmos um robô de cozinha, por outro lado, obteremos um resultado uniforme com custos estáveis, independentemente do conhecimento culinário de quem o utiliza. A receita poderá ser alterada durante o processo ou um segundo robô poderá ser utilizado pelas mesmas pessoas, ou por outra equipe, para testar a nova receita antes de levá-la ao mercado.
Voltando à linguagem tecnológica, a equipe do chef pode representar um grupo de profissionais de tecnologia recém-contratados. Essa equipe tem experiência nos setores bancário, energético, de telecomunicações ou de seguros e, por isso, tentará aplicar ao varejo aquilo que já conhece. O resultado mais provável será um produto que chega tarde, não atende às necessidades do setor e apresenta custos impossíveis de sustentar.
O robô de cozinha representa uma plataforma especializada em #varejo, capaz de fornecer todas as ferramentas e todo o software necessários para que uma equipe adote, no menor tempo possível, as melhores práticas aplicáveis ao setor.
comerzzia omnichannel platform é sua receita. comerzzia cloud development platform é seu robô de cozinha
Procuramos simplificar bastante este guia e, sobretudo, a “receita”, mas é essencial considerar todos os “ingredientes necessários” e garantir que sejam da melhor qualidade.
A #comerzzia #omnichannel #platform reúne todas as aplicações e processos voltados às vendas multicanal no #varejo. A solução inclui um #framework de desenvolvimento que permite criar novos processos de negócio ou modificar processos existentes na plataforma de forma ágil e simples, reduzindo o tempo necessário para atender às novas demandas do mercado.
Esse #framework possui um core de desenvolvimento bem estruturado e definido. Esses serviços horizontais fornecem a base para os diferentes módulos:
- Segurança.
- Rastreabilidade.
- Auditoria.
- Fluxos de estados configuráveis.
- Internacionalização.
- Internacionalização de processos fiscais, documentos e impostos.
- Integrações com terceiros.
- Alta capacidade de personalização.
- Integração simples com outras soluções de software.
- Operação multi-tenant, com suporte a múltiplas instâncias e/ou atividades de negócio.
- Padrão OpenAPI para disponibilizar serviços por meio de APIs totalmente documentadas.
- Distribuição incremental de dados às lojas, incluindo catálogo, promoções e configurações.
- Processamento quase em tempo real das vendas realizadas em diferentes canais e países.
- Gestão de eventos, IoT e sistemas em tempo real.
As diferentes tecnologias utilizadas no framework foram selecionadas de acordo com um conjunto de boas práticas voltadas a alcançar a maior produtividade no menor tempo possível, levando em consideração a curva de aprendizado da equipe tanto no desenvolvimento quanto na implantação ou entrega:
- Todas as tecnologias selecionadas são amplamente utilizadas no mundo empresarial e, na maioria dos casos, fazem parte da formação básica em universidades ou instituições de educação profissional.
- O software é desenvolvido de acordo com um conjunto de boas práticas que garante o crescimento estável da solução e a possibilidade de atualizar o software-base da comerzzia para suas versões mais recentes.
- Utilização de padrões.
- As aplicações e os módulos resultantes são escaláveis e oferecem alta disponibilidade e monitoramento ágil.
- A implantação pode ser realizada automaticamente em qualquer ambiente cloud, incluindo Amazon, Google e Azure, ou on-premises, sem necessidade de modificar o software e sob o controle dos gestores do projeto.
A #comerzzia #cloud #development #platform oferece um ambiente #DevOps totalmente operacional e pré-configurado. A plataforma permite gerenciar o ciclo de vida das aplicações, desde a fase de desenvolvimento e construção até sua implantação automatizada nos ambientes de homologação e/ou produção.
Com a #comerzzia #cloud #platform, podemos disponibilizar em poucos minutos um ambiente cloud de homologação e/ou produção totalmente operacional e previamente conectado à comerzzia cloud development platform. A solução inclui o “orquestrador de serviços”, que oferece a estabilidade e a escalabilidade necessárias para cada aplicação ou serviço implantado.
Publicação do Antonio Martin Alvarez, Diretor de Arquitetura da comerzzia. Via LinkedIn
