99 lines
No EOL
4.7 KiB
Markdown
99 lines
No EOL
4.7 KiB
Markdown
Basics
|
|
https://www.youtube.com/watch?v=kTp5xUtcalw&t=335s : freecodecamp ones
|
|
https://www.youtube.com/playlist?list=PLinedj3B30sDvBfeK9EPz9pcJNlM0f3ph : piyush garg ones
|
|
https://www.youtube.com/watch?v=pR5jOQnfNtY : docker in mobile
|
|
|
|
### Microservices architecture
|
|
- A variant of the service oriented architecture(SOA) structural style - arranges an aplication as a collection of loosely coupled services
|
|
- In a microservices architecture, services are fine-grained and the protocols are lightweight.
|
|
|
|
|
|
### Monolithic architecture
|
|
- built as a single unt
|
|
- deployed as a single unit (building time would be high)
|
|
- duplicated on each server
|
|
- ex: 3-tier apps like MVC architecture
|
|
|
|
|
|
### Microservices
|
|
- Breaking big system into smaller parts and each with its own responsibility.
|
|
- Scale these smaller pieces independtly from each other
|
|
- Loosely coupled : No strong bond because we expose functionality though api
|
|
- Enable autonomous development by different teams, languages : Can be written by smaller teams so outsourcing and independent development is possible so they can even use different programming languages too.
|
|
- Each microservices can have its own separate database
|
|
|
|
|
|
### Diagrams
|
|
Monolithic architecture
|
|
|
|
|
|
For deploying in more servers
|
|
|
|
|
|
|
|
Microservice architecture
|
|
|
|
|
|
For scaling
|
|
|
|
|
|
Monolith to microservices
|
|
|
|
|
|
|
|
## Microservice anti patterns
|
|
|
|
### Challenges
|
|
- Risk of unneccessary complexities when converting monlithic to so many microservices
|
|
- numerous services can be impacted too
|
|
- Security of microsercices is also a challenge
|
|
|
|
|
|
### Microservices Benefits
|
|
- Improved fault isolation : wont take whole system down if one of them go down
|
|
- less vendor lock in or technology in bcz of use of open source technologies
|
|
- Easier to understand
|
|
- Smaller and faster development
|
|
- Scalibility
|
|
|
|
### Microservices - Drawbacks
|
|
- Complexity is added to resolve complexity issues
|
|
So need to start it slowly with a pace that everyone can keep it
|
|
- Its easier to test independent services but it is also necessary to test whole system to check if they r communicating with each other properly or not.
|
|
- Is deployment really simpler
|
|
- challenges with multiple times
|
|
- One microservice update other microservices too
|
|
- Need to have multiple databases too
|
|
- Latency issues : As there r so many routes needs to be taken as each microservice will call api to talk to each other so there will be latency issues too
|
|
- Transient errors : Sometimes between calls there maybe errors which can be fixed with retry so make sure to do that
|
|
- Multiple point of failure
|
|
- Security issues as when communicating we may not want to expose everything and needed to be take care of that
|
|
|
|
|
|
|
|
## Cloud Natives
|
|
- Cloud natives uses containers, service meshes, microservices, immutable infrastructure and declaritive APIs.
|
|
Immutable infrastructure means instead of updating it we replace with newer versions.
|
|
These technologies is used to build and run scalable applications in modern, dynamic environments such as public, private and hybrid cloud.
|
|
- use of metrics, creation and updation are automated and frequent deployment of eye impact changes
|
|
- using of open source projects
|
|
|
|
|
|
### Cloud native concepts
|
|
- Speed and agility
|
|
- Application architecture
|
|
|
|
- Mentality : Pets vs Cattle
|
|
- Unlike VM where we need to take care it, infrastructure in this immutable and disposable like cattle
|
|
- Provisioned in minites and destroyed on demand
|
|
- Never updated or repaired, just re-provisioned/replaced.
|
|
- Cloud Native Trail Map
|
|
- Breaks journey into measurable objects
|
|
- Containerization
|
|
- Done through docker containers
|
|
- CI/CD
|
|
- Setup Continuous Integration/Continuous Delivery (CI/CD) so changes to source code automatically result in a new container being built, tested and deployed to staging and eventually perhaps to production
|
|
- Orchestration : Eg : Kubernetes and deploy using help chart
|
|
- Obervability and analysis : Monitoring, logging and tracing .
|
|
- Service proxy, discovery and mesh : Eg :envoy, CoreDNS, LinkerD
|
|
- Networking, Policy and Security: Eg : CNI, Open policy agent, Falco |