CSC3065 Cloud Computing 2024/25
Assessment 2: Text Editor
Assessment Briefing Version: 1 (21/10/2024)
Weighting: 60%
Set By: David Cutting
Moderated By: Neil Anderson
Date Released: 25/10/2024
Submission Due: 1700 on 02/12/2024
Academic Integrity
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:
https://www.qub.ac.uk/directorates/AcademicStudentAffairs/AcademicAffairs/ExaminationsandAssessment/MarkSchemesandClassifications/
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.
By submitting your work, the following criteria must be met:
1. Adherence to the prescribed limits, which may include page count, word count,
and time limits for videos, as specified in the assignment guidelines.
2. Presentation in a clear and well-proofread manner.
3. Submission on or before the specified or due date. In case of a late submission,
deferment should have been granted in advance.
4. Submission of all relevant files and URLs via Canvas.
5. Certification that this submission represents entirely original work, with correct
attribution of all sources, and full acknowledgment of any contributions from AI
technologies.
6. Declaration of having reviewed the University guidelines on Academic Offences,
which can be found at:
https://www.qub.ac.uk/directorates/AcademicStudentAffairs/AcademicAffairs/AppealsComplaintsandMisconduct/AcademicOffences/Student-Guide/
7. Confirmation that the submission is original work, with no part of it
having been previously submitted for any other assignment.
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.
Important Notes
Please note that any student may be called to a viva (oral presentation / discussion) of their work.
This is individual work and as such to avoid collusion you must ensure your own work (repositories and any other online artefacts) are protected. Failure to do this, for example having a public repository of your work, may result in collusion being detected if someone else uses your work (see the previous section on Academic Integrity).
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.
Repository: https://repository.hal.davecutting.uk/root/editor-frontend
Live Demo: http://frontend.editor.qpc.qubcloud.uk/
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).
Repository: https://repository.hal.davecutting.uk/root/editor-wordcount
Live Demo: http://wordcount.editor.qpc.qubcloud.uk/?text=Goodbye+cruel+world
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).
Repository: https://repository.hal.davecutting.uk/root/editor-charcount
Live Demo: http://charcount.editor.qpc.qubcloud.uk/?text=This+is+wonderful
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 used for validation and moderation – anything in the code or video that is not in the report will not be marked).
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 gracefully with errors 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. 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).
E. Stateful Saving of Text
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
F. 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)
3. Feedback
Feedback in the form of marks will be provided as soon as practicable after submission.
Individual feedback will take the form of a numeric score against each of the assessment criteria (there may be brief comments for these criteria if appropriate), a total made from these scores weighted by section, and an overall textual comment on the totality of the submission.
Generalised feedback will be provided to the class as a whole including overall trends and areas of particular concern.
Anyone wishing to discuss their marks in more detail are welcome to do so using any of the support arrangements outlined in this document.
4. Submission
Submission will be via Canvas and also through repository access. Please read this section carefully to avoid any mistakes which could lead to marks being lost.
Note: three uploads are required – unless you complete all three then this assignment will be regarded as not submitted. It is your responsibility to check the validity/lack of corruption of any uploads.
Late penalties will be applied to this assignment based on the latest timestamp of any uploaded item.
You are required to:
1. Provide repository access if not using the QPC gitlab (repository.hal.davecutting.uk – if you are using this then you don’t need to do anything other than provide the links in your report) so for example the EEECS gitlab or any other repository service. It is your responsibility to discuss this with a member of the teaching team to allow them access if this is the case.
2. Upload three items to the relevant assignment option on Canvas:
A completed report based on the template provided (you must use the template) named as
A demonstration video showing the operation of your system (see 4.1 for more details) to the VIDEO assignment on Canvas.
A zip file containing copy of all source code you have written (this is required in addition to the repository access for the external examiner) to the CODE assignment on Canvas.
3. Validate your uploads by viewing them via Canvas and making sure they are correct and uncorrupted. Previously students have uploaded the wrong assignments or an early version etc – it is your responsibility to ensure the correct item is uploaded.
4.1 Video Submission
To demonstrate your system working you are required to submit a video, usually a screen capture video, ideally as short as possible. This should show each of the key elements of your solution working (with inspection mode or similar to show network traffic to the endpoints).
You should use this video to highlight any specifics you wish to, for example any particularly detailed functionality included.
You are not required to specifically present or explain your work but this allows an exaimer to see it running! Be sure to cover all the features.
Please be mindful of filesize and compress/re-encode if needed. Previously we’ve had submissions of 1GB or more for a short video! This will take a long time to upload and upload (and check) must be completed by the deadline to avoid penalties.
Please note: the primary purpose of the video is for validation and for external examination. The report is the marked component so you must ensure you evidence everything in the report, anything included in the video but not in the report can not be marked. The marker may not even view the video.
5. Support Available
A number of support avenues are available throughout this project. It’s suggested you try them in this order, but this is your choice and you should feel free to avail yourself of one or all.
Canvas Discussion – you can ask any questions (in general please, don’t include your work as everyone can see!) on the Canvas Discussion Forum. This is very useful as everyone can see (the question and the answer!) and its possible students can help each other out.
Practical Sessions – there is a practical session Fridays 0900-1100 where you are welcome to ask questions about anything including this assignment. Just pop up on the Teams question channel and say hi.
Module Drop-in – CSC3065 offers a virtual drop-in session every Monday 1400-1700. Our module demonstrators (who will be involved in the marking) will be guaranteed to be there and the module lecturer will be most often as well. Just pop up on the Teams General channel and say hi.
Office Hours – David Cutting has office hours available every week. Appointments can be booked via the Office Hours link on Canvas.
