Project Documentation – Cloud-BasedTodoApp for TaskForge AB (a imaginarycompany)

1. Introduction

This project is a cloud-based web application developed using Spring Boot and
deployed on Amazon Web Services (AWS). The application is a simple yet scalable
todo list designed for the fictional company, TaskForge AB to help teams manage
their tasks collaboratively. It’s built with a focus on responsiveness, scalability and
reliability.

Screenshot of the application in the browser (the language used on the application is Swedish).

2. Technical Overview

Practical explanation for a company

Imagine that your business need a internal app where employees can write daily
tasks and where the system is simple and easy to maintain, this app makes sure:
● It automatically grows when many people use or try to access it at the same
time.
● Users can access it with a single link and it always works.
● If the unfortunate thing happens and a server crashes another one takes over
automatically so the system continues to run.
● All the information is stored and kept safe on the server.
● You never have to manually fix or start the servers/systems it does by itself.
This setup is great for a small to medium sized business that wants a reliable and
scalable tool without having to hire a big IT department.

3. AWS Infrastructure

The application runs inside an EC2 instance launched via an Auto Scaling Group.
Incoming traffic is routed through an Application Load Balancer which forwards
requests to a Target Group configured to communicate on port 8080 (standard port
for Spring). The Spring Boot app runs as a background systemd service, MySQL
runs locally on each EC2 instance.

Architecture diagram of the structure in AWS.

The running instances because the Auto scaling is set to a minimum of 2 instances and a maximum of 3 instances.

4. Deployment Steps

1. The Spring Boot app was generated using Spring Initializr.
2. MySQL was installed on the EC2 instance and configured.
3. The .jar file was built using Maven.
4. File was uploaded to EC2 using FileZilla(SFTP).
5. A systemd service was created for automatic startup on boot.
6. An AMI was created from the instance.
7. A Launch Template was created based on the AMI.
8. An Auto Scaling Group and Application Load Balancer were set up.

View of the project structure in the TodoService class.

The FileZilla view of how i uploaded the .jar file.

Systemd config file.

5. Application Features

● Displays all tasks directly on the homepage.
● Ability to add new todos.
● Mark tasks as completed or uncompleted.
● Delete tasks.
● Shows statistics: totals tasks and completed tasks.
● Responsive UI with a clean design.

The main view of the application showing the todo form and listed tasks.

6. Future Improvements

To further develop this solution, i would consider:
● Migrating the database to Amazon RDS for central storage.
● Adding authentication and user management.
● Serving the app via HTTPS for security.
● Adding different language options (only available in Swedish for now).
● Monitoring performance and changes with CloudWatch and CloudTrail.

7. Learning & Reflection

This project provided hands-on experience in:
● Cloud-based backend development.
● Setting up infrastructure in AWS (a little overwhelming in the beginning with
what service to use and keeping track of always terminating everything
correctly when done so the billing doesn’t skyrocket).
● Understanding how auto scaling and load balancing works.
● Connecting backend applications to databases.
● Learning and using the Terminal/Powershell.

This project helped me connect theoretical cloud concepts to a working, scalable
solution.
I now feel a little more confident in building, deploying and maintaining a cloud
environment on AWS.

Multi-Cloud Capability and Comparison (AWS,
Azure, GCP)

In addition to AWS I also did some research on how this application could be
deployed on Google Cloud Platform (GCP) and Microsoft Azure.

Google Cloud Platform (GCP)

Required services:
● Compute Engine (virtual machines)
● Cloud Load Balancer
● Cloud SQL (MySQL)
● Instance Groups + Autoscaler
● Cloud Storage

Pros:
● Great autoscaling capabilities.
● Good integration with Kubernetes/container integration.
● Good networking infrastructure.

Cons:
● Smaller community and ecosystem compared to AWS and Azure.
● Can be a little more difficult to learn especially for beginners.
● Less availability in some regions (the Nordics/Scandinavia) which can affect
latency depending on where you are trying to access it from.

Microsoft Azure

Required services:
● Azure Virtual Machine – Azures answer for EC2
● Azure Load Balancer
● Azure Database for MySQL
● Azure Virtual Machine Scale Sets (for autoscaling)
● Azure Blob Storage – Like AWS S3

Pros:
● Great integration with other Microsoft services like Office 365, Teams etc..
● User friendly interface and easy to use (AWS is more terminal work
sometimes).
● Good CI/CD (Continuous Integration/ Continuous Delivery) tools.

Cons:
● The costs can be a little higher than AWS in some regions.
● More GUI-driven (Graphical User Interface) and less terminal (can be good
and can be bad sometimes).
● Less “hands-on” controls compared to AWS.

Summary for End users:

All three platforms AWS, Azure, GCP offer great performance and high availability
which makes it that the end user has access to the service regardless of which
platform it’s deployed/running on.
The biggest difference is not noticed by the end user, it’s more of how the service is
set up and managed “behind the scenes”.
AWS is best suited if you need or want full control over how the application is run
and scaled.
Azure is the best choice for companies already using the Microsoft ecosystem, since
it’s very compatible with for example Teams and Office 365.
GCP is the best for modern solutions that use containers and/or Kubernetes, a good
choice for automated or advanced systems.
so the end user rarely notices what platform is being used but the choice what
platform to use affects how simple and effectively the application can be developed,
deployed and scaled.

Burp Suite

Purpose:

The purpose of this test was to simulate a load test and to see if the application
could handle a large amount of simultaneous requests of new todos.

Tools:

● Burp Suite Community Edition
● Repeater and Intruder – modules
● Target: Spring Boot – app on a EC2 behind a AWS Load Balancer

Execution:

1. A POST-call with task=BurpTest was sent via Repeater and was verified to
   work.
2. The request was sent to Intruder with a payload-list of (Burp1 – Burp100).
3. The Server handled the 100 calls.
4. Status code 302 showed that every request was redirected correctly.

Image of the Burp Suite Intruder dashboard before the test.

A part of the requests and the 302 status code that shows it redirected the calls
correctly.

Some of the 100 requests that were made by Burp Suite to the website.

Result:

● The application continued to answer normally and did not crash.
● All the calls were handled and saved to the database.
● No signs of overloading or crashing.
Burp suite worked fine to simulate a “high load” and the application showed good
performance and AWS Load Balancer + Auto Scaling handled the traffic
effectively. Maybe in the future i will try and write some kind of Bash/Python script
that sends thousands of requests because after a little searching i came to the
conclusion that Burp Suite Community Edition is good but a little limited for true
overloading.

Github link to the code: https://github.com/TeeDjaay99/Todo_list