very brief Introductory notes On Microservices

 This would be mainly some notes I have took 3- years ago when I first read Sam Newman's book building microservices, along with some points gathered along the time since then.

Let's start with a definition, what are microservices:

These are independently deployable small services build around a business domain.

 a little bit of details, These Microservices needs to be:

1- Able to change independently of each other.

2- Be Deployed by  themselves without requiring the consumes to change.

3- All communications between the services are via network calls to enforce separation and avoid the perils of tight coupling.

some other Key points to the core of the definitions and introduction:

  • How small is small: a Microservice is something that could be rewritten in around 2 weeks. (I believe this might be debatable or controversial).
    Another suggestion is that it should be small enough that you can keep the structure in your mind
    another key notice from Sam Newman, was that it seems like we have a good sense to notice when something is big or too big , so we can use this inversely that when something is not too big then its probably small.
  • What to Expose: we need to think what our services are going to expose  and what should they hide because in case of too much sharing, our consuming services become coupled to our internal representations, this would eventually decrease autonomy as this would require additional coordination with our consumers when when making changes .

Key Benefits from Microservices :

  1. Technology Heterogeneity:  Instead of having to use choose one technology for the whole application as in case of Monoliths, we can choose what fits the job this is also extended to data stores as well , whereas one service can have  a relational database while another one uses a graph database or a document based one and so on.
  2. Reliance : if one component fails and the failure does not cascade you can isolate the problem and the rest of the system can carry on working .
  3. Scaling: In monoliths we scale everything together , while in microservices we can scale those services that need scaling.
  4. Ease of Deployment: in case of monolithic architecture a one line of code change might lead to the whole application to be deployed to deliver this change.
    In Microservices we can make a change in one service and deploy it independently of the rest of the system. 
    This means that we can check our code for problems faster and we can make faster rollback if needed, which eventually means we can get new features to clients faster.
  5. Composability: we open opportunities for function re-use and we also allow for our functionality to be consumed in different ways for different purposes.
  6. Optimizing for replaceability: with our individual services being small in size the cost to replace them with a better implementation is easier to manage.
The Flipside:

But as with everything with architecture and software there is no one size fits all , so there are some drawbacks with the microservices as well as it totally depends on the  case and the domain.
Migration from Monolithic to Microservices might need a lot of time and planning as you would need to restructure you domain to a set of sub-domains ,  this also goes for business concerns, and subsequently the team itself so it is not only a technology problem.

There are are a massive list of concerns that needs to be addressed: 
Monitoring and Health Checks , , Tooling, Fallbacks, Fault Tolerance , Logging, Service Discovery, Tracing, Build Pipeline, Release Pipelines, Scaling and Load Balancing , network latency, Development environment and Debugging.

This might seems like stating the obvious but Microservices are not goal themselves they should be a way for a far more meaningful goals like discussed above.


Microservices do have a learning curve related to different tooling and concepts discussed above in order to be able to reap the corresponding benefits that is why this decision should be based on domain, team knowledge , time constraints , etc.

Microservices -and any distributed systems in this regard-  I think needs a more experienced/mature team to handle it , while Monolith is more straightforward even though it might suffer from bottlenecks no clear boundaries , ..etc.

Tiered Architecture vs Microservice:

In traditional N-Tier Architectures , we divide the application to layers based on the functionality of each layer, for example in the more usual 3 Tier architecture we have a layer for presentation , a layer for Business Logic and a layer for Database , but what happens is that a change in one layer would usually need a change in other layers as well.
while in Microservices we would have different business functionalities represented as service and as stated previously each one has to be independently deployable .
So consider for example an e-store application that runs as monolith , where there should be a change by introducing a new property to the user profile let's say adding the user's birth day , such. a change would require a change in the UI of the Profile page along with the api consumed by this ui , also the database to hold this user input data, like the figure below:
                                        3-Tier Architecture with usual scope of change
