Ch 1: What are Microservices?

Question 1

1: What is the main purpose of this book?

Answer 1

This book as a whole is designed to give a broad overview of the impact that microservices have on various aspects of software delivery.

Question 2

2: What are microservices?

Answer 2

Microservices are independently releasable services that are modeled around a business domain. A service encapsulates functionality and makes it accessible to other services via networks—you construct a more complex system from these building blocks.

Question 3

3: Name one advantage of microservice.

Answer 3

They are technology agnostic, which is one of the advantages they offer.

Question 4

4: Explain and draw how are microservices treated from the outside.

Answer 4

From the outside, a single microservice is treated as a black box. It hosts business functionality on one or more network endpoints (for example, a queue or a REST API, as shown in Figure1-1)

Question 5

5: Since internal implementations of microservices are hidden, what effect this has on databases? How is this concept called?

Answer 5

This means microservice architectures avoid the use of shared databases in most circumstances; instead, each microservice encapsulates its own database where required.

Microservices embrace the concept of information hiding.1 Information hiding means hiding as much information as possible inside a component and exposing as little as possible via external interfaces.

Question 6

6: What principle should be kept in mind when adding changes to a microservice?

Answer 6

Changes inside a microservice boundary (as shown in Figure1-1) shouldn’t affect an upstream consumer, enabling independent releasability of functionality.

Question 7

7: What is a service-oriented architecture (SOA) and what is the meaning of the service in this context?

Answer 7

Service-oriented architecture (SOA) is a design approach in which multiple services collaborate to provide a certain end set of capabilities. (A service here typically means a completely separate operating system process.)

Question 8

8: What are the usual problems when trying to implement SOA?

Answer 8

Many of the problems laid at the door of SOA are actually problems with things like communication protocols (e.g., SOAP), vendor middleware, a lack of guidance about service granularity, or the wrong guidance on picking places to split your system.

Question 9

9: What is the difference between SOA and microservices?

Answer 9

You should think of microservices as being a specific approach for SOA in the same way that Extreme Programming (XP) or Scrum is a specific approach for Agile software development.

Question 10

10: What are the key concepts of microservices?

Answer 10

• Independent Deployability
• Modeled Around a Business Domain
• Owning Their Own State
• Size
• Flexibility
• Alignment of Architecture and Organization

Question 11

11: What is the meaning behind Independent Deployability concept?

Answer 11

Independent deployability is the idea that we can make a change to a microservice, deploy it, and release that change to our users, without having to deploy any other microservices.

Question 12

12: What it means that to ensure Independent Deployability microservices must be loosely coupled?

Answer 12

To ensure independent deployability, we need to make sure our microservices are loosely coupled: we must be able to change one service without having to change anything else.

Question 13

13: What is the meaning behind Modeled Around a Business Domain concept?

Answer 13

By modeling services around business domains, we can make it easier to roll out new functionality and to recombine microservices in different ways to deliver new functionality to our users.

By making our services end-to-end slices of business functionality, we ensure that our architecture is arranged to make changes to business functionality as efficient as possible.

Question 14

14: What is the meaning behind Owning Their Own State concept?

Answer 14

One of the things I see people having the hardest time with is the idea that microservices should avoid the use of shared databases. If a microservice wants to access data held by another microservice, it should go and ask that second microservice for the data.

Hiding internal state in a microservice is analogous to the practice of encapsulation in object-oriented (OO) programming.

Question 15

15: What is the meaning behind Size concept? (How big should a microservice be?)

Answer 15

When you get into what makes microservices work as a type of architecture, the concept of size is actually one of the least interesting aspects.

“a microservice should be as big as my head.”

The rationale behind this statement is that a microservice should be kept to the size at which it can be easily understood.

the goal of microservices is to have “as small an interface as possible

I urge people not to worry about size. When you are first starting out, it’s much more important that you focus on two key things. First, how many microservices can you handle?

Second, how do you define microservice boundaries to get the most out of them, without everything becoming a horribly coupled mess?

Question 16

16: What is the meaning behind Flexibility concept?

Answer 16

Another quote from James Lewis is that “microservices buy you options.” Lewis was being deliberate with his words—they buy you options. They have a cost, and you must decide whether the cost is worth the options you want to take up.

Question 17

17: In what context are microservices most often discussed about?

