Your development team has been asked to refactor an existing monolithic application into a set of composable microservices. Which design aspects should you implement for the new application? (Choose two.)
Your development team has been asked to refactor an existing monolithic application into a set of composable microservices. Which design aspects should you implement for the new application? (Choose two.)
Creating an API contract agreement between the microservice implementation and the microservice caller is essential to ensure clear communication and decoupled architecture. This allows for independent development and deployment of services. Implementing a versioning scheme is crucial to handle future changes that could be incompatible with the current interface, ensuring backward compatibility and smooth transitions during updates. These two design aspects are fundamental in building scalable and maintainable microservices.
Vote BE
BE are correct
Note to admin: change this question's answer to reflect a 2 answer selection
B & E seems best
B & E is the answer
BD : is the correct one here. Create an API contract agreement between the microservice implementation and microservice caller. This will help to ensure that the microservices are decoupled from each other, and that the caller can be updated without having to update the implementation. Ensure that sufficient instances of the microservice are running to accommodate the performance requirements. This is important because microservices are often scaled independently, and you need to make sure that each microservice can handle the expected load.
BE is the answer. https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke#api_contracts Each microservice should be invoked only from a set of interfaces. Each interface should in turn be clearly defined by a contract that can be implemented using an API definition language like the OpenAPI Initiative specification or RAML. Having well-defined API contracts and interfaces allows you to develop tests as a main component of your solution (for example, by applying test-driven development) against these API interfaces. https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke#versioning To give you flexibility in managing updates that might break existing clients, you should implement a versioning scheme for your microservices. Versioning lets you deploy updated versions of a microservice without affecting the clients that are using an existing version.
B and D
For me to ensure that sufficient instances of the microservice are running to accommodate the performance requirements is not needed because of the big variety of services that provide autoscaling. BE
Agree with B and E. https://cloud.google.com/appengine/docs/standard/java/designing-microservice-api#using_strong_contracts
This one is tricky one as C and E could be better option as well but there was no mention about reliability…
I will agree with B and E
The two design aspects you should implement for refactoring a monolithic application into microservices are: B. Create an API contract agreement between the microservice implementation and microservice caller. This is crucial for microservices to communicate effectively. A well-defined API contract ensures that changes to one service don't break other services that depend on it. This promotes independent development and deployment. E. Implement a versioning scheme to permit future changes that could be incompatible with the current interface. Microservices are expected to evolve independently. Versioning allows for backward compatibility and graceful transitions when changes are made to the API. This prevents breaking changes and ensures smooth integration.
Let's look at why the other options are less critical: A. Develop the microservice code in the same programming language used by the microservice caller. While using the same language can simplify initial development, it's not a strict requirement. Microservices can be written in different languages as long as they adhere to the API contract. C. Require asynchronous communications between all microservice implementations and microservice callers. Asynchronous communication is often beneficial for microservices, but it's not always necessary. Synchronous communication can be appropriate in some cases, especially for tightly coupled services. D. Ensure that sufficient instances of the microservice are running to accommodate the performance requirements. This is important for scaling and performance, but it's more of an operational concern than a design aspect. It's handled through deployment strategies and monitoring.
Versioning schema is the evolutionary process in API development. For eg: /v1/users/1234 /v2/users/1234
API contract design is the first step in design-first approach while creating APIs (REST). We can also follow code-first approach while providing solution via public APIs. Design first approach is more flexible and provides sufficient amount of time for the dev team to gather requirements and to understand what customer really wants.
D & E， B and E are same thing. D is considering capacity of micro service.
B. Guarantees that the two parties are communicating in a well-defined way, which makes the microservices more flexible, composable, and easy to understand. E. Allows to make changes to the service's API while still maintaining backward compatibility. With versioning, new and old consumers can continue to use the service without interruption as new features are added. On the other hand, developing the microservice code in the same programming language as the microservice caller does not promote loose coupling, and it may also increase the complexity of the system as it will depend on language-specific features. Asynchronous communications are also not always necessary and depend on the use case and requirement. Ensuring sufficient instances of the microservice are running can be done by using a scalability strategy such as Auto-scaling, and this is not a specific design aspect.
BE with the recommendation on https://cloud.google.com/architecture/migrating-a-monolithic-app-to-microservices-gke
1. When you incrementally migrate services, configure communication between services and monolith to go through well-defined API contracts. Answer B 2. https://cloud.google.com/architecture/microservices-architecture-refactoring-monoliths#design_interservice_communication Ans C Ans B,C
To support C https://cloud.google.com/architecture/microservices-architecture-interservice-communication#logical_separation_of_service In this document, you isolate the payment service from the rest of the application. All flows in the original Online Boutique application are synchronous. "In the refactored application, the payment process is converted to an asynchronous flow. Therefore, when you receive a purchase request, instead of processing it immediately, you provide a "request received" confirmation to the user. In the background, an asynchronous request is triggered to the payment service to process the payment."
To support B *When you incrementally migrate services, configure communication between services and monolith to go through well-defined API contracts. https://cloud.google.com/architecture/microservices-architecture-refactoring-monoliths
I personally do not see or find anything supporting E at all...