Why Microservices Are Like Line Dancing

James Hickey - Feb 21 '19 - - Dev Community

This was inspired by

You can blame @helenanders26 for this atrocity.

Choreography

A line dance is a CHOREOGRAPHED dance where dancers ASSEMBLE into rows and dance in sync.

Much like services need to be CHOREOGRAPHED by some overarching system like Kubernetes, etc.

Seniors

It seems that line dancing is popular with SENIORS. When you have a large number of SENIORS together trying to have fun - line dancing just makes sense. Much like Microservices.

But don't be fooled. JUNIORS may think they can handle it. But it takes many years of experience to become proficient and wise enough to execute successfully.

Service Boundaries

In line dancing, people are lined up into rows called walls. Dancers must stay within their wall BOUNDARIES, else we begin to lose HIGH COHESION.

If that happens, you get HIGH COUPLING. In a dance with many fragile moving parts - this is bad. It becomes the first of a long line of dominoes being knocked down...

Composite UI

A line dance may actually have many walls!

Many walls combined as a whole creates a COMPOSITE that, together, looks and works much more beautifully than one massive HOMOGENEOUS and MONOLITHIC wall.

Service Discovery

When joining an existing line dance, you walk to the end of an existing line and become part of the dance. This is when our dancer is DISCOVERED.

He must quickly ensure he DISCOVERS who is around him so he doesn't cause any FAILURES.

If he does cause a FAILURE, experienced dancers will be RESILIENT enough to FALL BACK to the previous state.

Eventually Consistency

The dancer is responsible for making sure he/she begins to start stepping in time with the other dancers.

If the dancer misses any steps, it's usually fine as the dance will gain EVENTUAL CONSISTENCY.

Messaging

Dancers must not physically touch each other while dancing but must LISTEN for certain PUBLISHED cues in the music and beat.

Using ASYNCHRONOUS MESSAGES ensures that the dancers can continue dancing efficiently while directing other dancers if needed.

Service Autonomy

Dancers are AUTONOMOUS and can leave or join a dance whenever they like. If they wish to UPGRADE their shoes and come back later - much like a service DEPLOYMENT - no problem.

Also, a dancer has the flexibility to have his/her own personal style. Much like how services may choose their own set of technologies to use.

CAP Theorem

Some dances, like in professional leagues, must ensure that the entire dance is CONSISTENT. If there are any FAILURES then the dance will lose points and be deemed a poor execution.

On the other hand, more informal dances merely focus on having a pool of dancers AVAILABLE. If there are any FAILURES, we can always replace a dancer with someone else and RE-DISCOVER them.

Scalability

A line dance can get pretty big. As big as you want, really.

If there's a new groove that comes on the music system, each wall or row can SCALE to allow new people to join if they feel like they need some extra pizzazz.

Health Checks

Before beginning a dance, it's important to perform a HEALTH CHECK. If any dancers fail this test, then they better be sure to step out the next one.

We don't want any SENIORS hurt.

Legacy

Line dancing is difficult. Many SENIORS are wary of the troubles that one is faced with when undertaking such a task.

Be careful next time you think about organizing a line dance.

It may cause your SENIORS to leave a poor LEGACY behind. Especially when HEALTH CHECKS fail.

Keep In Touch

Don't forget to connect with me on twitter or LinkedIn!

Navigating Your Software Development Career Newsletter

An e-mail newsletter that will help you level-up in your career as a software developer! Ever wonder:

✔ What are the general stages of a software developer?
✔ How do I know which stage I'm at? How do I get to the next stage?
✔ What is a tech leader and how do I become one?
✔ Is there someone willing to walk with me and answer my questions?

Sound interesting? Join the community!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .