I’m proud to introduce version 1.0.0 of project Cereebro !
What is it ?
Keeping software documentation is an ageless problem. At the age of micro-services, it’s easy to get lost within a distributed system, even if you designed it.
Cereebro automatically builds a map of a distributed system.
Why ?
Cereebro was born because of a strong motivation : laziness.
Working as a technical lead for the Lab (experimental) team at edelia (EDF group) is pretty fun. We have more room than others team to make technical decisions, although at some point we may be asked to “do our chores” and follow part of the process like the others do. This is how I ended up being asked by the architecture team to maintain a list of all the micro-services built by our team, and the dependencies among them. …
Originally published at michaeltecourt.github.io on August 8, 2016.
I have been trying to finish this blog post forever, and the motivation was sparked by a tweet from Spring’s Oliver Gierke, thanks a lot !
Note : While checking the definition of RPC I realized that the concept was not just about calling remote services, it came along with the crazy idea of making programmers forget about network constraints. I’ll keep using the acronym RPC for “remote service calls” as most people get it.
Solutions like Eureka are popular because they solve a concrete configuration problem in the world of remote/micro services : instead of configuring the address of each service consumed by your application, each service checks-in with Eureka, and your application queries Eureka by to know where services are located.
Configuration goes from N URLs to 1, at the price of a couple spring-cloud-starter-eureka* dependencies : easiness wins, like always in programming.
Also usual in programming, fancy names can be misleading : service discovery is more about service address discovery or service registration depending on the angle.
Applications do not discover brand new services and learn how to use them on the fly, applications are coded to call certain services and expect certain responses out them. Only the “root” address of those services is configured “lazily” at runtime. …
While a picture is worth a thousands words, a good diagram is better than :
- a couple hour-long meetings
- six e-mails
- a 2MB PDF no developer will ever open
- the three above together
After pulling my hair speaking with product managers about interpretations we couldn’t agree on, after endless arguments with architects about what the clean design should have/could have been, after talking for too long about the pros and cons of solutions that would never work, I’ve found out that it’s much more productive to starting scribbling on the white board instead of debating through the air.
Most programmers agree, but the problem is that we have that tendency to re-invent the wheel when it comes to sketching what we have in mind.
Having worked recently on authentication and authorization projects on a fairly large system, I encountered a LOT of unique pieces of office art over the past few months. The enterprise world is full of unexpected creativity. …
About
