Cloud Architecture for UKRI Assignment Answer

Introduction - Cloud Architecture for UKRI

Get free samples written by our Top-Notch subject experts for taking online assignment help services 

UKRI stands for United Kingdom Research & Innovation organisation which is one of the many institutes within the framework of UK government which facilitates the funding of researchers along with providing scientific support and access to the scientists and researchers. It plays a primary role in scientific funds management organisation. It plays many other purposes, including keeping track of all the research activities happening in the country and the world. It maintains a comprehensive database for the same which can be accessed by the members of the UKRI. UKRI also acts as an administrator in the domain of science and technology, setting up domain-specific policies.

The manager of a cyber-infrastructure team of UKRI has requested us to move all the in-house content delivery and funding management system hosted on dedicated local servers to transfer into the cloud. And for this purpose, we have been tasked with designing the cloud architecture for the UKRI systems. UKRI has two primary methods – one of them is concerned with the management of funds, while another is concerned with providing access and support to the scientific community related to their projects. The funding system provides a web interface for the researchers and scientists where they can request and track their funding status. There is a similar interface for the team members if UKRI where they can channel the funding requirements to the external government APIs. For the second part of the UKRI operations, the scientific community can access an online library of published scientific papers and journals and can request for scientific equipment on loan.

Project Plan

We will begin the project by identification of goals for the cloud system of UKRI and brainstorming over the most suitable model for the given problem. We will consider every factor and will propose different scenarios. This will be our first milestone. After the completion of this milestone, we would have selected our goals and a suitable model for our cloud implementation. This will end the first phase. In the second phase, we will begin the analysis process. In the analysis process, we will critically examine the requirements and gather proper specifications for the same. This will mark the end of the second milestone and the second phase of our process. At the end of this phase, we will be about our requirements. Then we will move into the third phase. In the third phase, we will put our efforts into the design process. We will begin the structural architecture and planning of our cloud implementation in this phase. This mark the third milestone.

Table A

1. Requirement Gathering

Following is the tabular list of functional and non-functional requirements for the proposed UKRI cloud system.

Table B

Table C

Table D

Choice Of Cloud Platform And Data-Centre

We have decided to implement our cloud as FaaS because of two primary factors – there is not going to be any overly complex code and we will need 24x7 uptime (Wilder, 2012). Function as a Service (FaaS) is a serverless cloud computing offering. The provider provides the user with individual tasks that are billed to the second. The actual infrastructure of the provider remains hidden from the users. The functions return results and can be used for developing, operating, or managing applications (Reese, 2009). The abbreviation FaaS stands for Function as a Service and describes a serverless cloud computing concept. It belongs to cloud computing services such as SaaS (Software as a Service), PaaS (Platform as a Service) or IaaS (Infrastructure as a Service). As part of FaaS, the provider provides individual functions that can be addressed by customers and return results (Raj, 2012) within a short time. Function as a Service can be used to develop applications, to operate or to manage them (Laszewski et al., 2018). The service's actual infrastructure and the servers on which the services are provided remain hidden from the user—the service provider bills the used functions based on the required computing power and memory.

FaaS is reactive and is controlled by events (Linthicum, 2019). There are no ongoing processes. Specific triggers trigger events that trigger a call to the Function. Function as a Service delivers the result and then waits for the next call. An essential feature of Function as a Service is that everything below the Function can be viewed as given and abstracted. Users do not have to worry about the server, networks, storage or operating systems of the service. The billing of the functions used is dependent on usage and is accurate to the second. Only tasks that are used will be charged. FaaS is stateless from the perspective of the application being operated. The petition calls a specific function, and the result is returned. If states are to be saved or data is to be persistently held by an application implemented with FaaS, a database or a file system must be connected (Suarez, 2016). The stateless functions are scalable and make it possible to keep large capacities ready for changing application loads (Shroff, 2010). Function as a Service offers numerous advantages. Developers do not have to worry about the infrastructure and the servers' connection, but only address individual functions. The services are very scalable and enable exact, usage-dependent billing. Tasks that are not used are free of charge and do not require any resources. If individual functions are only sometimes needed, they can still be addressed at any time. The service provider takes over the complete administration of the infrastructure (C?apa & Gerrard, 2019). The self-contained, stateless functions are easy to maintain and easy to update if necessary. The logic of applications can be isolated into individual services and can be flexibly adapted to the performance requirements.

2. System Architecture

As it is evident from Figure A and Figure B, we have used FaaS style of cloud implementation. We have used the AWS FaaS components for this implementation. We have used the AWS Lambda (Figure C), which is a FaaS orchestrator. We have also used AWS DynamoDB (Figure D) as our persistent storage and AWS S3 bucket as our static storage. Researchers UKRI team interact with the FaaS orchestrators via AWS Route53 webservers.

For illustration purposes, we have considered the flow of data. In one instance, the researcher connects to the lookup web interface using a VPN and then asks for a particular resource, this activates the function which fetches the relevant resource from the datastore and puts into a static store for the web-server to pull it down and show to the researcher. Similarly, the researcher or a member of the UKRI team can access the funding panel interface using a VPN and in this segment of the cloud, there are various functions related to initiation and tracking of funding. They also follow a similar activation process related with funding database.

3. Analysis And Reflection

It becomes noticeably clear that the choice of FaaS has lived up to expectations because we can ensure 24x7 uptime in this. As already mentioned, various components of this system such as the VPN gateway, the web-interface servers, the static buckets, storage spaces and the functions work in unison to achieve all the goals and requirements of the UKRI cloud implementation. One of the major advantages of this implementation is that it is very flexible and UKRI will always be in a good position to re-architecture the whole cloud or add additional services.

Conclusion

To conclude our process, we would like to emphasize that proper process was followed starting from project planning, requirement gathering, milestones mark-up, selection of platform and datacentre. Then we designed the whole architecture by proposing that FaaS is the correct way to go ahead and we were able to achieve all the goals and requirements by implementing our cloud architecture as FaaS. The architecture which is built is robust, reliable, secure, and scalable.

References

C?apa, K., & Gerrard, B. (2019). Professional Cloud Architect – Google Cloud Certification Guide: A handy guide to designing, developing, and managing enterprise-grade GCP cloud solutions. Packt Publishing.

Laszewski, T., Arora, K., Farr, E., & Zonooz, P. (2018). Cloud Native Architectures: Design high-availability and cost-effective applications for the cloud. Packt Publishing.

Linthicum, D. (2019). Cloud architecture: Advanced concepts. linkedin.com.

Raj, P. (2012). Cloud enterprise architecture. Taylor & Francis.

Reese, G. (2009). Cloud application architectures: Building applications and infrastructure in the cloud. O'Reilly Media.

Shroff, G. (2010). Enterprise cloud computing: Technology, architecture, applications. Cambridge University Press

Suarez, C. (2016). Cloud architecture and engineering. Willford Press.

Wilder, B. (2012). Cloud architecture patterns: Using microsoft azure. O'Reilly Media.