The Long Road to Microservices

2011

in 2011 there was a talk-server, an API that everyone would talk to to get stuff

increase in members, so needed to do more, so cooridnation needed within teams

• e.g. let's focus on the video share functionality
• and everyone worked together on on functionality

then the team expanded again

• there were more things that different parts of the large team wanted to do at the same time

used to be one team, and now the team needed to coordinate more and more within the team, and it was difficult to prioritize, and a lot of coordination needed within the team

the team slowed down in terms of development

split team

then the team is split by functionality

stamp team focuses on new stamp VOIP team focuses on video

2019

app server became a huge microservice

and its not really a microservice at all

but one square (functionality) included multiple services and multiple members

e.g. the stickershop has 20 services included in the stickershop team

now

now the messaging service is a 300,000 line monolith

every team moves at a different speed

the good

development speed up

the bad

entire service could have outages people from different teams needed to solve the outage together

concept needed to build microservice architecture

1. connectivity - armeria
2. directory service- centrla dogma
3. routing - LEGY

Armeria

• connectivity function (RPC layer)

async RPC/REST library

• built on top of Java8, Nettym HTTP/2, Thrift, gRPC
• most connections are implementation with a decorator pattern (HOC)
• user acn create their own client according to their required characteristics
• how the load should be managed, how the connection should be managed, doesn't need user to configure

Central Dogma

central information management

• directory service
• repo for textual configs (yaml, jenkins buildfile)
• highly available, version controlled, advanced query mechanism
• start time and run time is configured safely
• can setup notifications when configs change

example

armeria client doesnt need to know where the server exists url included in message

LEGY

• API gateway written in erlang
• to reduce communicatoin latency, LEGY is installed at the closest data center
• url_handler similar to nginx

example: moving stickershop to microservices

2017

stamp ownership data is stored in REDIS redis data is used to validate the sticker information when the user buys a sticker, that data is created from scratch and placed onto the user's redis document when a user (with a large ownership of >10,000 stickers) purchases a sticker, the talk-server (API gateway) stops momentarily because it's really slow the ripple effect causes entire servies to be affected

solution

change data structure so that the slow query would not happen introducing the circuit-breaker pattern to stop ripple effects

BUT communication quanitty would be increased