A post about microservices chassis

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.
+
+<!-- more -->
+
+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.

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.
+
+<!-- more -->
+
+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".
+
+<!-- 
+vim:spelllang=pt:
+-->
+