Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CSC3065 Cloud Computing
Assessment 2: Editor
Weighting: 60%
Late submission penalties and rules will be applied in accordance with the QUB policy on
late submission. For more information on this or any other QUB policy with regards to
assessment please see:
Please be aware that this is an individual assignment and as such will be checked for
plagiarism. You should ensure that the work is yours and yours alone, citing any third-party
sources as applicable. Plagiarism is a serious academic offense. Submission of your work
implies your claim that it is your individual work and has not previously been submitted for
academic credit.
If you have any questions about the assignment please see the module organiser David
Cutting in the first instance or use any of the support options listed in this document.
1. Assessment Details
The QUBeditoron3000 (the editor) is the world’s most over-engineered yet deeply
unreliable text editor. It has been implemented using several cloud technologies including
stateless, containers, CI, and is currently deployed on the QPC.
Your assignment is to start with this as a base and to add more functionality as specified in
this document. There is some potential for a choice for what specifically you wish to
implement so you must make decisions on how to make these improvements.
The editor is basically a text box with some buttons which perform operations (such as word
counts) and report back the result.
editor-frontend: this is a simple container that contains some static HTML and Javascript
that implements a frontend. When operations are required it makes an XMLHttpRequest in
Javascript to one of the worker services. The endpoints it uses for these requests are
configured within the Javascript.
editor-wordcount: this is a PHP based container that takes a HTTP GET parameter (text) and
returns some JSON including the answer (number of words) and a description string. There
is some rudimentary CI testing (unit testing of the function alone but not as a web service).
editor-charcount: this is a Node/Express based container than takes a HTTP GET parameter
(text) and returns some JSON including the answer (number of characters) and a description
string. There is some rudimental CI testing (unit testing of the function along but not as a
web service).
You are required to modify and extend this editor as described in the following tasks.
Make sure you read and understand the instructions carefully, especially those on
submission! The report is what is marked (code and the video will only be sample checked
as needed to verify a claim made in the report or for moderation – anything in the code or
video that is not in the report will not be marked).
1.1 Tasks
A. New Functions
Add a minimum of four new functions to the editor including the changes to the front-end
as well as back-end implementations for each. See the assessment criteria for more
information but in general higher marks are given for use of new languages (beyond those
provided) and things such as CI pipelines. Points can also be awarded for use of novel
technologies i.e. deployment using FaaS for one function as an example (new technology or
language points are only awarded once, i.e. if you use FaaS twice it only counts as novel
once even if you use different languages or providers).
Example functions to add could include: number of vowels, comma counter, number of
spelling errors, average word length, number of palindromes, number of instances of “and”.
Note only four functions will be marked, handing in work with more than four functions will
result in the first four being marked and others ignored.
B. Improvement to Current Implementation
There are a number of issues with how the current editor works which include (but are likely
not limited to):
• Lack of handling for asynchronous calls being blocked or actions happening while
waiting for a response in the front end (for example if I click to get a wordcount but
then click to get a character count quickly before the first one has completed, they
will overwrite each other)
• No error handling by the front end (what if a backend service returns an error result)
• No error handling by either of the provided backend example services (neither cope
for example with empty strings or the variable text not being passed)
• Static configuration of routes to services in the frontend (they are lines of code
inside the source, would be much better to have some external configuration file or
service to work)
• CI testing for the provided backend services are unit tests on the function alone (i.e.
they do not actually perform an HTTP request to check web API functionality)
Plan and implement improvements to address some or all of the above, or other
shortcomings or issues you perceive within the provided system. See the assessment criteria
and submission instructions for more information on what may be assessed and how to
show this working.
C. Custom Proxy Router
Currently each function endpoint has a custom URL configured in the frontend client. For
this challenge you will build a self-contained reverse web proxy as a container to which the
frontend will pass all calls to (including any variables).
This proxy will then itself hold the specific endpoints for different methods and make an
HTTP call to the end service before getting then returning the answer.
For full marks this service should be highly configurable (how do we update the end points
or add new ones, can this happen dynamically while the service is running for instance) and
support some service discovery options (what methods are available or automatic
registration of new services for example).
Note you are required to build this yourself rather than using a third-party service or
container.
D. Frontend Service Failure Handler
The frontend currently stores a single URL for each function (after C this will be a single URL
for the proxy). This challenge is to update the frontend to support multiple URLs for each
function/proxy. If a specific URL falls offline or errors the frontend should be able to
continue using other endpoints instead.
This may also include load balancing while multiple endpoints are available.
As mentioned in combination with C this would refer to multiple URLs for the proxy service
provided by C1. Please note “frontend” as always refers to the HTML+JS component (the in-
browser), should you implement this handler in the proxy it will not count for marks against
C this only relates to the browser.
E. Monitoring and Metrics
Monitoring and testing service – all the testing currently happens during the build cycle with
CI testing. Implement a separate service (this could be a container or other service) that
when used makes HTTP requests (perhaps with random text strings) to the functions and
checks (a) correctness of results against expectations and (b) overall performance in time (in
an ideal world this service should periodically check performance and record results in
addition to an on-demand operation). Note you are required to build this yourself rather
than using a third-party service or container.
For full marks you are expected to have some form of monitoring periodically test and alert
on failure of your editor services (this can be an external service or container as you like as
long as you have done the first part from scratch yourself).
F. Stateful Saving of Current Value
Currently there is no way to store the current text in the editor. For this section you should
implement, using any technology (containers, FaaS, database, etc) you like a way to:
• Save the current text and return (and display) an identifier for this saved text
• Provide the option to enter an identifier and thus recall the saved text to the
frontend
G. Multi-Vendor Architecture
Complete a justified design (you are not required to implement) for how the editor could be
fully deployed onto multiple cloud vendors perhaps with a common broker/router. Include
diagrams and text as appropriate demonstrating how your design would ensure ultimate
resilience and continue to badly add numbers together even after a zombie uprising.
1.2 Deployment Environment
As it stands the current editor is deployed on the QPC Kubernetes system with source code
and docker registry in the QPC gitlab. It is suggested that you continue to use this
architecture for your project, or at least most of it, but this isn’t a requirement.
You are free to use any provider(s) you like and their technology stacks but be aware that
(a) less support will be available and (b) you must make any code accessible when you
submit (see submission section for details). It’s strongly suggested you discuss with the
teaching team before selecting a platform other than QPC Kubernetes/gitlab.
If you use another platform and then run out of credit so the project cannot be completed
or demo’d then you will loose marks.
2. Assessment Criteria
The following are the criteria against which your submission will be marked and their
conceptual marking equivalents.
General Marking Criteria (note this will be applied holistically to each section and are examples of the standard required)