0% found this document useful (0 votes)
8 views

Assignment

Uploaded by

tim wa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Assignment

Uploaded by

tim wa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Microservices Architecture Assignment 2024 – Weighting 40%

A. Distributed Microservice Application


The purpose of this assignment is to demonstrate your ability to apply the learning
from the module to build a distributed application composed of multiple
collaborating services in the form of microservices. The application is expected to
cover the following aspects from the module:
 REST based microservices built with Spring Web and Spring JPA
 Configuration management with Spring Cloud Config (File)
 Service discovery with Spring Cloud Netflix Eureka
 API gateways with Spring Cloud API Gateway
 Building relilient microservices using Resilience4J
 Login and Authentication (JWT, OAuth2)
 Implementing observability and monitoring fo services
At a high level the overall project deployment should look similar to the following:

Figure 1 High Level Deployment

The application deployment shall consist of the following:


1. Minimum of two separate Microservices exposing resources. Be original.
2. Service B will expose entities stored in a database with CRUD (Create, Retrieve,
Update and Delete) operations exposed via a REST API.
3. Service A will expose entities stored in a second database with CRUD (Create,
Retrieve, Update and Delete) operations. This database will be shared by multiple
instances of Service A. (Note : One instance of MySQL is sufficient for demo)
4. Service A will also make REST calls to retrieve data from Service B
5. A Client application will expose endpoints that can be invoked by POSTMAN (a REST
client) and is responsible for invoking REST calls in Service A.

B. Application Domain
When deciding on the two Microservices and their entities, come up with a suitable
Application idea. Model two resources that have a sensible relationship between them.
Do not just name them “ServiceA” and “ServiceB”.

C. Detailed Deployment
The purpose of the application is to demonstrate the following:
1. Microservices development using Spring Web to expose REST API and using
Spring JPA for Database interaction.
2. Each microservice instance should register with a Spring Eureka discovery service
on start-up.
3. Each microservice should retrieve configuration data from a Spring Cloud
Configuration Server on start-up. The configuration service can use a simple File
System backend or git (recommended).
4. All REST calls between the Client and the Service are expected to be routed via a
Gateway which uses the Eureka discovery service.
5. The application should use Authentication (e.g. JWT, Oatuh2).
6. REST calls are expected to be traced or monitored.
7. The REST endpoints should use some form of data validation using the Validation
API.
8. The REST APIs should conform to proper API design – with correct formulation of
URL’s and correct status codes (Ref ONAP link).
d. Deadlines
Note 1:. Be mindful that late submissions might not be corrected in time due to cutoff
dates for exam results. If you cannot submit on that date due to illness or other
extenuating circumstance you will have to request a deferral from [email protected]
Note 2: A live Q&A may be scheduled for either Sprint after the submission date if
deemed necessary.

Submission Date

Friday 19th April 2024


e. Submission

What to submit
Report Introduction to application, rational and context
List of User Stories that are completed
Description of Microservices and their relationships
Description of the entity classes in the application including the
validation annotations
Description of Cloud Native features implemented (e.g. service
discovery, config)
Test results – screenshots of the output (POSTMAN response
body/headers, traces, show Cloud Native behaviours)
Evaluation – Evaluation (1-2 pages)of how well you adhered to the
project brief and any problems encountered.
Code A .zip file of all code
Demo Brief context and rationale of your application.
Demo of all User Stories.
Demo cloud native behaviours used (e.g Service discovery)
Maximum time 10 minutes
f. Marking Rubric
Elements Excellent Good Satisfactory Fail
(70+) (55%-69%) (40%-55%) (0-39%)
Presentation The presentation is The presentation is The presentation is Presenter does not
10%) audible. The audible. The audible and the engage the viewer.
presentation provides presentation provides presentation provides Presenter does not
evidence of adequate evidence of evidence of adequate adhere to the maximum
preparation. Content is adequate preparation. preparation. time limit.
presented in a logical Content is presented in a
and coherent structure. logical and coherent
Appropriate use is made structure.
of audio/visual materials,
which are clear and well
organised.
Context and Rationale A concise synopsis of A concise synopsis of A concise synopsis of the Presenter did not
(5%) the context and rationale the context and rationale context of the application provide a context or
of the application is of the application is is given. rationale for the
given. Presenter displays given. application.
evidence of originality.
User Stories/ Application Presenter demonstrated Presenter demonstrated Presenter demonstrated Presenter demonstrated
Demo a complete application. a more complete an application with a good no or minimal
(45%) The presenter described application with full level of functionality (two functionality. No server
and rationalised the CRUD and searches. microservices with CRUD side validation of data.
application. Evidence of Some cloud native actions communicating). No cloud native
understanding of the behaviours included. behaviours (e.g Cloud
technology used. Ability Server side data config, Service
to identify any key validation. Evidence of Discovery, Load
limitations. understanding of the Balancer)
REST API well followed technology used
design principles – ref
ONAP. HATEOAS
considered. Cloud native
behaviours and
authentication included.

Screencast (60%)

Ctd
Elements Excellent Good Satisfactory Fail
(70+) (55%-69%) (40%-55%) (0-39%)
Organisation and Report demonstrates a Content is presented in a Content adequately Content is inadequate.
Presentation high level of competency logical and coherent presented. Inconsistent Poor formatting.
(5%) in the subject area. structure. Appropriate formatting. Minimal use of
Content is presented in a use diagrams and tables. diagrams.
logical and coherent
structure. Appropriate
diagrams. Consistent
formatting.
User Stories, User Stories follows User Stories follows User Stories partly follows Poor User Story
5% INVEST and fully reflects INVEST with Acceptance INVEST principles. formulation,
the functionality and vice criteria.
versa. Acceptance
criteria listed.
Architecture and REST Good architecture Good architecture No or minimal No architecture
APIs)10% description and REST description and REST architecture description. description. REST end
end points documented. end points documented REST end points partialy points not documented.
API documented using documented
Swagger. Good API
design and HATEOAS
considered.
Cloud Native Behaviours High level of competency Good use of some of the Partially use of some of No Cloud Native
& Security 10% and use of cloud native Cloud Native behaviors the Cloud Native Behaviour described or
behaviours behaviors. implemented(Discovery,
demonstrated. Good use Load Balancer, Config,
of diagrams were Tracing and
appropriate. Authentication.
Evaluation(10%) Bugs and improvements Bugs and improvements Bugs and improvements Minimal or no evaluation
in application identified in application identified in application identified
and suggested solutions and suggested solutions and suggested solutions
described. Any described. Application described.
limitations of the evaluated against the
architecture identified. project brief.
Application evaluated
against the project brief.

Report and Code(40%)


Live Q&A : If I have questions or queries on your submission, a Live Demo/Q&A session
over zoom will be scheduled for week 06th May 2024.
CheckList:
 Upload to moodle by Friday 19th April. 2024 17.00. .zip with your code, screencast
and report.
 Live Demo/Q&A via zoom : You will be notified via student email if you need to
participate in a Live Q&A.

You might also like