Este blog discute como a criação de uma equipe de engenharia de plataforma de nuvem (' CPE ') em sua organização acelerará o desenvolvimento de SaaS, reduzirá o desperdício organizacional e melhorará o compartilhamento de conhecimento.
Como arquiteto no grupo de engenharia de plataforma de nuvem da CyberArk , neste blog, compartilharei nossa jornada nos últimos três anos, discutirei o que fazemos, como reduzimos o desperdício organizacional (e o revertemos), os desafios que enfrentamos e como os resolvemos.
Desenvolvendo um aplicativo SaaS - Os problemas iniciais
Criar um aplicativo SaaS não é uma tarefa fácil.
Quando as organizações criam múltiplas ofertas de SaaS, várias equipes lidam com a pesquisa e o desenvolvimento. As equipes enfrentam desafios e questões semelhantes em relação aos recursos de infraestrutura de nuvem.
Como você implanta na nuvem?
Como você lida com registro e observabilidade?
Quais são as melhores práticas de segurança?
Como manter o isolamento dos inquilinos? e muito mais.
Cada aplicativo SaaS requer os mesmos recursos de infraestrutura de nuvem que o tornam pronto para produção. Esses recursos não estão relacionados a um domínio de negócios específico.
Diferentes equipes geralmente desenvolvem esses recursos de infraestrutura de nuvem simultaneamente à medida que continuam sua jornada para um aplicativo SaaS pronto para produção.
Esse desenvolvimento pode levar a múltiplas soluções, talvez até mesmo a um conjunto tecnológico diferente, tudo dentro da mesma organização, resultando em grande desperdício organizacional.
E se eu dissesse que você pode reduzir esse desperdício e transformá-lo em um catalisador de inovação, compartilhamento de conhecimento organizacional e aceleração do desenvolvimento?
O que é Cloud Platform Engineering (CPE)
Primeiro, em poucas palavras, o propósito dos grupos CPE é reduzir a carga cognitiva de outras equipes e desenvolvedores na organização, se tornar uma fonte de conhecimento e ajudá-los a se concentrar em sua lógica de negócios. Ele fornece às outras equipes na organização os serviços, SDKs, conhecimento e pilha tecnológica necessários para iniciar um novo aplicativo SaaS do zero com relativa facilidade.
Em segundo lugar, é o lugar mais emocionante para se estar em uma empresa, pois você lida com as tecnologias mais recentes, enfrenta muitos desafios e é recompensado com uma vasta influência organizacional.
Terceiro, não é um grupo DevOps. Eu diria que nos mundos SaaS/Serverless e Infraestrutura como capacidades de implantação de código, todos os desenvolvedores também são desenvolvedores DevOp que precisam definir suas funções, papéis e bancos de dados do AWS Lambda como parte de seu trabalho regular. Além disso, como você verá abaixo, o CPE cria aplicativos Serverless; alguns são voltados para o cliente externo e exigem engenheiros de software como a maioria dos aplicativos SaaS padrão.
Responsabilidades dos CPEs
O grupo CPE tem clientes internos (desenvolvedores internos de outras equipes) e clientes externos "regulares" da empresa.
As responsabilidades incluem:
Manter ambientes de produção de aplicativos SaaS externos orientados ao cliente que também podem atender equipes internas (data lakes, interface de usuário compartilhada, integração de clientes, etc.).
Mantenha ambientes de produção de aplicativos SaaS internos que fornecem valor para outras equipes. Serviços como autenticação, autorização, observabilidade e mais.
Crie bibliotecas de SDK consumidas por todos os serviços internos — isolamento de locatários, registro, sinalizadores de recursos, etc.
Forneça modelos reutilizáveis de infraestrutura como código (construções CDK etc.) que permitam que equipes internas implantem recursos de nuvem configurados com as melhores práticas de segurança.
Crie guias de melhores práticas nativas da nuvem, planos de treinamento SaaS, consultoria e orientação para novas equipes que estão começando sua jornada SaaS.
Como você pode inferir da lista acima, essas responsabilidades fornecem soluções para problemas que todo aplicativo SaaS pronto para produção exige.
Essas soluções têm UM proprietário, o grupo CPE .
Outras equipes podem se concentrar em sua lógica de negócios e acelerar seu caminho para o GA do aplicativo SaaS.
Como tudo começou para nós
A CyberArk é líder global em segurança de identidade e gerenciamento de acesso privilegiado.
Foi fundada em 1999 e emprega mais de 2.300 funcionários em todo o mundo no momento em que este artigo foi escrito.
A linha de produtos da empresa é há muito tempo uma solução local.
Houve uma mudança global para produtos baseados em SaaS nos últimos anos, e a CyberArk não é estranha a essa mudança.
Várias equipes começaram a criar produtos SaaS e aprender na prática.
Eles entregaram produtos excelentes. No entanto, como não havia um grupo CPE na época, eles construíram múltiplas soluções e infraestruturas para os mesmos problemas modernos de aplicativos SaaS.
Essas soluções causaram um aumento no desperdício organizacional e em múltiplas pilhas de tecnologia.
Algumas equipes pesquisaram o isolamento de locatários ou desenvolveram um mecanismo de sinalizadores de recursos para a função AWS Lambda.
No geral, é um desperdício, as equipes deveriam ter compartilhado melhor o conhecimento, e um proprietário deveria ter sido o dono dessas infraestruturas de nuvem sem lógica de negócios.
Entrando na área de Engenharia de Plataforma de Nuvem.
Então o grupo CPE foi criado, e eu entrei assim que pude.
Metas Iniciais
A ideia era encontrar as melhores soluções, pois toda a empresa dependeria de nós.
Nosso conjunto tecnológico consistia em funções AWS Lambda baseadas em Python e tecnologias AWS Serverless.
Além disso, desde um estágio relativamente inicial do grupo, a CyberArk decidiu que alguns membros do grupo desenvolveriam um novo aplicativo SaaS empresarial e consumiriam os serviços de CPE desde o início.
Essa abordagem ajudará o grupo de CPE a entender as reais necessidades e dificuldades de um aplicativo SaaS e ajudará a persuadir outras equipes na empresa de que há valor no trabalho do CPE e que elas devem se integrar a ele o mais rápido possível.
Por que o CPE é bom para nós (e para você!)
Hoje, quando uma equipe inicia um novo aplicativo Saas sem servidor no CyberArk, ela enfrenta vários desafios:
Uma nova linguagem de programação (geralmente vem de C++) - Python
O desenvolvimento sem servidor em nuvem e AWS é um território desconhecido
Em vez de aprender tudo sozinhos do zero, eles usam o treinamento do workshop SaaS da CPE e sua orientação ao longo do caminho.
O workshop aborda os fundamentos da AWS, o uso do SDK e dos serviços do CPE, as melhores práticas para AWS Serverless e dicas e truques do Python.
Perto do fim do workshop, a equipe cria um novo repositório GitHub para seu novo serviço a partir do modelo Serverless Application da CPE e aprende como escrever testes, implantar novo código na AWS e como depurar na nuvem. Após a conclusão, eles devem ter todas as ferramentas necessárias para começar a trabalhar na nuvem com a pilha de tecnologia da empresa e as ferramentas da CPE.
É claro que, quando surgirem dúvidas ou dilemas, a equipe pode consultar os membros do CPE.
Os membros do CPE devem fornecer ajuda e agir como defensores de suas utilidades e métodos. Caso contrário, ninguém os usaria.
Dois cliques para um novo aplicativo sem servidor
Então, o que é esse modelo mágico do CPE Serverless?
É um projeto de modelo do GitHub que você pode usar para criar seu aplicativo Serverless. No entanto, não é um modelo padrão: você obtém um projeto com uma Infraestrutura como código (CDK v2) que implementa um AWS API Gateway e várias funções do AWS Lambda que formam uma simples CRUD REST API juntas.
Além disso, os manipuladores do AWS Lambda usam todas as práticas recomendadas e SDKs de CPE, como registro, observabilidade, validação de entrada e muito mais.
Caso você tenha perdido, criei uma versão de código aberto deste projeto.
Você pode encontrá-lo aqui .
Este projeto dá à nova equipe um grande salto inicial no mundo AWS Serverless e garante que eles acertem o básico. A partir daí, eles podem se concentrar em seus requisitos de negócios e desenvolver seu aplicativo de acordo com as diretrizes do CPE.
Parece ótimo no papel, mas funciona?
Sim!
Uma equipe formada por desenvolvedores não Python que passaram por esse treinamento e usaram o modelo e conseguiram entregar um produto de forma extremamente rápida.
Em apenas quatro meses, eles conseguiram criar um novo aplicativo sem servidor e chegar aos estágios de parceiros de design, o que significa que clientes reais avaliaram seu serviço em produção.
Em uma empresa tão grande como a CyberArk, isso era inédito!
Os desafios do CPE
Os clientes da CPE são desenvolvedores internos da CyberArk e clientes externos pagantes da CyberArk. Essas duas entidades trazem uma camada extra de complexidade para a equipe da CPE e meu trabalho como Arquiteto de Sistema da CPE.
Além disso, o CPE não oferece apenas um serviço SaaS. Seu portfólio de serviços é complexo e único, pois contém vários serviços SaaS, SDKs internos e infraestrutura como recursos de código compartilhado.
A equipe do CPE enfrenta os seguintes desafios:
Crie e mantenha serviços de nível de produção. Lide com casos de clientes, bugs e erros de produção e melhore a resiliência do SaaS. Assim como qualquer equipe regular de aplicativo SaaS.
Ganhe a confiança de outras equipes na organização como um conselheiro confiável e uma fonte de conhecimento. Se ninguém usa suas ferramentas, é como se você nunca tivesse existido. Forneça valor ou desapareça.
Ajude novas equipes a entrar em produção e integrar-se aos serviços da CPE.
Fornecer excelente experiência de desenvolvedor e alta mentalidade de orientação de serviço para clientes internos e externos. No entanto, a equipe do CPE contata clientes internos, ou seja, desenvolvedores do CyberArk, com mais frequência do que clientes externos. É necessário ajudar o mais rápido possível (manter um desenvolvedor "bombeiro" pronto para problemas críticos) e estar aberto a feedback ou críticas. O trabalho do CPE é saber como manter seus clientes internos felizes. Clientes felizes usam seus produtos, e clientes insatisfeitos se ramificam e desenvolvem soluções concorrentes, contribuindo para o desperdício organizacional.
Evite se tornar um gargalo de desenvolvimento. Como todas as equipes usam os mesmos SDKs e serviços internos do CPE, muitas solicitações de recursos e bugs podem atrasar as equipes até que o CPE os lide.
Compartilhe informações e conhecimento por toda a organização de forma eficiente. Se você desenvolver um novo recurso e ninguém o estiver usando porque não o conhece, ele não terá valor para a organização.
Como superamos esses desafios
Feedback do cliente interno
Os desenvolvedores não gostam de se sentir excluídos ou que suas opiniões não são consideradas.
Feedback é a chave. Ninguém gosta de receber um monte de soluções e SDKs e ouvir que é assim que trabalhamos; lide com isso. A comunicação aqui precisa ser compartilhada, fazendo com que as opiniões das pessoas sejam ouvidas e consideradas ao projetar um novo SDK ou serviço.
Na equipe CPE, reunimos requisitos de todas as partes. Publicamos um documento de design de recurso e pedimos feedback. Garantimos que ele atenda às necessidades de todos.
Não resolvemos nossos problemas ou um problema específico de um cliente interno; produzimos soluções que toda a organização utiliza.
As soluções e discussões são escritas e documentadas no Confluence para referência futura. A documentação pode ajudar a convencer novas equipes no futuro de que o design é sólido e que o CPE levou todas as alternativas em consideração.
Coletar feedback na fase de design é uma coisa, mas é ainda mais crítico coletar feedback quando o recurso é lançado. Eu coleto feedback pedindo feedback aos meus colegas arquitetos ou enviando um questionário internamente.
Você precisa entender se os clientes estão usando suas soluções, por que eles não estão usando algumas delas e quão satisfeitos eles estão.
Mentalidade de código aberto
Começamos a tratar nossos repositórios e o código como código interno de código aberto.
É evidente que existem vários meios:
Incentivamos os desenvolvedores de toda a organização a doar código, abrir solicitações de pull e corrigir bugs que o CPE não consegue resolver rápido o suficiente. Isso requer uma nova cultura organizacional, pois os gerentes de outras equipes precisam dar tempo para que seus desenvolvedores doem código ao CPE. Isso é feito na crença de que eles ajudam toda a empresa e avançam não apenas seu serviço, mas a organização como um todo. Uma vez que o código é mesclado, ele pertence ao CPE, e cabe à equipe do CPE mantê-lo. Portanto, essas doações são coordenadas com os arquitetos e líderes de equipe do CPE.
Melhore a visibilidade das mudanças - cada repositório agora usa lançamentos do GitHub para publicar novos recursos e correções de bugs. Cada novo lançamento é transmitido nos canais da equipe feitos para atualizações de CPE.
Melhore a documentação
Você pode ter os melhores serviços e utilitários, mas ninguém os usará a menos que sejam fáceis de integrar e bem documentados. Costumávamos ter longos arquivos leia-me em nossos repositórios do GitHub ou páginas de guia espalhadas no Confluence, e era difícil para os serviços encontrarem informações. Recebemos esse feedback das equipes e fizemos uma mudança.
Criamos um hub de documentação CPE interno onde você pode encontrar links para cada site de documentação de SDK e serviço. Cada SDK/serviço tem seu site de documentação baseado em páginas do GitHub. Se você não sabe o que é documentação de páginas do GitHub, confira minha documentação de modelo Serverless aqui . É simples de navegar, tem um mecanismo de busca interno e deve oferecer uma experiência melhor do que um longo arquivo leia-me.
É importante notar que essas páginas do GitHub não substituem outras ferramentas organizacionais para compartilhamento de conhecimento (como o Confluence), mas vêm como um complemento. Cada repositório deve ter um site explicando o que ele faz, como usá-lo com exemplos de código extensivos e oferecer links para páginas de design do Confluence.
Defensores do CPE
Melhorar a experiência do desenvolvedor faz parte das minhas responsabilidades diárias como System Architect no grupo CPE. A documentação é excelente, e os lançamentos do GitHub também são fantásticos, mas no final, as pessoas tentam usar o código e podem encontrar dificuldades. Nesses casos, é essencial ter membros CPE dedicados que ajudem outras equipes a integrar os serviços CPE e SDKs.
Como você decide que algo pertence ao CPE
Se é um recurso que todo aplicativo SaaS empresarial exige, ele pertence ao CPE.
Nesta categoria, você pode encontrar registro, observabilidade, isolamento de locatários, etc.
Se houver um caso de uso compartilhado entre vários produtos/equipes, pode ser o caso de uma biblioteca/serviço compartilhado. No entanto, às vezes, a decisão é mais complexa.
Por exemplo, vários serviços exigem um mecanismo para implantar recursos em contas AWS de clientes. Cada serviço pode desenvolver e manter tal capacidade, levando a um desperdício organizacional, pois todos os serviços criam a mesma solução técnica.
Uma solução melhor seria deixar o CPE criar e manter uma capacidade que atenda a todos os requisitos dos serviços.
Para remover o CPE como um gargalo, em alguns casos, outras equipes que podem ter um cronograma mais apertado começarão a desenvolver o serviço de plataforma (com orientação de seus arquitetos). Uma vez concluído, o serviço é movido para a responsabilidade total do CPE.
Onde estamos agora
Cada novo aplicativo SaaS começa sua jornada com treinamento CPE, SDK, documentação e orientação.
O grupo CPE recebeu a 'marca de aprovação e qualidade' da organização.
Continuamos trabalhando duro para manter e conservar a confiança que a organização nos deu.
Continuamos melhorando nossa documentação e reduzindo o esforço de integração.
Continuamos aprendendo novas tecnologias e serviços da AWS e atualizamos nossas recomendações adequadamente.
Recebemos doações de código e PRs semanalmente. Solicitações de recursos e discussões geralmente se transformam em doações de código. Os doadores sabem que outras equipes se beneficiarão do trabalho deles, e a melhor parte é que eles não precisam manter o código depois que ele for mesclado.
Quando você deve iniciar um grupo CPE
Esta seção é estritamente minha opinião.
A regra geral aqui é que quanto maior a empresa, mais cedo ela precisará de um grupo de CPE, pois o desperdício organizacional fica cada vez maior.
Pequena organização/startup - Onde todos fazem tudo, pode haver apenas um produto e menos desperdício. No entanto, você pode começar um esquadrão dedicado ad-hoc que fornece um impulso na infraestrutura necessária e SDKs, que são posteriormente desmontados.
Empresa de médio/grande porte que deseja iniciar seu primeiro aplicativo SaaS - crie um CPE.
Já na nuvem, a empresa começou a desenvolver vários aplicativos SaaS por diversas equipes - para criar um CPE.
Suponha que você decida iniciar uma organização de grupo CPE; ótimo!
Preste atenção a estas conclusões finais, pois elas são as mais importantes:
Como um player crítico na organização, é crucial manter a mais alta qualidade, seja na documentação, pesquisa e implementação. Se o CPE quebrar, todos os aplicativos SaaS quebrarão também.
Feedback, feedback e feedback novamente. Faça com que todos se sintam como parceiros valorizados do CPE. Acerte o design ou ninguém vai usá-lo.
A nuvem está em constante mudança. Esteja atento a novos serviços AWS, melhorias e novos SDKs. Você pode liderar uma mudança massiva em sua empresa.
Boa sorte em seus esforços de CPE!
Para mais perguntas, sinta-se à vontade para usar o formulário de contato .
Comments