2. Microservices Core Concepts Flashcards
How do services communicate in a microservices architecture?
All communication between services leverage REST over HTTP. There are other methods like event-based communications. However, the intra-service calls are all REST based.
What is one of the top concerns when it comes to documenting APIs in microservices architecture and why?
Unifying service documentation. There is no standard way of documenting RESTful services. So, developing common means of service documentation is critical, especially in a large organisation.
What does the way that the microservices communicate mean for different teams working on the same project, and why?
Each team can consume the services of another team, because they all communicate in a common way (REST).
What can be said about the concepts of “size” and “operations” in the context of microservices?
Size isn’t as critical as operations. A microservice handles one set of related functions with little or no cross-domain operations.
In a microservices architecture, what’s the relationship between a service, domain, and objects?
A service operates on a well-defined domain. Operations aren’t defined on data objects or business objects. Instead, on the domain as a whole. However, there also might be services that handle a set of related business processes that may spin one or more domains.
What kind of services should a microservices architecture include when it comes to dealing with data operations, and what do these services often expose?
Very low-level, data-focused services. These services often expose domain-specific CRUD operations on a domain object, but the domain can also spin multiple data objects. You can also build a service to handle a set of related business processes that may span one or more domains.
What should the size of a service in a microservices architecture focus on?
Domain operations.
What are the two common mistakes that a team moving onto a microservices architecture make?
Building their services either too fine-grained or not fine-grained enough.
What’s the drawback of building too fine-grained services in a microservices architecture?
The distribution tax will hit you hard as the latency of calls really kicks in.
What is the benefit of having smaller services?
They build faster, have fewer test scenarios, and deploy and start up much quicker.
What does protocol-aware heterogeneous interoperability mean?
Services are bound to a protocol and execute communication over that protocol in a way that works in a mixed, or heterogeneous, environment.
What’s the benefit of a microservices architecture when it comes to different teams working in different languages?
Each team member can build their services in a language that’s native to them, and then expose those services to others to consume using ReST.
Other teams that need to consume these services don’t need to have any knowledge whatsoever of how the services themselves work, nor do they need to learn some special communication technology. They simply leverage ReST the same way they would if they were calling their own services.
Where does the agility of microservices architecture come from?
The fact that each team works in a language and framework that is natural to them. This means that they can deliver code quickly because they aren’t constrained by artificial boundaries imposed by the rules of an architecture pattern that’s unknown to them.
What is the risk associated with the fact that each service can call any other service in a microservices architecture?
There is no clear delineation of who’s calling the service.
There are no constraints on who can call what, which means orchestration is key. Each service must maintain a certain level of passivity in their APIs, or there’s a risk of system failure.
What can be said about microservices in regards to distribution and scaling?
The communication pattern of microservices lends itself to a truly distributed model. While distribution beyond a single data centre is not a requirement, it definitely is a one of the benefits.
Along with the ability to easily distribute your system as a whole, the microservices architecture model provides for a highly scalable system.
Both of these properties are very powerful for a modern application suite.
What does distribution entail in a microservices architecture?
Each service is accessed over a remote network call regardless of being in a local or a remote data centre. Therefore, you can theoretically move the services anywhere you want around the globe, and the system will work.
From a reality perspective, though, putting services all over the world is costly both in infrastructure and the latency of the calls themselves. The benefit of this ability, however, shouldn’t be lost on the individual service-to-service calls.
What problem does distribution solve in a microservices architecture?
Getting infrastructure and services globally available when needed without making all services globally available.
How is scalability achieved in a microservices architecture?
Each application is independent of every other application in the system. As such, when an individual service comes under load, it can be individually scaled.
In a traditional model, you would have to scale every component in your system to handle the load increases on a single service. A microservices architecture allows you to simply increase the number of instances for a certain service when you experience that load.
What are the two “biggest” benefits of a microservices architecture?
Distribution and scalability.
What are the three low-level costs of a service call in a microservices architecture that mi?
- Connection setup
- Connection teardown
- Wire latency
What is the significance of latency in a single service in regards to the system as a whole in a microservices architecture?
Any latency added to the normal flow can be detrimental to the system as a whole. Latency in a low-level service, or any service for that matter, can become exponentially exaggerated in a model where every call is remote.
