https://www.youtube.com/watch?v=PFQnNFe27kU
Principles of microservices by Sam new man
Principle
Source:
12factor.net
Microservices are nothing but Opionionated form of SOA
Small Autonomous Services, that work together, modelled around a business Domain.
The Architecture should buy the options for us.
We should able to have options to do more stuff later, if we decide to do so.
If we plan to invest in this finer grained architecture, and in exchange for which, we get a lot of different choices.
Choices can be good.
Monolithic software:
One main technology stack.
Maybe only one type of main idiomatic design used in that system.
This can actually be a source of large amount of Friction.
we may end up taking different decisions in similar situations.
We end up with a lot of inconsistencies.
We may use set of Framing or Value statements that help us in decision making
Principles that guide the decision making.
This stuff when we follow it well,
Design decisions, and constraints for the Heroku platform itself.
This guides your decision making.This was set of principles
Architecture principles :
These things, that decide, how we are going to design our software, they exist for a reason.
They exist to drive the company forward.
They expand rapidly to move forward.
These principles help us to move fast.
There is much less emphasis about being consistent.
There is much more emphasis about empowering teams.
Practices:
-----------
These are the mechanisims by which you implement the principles
Our Architecture principles change a bit more.
We learn stuff
We realize that all this stuff was great.
We ask the question, how are things done around here ?
Principles of driving towards an end goal.
The End goal being, driving the company forward.
The 12 factors for heroku to have an end goal, is that your application should work on Heroku.
Research:
------------
What are the things that microservices do, in order to get to this end goal
The end goal being, extracting all the benefits as much as they can from micro services.
So, what are the principles, that we need to follow to build these Things .
The Small Autonomous Services, that work together.
1) First principle : Modeling things around a business Domain.
This gives us more Stable API's
2) Embracing the Culture of Automation, and the fact that we got a lot more deployable units
3) Hiding the implementation Details to allow one service to evolve independently of another
4) Decentralizing as much as possible
Both of the Decision making power, to Architectural Design Concepts
5) Deploying independently
6) Consumer FIRST ( Outside In )
7) Isolating Failure
8) Making sure the systems are highly observable
Principle 1:
--------------- When we look at the Architecture of Microservice system, we should have some idea about the Domain, in which it operates.
Compare that with lot of the services that are coming out of the Service Oriented Architecture
where people took a
Small Autonomous Services, that work together, modelled around a business Domain.
The Architecture should buy the options for us.
We should able to have options to do more stuff later, if we decide to do so.
If we plan to invest in this finer grained architecture, and in exchange for which, we get a lot of different choices.
Choices can be good.
Monolithic software:
One main technology stack.
Maybe only one type of main idiomatic design used in that system.
This can actually be a source of large amount of Friction.
we may end up taking different decisions in similar situations.
We end up with a lot of inconsistencies.
We may use set of Framing or Value statements that help us in decision making
Principles that guide the decision making.
This stuff when we follow it well,
Design decisions, and constraints for the Heroku platform itself.
This guides your decision making.This was set of principles
Architecture principles :
These things, that decide, how we are going to design our software, they exist for a reason.
They exist to drive the company forward.
They expand rapidly to move forward.
These principles help us to move fast.
There is much less emphasis about being consistent.
There is much more emphasis about empowering teams.
Practices:
-----------
These are the mechanisims by which you implement the principles
Our Architecture principles change a bit more.
We learn stuff
We realize that all this stuff was great.
We ask the question, how are things done around here ?
Principles of driving towards an end goal.
The End goal being, driving the company forward.
The 12 factors for heroku to have an end goal, is that your application should work on Heroku.
Research:
------------
What are the things that microservices do, in order to get to this end goal
The end goal being, extracting all the benefits as much as they can from micro services.
So, what are the principles, that we need to follow to build these Things .
The Small Autonomous Services, that work together.
1) First principle : Modeling things around a business Domain.
This gives us more Stable API's
2) Embracing the Culture of Automation, and the fact that we got a lot more deployable units
3) Hiding the implementation Details to allow one service to evolve independently of another
4) Decentralizing as much as possible
Both of the Decision making power, to Architectural Design Concepts
5) Deploying independently
6) Consumer FIRST ( Outside In )
7) Isolating Failure
8) Making sure the systems are highly observable
Principle 1:
--------------- When we look at the Architecture of Microservice system, we should have some idea about the Domain, in which it operates.
Compare that with lot of the services that are coming out of the Service Oriented Architecture
where people took a
Deployment platform in AWS
Cheaply provision Test and Dev Environment
Services being owned and operated by Teams
As a starting Step , the team got 2 services up in 3 months.
This went really well for them.
It took an another 9 months to get 7 more services up.
It took another , 6 months to get 60 different services up.
60 Different types of services.
Decomposed the JVM based platform .
Once the sufficient investment in the platform kicked in, then the things spiked up.
AUTOMATION
Can i write a line of code, and provision an isolated operating System or provision a Service.
Have i got sufficient Testing in place, that helps me understand weather or not i can release the software.
Am i treating every checkin as a Release Candidate.
Have i really got rigor around that stuff.
All of these things are the stuff we have to invest in.
There will be a lot of upfront work to get this working, and this will require ongoing investment as well.
3. Hiding Implementation details
I feel confident in sharing with you.
Scaling up is easy
It is easy to do.
It allows two services to share information.
If we expose the DB to other service in this way, we expose the implementation Details
Whats very bad is the integration of 40 separate services with the Database Schema :(
We could not track down who all those people were.
This drastically impacts, the ability to change , design and evolve the ability of the system.
It is easy to do.
It allows two services to share information.
If we expose the DB to other service in this way, we expose the implementation Details
Whats very bad is the integration of 40 separate services with the Database Schema :(
We could not track down who all those people were.
This drastically impacts, the ability to change , design and evolve the ability of the system.
If you want to gather information from a service, we need to change the way it requests information.
We need to make a request, we need to make a API call. We need to send a message to it.
In this way at the API layer, people owning the service get to decide what is hidden and what is not hidden.
It allows them to change the internals of the system safely.
HIDE your Databases.
This will be one of the most important things to allow your services to scale up independently.
We still need to think about what that API shares as well.
The bounded context is sort of an Explicit boundary within a Domain.
Example of Context.
We need to make a request, we need to make a API call. We need to send a message to it.
In this way at the API layer, people owning the service get to decide what is hidden and what is not hidden.
It allows them to change the internals of the system safely.
HIDE your Databases.
This will be one of the most important things to allow your services to scale up independently.
We still need to think about what that API shares as well.
The bounded context is sort of an Explicit boundary within a Domain.
Example of Context.
