O crescimento da microservice adoção causou um ressurgimento na popularidade de alguns anteriormente negligenciada, padrões de design de software. Muitos desses padrões foram extraídos do projeto de domínio de Eric Evans, um livro que é tanto sobre a estrutura de equipe quanto sobre arquitetura de software.

E destes padrões, o contexto limitado é talvez o mais importante de entender. Como engenheiros, temos vindo a considerar o contexto limitado como um padrão de design de arquitetura de software. Mas isso é porque nós cooptamos um pouco de seu uso original. Como usado por Evans, o contexto limitado é tanto um padrão organizacional como um padrão técnico.

é por isso que eu vim a ver o padrão de contexto limitado como uma chave na compreensão de micro-serviços. Não apenas como construí-los, mas realmente por que os construímos em primeiro lugar, e como eles podem fazer nossas organizações mais bem sucedidas. Se compreendermos o que são os contextos limitados – se adoptarmos a mentalidade de contexto limitado, tanto técnica como organizacionalmente-então poderemos ser verdadeiramente bem sucedidos na construção da nossa arquitectura de micro-serviços.porquê mudar para os micro-serviços?para começar, vamos fazer um pouco de exercício. Faça a si mesmo esta pergunta: Porque é que construímos micro-serviços, em primeiro lugar?Pense um pouco. Quais são os benefícios que primeiro vêm à mente? Quais são os principais problemas que devemos esperar resolver? Anota algumas respostas, só para te manteres honesto.tem a sua resposta? Bom. Lê-o para ti. Atingiste os benefícios técnicos normais? Entrega contínua, escalabilidade, ambientes poliglotas, contentores e nuvens, e todas essas coisas boas? Grande.

mas a sua resposta de topo incluía alguma coisa sobre permitir que a sua organização operasse de forma mais eficiente? Devia. Porque construir micro-serviços não é sobre realizar benefícios técnicos. Na verdade, trata-se de ganhar benefícios organizacionais. Tudo o resto é um detalhe de implementação.

monólitos = código acoplado e equipas acopladas

à medida que os nossos monólitos crescem cada vez mais, a produtividade começa a diminuir. Há pelo menos duas razões principais para isso.em primeiro lugar, cada equipa de engenharia está a contribuir para uma base de dados gigante. Como tal, as equipas enfrentam uma probabilidade cada vez maior de que o seu código vai entrar em conflito com o código dos outros. Para ajudar a mitigar as potenciais questões que isso poderia causar, nós instituímos procedimentos – o código congela, períodos de teste de QA, soltar trens, etc. – que foram concebidos para abrandar a nossa produtividade.

é claro, estes procedimentos impedem que as características e melhorias sejam implantadas em tempo útil. Eles também causam estragos na capacidade dos engenheiros de se concentrar nas prioridades de suas equipes. Se um bug é encontrado durante um período de teste, a equipe responsável deve mudar de contexto e se concentrar em resolver esse bug. Se um bug grave é encontrado na produção, a equipe tem que não só corrigir o bug, mas também saltar através de aros para obtê-lo implantado pelo próximo trem de lançamento.

O dever de permanência torna-se um boondoggle. Se algo correr mal com o nosso monólito, alguém precisa de estar disponível — dia ou noite — para resolver o problema. Mas quem? Grandes organizações com grandes monólitos são geralmente confrontadas com duas escolhas:

• uma equipe de gerenciamento de incidentes cuja única, triste, triste tarefa dentro da organização é responder a problemas causados pelo código de outros engenheiros, e descobrir como resolvê-los.
• um horário rotativo de permanência, em que a cada semana algum engenheiro arbitrário é atribuído o triste, triste trabalho de se tornar responsável por resolver problemas que são mais provavelmente causados pelo código escrito por algum outro engenheiro, em alguma outra equipe de engenharia.

(Mis)organizando as nossas equipas

os monólitos mexem com as nossas organizações de outra forma. Toda a nossa organização está a trabalhar no mesmo Grande Produto. Mas ainda precisamos de dividir a organização em equipas geríveis. Então nós tendemos a procurar papéis funcionais para encontrar limites de equipe:

