02. Building microservices with Spring Boot Flashcards
What are the characteristics of a microservice-based architecture ?
- Constrained
- Loose coupled
- Abstracted
- Independent
What does it mean that a mircroservice must be constrained ?
Microservices have a single set of responsibilities and are narrow in scope. Microservices embrace the UNIX philosophy that an application is nothing more than a collection of services where each service does one thing and does that one thing really well.
What does it mean that a mircroservice must be Loose coupled ?
A microservice-based application is a collection of small services that only interact with one another through a non–implementation specific interface using a non-proprietary invocation protocol (for example, HTTP and REST). As long as the interface for the service doesn’t change, the owners of the microservice have more freedom to make modifications to the service than in a traditional application architecture.
What does it mean that a mircroservice must be Abstracted ?
Microservices completely own their data structures and data sources. Data owned by a microservice can only be modified by that service. Access control to the database holding the microservice’s data can be locked down to only allow the service access to it.
What does it mean that a mircroservice must be Independent ?
Each microservice in a microservice application can be compiled and deployed independently of the other services used in the application. This means changes can be isolated and tested much more easily than with a more heavily interdependent, monolithic application.
When building a microservices architecture, a project’s architect focuses on three key tasks:
- Decomposing the business problem
- Establishing service granularity
- Defining the service interfaces
What are the guidelines for identifying and decomposing a business problem into microservice candidates ?
- Describe the business problem, and listen to the nouns you’re using to describe the problem
- Pay attention to the verbs.
- Look for data cohesion
Can you explain how to describe the business problem ?
Using the same nouns over and over in describing the problem is usually an indication of a core business domain and an opportunity for a microservice. Examples of target nouns for the EagleEye domain from chapter 1 might look something like contracts, licenses, and assets.
Can you explain what does it means to Pay attention to the verb ?
Verbs highlight actions and often represent the natural contours of a problem domain. If you find yourself saying “transaction X needs to get data from thing A and thing B,” that usually indicates that multiple services are at play. If you apply to EagleEye the approach of watching for verbs, you might look for statements such as, “When Mike from desktop services is setting up a new PC, he looks up the number of licenses available for software X and, if licenses are available, installs the software. He then updates the number of licenses used in his tracking spreadsheet.” The key verbs here are looks and updates.
Can you explain what does it means to Look for data cohesion ?
As you break apart your business problem into discrete pieces, look for pieces of data that are highly related to one another. If suddenly, during the course of your conversation, you’re reading or updating data that’s radically different from what you’ve been discussing so far, you potentially have another service candidate. Microservices should completely own their data.
What concepts will you follow to define microservices granularity ?
- It’s better to start broad with your microservice and refactor to smaller services— It’s easy to go overboard when you begin your microservice journey and make everything a microservice. But decomposing the problem domain into small services often leads to premature complexity because microservices devolve into nothing more than fine-grained data services.
- Focus first on how your services will interact with one another— This will help establish the coarse-grained interfaces of your problem domain. It’s easier to refactor from being too coarse-grained to being too fine-grained.
- Service responsibilities will change over time as your understanding of the problem domain grows— Often, a microservice gains responsibilities as new application functionality is requested. What starts as a single microservice might grow into multiple services, with the original microservice acting as an orchestration layer for these new services and encapsulating their functionality from other parts of the application.
What are the indicators of a bad microservice design =
- A service with too many responsibilities
- The service is managing data across a large number of tables. If you find yourself persisting data to multiple tables or reaching out to tables outside of the immediate database, this is a clue the service is too big. A microservices should own no more than 3 to 5 tables
- Too many test cases
- The microservices in one part of the problem domain breed like rabbits—If everything becomes a microservice, composing business logic out of the services becomes complex and difficult because the number of services needed to get a piece of work done grows tremendously. A common smell is when you have dozens of microservices in an application and each service interacts with only a single database table.
- Your microservices are heavily interdependent on one another—You find that the microservices in one part of the problem domain keep calling back and forth between each other to complete a single user request.
- Your microservices become a collection of simple CRUD (Create, Replace, Update, Delete) services—Microservices are an expression of business logic and not an abstraction layer over your data sources. If your microservices do nothing but CRUD-related logic, they’re probably too fine-grained.
Name 4 guidelines that can be useful to design service interface:
- Embrace the REST philosophy— The REST approach to services is at heart the embracing of HTTP as the invocation protocol for the services and the use of standard HTTP verbs (GET, PUT, POST, and DELETE).
Model your basic behaviors around these HTTP verbs. - Use URI’s to communicate intent— The URI you use as endpoints for the service should describe the different resources in your problem domain and provide a basic mechanism for relationships of resources within your problem domain.
- Use JSON for your requests and responses— JavaScript Object Notation (in other words, JSON) is an extremely lightweight data-serialization protocol and is much easier to consume then XML.
- Use HTTP status codes to communicate results— The HTTP protocol has a rich body of standard response codes to indicate the success or failure of a service. Learn these status codes and most importantly use them consistently across all your services.
In a Spring Boot application, you can define Spring Beans by:
- Annotating a Java class with a @Component, @Service or @Repository annotation tag
- Annotating a class with a @Configuration tag and then defining a constructor method for each Spring Bean you want to build with a @Bean tag.
what is a Controller in a spring boot app ?
A Controller class exposes the services endpoints and maps the data from an incoming HTTP request to a Java method that will process the request.
