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)