Infelizmente, este tipo de estrutura organizacional limites do trabalho colaborativo. Em vez de trabalharmos juntos para resolver o verdadeiro problema em mãos (por exemplo, como projetamos, construímos e mantemos o recurso X? os membros das diferentes áreas funcionais simplesmente se concentram em sua própria parte, metaforicamente atirando seu trabalho por cima da cerca quando terminam. O potencial de colaboração e sinergia — onde a qualidade combinada do esforço da equipe é muito mais do que a soma dos membros individuais da equipe — está perdido.

também está repleta de estrangulamentos. Quando organizarmos as nossas equipas por área funcional, teremos naturalmente um desalinhamento de prioridades. Digamos que a equipa de gestão de produtos decidiu que o processo de saída da monolith tem de ser renovado. Eles vão marcar tempo com a equipa de design para juntar algumas piadas. Em algum momento, as piadas serão terminadas e entregues à equipe frontend para implementar. Claro que a equipa frontend vai precisar que as APIs sejam implementadas pela equipa backend, por isso vão ser bloqueadas até isso estar concluído. Uma vez que a equipe de backend prioriza seu trabalho nos novos serviços de checkout, ela descobre que precisa de ajuda da equipe de Administração de banco de dados (DBA). Que, é claro, tem as suas próprias prioridades. Então a equipa de infra-estrutura será bloqueada até que um DBA seja libertado.

Em uma forma, essa estrutura organizacional parece um pouco como um mal projetado, excessivamente juntamente arquitetura de software… não é?Microservices = código dissociado, equipes dissociadas

por contraste, uma arquitetura de microservices permite a autonomia da equipe. Torna-se muito mais fácil formar equipas que são auto-suficientes, que trabalham eficientemente em conjunto, e que não são constantemente bloqueadas por dependências de outras equipas.as equipas podem assumir plenamente o seu trabalho, desde o design até ao desenvolvimento até à implantação. Cada membro compartilha a responsabilidade de alcançar o objetivo de sua equipe, então eles se tornam incentivados a participar em mais do que apenas “sua parte”. Eu trabalhei com equipes onde gerentes de produtos, designers, front-end, back-end e engenheiros móveis se reuniram para projetar recursos de produtos, produzindo resultados muito melhores do que poderiam ter sido alcançados por uma pessoa.

A equipe ganha responsabilidade por seus próprios artefatos, uma vez que eles são implantados na produção. Isso geralmente leva a um código de maior qualidade que é mais fácil de resolver problemas. Porquê? Ao contrário de um monólito, as equipes tendem a ter uma visão holística dos micro-serviços que possuem. Por isso, é muito mais fácil para a equipa antecipar problemas, adicionar bons registos e métricas para resolver problemas quando ocorrem, e fazer o uso adequado de padrões de resiliência (por exemplo, repetições, disjuntores e fallbacks, etc) para ajudar a evitar problemas em primeiro lugar.além disso, uma vez que as equipas têm um sentido pleno de propriedade sobre o seu trabalho, Manter os seus serviços saudáveis e em funcionamento na produção torna-se menos sobre um calendário de lançamento noturno, e mais sobre nutrir a sua criação.

finalmente, as equipes estão trabalhando para o mesmo objetivo, na mesma linha do tempo. Isso significa que não se bloqueia mais uma pessoa à espera que alguém de outra área funcional se liberte.

nós precisamos ser intencionais sobre autonomia

mas nós não obtemos esses benefícios gratuitamente simplesmente quebrando o nosso monólito em microservices. Vamos dar uma olhada em nossa primeira, ingênua visão de um microservices arquitetura:

Se nós somos como a maioria dos engenheiros, a nossa ideia inicial de uma microservice arquitetura é, bem, um monte de microservices. Cada um expõe algum tipo de API (descanso, talvez) para permitir que qualquer outro serviço para ler a partir dele e escrever para ele.à medida que ganhamos experiência, aprendemos que nem todos os micro — serviços servem o mesmo propósito-ou, pelo menos, não deveriam. E, portanto, muito parecido com o nosso monólito tinham sido dispostos em camadas, de modo que nós fazemos a nossa microservices:

neste ponto, definimos os diferentes tipos de microservices e aplicações que queremos construir. Grande. Mas ainda não fizemos grandes progressos em termos de autonomia da equipa. Cada microservice terá de ser propriedade de alguma equipa. Assim, coloca-se a questão: Quais são as equipas que vão possuir os micro-serviços?

equipes funcionais

a Nossa primeira, ingênua abordagem poderia ser a de organizar as nossas equipas imitando o nosso monólito estrutura organizacional:

Aqui, vemos equipes (em roxo) organizado pela função: UX design, frontend de engenharia, de back-end de engenharia, os dados de engenheiros, DBAs, controle de qualidade, etc.

isto pode parecer certo, pelo menos inicialmente. Mas vamos dar um passo atrás e olhar para o valor que estamos tentando entregar aos nossos clientes. É nosso objetivo construir coisas como o seguinte para os nossos clientes?

• um grupo de esquemas de bases de dados
• um grupo de modelos de interface de utilizador
• um grupo de micro-serviços que podem falar com uma base de dados MySQL?

nem por isso. Essas são apenas as ferramentas pelas quais usamos para criar valor para nossos clientes. O valor real que nós fornecemos aos nossos clientes / usuários vem na forma de recursos e funcionalidade, tais como:um catálogo de produtos para pesquisar um mecanismo para colocar itens em um carrinho de compras e posteriormente comprá-los um sistema de notificação para alertar os clientes sobre o estado de suas compras.da mesma forma, não queremos organizar nossa equipe por área funcional. Em vez disso, devemos definir as nossas equipas pelo valor que elas criam para os clientes, ou seja, em todas as funções, em (devidamente designadas) equipas multifuncionais.

com equipas funcionais cruzadas, todos estão a trabalhar em conjunto para construir um produto ou recurso específico, do início ao fim. Todos na equipe têm os mesmos objetivos e prioridades, por isso nenhuma área funcional é bloqueada por outra. O novo serviço de API da infra-estrutura necessita de algum trabalho de desenho de bases de dados? Muito bem, o engenheiro de apoio da equipa e a DBA podem dar prioridade ao seu trabalho em conjunto.no seu melhor, as equipas inter-funcionais incentivam os membros a colaborar ao longo de cada fase do projecto. Cada membro da equipe contribui para a concepção geral da característica. Frontend, backend e engenheiros móveis definem conjuntamente contratos API. Todos fazem testes. E todo mundo começa a se tornar bem versado em seu domínio particular.

E então, a nossa equipa de estruturas pode começar a procurar algo parecido com isto:

o Que é melhor. Mas algo ainda não está certo.

Claro, nós formamos equipes que provavelmente serão mais eficazes na posse de produtos. Mas ainda temos uma abordagem de cima para baixo para identificar a topologia dos micro-serviços que a nossa organização pretende construir. Ficamos com uma grande coleção de micro-serviços interdependentes, a maioria dos quais estão juntos. Atribuímo-los a equipas diferentes para construir.

isto leva a preocupações como:

• Como podemos criar APIs que irão satisfazer todas as necessidades actuais e futuras que qualquer cliente possa ter? Podemos encapsular nossos dados quando algum dos nossos serviços pode ser chamado por qualquer outro serviço de equipe?quanto tempo vamos perder à espera que outras equipas implementem as nossas dependências?que falhas dos nossos sistemas podem ser causadas por falhas noutros sistemas (falhas em cascata)?podemos controlar o número de chamadas em que os nossos serviços estão envolvidos? Podemos garantir que nossa organização não acaba criando chamadas infinitamente sincronizadas entre Serviços, levando a tempos de resposta astronômica, ou pior (e sim, eu vi isso acontecer) chamadas infinitamente recursivas através de serviços?e se a característica específica da nossa equipa ou o espaço de problemas não forem adequados para a topologia de micro-serviços pré-planeada?

precisamos ainda de uma maneira diferente de pensar. Talvez já exista um padrão para seguirmos?

Enter the Bounded Context

The Bounded Context is a key design pattern borne out of domain driven design, or DDD. Compreender o contexto limitado ajuda-nos a formar equipas autónomas e, por extensão, arquitecturas de micro-serviços autónomas.

DDD em si descreve uma metodologia de desenvolvimento de software em que indivíduos dentro de uma organização trabalham juntos para definir uma linguagem comum. Em seu livro Design impulsionado domínio, Eric Evans frequentemente retrata engenheiros trabalhando com proprietários de produtos para estabelecer um vocabulário acordado para descrever coisas como produtos, componentes dos produtos, ações que um produto pode realizar (ou pode ser realizado no produto), Partes de fluxos de trabalho, etc. Este vocabulário engloba o domínio da organização.

em muitas grandes organizações, no entanto, a definição de um vocabulário único e consistente torna-se inviável. Nestes casos, dividimos o nosso domínio em subdomínios. Exemplos de subdomínios podem incluir:

• gerenciamento de Inventário
• descoberta Produto
• Order management
• carrinhos de Compras e checkout

Como designers, engenheiros, gerentes de produto, etc, se reúnem para criar um subdomínio, eles formam a sua própria maneira de pensar e de falar sobre o subdomínio e seus componentes.

é aqui que a DDD se encontra com a estrutura de equipa multifuncional. Embora os membros da equipe sejam de diferentes áreas funcionais, eles são responsáveis por seu próprio subdomínio, eventualmente se tornam especialistas residentes. Além disso, a equipe é responsável por determinar quais artefatos — micro — serviços, aplicações web, aplicativos móveis, bancos de dados e infraestrutura relacionada-são necessários para trazer o subdomínio à vida, e aos clientes da organização.

podemos pensar na equipe e seus artefatos como compreendendo um contexto limitado.

definindo o contexto limitado

enquanto Evans discute os contextos limitados frequentemente em seu livro, ele realmente não define o padrão explicitamente. Então vou tentar fazê-lo aqui:

contexto limitado:

um sistema internamente consistente com limites cuidadosamente projetados que mediam o que pode entrar no sistema, e o que pode sair dele.

Em outras palavras, um Contexto Limitado representa um contexto essencialmente, um sistema que encapsula cooperativa de componentes — claramente definidos limites que governam o que pode entrar no sistema, e que pode sair dele.

Células (aquelas pequenas coisas que formam todos os seres vivos) oferecemos uma interessante analogia. Dentro de uma célula estão todos os tipos de componentes (o núcleo, ribossomas, citoplasma, citosqueletos, etc) que são todos encapsulados dentro da própria célula. Ao redor de cada célula, no entanto, está uma membrana, que atua como a barreira entre os internos da célula e o resto do organismo. A membrana protege a célula do seu ambiente, permite a entrada de nutrientes específicos e permite a saída de vários subprodutos.

na mesma veia, um contexto limitado consiste numa variedade de componentes (micro-serviços, aplicações web, aplicações móveis, bases de dados, filas de mensagens, etc.). Ele também serve como uma barreira lógica que encapsula esses componentes. Internamente, os componentes podem ser acoplados, e podem passar livremente os dados uns aos outros. Mas o contexto delimitado ajuda a impor acoplamento solto externamente, definindo pontos explícitos onde:

• de dados externa pode entrar (talvez através de consumidor inscrito para um Kafka tópico)
• dados internos pode sair (talvez através de outro Kafka tópico, ou através de um bem-design OBTER API, cuidadosamente elaborado para ocultar qualquer sistema interno de detalhes)

Um Contexto Limitado representa sua equipe multifuncional bem. A equipe é composta por vários membros da equipe (designers, frontend/backend/mobile engineers, gerentes de produtos, engenheiros de dados e engenheiros de QA, etc). Internamente, estes membros trabalham em cooperação para alcançar os mesmos objetivos consistentes. Além disso, esses membros da equipe são (ou devem ser) encapsulados de modo que eles tenham dependências mínimas de outras equipes.

assim, em vez de começar a nível organizacional e definir todas as aplicações e micro-serviços que esperamos construir, construímos equipas em torno dos nossos sub-domínios, permitindo que essas equipas cresçam os seus sub-domínios e definam o que precisa de ser construído. Feito corretamente, nós tendemos a ver vários contextos limitados na organização como crescendo organicamente, em vez de como estruturas rígidas, predefinidas.

Implications on breaking the monolith

Conway’s Law tells us that organizations design software systems that mimic their organization’s communication structure. Isso muitas vezes prova ser verdade, então devemos ser pensativos sobre como estruturamos nossa organização enquanto começamos a construir micro-serviços.

Na verdade, por agora, uma imagem deve estar emergindo em sua mente. À medida que passamos do monólito para os micro-serviços, devemos começar a pensar verticalmente (dividindo o monólito pelos seus sub-domínios) em vez de horizontalmente (dividindo o monólito pelas suas camadas funcionais).

Em outras palavras, não devemos começar por substituir o monólito da camada de acesso a dados com dados microservices. Em vez disso, devemos começar por dividir um recurso inteiro (como o processo de checkout, ou talvez pesquisa de produto). Cada recurso representará um contexto limitado. E cada um será dividido por uma equipa transversal dedicada.além disso, essa equipa deve concentrar-se na sua tarefa em mãos, ou seja:

• replicar fielmente a funcionalidade existente,
• ou (melhor) construir uma experiência nova e melhorada para os seus clientes.

Como parte do processo, a equipe deve projetar o sistema que é mais adequado para o empreendimento.

Por exemplo, podemos decidir descascar a nossa funcionalidade de pesquisa de produtos a partir do nosso monólito. A equipe de pesquisa de produtos pode, em última análise, projetar um sistema que inclui:

• Kafka consumidores que ouvem uma série de tópicos externos Kafka para atualizar seu próprio sistema interno de registro (SoR) para produtos.
• um Kafka editora que leva a alterações da sua Irmã para um interno Kafka tópico
• outro Kafka consumidor que escuta interna tópico e atualizações de um Elástico de índice de Pesquisa
• um GraphQL ponto de extremidade para o exterior, pesquisas de consultas Elástico de Pesquisa
• um Resto de ponto de extremidade que recupera produtos individuais por ID
• um novo aplicativo web que utiliza os pontos de extremidade para permitir que os clientes para procurar por produtos e explorar detalhes do produto
• um conjunto semelhante de telas em nossos aplicativos móveis que utilizam esses pontos de extremidade
• Um Kafka editora que leva mensagens, representando distintas consultas realizadas pelos clientes, externos, Kafka tópico, para utilização por qualquer outro contexto limitado (por exemplo, google analytics) que pode estar interessado

Como podemos começar a descolar-se mais e mais vertical partes do monólito, outras equipes de construir seus próprios Contextos limitados. Estes contextos limitados podem acabar parecendo bastante diferentes um do outro.

Observe que os componentes dentro de um determinado Contexto Limitado pode ser acoplado; no entanto, nós estamos mantendo nossos Contextos limitados dissociado do outro. No nosso exemplo, qualquer comunicação entre contextos limitados acontece passando mensagens através de uma fila de mensagens Kafka. O que é importante é que estamos a evitar chamadas síncronas de pedido / resposta entre contextos limitados.

isto também é verdade com o que resta do monólito. Certamente não queremos um acoplamento apertado entre os nossos novos micro-serviços e o nosso legado monólito. Assim, à medida que descascamos partes do monólito, alavancamos a passagem de mensagens para permitir que as partes restantes se comuniquem com os nossos novos contextos limitados.

Reality check on all of this decoupling

At this point, we may ask yourselvers whether it’s really possible to keep our Bounded Contexts decoupled.no mundo real, podemos realmente manter as nossas equipas protegidas de dependências externas? Nunca haverá casos em que uma equipa deve ser bloqueada por outra equipa para fazer o seu trabalho?

e podemos realmente criar arquiteturas de Serviço para os nossos subdomínios que são completamente dissociados de outros subdomínios? Não há realmente nenhuma necessidade de uma aplicação em um contexto limitado para alguma vez síncronamente chamar um serviço em outro?

na realidade, pode ser impossível manter os nossos contextos limitados 100% dissociados. Mas podemos aproximar-nos, muito mais do que a maioria de nós pensa.

architectures Real-life

Let’s start by looking at decoupled architectures. Muitas vezes acreditamos na falácia de que qualquer dado tipo de dados deve viver em exatamente um local, e que qualquer outro sistema deve chamar diretamente para esse local para acessar os dados.

referimo-nos a isto como atribuindo uma única fonte de verdade (SSoT) aos nossos dados. Mas como descrito neste artigo que disseca a ideia dos SSoTs, essa mesma noção é, de um modo geral, um anti-padrão. Em vez disso, a maioria dos contextos limitados deve armazenar sua própria cópia local de quaisquer dados que eles precisam usar.

isto é exemplificado pelo nosso contexto limitado de pesquisa de produtos da secção anterior. Este contexto limitado, é claro, depende muito dos dados do catálogo de produtos da nossa organização. Mas as probabilidades são, que os dados são gerados em um contexto limitado diferente (vamos chamá-lo de o contexto de entrada de produto Limitado).

nossa primeira abordagem (ingênua) pode ser expor uma API de Repouso do contexto limitado de entrada de produtos e forçar os serviços dentro do contexto limitado de busca de produtos a chamar essa API. Mas podemos fazer melhor. Em vez disso, podemos manter os sistemas dissociados, publicando as alterações introduzidas pelos serviços de entrada de produtos na Kafka. Nossos consumidores de pesquisa de produtos Kafka, em seguida, pegar essas mensagens e atualizar as bases de dados de pesquisa de produtos.

Observe que esses dois Contextos limitados, eventualmente, são-consistente. Isto significa que haverá breves períodos de tempo em que um dado pedaço de dados pode ser inconsistente entre a entrada do produto e a busca do produto. Por exemplo, se o preço dos widgets Wombat brancos for aumentado de $1,99 para $2.49, haverá um breve período de tempo (muitas vezes uma questão de segundos, se não milisegundos), onde há uma diferença de 50 ” no preço Widget Wombat branco nos dois contextos limitados.

isto leva aos casos do mundo real quando não temos alternativa a não ser um casal de contextos limitados. Em alguns casos, a coerência eventual não é aceitável. Por exemplo, antes que um cliente possa completar sua compra on-line, podemos precisar garantir que cada item em seu carrinho de Compras está, de fato, disponível naquele momento. Mesmo assim, muitas vezes podemos minimizar o acoplamento entre os dois contextos limitados.

nossas interações podem ser assim:

• Como o cliente usa a IU de pesquisa de produtos para encontrar produtos, as bases de dados de pesquisa de produtos são usadas para recuperar informações (tais como estilos, opiniões dos clientes, preços, etc.) sobre os produtos
• mesmo quando o cliente começa o processo de checkout, nós ainda usamos as bases de dados de pesquisa de produtos para recuperar a informação que precisa ser exibida.finalmente, quando o cliente clica nesse botão final de “compra Completa”, fazemos uma única chamada síncrona para o contexto limitado de entrada do produto para validar a disponibilidade dos itens antes de completar a compra.

outro exemplo comum que requer consistência imediata relacionada com a autorização. Em muitos sistemas, tokens de segurança devem ser recuperados ou validados em cada pedido. Nesses casos, provavelmente precisamos permitir que nossos contextos limitados chamem outro contexto limitado, orientado à segurança.

estruturas orgânicas da vida real

Que tal equipas auto-suficientes e funcionais? Como é possível no mundo real?na realidade, é um processo de movimento contínuo em direcção a equipas totalmente independentes. Raramente alcançaremos 100% de autonomia com as nossas equipas. Mas se começarmos por organizar as nossas equipas de forma inteligente, e reconhecermos e respondermos aos estrangulamentos que surgem, podemos chegar perto.para começar, devemos maximizar as nossas equipas verticais e funcionais e minimizar o número de equipas horizontais e monofuncionais. Isso significa resistir ao impulso de formar as chamadas equipas “nucleares” -cuja missão é construir serviços de dados comuns que são consumidos por outras equipas orientadas para o produto — e, em vez disso, formar as nossas equipas em torno do valor comercial que irão fornecer.

muitas organizações avançam para este objectivo, formando pela primeira vez equipas de gestores de produtos orientadas para o domínio, e engenheiros de ponta e de fundo. É um começo. Mas quem mais devem estas equipas incluir? A adesão exata pode diferir entre diferentes equipes com diferentes necessidades. Mas devemos considerar coisas como::

• Se nossa equipe tem engenheiros front-end, então as probabilidades são que eles devem estar trabalhando em estreita colaboração com um designer gráfico que é dedicado ao Domínio.engenheiros móveis – muitas vezes sequestrados em sua própria área do org — devem ser incluídos para domínios com um componente móvel.no seu artigo esclarecedor sobre as malhas de dados, Zhamak dehghani lamenta que os engenheiros de dados sejam muitas vezes excluídos das equipas funcionais-em detrimento dos engenheiros de dados e das próprias equipas funcionais.uma vez que determinemos os membros das nossas equipas, devemos ter cuidado com os pontos de estrangulamento. Há outras equipas que normalmente bloqueiam a produtividade das nossas equipas?por exemplo, muitas organizações têm uma equipe de segurança dedicada. Trata-se, naturalmente, de uma boa prática; as organizações precisam de uma estratégia de segurança coesa e de uma forma de assegurar a governação em relação a essa estratégia. No entanto, também é comum as equipes pararem seu trabalho em várias etapas para permitir revisões de segurança de seu trabalho. Mesmo na melhor das situações, isso estabelece bloqueios de estradas para nossas equipes como uma prática de negócios de rotina. Além disso, muitas vezes levará as equipes a ter que raspar todo ou parte de seu trabalho e começar de novo, uma vez que eles descobrem requisitos de segurança que não tinham sido cumpridos.este é claramente um mau cheiro. Mas, como podemos impor os padrões de segurança de nossa organização, permitindo que as equipes permaneçam autônomas e produtivas?podemos fazê-lo adicionando engenheiros de segurança às nossas equipas funcionais. Há três abordagens que podemos tomar:se tivermos a sorte de ter uma equipa de segurança relativamente grande, podemos atribuir a cada equipa cross-functional um engenheiro de segurança a tempo inteiro (SE).com equipes de segurança menores, cada SE pode ser atribuída a uma série de equipes de trabalho em tempo parcial. Isso ainda permitiria que a SEs compreendesse os objetivos e projetos das equipes, e trabalhar com a equipe para aderir aos padrões de segurança da org ao longo do processo.se não tivermos recursos de segurança suficientes para ambos, podemos avançar na direcção oposta. Em vez de trazer membros da equipe de segurança para as nossas equipes cross-functional, nós podemos trazer membros das equipes cross-functional para a equipe de segurança. Cada equipa funcional designaria um ou dois representantes de segurança. Os representantes se reuniriam periodicamente com segurança e seriam mantidos a par das exigências e padrões de segurança da organização. Podem não ser peritos em segurança. Mas eles serão capazes de servir o papel de um engenheiro de segurança, garantindo que suas equipes adiram às práticas de segurança da organização.

Guilds

Este encaixe em outro padrão organizacional que tem vindo a ganhar força: guilds. O modelo da guilda nasceu do modelo de equipe cross-functional. Por sua natureza, essas equipes são povoadas por membros especializados em diferentes funções. No entanto, muitas vezes faz sentido para as pessoas que se especializam em uma função específica para se reunir também; por exemplo, para:a nossa última solução de segurança formou efectivamente uma”guilda de segurança”. Os membros da equipe trabalhavam principalmente com suas equipes verticais, mas periodicamente, alguns deles se reuniam com o “guild” de segurança para discutir as práticas e padrões de segurança da organização.

O modelo guild também funciona particularmente bem quando se trata de arquitetura de software. Particularmente com uma arquitetura de micro-serviços, é necessário algum nível de governança técnica em toda a organização. No entanto, ter um grupo de arquitetos sentados em uma torre de marfim metafórica, distribuindo regras para as equipes, é geralmente contraproducente. Em vez disso, engenheiros seniores/Líderes de nossas equipes cross-functional podem se reunir periodicamente em uma guilda de arquitetura. Lá, eles podem levantar questões de suas equipes, e trabalhar em soluções, e estabelecer pattens e padrões.

Guildas também pode ser estendido para quase todas as outras funções. Afinal, queremos que os designers estejam desenvolvendo e trabalhando a partir de um guia de estilo UI comum. Queremos que os nossos engenheiros de frontend usem os mesmos elementos UI. Os engenheiros da QA devem estar alinhados com a forma como os testes são feitos em nossas organizações. E os gerentes de produtos devem estar em sintonia com o roteiro geral de produtos da organização.

reunir tudo

mudar para micro-serviços pode melhorar dramaticamente a produtividade das nossas equipas. Mas precisamos entender como aproveitar uma arquitetura de micro-serviços para chegar lá. De todos os padrões de design e conceitos que se relacionam com micro-serviços, o contexto limitado é indiscutivelmente o mais importante para nos dar essa compreensão.com uma compreensão sólida do contexto delimitado, entendemos que:

• Nossa estrutura organizacional e os nossos técnicos de arquitetura ir de mão em mão
• o Nosso produto orientado para as equipes devem ter o mínimo de dependências em outras equipes, assim como os sistemas de construir deverá ser dissociado de outros sistemas

Em geral, abrangendo o Contexto Limitado coloca a mentalidade de que o que precisamos para ter sucesso com o nosso microservices arquitetura. Certifique-se de entender este padrão Importante Antes de embarcar em sua viagem de microservices!