diff --git a/content/code/microservices-chassis.md b/content/code/microservices-chassis.md new file mode 100644 index 0000000..18cf01e --- /dev/null +++ b/content/code/microservices-chassis.md @@ -0,0 +1,75 @@ ++++ +title = "Microservices: Chassis" +date = 2020-04-17 + +[taxonomies] +tags = ["microservices", "chassis", "frameworks", "languages"] ++++ + +The chassis for a microservices fleet is defined as the libraries and +frameworks that one should use when creating a new microservice. + + + +The "chassis" is actually a [known +pattern](https://microservices.io/patterns/microservice-chassis.html), but the +literature points it as a decision about the libraries and frameworks that +should be used when creating microservices. + +For example, if you're working with Java, you'd probably pick something like +Spring Boot as a chassis for your microservices, in a way that anyone creating +a new microservice already have the library (and local knowledge) on how to +build it. + +And, for each language, you need to pick a different chassis -- you can't use +Spring Boot with Python, for example. + +You may have noticed that "but" in the second paragraph. Personally, I think +the choice of chassis go way beyond just creating a microservices. + +## Shared Knowledge + +One of the major factors of using chassis for your microservices is the shared +knowledge between teams. Teams that are using the same chassis can exchange +solutions on how to solve some problems, how to make processing faster, new +releases information and so on. + +Even if the teams will never touch each other's code, the simply fact that +they can share these information between them is a huge boom. + +And even for teams using different languages is a major point: One team can +point that their framework allows them to do things in a more simpler way that +can be researched by some other team, using a complete different framework, in +a complete different language, on how to build the same stuff. + +## Applying a Common View + +While the pattern describes only frameworks and libraries, the choices of +surrounding services also makes part of the chassis, in my opinion. + +For example, the teams pick Kafka as a messaging broker between services -- +which would allow any team, on any framework, on any language, to use the same +service for exchanging messages -- allowing any team that has a need +for a message broker can use the same install (but using different +topics) and reduce maintenance costs. But what happens when one team decides +to use Kafka as a database and put a retention to "forever"? That would +utterly confused everyone else. "Why is this topic getting bigger and +bigger?" Worse, without a well described DevOps documentation, someone may see +that growing topic, check it out, see that is has no retention policy and add +one based on the other projects. + +Another example: For highly relational data, there is a PostgreSQL +installation for everyone. Each team have their own database and users. But +one team, which got responsible for two microservices, have one with data +which is relational and another that basically requires a key-value store. +Instead of asking for key-value store, they decide to create a database with a +single table, with a key field and a large text field for storing JSONs. +This, again, breaks the defined chassis, as one would expect PostgreSQL to be +the relational database and not as a key-value store. + +## Conclusion + +Chassis are good for microservices development due their quick development +start up and shared knowledge, but they go way beyond just frameworks and +libraries: They related to everything around the services and the way they are +viewed by each microservice. diff --git a/content/code/microservices-chassis.pt.md b/content/code/microservices-chassis.pt.md new file mode 100644 index 0000000..131e82d --- /dev/null +++ b/content/code/microservices-chassis.pt.md @@ -0,0 +1,88 @@ ++++ +title = "Microserviços: Chassi" +date = 2020-04-17 + +[taxonomies] +tags = ["microserviços", "chassi", "framework", "linguagens"] ++++ + +O chassi de um fleet de microserviços é definido como as bibliotecas e +frameworks que alguém deve usar quando está criando um novo microserviço. + + + +O "chassi" é um [design +pattern](https://microservices.io/patterns/microservice-chassis.html) +conhecido, mas a literatura fala sobre a escolha de bibliotecas e frameworks +que devem ser usados quando se está criando um microserviço. + +Por exemplo, se você está trabalhando com Java, você provavelmente teria algo +como Spring Boot como chassi para os seus microserviços, de forma que qualquer +um que comece um microserviço já tenha uma biblioteca (e conhecimento local) +de como construir. + +E, para cada linguagem, você precisa escolher um chassi diferente -- você não +pode usar Spring Boot com Python, por exemplo. + +Você deve ter notado que eu coloquei um "mas" no segundo parágrafo. +Pessoalmente, eu acho que a escolha do chassi vai bem além da criação de +microserviços. + +## Conhecimento Compartilhado + +Um dos maiores fatores de se usar um chassi para o seu microserviço é o +conhecimento compartilhado entre os times. Times que utilizam o mesmo chassi +podem trocar informações em como solucionar alguns problemas, como fazer o +processamento ficar mais rápido, informações sobre releases novas e assim por +diante. + +Mesmo que os times nunca mexam nos códigos dos outros, o simples fato que eles +podem compartilhar essas informações entre eles é um grande avanço. + +E mesmo para times que utilizam linguagens diferentes isso é um grande ponto: +Um time pode descrever como o framework que eles utilizam permite fazer alguma +coisa de forma mais simples, de forma que outro time possa pesquisar se o seu +chassi permite fazer algo da mesma forma. + +## Aplicando uma Visão Comum + +Enquanto o pattern descreve apenas frameworks e bibliotecas, as escolhas dos +serviços ao redor do serviço também faz parte do chassi, na minha opinião. + +Por exemplo, um time decide usar Kafka como mensageria[^1] entre serviços -- o +que permite que qualquer outro time, usando qualquer outro framework, em +qualquer outra linguagem, a usar o mesmo serviço para troca de mensagens -- +permitindo que qualquer time que precise usar um serviço de troca de mensagens +possa usar a mesma instalação (mas usando tópicos diferentes), reduzindo +custos de manutenção. Mas o que acontece quando um time decide usar Kafka como +banco de dados e define o tempo de retenção para "sempre"? Isso iria confundir +completamente todos os outros. "Por que esse tópico está sempre crescendo?" +Pior, sem uma documentação de DevOps bem descrita, alguém pode ver o tópico +crescendo, verificar, ver que a política de retenção está diferente do resto e +adicionar um baseada em outros projetos. + +Outro exemplo: Para dados relacionados, há uma instalação do PostgreSQL para +todo mundo. Cada time tem o seu próprio database e usuários. Mas um time, que +acabou ficando responsável por dois microserviços, tem um serviço com dados +que são relacionais e outro que basicamente necessita de um armazenamento de +chave-valor. Ao invés de pedir por um banco de dados chave-valor, o time +decide criar um database com apenas uma tabela, com um campo para a chave e um +campo de texto para guardar JSONs. Isso, novamente, quebra a definição do +chassi, pois seria esperado que o PostgreSQL fosse usado como banco +relacional e não como um banco chave-valor. + +## Conclusão + +Chassis são bons para o desenvolvimento de microserviços por permitir um +início de desenvolvimento rápido e com compartilhamento de conhecimento, mas +eles vão além de apenas frameworks e bibliotecas: eles relacionado tudo ao +redor dos serviços e como esses são vistos por cada microserviço. + +--- + +[^1]: "Message broker". + + +