Microservices Entropy

It may be intressting to take a look to our previous article : Microservice, Container, Cloud-native

Over years, software engineering has changed, whether it's following a trend from GAFA (Googlen Apple, Facebook & Amazon) or new technologies like virtualisation containerization or even lot of old useful deathless standards done in the in the 1970s, microservice as described by Adrian Cockcroft at Netflix : this approach is "fine grained SOA". it look like SOA is one of those interesting forerunner reflexion that was waiting for a technology evolution to become the new standard.

I would start commenting this by a little quote:

" IT world primitive laws is build refactor and destroy." Me

Today am going to share an experience about building microservices the easy way.

"I have not failed. I've just found 10,000 ways that won't work." Thomas A. Edison
Am Going to focus on the second one, if I may say so there is indeed a 10000 way to do it wrong, applied to Microservices implementation, the topic that lead us to remembrer this quote, we can just notice how it's easy to face the entropy that makes you deeply doubt about the whole concept, this is sad specialy if you've bet a lot on this.

for example, if a team of ten devs creates a based microservice app, they will likely face the entropy. i can hear you saying which entropy we're talking about ? :

In microservice concept (as I like to define it), the code should be reusable and pretty small, again we will not fall into the microservices pitfall questions :

" If I have a big java app, How should i considering spliting up on a couple of MS? "

You will probably not create a microservice per function ( chunk you app into function is not a GOOD IDEA ). better than that, a modularity approach is recommended. If your MS app needs an authentification, you should probably consider create a auth-microservice a small JSON REST API that makes the authentication process more digest and let you and the whole team minimize the workload of the heavy authentication complexity ".

" which argument i should send to LDAP."

Or

"I've got some errors using the AD"

Back to our subject, consider a team much bigger than the first one let say twenty two devs, the entropy occurs when following this example each one of the devs embeded his own authentication module within his attributed microservice. SO this is the main problem, developing the same function, the same module twenty two times is a waste of effort and time (Don't be surprised if say that this things may happen even in the big and famous startup in the world) unfortunelty this is a way to misuse the concept and to not get the most of it.

The key to avoid this kind of issues below helps starting a team to work in a sane devops culture and mindset :

1 - A small team is a team under 5 person.

Working in a small task force team : A small team is a team that can share a medium pizza a team under 5 pesoon.

" Small teams are holy" Werner Vogels (CTO et VP Amazon) :
2- Communication is the key.

It may seem trivial, but spending 5 min in the middle of the day around a stand up may take you away from wasting days on building and refactoring between bugs hotfix and error. Doing a quick briefing make you reach the milestone project more quickly,

Beware the overAgile sandrome : Spending a huge time on synchronization on a daily bases may hurts your planing and blur your project .

3- Using the right tool the right way.

A tool like a Slack can helps you keeping the track on the work history useful if you're back from holiday. Slack is a tool to synchronize team saves unnecessary emails. two things can make your team ward off a such the tool. transforme the Slack/Github to an activity monitoring tool or even worst to a worktime tracker.

beware the slack addiction syndrome as well.

Hope this paper inspire you to follow the right microservice implementation.

Waiting for your feed back, please leave a comment.