1 of 16

Microservices:

What not to do and to expected

Chakrit Likitkhajorn

All expectation come from blog post and articles based on personal experienced

2 of 16

“I have spaghetti code.”

​

“Do microservice, so we can be modular and maintainable”

3 of 16

Spaghetti service can be real

4 of 16

Spaghetti service in Real life

200 API Called for each request (back and forth like crazy)

  • Service SLA: 150ms and 99% uptime
  • 200 * 150 = 30 secs
  • 99% uptime power by 200 calls: 13% uptime for each request

Same old unmaintainable spaghetti codebase, plus network stability problem

5 of 16

“Confusing cause and effect”

​

Microservice architecture is clean because only clean codebase can become microservices

​

not the other way around.

6 of 16

“Let do technical analysis to separate microservices boundaries”

​

For example: Code dependency analysis

7 of 16

Wow!!! Now service release take only 10 seconds. We have awesome release cycle

8 of 16

Meanwhile...

To actually release feature, we need

  • Team 1 needs to work on service A, and produce mock endpoint
  • Team 2 needs to work on service B after service A provided endpoint
  • Team 3 needs to work on Frontend side, using service provide by Team 2
  • To actually complete the requirement, Team 4 also need to create some little scheduler connected to service provided by Team 1 and 2
  • Every team must setup meeting and schedule accordingly

9 of 16

And then….

Technical release cycle: 1 minute for each service

Business release cycle since requirement was confirmed: 4 weeks

​

​

​

10 of 16

And then...

  • Code dependency become very clean and few

At the cost of

  • Human & Team dependency: Tightly couple

​

Why do I need technical release cycle of 1 minute anyway?

If business release cycle become like, 1 month?

11 of 16

Use business perspective

​

Remove human dependency

​

Analyze of requirement and business release

12 of 16

Read by queue system

13 of 16

Read is actually easier to manage without persistent.

​

Timeout and Retry is easier to deal with

14 of 16

We tried this, and we nearly reinvent the REST itself to deal with timeout, cancellation, disconnected client, etc…

​

Moral: Queue is not suitable for read

15 of 16

Some more things that you should not do nor expected

  • No data duplication policy
  • Complex system calling each other
  • N-Tier style microservices (blame
  • Microservices that too micro that no one actually maintaining anything

16 of 16

Thank you

​

https://vimeo.com/191341705

​

“Avoiding Microservice Megadisaster”

​

Jimmy Bogard