Answer 17

Microservices are most often discussed as an architectural approach that is an alternative to monolithic architecture.

Question 18

18: What is considered as monolith in this book?

Answer 18

When I talk about monoliths throughout this book, I am primarily referring to a unit of deployment. When all functionality in a system must be deployed together, I consider it a monolith.

Question 19

19: What are the usual variants of monolith architecture?

Answer 19

• the single-process monolith,
• the modular monolith,
• and the distributed monolith

Question 20

20: What is the single-process monolith?

Answer 20

A system in which all of the code is deployed as a single process.

Question 21

21: What is the modular monolith?

Answer 21

As a subset of the single-process monolith, the modular monolith is a variation in which the single process consists of separate modules. Each module can be worked on independently, but all still need to be combined together for deployment

Question 22

22: What is the challenge of a modular monolith?

Answer 22

One of the challenges of a modular monolith is that the database tends to lack the decomposition we find in the code level.

Question 23

23: What is the distributed monolith?

Answer 23

A distributed monolith is a system that consists of multiple services, but for whatever reason, the entire system must be deployed together.

Question 24

24: What are the advantages of monoliths?

Answer 24

• much simpler deployment topology
• can simplify code reuse within the monolith itself
• it is sensible default choice as an architectural style

Question 25

25: What are some technology awareness that should be taken into consideration before implementing microservices?

Answer 25

• log aggregation and distributed tracing
• containers and Kubernetes
• streaming
• public cloud and serverless

Question 26

26: What is log aggregation and distributed tracing useful for?

Answer 26

With the increasing number of processes you are managing, it can be difficult to understand how your system is behaving in a production setting.

I strongly advocate the implementation of a log aggregation system as a prerequisite for adopting a microservice architecture.

These systems allow you to collect and aggregate logs from across all your services, providing you a central place from which logs can be analyzed, and even made part of an active alerting mechanism.

Question 27

27: How should individual microservice instances be run?

Answer 27

Ideally, you want to run each microservice instance in isolation. This ensures that issues in one microservice can’t affect another microservice—for example, by gobbling up all the CPU.

Question 28

28: What is the usual way to go about isolating service instances?

Answer 28

Containers, on the other hand, provide a much more lightweight way to provision isolated execution for service instances.

Question 29

29: What is Kubernetes used for?

Answer 29

After you begin playing around with containers, you’ll also realize that you need something to allow you to manage these containers across lots of underlying machines. Container orchestration platforms like Kubernetes do exactly that, allowing you to distribute container instances.

Question 30

30: What is important to have in mind when deciding to run Kubernetes cluster?

Answer 30

Do your best to ensure that someone else is running the Kubernetes cluster for you, perhaps by making use of a managed service on a public cloud provider. Running your own Kubernetes cluster can be a significant amount of work!

Question 31

31: Why is streaming important for microservices?

Answer 31

Although with microservices we are moving away from monolithic databases, we still need to find ways to share data between microservices.

For many people, Apache Kafka has become the de facto choice for streaming data in a microservice environment.

Question 32

32: Why are public cloud providers important? Name three main providers.

Answer 32

Public cloud providers, or more specifically the main three providers—Google Cloud, Microsoft Azure, and Amazon Web Services (AWS)—offer a huge array of managed services and deployment options for managing your application.

Question 33

33: What are the advantages of microservices?

Answer 33

• technology heterogeneity
• robustness
• scaling
• ease of deployment
• organizational alignment
• composability

Question 34

34: What are the microservices pain points?

Answer 34

• developer experience
• technology overload
• cost
• reporting
• monitoring and troubleshooting
• security
• testing
• latency
• data consistency

Question 35

35: What is the meaning behind technology heterogeneity?

Answer 35

With a system composed of multiple, collaborating microservices, we can decide to use different technologies inside each one.

This allows us to pick the right tool for each job rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.

With a monolithic application, if I want to try a new programming language, database, or framework, any change will affect much of my system. With a system consisting of multiple services, I have multiple new places to try out a new piece of technology. I can pick a microservice with perhaps the lowest risk and use the technology there, knowing that I can limit any potential negative impact.

Question 36

36: What is the significance of robustness advantage?

Answer 36

A component of a system may fail, but as long as that failure doesn’t cascade, you can isolate the problem, and the rest of the system can carry on working.

