Microservices Architecture

Question 1

Three main considerations when deciding between Monolithic and Microservices Architectures?

Answer 1

1. Requirements: Stakeholders, Endusers, Functions, inputs & outputs
2. Resources: Time, Money, Engineering Resources, Knowledge
3. Tradeoffs: Development Complexity, Scalability, Time to deploy, Flexibility, Operational Cost, Reliability

Question 2

Tradeoff: Development Complexity

Answer 2

Development Complexity
Development complexity represents the effort required to deploy and manage an application.

Monoliths - one programming language; one repository; enables sequential development

Microservice - multiple programming languages; multiple repositories; enables concurrent development

Question 3

Tradeoff: Scalability

Answer 3

Scalability captures how an application is able to scale up and down, based on the incoming traffic.

Monoliths - replication of the entire stack; hence it’s heavy on resource consumption

Microservice - replication of a single unit, providing on-demand consumption of resources

Question 4

Tradeoff: Deployment

Answer 4

Time to Deploy

Time to deploy encapsulates the build of a delivery pipeline that is used to ship features.

Monoliths - one delivery pipeline that deploys the entire stack; more risk with each deployment leading to a lower velocity rate

Microservice - multiple delivery pipelines that deploy separate units; less risk with each deployment leading to a higher feature development rate

Question 5

Tradeoff:Flexibility

Answer 5

Flexibility
Flexibility implies the ability to adapt to new technologies and introduce new functionalities.

Monoliths - low rate, since the entire application stack might need restructuring to incorporate new functionalities

Microservice - high rate, since changing an independent unit is straightforward

Question 6

Tradeoff: Operational Cost

Answer 6

Operational Cost
Operational cost represents the cost of necessary resources to release a product.

Monoliths - low initial cost, since one code base and one pipeline should be managed. However, the cost increases exponentially when the application needs to operate at scale.

Microservice - high initial cost, since multiple repositories and pipelines require management. However, at scale, the cost remains proportional to the consumed resources at that point in time.

Question 7

Tradeoff: Reliability

Answer 7

Reliability
Reliability captures practices for an application to recover from failure and tools to monitor an application.

Monoliths - in a failure scenario, the entire stack needs to be recovered. Also, the visibility into each functionality is low, since all the logs and metrics are aggregated together.

Microservice - in a failure scenario, only the failed unit needs to be recovered. Also, there is high visibility into the logs and metrics for each unit.

Question 8

Which practices should be built into a microservice to increase resiliency, lower the time to recovery, and provide transparency of how a service handles incoming requests.

Answer 8

1. Health checks
2. Metrics
3. Event logs
4. Tracing
5. Resource consumption

Question 9

4 main kinds of operations that take place during maintenance of microservices

Answer 9

SPLIT
A split operation - is applied if a service covers too many functionalities and it’s complex to manage. Having smaller, manageable units is preferred in this context.

MERGE
A merge operation- is applied if units are too granular or perform closely interlinked operations, and it provides a development advantage to merge these together. For example, merging 2 separate services for log output and log format in a single service.

REPLACE
A replace operation - is adopted when a more efficient implementation is identified for a service. For example, rewriting a Java service in Go, to optimize the overall execution time.

RETIRE
A stale operation - is performed for services that are no longer providing any business value, and should be archived or deprecated. For example, services that were used to perform a one-off migration process.

Question 10

Extensibility VS Flexibility

Answer 10

EXTENSIBILITY
Extensibility is all about the addition of new behaviors. Code is said to be extensible if adding new behaviors to it has little or no impact on existing behaviors. Said another way, the software is extensible if adding new behavior involves adding new code without changing existing code.

FLEXIBILITY
Flexibility focuses on how easy it is to change existing code so that it can be used in a way that it wasn’t originally designed for.

Both extensibility and flexibility are characteristics that dictate the level of ease with which someone can perform perfective maintenance