You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
133 lines
6.1 KiB
133 lines
6.1 KiB
<!DOCTYPE html> |
|
<html lang="en"> |
|
<head> |
|
<meta http-equiv="X-UA-Compatible" content="IE=edge"> |
|
<meta http-equiv="content-type" content="text/html; charset=utf-8"> |
|
|
|
<!-- Enable responsiveness on mobile devices--> |
|
<!-- viewport-fit=cover is to support iPhone X rounded corners and notch in landscape--> |
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, viewport-fit=cover"> |
|
|
|
<title>Julio Biason .Me 4.3</title> |
|
|
|
<!-- CSS --> |
|
<link rel="stylesheet" href="https://blog.juliobiason.me/print.css" media="print"> |
|
<link rel="stylesheet" href="https://blog.juliobiason.me/poole.css"> |
|
<link rel="stylesheet" href="https://blog.juliobiason.me/hyde.css"> |
|
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface"> |
|
|
|
|
|
|
|
|
|
|
|
</head> |
|
|
|
<body class=" "> |
|
|
|
<div class="sidebar"> |
|
<div class="container sidebar-sticky"> |
|
<div class="sidebar-about"> |
|
|
|
<a href="https://blog.juliobiason.me"><h1>Julio Biason .Me 4.3</h1></a> |
|
|
|
<p class="lead">Old school dev living in a 2.0 dev world</p> |
|
|
|
|
|
</div> |
|
|
|
<ul class="sidebar-nav"> |
|
|
|
|
|
<li class="sidebar-nav-item"><a href="/">English</a></li> |
|
|
|
<li class="sidebar-nav-item"><a href="/pt">Português</a></li> |
|
|
|
<li class="sidebar-nav-item"><a href="/tags">Tags (EN)</a></li> |
|
|
|
<li class="sidebar-nav-item"><a href="/pt/tags">Tags (PT)</a></li> |
|
|
|
|
|
</ul> |
|
</div> |
|
</div> |
|
|
|
|
|
<div class="content container"> |
|
|
|
<div class="post"> |
|
<h1 class="post-title">Microservices: Chassis</h1> |
|
<span class="post-date"> |
|
2020-04-17 |
|
|
|
<a href="https://blog.juliobiason.me/tags/microservices/">#microservices</a> |
|
|
|
<a href="https://blog.juliobiason.me/tags/chassis/">#chassis</a> |
|
|
|
<a href="https://blog.juliobiason.me/tags/frameworks/">#frameworks</a> |
|
|
|
<a href="https://blog.juliobiason.me/tags/languages/">#languages</a> |
|
|
|
</span> |
|
<p>The chassis for a microservices fleet is defined as the libraries and |
|
frameworks that one should use when creating a new microservice.</p> |
|
<span id="continue-reading"></span> |
|
<p>The "chassis" is actually a <a href="https://microservices.io/patterns/microservice-chassis.html">known |
|
pattern</a>, but the |
|
literature points it as a decision about the libraries and frameworks that |
|
should be used when creating microservices.</p> |
|
<p>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.</p> |
|
<p>And, for each language, you need to pick a different chassis -- you can't use |
|
Spring Boot with Python, for example.</p> |
|
<p>You may have noticed that "but" in the second paragraph. Personally, I think |
|
the choice of chassis go way beyond just creating a microservices.</p> |
|
<h2 id="shared-knowledge">Shared Knowledge</h2> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<h2 id="applying-a-common-view">Applying a Common View</h2> |
|
<p>While the pattern describes only frameworks and libraries, the choices of |
|
surrounding services also makes part of the chassis, in my opinion.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<h2 id="conclusion">Conclusion</h2> |
|
<p>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.</p> |
|
|
|
</div> |
|
|
|
|
|
|
|
|
|
</div> |
|
|
|
</body> |
|
|
|
</html>
|
|
|