Wk 2 Monoliths Microservices Flashcards
Monolith architectural style:
Products are run by a single process and formed by a collection of modules.
Monolith:
Single process computer program with an internal structure formed by modules.
Procedure calls:
Communication between modules
Monolith advantages:
- Domain driven design : Modules can be made to correspond to business functions
- permissionless innovation : modules developed by teams working on agreed interfaces
- automatic deployment to version control of the program as a whole
Term monolith origins:
Monolith originated in the Linux community and used negatively as a synonym to legacy applications
Two pizza rule:
Every internal team needs to be small enough to be adequately fed by two pizzas.
Microservices Architectural style:
Products and applications are formed from a collection of microservices, each run by a separate process.
Message passing:
Communication between microservices
Microservice:
Application built with small independent components and around business capabilities. It is independently deployable.
Characteristics of microservices:
Componentization via services:
Organization around business and decentralised governance.
Microservice Advantages:
- coordination cost reduction
- easier deployment
- release when it is ready
- development using the best technology for the service
- robustness
- scaling
Coordination cost problem:
When one team is dependent on another to deliver. Appears in multi team projects and often there is a choice between slowing down or coordinate the teams ( tension between safety and speed )
Microservice minimises those costs.
Why does a microservice architecture increase robustness?
Because failure of one service does not impact another service.
Why are microservices good for scaling?
Resources for one service are not the same for another.
Microservice architecture design problems:
- Long feedback loops
- too many moving parts
- analysis paralysis
Why are there long feedback loops with microservices ?
It is difficult to do, identifying the impact of a decision until a problem arises, making it difficult to evaluate problems.
What is the issue with having many parts ?
Microservices are complex adaptive systems. When all parts come together an emergent system behaviour is produced. Small changes in a decision may impact in unexpected ways .
Analysis paralysis:
Decisions are both impactful and difficult to measure leading to endless speculation. End in a state of indecision trying to model endless permutations.
Conway’s law:
1968 “any organization that design it’s system will inevitably produce a design whose structure is a copy of the organisations communication structure”
What structures do many organisations follow:
A reverse of Conway’s law, organizations communication structure the same as their service structure.
Building a MVP:
- microservoces late
- microservices early
Microservices late:
Start with a monolith to entre the marketplace earlier and change to microservices later. Ready to learn from the customer.
Migration :
When a business decides to move from a monolith to the microservices architectural structure.
Strangler pattern:
Pattern to migrate from monolithic to microservice. Manages the migration by having a temporary facade providing access to the modules.
Modules are replaced behind the facade that provides access to them. ( Slowly strangled by microservices)
Microservice early:
Enter marketplace later with a better structured product, ready to make customer segment pivot.
Microservice design:
- high coesion
- loose coupling
High cohesion:
All related functionality is in one component. Unrelated in others.
If functionality needs changing only one component needs changing.
Loose coupling:
Changing one component does not necessitate change in another
Microservices principles:
-DRY
-KISS
-SRP
-YAGNI
- Least Knowledge
DRY :
Don’t repeat yourself: duplicate things should be merged.
KISS:
Keep it simple, stupid
SRP:
Single responsibility principle, components should have only one responsibility and one reason to change.
YAGNI
You aren’t going to need it
Least knowledge
Components should only know about the structure of components they deal with directly
Microservices:
Indipendently resealable services modelled around a business domain
Technologically agnostic
Type of service oriented architecture
Hexagonal architecture pattern:
Internal implementation separate from external interfaces
Types of monoliths:
Modular
Distributed
Modular :
Lack decomposition on a code level
Distributed:
System consists of multiple services but for some reason the entire system must be deployed together.
Distributed monolith:
Has all the disadvantages of a distributed system and a single process system.
Highly coupled architecture makes it that all changes ripple across service boundaries.
Delivery contention:
Different developers want to change code, or different teams wanting to finish functionality at different times.
Containers:
provide a lightweight way to isolate execution for a single service instance.
To manage containers you need a container orchestration platform.
Containers are hard to justify if you have few microservices.
Microservices advantages:
-tecnology heterogeneity
-Robustness
-scaling
-ease of deployment
- organisational alignment
- composability
Microservice disadvantages:
- Developer experience
- technology overload
- cost
- reporting
- monitoring and troubleshooting
- security
- testing
- latency
- data consistency
Developer experience:
More resource intensive runtimes can limit the number of services that can run on a machine.
Technology overload:
Difficult to balance the breath of the technology you use and cost of diversity.
Reporting:
More difficult as data is scattered across services
Monitoring and troubleshooting:
In an architecture with thousands of processes it’s hard to tell what causes issues
Security:
- monoliths information is in the process
- SOA ( Microservices) informatoon flows through the network between services
Testing:
The more functionality is tested the more confident in the system. End to end testing in microservices cover a much higher scope of functionality.
Latency:
Information in one process now needs to be serialised .
When not to use monoliths :
- startups / new products -> domain changes and small teams
- organizations that create software deployed by the customer
When to use monoliths :
- large scale ups
- SaaS software as a service application ( expected to run 24/7 usually)
- cloud based platforms
Monolith properties:
- highly cohesive
- loosely coupled
- easy to debug
- efficient
- easy to manage
Properties of microservices:
- small in size ( maintained by one team)
- highly cohesive
- loosely coupled
- independently deployable
- decentralised governance