if we are to have the same change in a microservice architecture:
we would have a single microservice for the user-profile , another for payment,...etc so the change would be in only one service .



so in general this would show that in a grander scheme, microservice architecture provide a cohesion in the system based on business functionality (Payment, Stocks, Order, User Profiles,...etc) rather than a technical cohesion (Database, frontend , backend) . 
So I think to some point this is also a direct reflection on Conway's law: 
"Organizations who design systems,  are constrained to produce designs which are copies of the communications structures of these organizations"
the way we used to form teams is based on their areas of competency/expertise (front end , backend -C#, Java , Database Admins ....etc) , while currently with the domain driven design gaining more appeal and as a way to reduce silos and facilitate thing like continuous integration and delivery, we are dividing the teams along vertical business lines like the last figure has shown. 
So in case of microservices we would have a team with a full end-to-end responsibility for making changes related to the user-profile in general.


Resources :

 1- Article about a team that was thinking to migrate to Microservice then while weighing Pros and Cons over time they think against it :
Why our team cancelled our move to microservices

2-Airbnb journey to Microservices: The Human Side of Airbnb’s Microservice Architecture


4- A hilarious take on complications teams might suffer from with microservices:
https://www.youtube.com/watch?v=y8OnoxKotPQ

5- jokes aside though , Dave Farley's well articulated take on the microservices pros and cons: 
The Problem With Microservices

6- LinkedIn migration to Microservices LinkedIn _microservices

7- Company called Segment moved from Monolith to microservices then to monolith again.
Goodbye Microservices

8- Company named Istio that has moved from microservices to monolith again:





Comments

Post a Comment

Popular posts from this blog

Head First Architecture Chapter-3

Image
 This chapter is mainly about the fact that software architecture has a lot of tradeoffs. An Application Scenario: A scenario was given about an application for selling sneakers (this could be anything tbh), that helps people buy, sell, and trade collectible sneakers.  The initial architecture was simple a single service that responds to requests send by mobile app users. So there are 2 options we might get into the tradeoff between them , which are using queues or using topics for messaging : so we can do the tradeoff analysis for each approach of them: 1- Queue approach  Pros:  a- It is more secure as the publishing service is aware of the receivers as each new service would have a new queue and the publishing service would need to know about it to send to it. b- we can have a different format for each receiver. c- we can scale and monitor independently each queue.  2- Queue approach Cons: a- Higher degree of coupling which hurts extensibility. b- Require...
Read more

The Culture Map -Some notes

Image
 I have been reading over the last few days  a book titled the Culture Map, it is extremely amusing and a clear eye opener for me . It is about the different culture contexts and how they can affect us in the work environment , implicitly and unintentionally sometimes. This also does not mean to follow  the different stereotypes as people from same country can different traits for sure, but also the cultural effect can have huge impacts on behaviors for sure. The Book Defines 8 Scales /Measurements that are needed in any business environment and how the cultural differences might affect them. 1- Communication: Low Context vs High Context : There are some cultures that start any communication without suggestion that there is a common context between different parties , that is why they tend to clearly document every step and  leave no space for speculation those are low context style of communication. While there are some other cultures that tend to assume an existing...
Read more

Head First Architecture

Image
 I have found out that there is a new book that is under early release version on the O'reilly website  called Head First Architecture that is to follow on the great Head First series , as I have read the Head First Design patterns book and really liked it several years ago and the fact that Neal Ford  (One of the authors of Software Architecture An Engineering Approach) is one of the authors, I take a look on it and found that it really is adding a lot of value at least for me, so I am doing a brief summary of it in the next couple of posts hopefully. At first it draws an analogy between building houses and building software systems, in this analogy the building plan or the blueprint of houses is the equivalent of the software architecture, what might be the similar point between both: 1- Both specify the structure of the system, in the house case it defines the rooms, walls, stairs and floors, in the case of the software system it defines the databases, services, user-i...
Read more