In a monolithic service, if the service fails, everything stops working.

Question 37

37: What is the significance of scaling advantage?

Answer 37

With a large, monolithic service, we need to scale everything together.

With smaller services, we can scale just those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.

Question 38

38: What is the significance of ease of deployment advantage?

Answer 38

A one-line change to a million-line monolithic application requires the entire application to be deployed in order to release the change.

With microservices, we can make a change to a single service and deploy it independently of the rest of the system.

Question 39

39: What is the significance of organizational alignment advatnage?

Answer 39

Smaller teams working on smaller codebases tend to be more productive.

Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity.

Question 40

40: What is the significance of composability advantage?

Answer 40

One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes.

Question 41

41: What is the significance of developer experience pain point?

Answer 41

As you have more and more services, the developer experience can begin to suffer. More resource-intensive runtimes like the JVM can limit the number of microservices that can be run on a single developer machine.

I think limiting the scope of which parts of a system a developer needs to work on is likely to be a much more straightforward approach.

Question 42

42: What is the significance of technology overload pain point?

Answer 42

Microservices may well give you the option for each microservice to be written in a different programming language, to run on a different runtime, or to use a different database—but these are options, not requirements.

It’s also worth pointing out that the bandwidth taken up by trying to understand all of this new technology will reduce the time you have for actually shipping features to your users.

Question 43

43: What is the significance of cost pain point?

Answer 43

Firstly, you’ll likely need to run more things—more processes, more computers, more network, more storage, and more supporting software (which will incur additional license fees).

Secondly, any change you introduce into a team or an organization will slow you down in the short term. It takes time to learn new ideas, and to work out how to use them effectively.

Question 44

44: What is the significance of reporting pain point?

Answer 44

Reporting across all our data has just become much more difficult, because now our data is scattered across multiple logically isolated schemas.

Question 45

45: What is the significance of security pain point?

Answer 45

You might need to direct more care to protecting data in transit and to ensuring that your microservice endpoints are protected so that only authorized parties are able to make use of them.

Question 46

46: What is the significance of testing pain point?

Answer 46

With a microservice architecture, the scope of our end-to-end tests becomes very large. We would now need to run tests across multiple processes, all of which need to be deployed and appropriately configured for the test scenarios.

Question 47

47: What is the significance of latency pain point?

Answer 47

With a microservice architecture, processing that might previously have been done locally on one processor can now end up being split across multiple separate microservices. Information that previously flowed within only a single process now needs to be serialized, transmitted, and deserialized over networks that you might be exercising more than ever before. All of this can result in worsening latency of your system.

Question 48

48: What is the significance of data consistency pain point?

Answer 48

Shifting from a monolithic system, in which data is stored and managed in a single database, to a much more distributed system, in which multiple processes manage state in different databases, causes potential challenges with respect to consistency of data.

Question 49

49: In what cases are microservices a GOOD choice?

Answer 49

In my experience, probably the single biggest reason that organizations adopt microservices is to allow for more developers to work on the same system without getting in each other’s way.

Software as a Service (SaaS) applications are, in general, also a good fit for a microservice architecture.

The technology-agnostic nature of microservices ensures that you can get the most out of cloud platforms.

Microservices also present clear benefits for organizations looking to provide services to their customers over a variety of new channels.

Question 50

50: In what cases are microservices a BAD choice?

Answer 50

Given the importance of defining stable service boundaries, I feel that microservice architectures are often a bad choice for brand-new products or startups.

In either case, the domain that you are working with is typically undergoing significant change as you iterate on the fundamentals of what you are trying to build.

I do see a temptation for startups to go microservice first, the reasoning being, “If we’re really successful, we’ll need to scale!” The problem is that you don’t necessarily know if anyone is even going to want to use your new product.

The process of finding product market fit means that you might end up with a very different product at the end than the one you thought you’d build when you started.

The challenge of microservices for startups is compounded by the fact that normally your biggest constraint is people. For a small team, a microservice architecture can be difficult to justify because there is work required just to handle the deployment and management of the microservices themselves. Some people have described this as the “microservice tax.”

Finally, organizations creating software that will be deployed and managed by their customers may struggle with microservices. In all likelihood, they will have no idea what a pod, Kubernetes, or a cluster even is.