Depois de trabalhar com diferentes tecnologias por muitos anos, Jeppe Cramon acredita que o mais importante ao projetar sistemas é entender o domínio de negócios em que estamos trabalhando. Devemos nos concentrar em identificar os bounded contexts e os recursos de negócios, e projetar serviços e microservices usando esse conhecimento. Em uma recente apresentação na conferência Micro CPH em Copenhague, Cramon falou sobre a experiência de trabalhar com sistemas distribuídos. Nos últimos cinco anos trabalhou com microservices, princípios e com os padrões que considera benéficos para criar com sucesso sistemas em microservices.
A mais ou menos 10 a 15 anos atrás, muitas empresas usaram portais e portlets. Cramon, fundador do Cloud Create, observa que apesar dos problemas, como uma tecnologia pesada e inflexibilidade, a vantagem era que a interface do usuário (UI) era composta por uma página dividida com pequenas views, cada uma gerenciada por um pequeno serviço. Isso significava que muitos desenvolvedores poderiam trabalhar de maneira independente na mesma página e que cada uma das visualizações era fácil de ser alterada devido à natureza desacoplada.
Para Cramon, essas ideias evoluíram para o SOA e para serviços maiores. Um problema comum era que os serviços dependiam de outros serviços, e um serviço de dados ou entidade com falha poderia derrubar outras dependências. Garantir a consistência era difícil, geralmente exigindo transações distribuídas que não escalam. Outro desafio em sistemas distribuídos é quando a comunicação síncrona é usada, por exemplo, RPC, REST ou SOAP. Isso reduz a tolerância a falhas e prejudica o desempenho. Cramon resume a experiência com:
Amigos não permitem que amigos usem SOA em camadas.
Com base em sua experiência nessas e em outras tecnologias. Cramon acredita que devemos nos concentrar no domínio do negócio e encontrar os limites dentro dele, para podermos definir os serviços para a solução. O que deseja alcançar é o alinhamento do domínio do problema e do domínio da solução. O negócio deve estar refletido no código, permitindo que a empresa e TI falem a mesma linguagem onde quer que esteja. Os recursos do negócio costumam ser bem estáveis, e Cramon se refere a Bill Poole, que em 2008 escreveu sobre o alinhamento de capacidade de negócios e outros conceitos que mais tarde se tornaram sinônimos de microservices.
Cramon prefere modelos menores com propriedade de dados clara e usa eventos de negócios para impulsionar processos de negócios. Isso mantém os serviços desacoplados e permite o uso de um processo de negócios orquestrado ou coreografado para garantir que cada fluxo de trabalho seja tratado de maneira correta. Cramon observa que apenas eventos relevantes para o negócio devem ser publicados, eventos internos de um serviço são um detalhe de implementação.
Descrevendo o mundo dos microservices de hoje, Cramon usa a definição de serviço de Udi Dahan do artigo The Known Unknowns of SOA. Dahan define o serviço como autoridade técnica para um determinado bounded context ou capacidade de negócios. É o proprietário de todos os dados e regras de negócios nesse contexto, e Cramon enfatiza que isso se aplica a todos os lugares e que, dessa forma, podemos formar uma fonte única e verdadeira para o contexto.
Em relação ao design de serviços, Cramon observa que um serviço representa um limite de responsabilidade lógica e, portanto, precisa ser implantado em todos os lugares onde os dados são necessários, também observa que a responsabilidade lógica e a implantação física de um serviço não precisam ser de um para um e se refere a Philip Krutchen e sua visão de arquitetura 4 + 1.
Para conseguir isso, precisamos de blocos mais refinados, e para Cramon, este é exatamente o local onde os microservices se encaixam. Com um serviço implementado por um ou mais microservices, se tornando unidades individuais implantáveis com os próprios pontos de extremidade. Um exemplo é dividir um serviço ao longo dos limites transacionais ao usar o CQRS, o modelo de gravação pode então ser manipulado por um microservice e o modelo de leitura por um ou mais microservices diferentes.
Não há necessidade de todos os microservices serem implementados individualmente. Outro conceito, também do Dahan, são componentes autônomos que representam unidades lógicas implantáveis. Isso significa que podem, mas não precisam ser, implantados individualmente. Cramon ressalta que devemos projetar para a distribuição, mas precisamos aproveitar a localidade sempre que possível. Distribua apenas quando necessário, por exemplo, devido a problemas de escalabilidade.
Muitos serviços podem ser implantados no mesmo servidor físico e no mesmo aplicativo. Cramon observa que aplicativos e serviços são conceitos diferentes, um limite de aplicativo é um limite de processo e um limite físico, enquanto um serviço é um limite lógico. Isso significa que diferentes partes dos serviços podem ser implantadas em diferentes camadas, algumas partes podem ser implantadas na camada da web enquanto outras partes são implantadas na camada de serviço da aplicação. Mas isso também significa que o mesmo serviço pode ser implantado em vários níveis ou aplicações.
Cramon enfatiza que o serviço representa um limite lógico e é uma agregação de diferentes componentes autônomos, vendo os aplicativos como mashups de serviços diferentes significando que um serviço deve possuir componentes de interface do usuário para alcançar o desacoplamento total.
A maioria das apresentações da conferência foram gravadas e estarão disponíveis nas próximas semanas.