Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Enterprise > Wk 2 Monoliths Microservices > Flashcards

Wk 2 Monoliths Microservices Flashcards

1
Q

Monolith architectural style:

A

Products are run by a single process and formed by a collection of modules.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Monolith:

A

Single process computer program with an internal structure formed by modules.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Procedure calls:

A

Communication between modules

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Monolith advantages:

A
  • 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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Term monolith origins:

A

Monolith originated in the Linux community and used negatively as a synonym to legacy applications

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Two pizza rule:

A

Every internal team needs to be small enough to be adequately fed by two pizzas.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Microservices Architectural style:

A

Products and applications are formed from a collection of microservices, each run by a separate process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Message passing:

A

Communication between microservices

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Microservice:

A

Application built with small independent components and around business capabilities. It is independently deployable.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Characteristics of microservices:

A

Componentization via services:
Organization around business and decentralised governance.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Microservice Advantages:

A
  • coordination cost reduction
  • easier deployment
  • release when it is ready
  • development using the best technology for the service
  • robustness
  • scaling
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Coordination cost problem:

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Why does a microservice architecture increase robustness?

A

Because failure of one service does not impact another service.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Why are microservices good for scaling?

A

Resources for one service are not the same for another.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Microservice architecture design problems:

A
  • Long feedback loops
  • too many moving parts
  • analysis paralysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Why are there long feedback loops with microservices ?

A

It is difficult to do, identifying the impact of a decision until a problem arises, making it difficult to evaluate problems.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

What is the issue with having many parts ?

A

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 .

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Analysis paralysis:

A

Decisions are both impactful and difficult to measure leading to endless speculation. End in a state of indecision trying to model endless permutations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Conway’s law:

A

1968 “any organization that design it’s system will inevitably produce a design whose structure is a copy of the organisations communication structure”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

What structures do many organisations follow:

A

A reverse of Conway’s law, organizations communication structure the same as their service structure.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Building a MVP:

A
  • microservoces late
  • microservices early
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Microservices late:

A

Start with a monolith to entre the marketplace earlier and change to microservices later. Ready to learn from the customer.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Migration :

A

When a business decides to move from a monolith to the microservices architectural structure.

24
Q

Strangler pattern:

A

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)

25
Q

Microservice early:

A

Enter marketplace later with a better structured product, ready to make customer segment pivot.

26
Q

Microservice design:

A
  • high coesion
  • loose coupling
27
Q

High cohesion:

A

All related functionality is in one component. Unrelated in others.

If functionality needs changing only one component needs changing.

28
Q

Loose coupling:

A

Changing one component does not necessitate change in another

29
Q

Microservices principles:

A

-DRY
-KISS
-SRP
-YAGNI
- Least Knowledge

30
Q

DRY :

A

Don’t repeat yourself: duplicate things should be merged.

31
Q

KISS:

A

Keep it simple, stupid

32
Q

SRP:

A

Single responsibility principle, components should have only one responsibility and one reason to change.

33
Q

YAGNI

A

You aren’t going to need it

34
Q

Least knowledge

A

Components should only know about the structure of components they deal with directly

35
Q

Microservices:

A

Indipendently resealable services modelled around a business domain

Technologically agnostic
Type of service oriented architecture

36
Q

Hexagonal architecture pattern:

A

Internal implementation separate from external interfaces

37
Q

Types of monoliths:

A

Modular
Distributed

38
Q

Modular :

A

Lack decomposition on a code level

39
Q

Distributed:

A

System consists of multiple services but for some reason the entire system must be deployed together.

40
Q

Distributed monolith:

A

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.

41
Q

Delivery contention:

A

Different developers want to change code, or different teams wanting to finish functionality at different times.

42
Q

Containers:

A

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.

43
Q

Microservices advantages:

A

-tecnology heterogeneity
-Robustness
-scaling
-ease of deployment
- organisational alignment
- composability

44
Q

Microservice disadvantages:

A
  • Developer experience
  • technology overload
  • cost
  • reporting
  • monitoring and troubleshooting
  • security
  • testing
  • latency
  • data consistency
45
Q

Developer experience:

A

More resource intensive runtimes can limit the number of services that can run on a machine.

46
Q

Technology overload:

A

Difficult to balance the breath of the technology you use and cost of diversity.

47
Q

Reporting:

A

More difficult as data is scattered across services

48
Q

Monitoring and troubleshooting:

A

In an architecture with thousands of processes it’s hard to tell what causes issues

49
Q

Security:

A
  • monoliths information is in the process
  • SOA ( Microservices) informatoon flows through the network between services
50
Q

Testing:

A

The more functionality is tested the more confident in the system. End to end testing in microservices cover a much higher scope of functionality.

51
Q

Latency:

A

Information in one process now needs to be serialised .

52
Q

When not to use monoliths :

A
  • startups / new products -> domain changes and small teams
  • organizations that create software deployed by the customer
53
Q

When to use monoliths :

A
  • large scale ups
  • SaaS software as a service application ( expected to run 24/7 usually)
  • cloud based platforms
54
Q

Monolith properties:

A
  • highly cohesive
  • loosely coupled
  • easy to debug
  • efficient
  • easy to manage
55
Q

Properties of microservices:

A
  • small in size ( maintained by one team)
  • highly cohesive
  • loosely coupled
  • independently deployable
  • decentralised governance

Enterprise (8 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions