Intake: Student: Lecturer: Hand in Date

MODULE: CT071-3-5-3-DDAC
INTAKE: UC3F1706SE
STUDENT: JAEDON TAN YUNG-MING | TP034526
LECTURER: DR. KALAI ANAND RATNAM
HAND IN DATE: 13th APRIL 2018
Acknowledgement
Thank you Dr. Kalai for introducing me to the budding world of cloud computing – it was a
fresh experience.
To everyone who has helped me along the way, thank you for your support!
ii
Table of Contents
Acknowledgement ....................................................................................................................ii
1.0 Introduction ........................................................................................................................ 1
2.0 Project Plan ........................................................................................................................ 3
3.0 Design .................................................................................................................................. 4
3.1 Design Considerations...................................................................................................... 4
3.2 Modelling ......................................................................................................................... 5
3.2.1 Use Case Diagram..................................................................................................... 5
3.2.2 Use Case Descriptions............................................................................................... 6
3.2.3 Activity Diagrams .................................................................................................... 12
3.2.4 Entity Relationship Diagram ................................................................................... 17
3.2.5 Cloud Architecture Diagram ................................................................................... 18
4.0 Implementation ................................................................................................................ 19
4.1 Application Development .............................................................................................. 19
4.2 Azure Publishing ............................................................................................................ 23
4.2.1 Resource Provisioning ............................................................................................. 23
4.2.2 Deployment .............................................................................................................. 25
4.2.3 Traffic Manager ....................................................................................................... 28
4.3 Application Scaling ........................................................................................................ 29
4.3.1 Scaling Up ............................................................................................................... 29
4.3.2 Scaling Out – Autoscaling ....................................................................................... 30
4.3.3 MySQL Scaling ........................................................................................................ 31
4.4 Reliability and Performance ........................................................................................... 32
5.0 Test Plan and Testing Discussion ................................................................................... 33
5.1 Unit Testing .................................................................................................................... 33
5.2 Performance Testing ...................................................................................................... 36
5.3 Analysis .......................................................................................................................... 38
6.0 Managed Databases ......................................................................................................... 39
7.0 Conclusion ........................................................................................................................ 41
References ................................................................................................................................ iv
Appendix ................................................................................................................................... v
iii
1.0 Introduction
Maersk Line, the world’s largest container shipping company, has been seeing a huge
growth in its shipping volume over the years. As of now, it operates over 600 vessels with
customers through 374 offices in 116 countries. Due to the increasing scale, the company
decided to employ cloud powered solutions to allow for this growth. Maersk has had dealings
with Microsoft Azure before and now wishes to expand the scope of the relationship. It
ultimately intends to consolidate all of its server rooms and data centres onto the virtualised
platform. The company will start with a container management system to manage its containers
and reduce logistics costs.
Requirements
The developer is required to design and develop a single tenant web solution that meets the
following criteria as below:
1. From import, export and transhipment processing to gate operations.

2. To be able to scale the solution to meet the needs of demands during peak seasons.
3. Improves profitability, reduce costs, increases productivity, eradicates errors and
optimizes resources to future-proof cargo handling business for high performance.
4. Assurance & reliability through Failover Management.
5. Accurately allocates inbound containers to yard locations and plan outbound containers
to individual haulier vehicles, delivering an exceptional level of automation and
removing human error.
6. Manage entire booking process from schedule search to booking confirmation.
1
Deliverables & Fulfilment
1. Design & Develop a single tenant web application hosted on Microsoft Azure as an
App Service (Web App) or on AWS Elastic Beanstalk.
2. Consume Relational Database
3. Consist of 5 - 10 interlinked pages.
4. Provide quality content and design.
5. Analyse web application performance with monitoring tools.
6. To be able to scale the solution to meet the needs of demands during peak seasons.
7. Source code to place in source control management services.
2
2.0 Project Plan
Figure 1. Gantt Chart
3
3.0 Design
3.1 Design Considerations
The developer had to make several assumptions and considerations for the purposes of
this project. They are as follows:
1. The Container Management System (CMS) is to be used by Maersk Line’s

employees internationally.
2. The system will only handle shipment management, customer management, item
management, and vessel management. Additionally, administrator users will also
be able to handle agent management on the system.
3. Bitbucket is the developer’s Git Repository of choice.
4. The system will be written in PHP and MySQL.
5. The developer has to handle the deployment and testing of the system on
Microsoft Azure with a limited budget.
6. The main region for hosting will be Central US with SEA being the secondary
region.
4
3.2 Modelling
3.2.1 Use Case Diagram
Figure 2. Use Case Diagram
5
3.2.2 Use Case Descriptions
Login
Use Case Name Login

Summary Registered user logs into the system where credentials are
validated.
Dependency <<extend>>Logout
Actor Agent, Admin
Precondition 1. Login page is accessed, and the interface has loaded.
2. User must have an account registered on the system.
Main Sequence 1. User enters credentials
2. User clicks “Login”
3. System validates credentials
4. System displays respective user main page depending on
user type
Alternative sequences Step 3: Credentials entered are invalid. System asks user to try
again.
If user logs out

5. User clicks Logout to log out of the system
Post condition System displays user’s respective home page.
Table 1. Use Case Description – Login
6
View Shipments
Use Case Name View Shipments

Summary User views and manages shipments details
Dependency <<extend>>Add Shipment
<<extend>>Edit Shipment
<<extend>>Delete Shipment
Actor Agent, Admin
Precondition User is logged into the system
Main Sequence 1. User clicks Shipments on the sidebar
2. System redirects to Shipments page
3. System displays table of shipments
Alternative sequences If user adds shipment
4. User clicks “Create New” button
5. System redirects to data entry page
6. User inputs respective data
7. User clicks submit
8. System validates the submitted data
9. System adds the new entry to the database
10. System redirects to the Shipments page
If user edits shipment

4. User clicks edit button on selected shipment entry
5. System redirects to “Edit Shipment” page
6. User updates respective details
10. System redirects to the Shipments page
If user deletes shipment

4. User clicks delete button on selected shipment entry
5. System prompts user to confirm deletion of entry
6. User confirms deletion
7. System deletes the selected entry
8. System refreshes the page
Post condition System displays Shipments page
Table 2. Use Case Description – View Shipments
7
View Customers
Use Case Name View Customers

Summary User views and manages customer details
Dependency <<extend>>Add Customer
<<extend>>Edit Customer
<<extend>>Delete Customer
Actor Agent, Admin
Main Sequence 11. User clicks Customers on the sidebar
12. System redirects to Customers page
13. System displays table of registered customers
Alternative sequences If user adds customer
20. System redirects to the Customers page
If user edits customer

11. User clicks edit button on selected customer entry
12. System redirects to “Edit Customer” page
17. System redirects to the Customers page
If user deletes customer

9. User clicks delete button on selected customer entry
Post condition System displays Customers page
Table 3. Use Case Description – View Customers
8
View Items
Use Case Name View Items

Summary User views and manages item details
Dependency <<extend>>Add Item
<<extend>>Edit Item
<<extend>>Delete Item
Actor Agent, Admin
Main Sequence 21. User clicks Items on the sidebar
22. System redirects to Items page
23. System displays table of registered items
Alternative sequences If user adds item
30. System redirects to the Items page
If user edits item

18. User clicks edit button on selected item entry
19. System redirects to “Edit Item” page
24. System redirects to the Items page
If user deletes item

14. User clicks delete button on selected item entry
Post condition System displays Items page
Table 4. Use Case Description – View Items
9
View Vessels
Use Case Name View Vessels

Summary User views and manages vessel details
Dependency <<extend>>Add Vessel
<<extend>>Edit Vessel
<<extend>>Delete Vessel
Actor Agent, Admin
Main Sequence 31. User clicks Vessels on the sidebar
32. System redirects to Vessels page
33. System displays table of registered vessels
Alternative sequences If user adds vessel
40. System redirects to the Vessels page
If user edits vessel

25. User clicks edit button on selected vessel entry
26. System redirects to “Edit Vessel” page
31. System redirects to the Vessels page
If user deletes vessel

19. User clicks delete button on selected vessel entry
Post condition System displays Vessels page
Table 5. Use Case Description – View Vessels
10
View Agents
Use Case Name View Agents

Summary User views and manages agent details
Dependency <<extend>>Add Agent
<<extend>>Edit Agent
<<extend>>Delete Agent
Actor Admin
Main Sequence 41. User clicks Agents on the sidebar
42. System redirects to Agents page
43. System displays table of registered agents
Alternative sequences If user adds agent
50. System redirects to the Agents page
If user edits agent

32. User clicks edit button on selected agent entry
33. System redirects to “Edit Agent” page
38. System redirects to the Agents page
If user deletes agent

24. User clicks delete button on selected agent entry
Post condition System displays Agents page
Table 6. Use Case Description – View Agents
11
3.2.3 Activity Diagrams
Login
Figure 3. Activity Diagram – Login
Logout
Figure 4. Activity Diagram – Logout
12
View Shipments
Figure 5. Activity Diagram – View Shipments
The same activity diagram applies for View Customers, View Items, View Vessels, and
View Agents.
13
Create Shipment
Figure 6. Activity Diagram – Create Shipment
14
Edit Shipment
Figure 7. Activity Diagram – Edit Shipment
View Agents.
15
Delete Shipment
Figure 8. Activity Diagram – Delete Shipment
View Agents.
16
3.2.4 Entity Relationship Diagram
Figure 9. Entity Relationship Diagram
17
3.2.5 Cloud Architecture Diagram
Figure 10. Cloud Architecture Diagram
The figure above portrays the system’s cloud architecture. Two resource groups are
deployed to two different regions – Central United States and South East Asia. Central US was
selected to be the main region as most of the traffic is coming from that surrounding area at the
moment. As the main region, the shared MySQL database and the staging deployment slot are
hosted in the Central US resource group. There are plans to replicate the database in the SEA
resource group when the budget increases. A traffic manager is used to redirect users to the
closest region when the website is accessed to ensure optimal performance. Autoscaling is also
integrated to handle unforeseen spikes in traffic.
Two deployment slots are used for Continuous Delivery of the code. The first slot,
staging, is where code is automatically synced with the git repository hosted on Bitbucket.
Testing is done on this deployment slot before the website is transferred to the second slot,
production. The production slot – located in both Central US and SEA regions – is where the
live version of the website resides and is accessible to the system’s users.
18
4.0 Implementation
4.1 Application Development
The website’s backend was developed using PHP and MySQL in the IDE. MySQL was
selected due to its easy integration with PHP. Frontend development was done using HTML,
CSS, and JavaScript with the goal of creating a quality user experience. Bootstrap was the
chosen framework for the frontend as it increases the speed of development while providing
the availability of immense documentation and a huge support community (Bharath, 2013).
PHP was selected to handle the transfer of data between the website and the database. The file
structure of the system is as follows:
Figure 11. System Project Files
19
The files are separated into different folders with frontend files – such as the CSS,
JavaScript, and image files – put into the assets folder. The CSS folder contains the stylesheet
file for Bootstrap. The PHP files for guest users are stored in the root directory. The header and
footer are also stored here. The files for logged in users are stored in the loggedin folder. A
standardised colour scheme is used for all web pages to maintain a consistent look and feel for
the website. Furthermore, a universal header is used to ensure that the necessary resources are
included in each web page.
Figure 12. Header and Footer Inclusion
The header also includes the config.php file which starts the session and establishes the
connection to the database. It is essential that this file is included in every web page. The
inclusion of this file removes the need to manually configure each file. The contents of the
configuration file are in the following code snippet.
Figure 13. Configuration File
20
A standardised naming convention was employed by the developer to allow for easy
referencing during development. For example, there are four functions to be executed in the
different categories – shipments, customers, items, vessels, and agents. The four functions are
retrieve, create, update, and delete. Therefore, the files for the customers category would be
named cust.php, cust-add.php, cust-update.php, and cust-delete.php respectively. For
different categories, the ‘cust’ section of the file name will just be replaced with the category’s
name.
There are two types of users in this system – agent and admin. Admins, or administrators,
have access to a function that agents do not. This function is made available dynamically when
an administrator logs in. The system identifies the type of user through the SESSION’s role.
The following is the home page of the website. A dashboard style layout was used for logged-
in users, unlike the home page.
Figure 14. Website Home Page
21
Figure 15. Logged-In User Home Page
Development was done in the IDE PhpStorm 2018 and XAMPP was used to help in local
debugging. Bitbucket was used to host the Git repository and to handle version control. This
allowed for smooth change management and tracking and served to be useful during integration
with Microsoft Azure. The repository can be found here in the following link:
https://bitbucket.org/naseelemak/ddac/.
22
4.2 Azure Publishing
4.2.1 Resource Provisioning
The publishing of the system began with resource provisioning as outlined in the cloud
architecture diagram in Section 3.2.5 of this document. Three resource groups were created for
this project. The resources to be hosted in the Central US region are contained in the maersk
resource group, resources hosted in the SEA region are contained in maersk-sea, and
miscellaneous resource are contained in maersk-misc. The miscellaneous resources mainly
include resources concerned with handling user traffic.
Figure 16. Maersk Resource Groups
The web apps were then created starting with the one for Central US. Upon selecting the
web app resource from the market, the web app creation menu was presented. It was there that
the app service plans were created at the same time as the web apps. The pricing standard
selected for both service plans was the S1 Standard due to the constrained budget. Subsequently,
the configuration can later be scaled up if necessary.
Figure 17. S1 Standard
Each web app was provisioned to its respective resource group – one for Central US and
one for SEA. The same applies to the app service plans.
23
As mentioned earlier, one web app was created for the Central US region and one was
created for the SEA region. They were named ddac-maersk and ddac-maersksea respectively.
The former is hosted on http://ddac-maersk.azurewebsites.net and the latter is hosted on
http://ddac-maersksea.azurewebsites.net. Both web apps were set up on Linux with runtime
stack PHP 7.2. The MySQL database was provisioned to the Central US resource group and
was set up with the lowest settings on the General Purpose Tier.
Figure 18. Azure MySQL Minimal Configuration
24
4.2.2 Deployment
Continuous Delivery (CD) was employed for the system’s deployment. CD is the process
of building, testing, configuring, and deploying from a build environment to a production
environment (Guckenheimer, 2018). This process serves as a tool to developers by streamlining
the journey of the system from build to production. Continuous Delivery is a learn practice that
keeps production fresh through taking the shortest path between new code availability in
version control and deployment.
This began with setting up the connection between Bitbucket – the code repository was
hosted there – and the web apps of both regions. A staging deployment slot was then set up to
sync with the repository. New code committed to Bitbucket will sync with the staging
deployment slot before being deployed to the production slot. The staging slot for ddac-
maersk is as in the following figure.
Figure 19. Staging Deployment Slot
25
When code changes are synced with the staging slot, no changes are made to the
production slot. This is particularly useful for testing any changes made to the website code to
see if it runs smoothly on Azure. Any issues detected during staging will be reported to the
developer. This protects against faulty code being deployed onto the live, production slot. After
the code has been proven to work in staging, the slot gets swapped with production. Staging
versions of the website have the suffix “-staging” added to its URL. The following figures
show what the production section looks like when the code has already been deployed to
staging.
Figure 20. Production Slot
Figure 21. Staging Slot
26
The swap from staging to production can be done automatically depending on the web
app’s settings. A swap is done instead of a mere copy is so that a backup is available if any
problems arise. This backup will allow for quick restoration of the production slot to its
previous state. The following figure demonstrates deployment to staging and swapping with
production.
Figure 22. Continuous Delivery
Figure 23. Successful Swap To Production
27
4.2.3 Traffic Manager
A traffic manager was provisioned to manage international user traffic. The goal was to
provide users with a fast and responsive system no matter their geographical location. As with
all systems, user satisfaction is a key priority. The routing method selected for the traffic
manager was performance. This routing method redirects website users to the instance closes
to them. At this point, only two endpoints are available with one in the Central US region and
one in the SEA region.
Figure 24. Traffic Manager Endpoints
28
4.3 Application Scaling
Scaling applications on Microsoft Azure has been made to be as seamless and easy as
possible. For Maersk’s Container Management System this is a particularly useful feature as it
operates on a large and fluctuating scale. Among the factors to consider in terms of resources
are average usage of the system, available budget, and traffic spike periods. Microsoft Azure
provides its users with the option to scale up or scale out anytime even after the system has
been deployed (Tardif, 2013). This provides the developer with the flexibility to test things out
first on a smaller scale before scaling things up.
4.3.1 Scaling Up
The S1 standard was selected for the system’s initial deployment as it was not too
expensive and provided the features necessary for the time being. As Maersk is a multinational
company, the CMS will be used by the company’s employees in many different geographical
locations. This is where the traffic manager plays its part and such features are only available
from the S1 standard onwards.
Figure 25. Pricing Tiers
29
Among other required features only available from S tier onwards are Continuous
Delivery, 5 staging slots, server performance monitoring, autoscaling, backup functionality,
and extra storage. These features are essential in providing Maersk with a system that can serve
its purpose well while meeting standards. With the scale that Maersk operates on, features like
autoscaling and server performance monitoring are imperative as they would minimise the risk
of system issues.
4.3.2 Scaling Out – Autoscaling
Autoscaling was configured for both web apps to automatically handle changes in user
traffic. This feature is built-in to resources like Web App to help applications perform
consistently by responding to demand changes (Microsoft, 2018). Rules were set up for more
instances of the server to be deployed during periods of increased traffic. The following figure
shows the autoscaling settings for the Central US instance of the web app.
Figure 26. Autoscaling for the Web App
Two rules were set in the autoscaling configuration. One is to scale the application out
by one instance if the average CPU percentage in the last 10 minutes goes beyond 75%.
Conversely, in the second rule, if the average CPU percentage in the last 10 minutes is below
25%, the web app will scale in by one instance. An average figure is taken for the CPU
percentage instead of a direct figure to ensure that sudden temporary spikes do not trigger
autoscaling. The maximum instance limit is set to two to keep things within budget.
30
4.3.3 MySQL Scaling
Microsoft Azure also allows resources like Azure Database for MySQL to scale even
after deployment. Among the things that can be scaled are virtual cores, storage, and backup
retention period. Naturally, when the scale increases so does the price. For the initial
deployment of the system, the lowest settings were selected. The following are the scaling
options available.
Figure 27. MySQL Scaling Options
31
4.4 Reliability and Performance
To provide for good system reliability and performance, several considerations were
made. First, to ensure reliability of the application, several instances were created and in
different locations. With the traffic manager in place, if one of the endpoints go down, users
can easily be redirected to an up and running one. Responsiveness of the system is also
improved as the traffic manager selects the application instance closest to the accessing user.
The endpoints in the traffic manager also serve as a restore point does reducing the possibility
of downtime.
Furthermore, the use of the staging deployment slot only enhances the system’s
availability. With this, changes in production can quickly be reverted if found to be having
issues. The staging slot also ensures that code is as functioning before swapping to production.
A number of scaling measures were also put in place such as autoscaling and configuration
scaling. The former upscales the application automatically when demand increases while
downscaling when the reverse happens.
32
5.0 Test Plan and Testing Discussion
5.1 Unit Testing
Test Case ID Function Tested Description Expected Result Actual Result Status
1. Enter valid username and 1. Login Successful 1. Login Successful
valid password
2. Enter valid username and 2. Login failed; invalid 2. Login failed; invalid
invalid password details details
MTC1 Login Pass
3. Enter invalid username and 3. Login failed; invalid 3. Login failed; invalid
valid password details details
4. Enter invalid username and 4. Login failed; invalid 4. Login failed; invalid
invalid password details details
1. Select Logout 1. Logout successful; 1. Logout successful;
MTC2 Logout redirect to login page redirect to login page Pass
1. Click "Shipments" on 1. Redirects to Shipments 1. Redirects to Shipments

sidebar page and lists respective page and lists respective
entries entries
2. Click "Create New" button 2. Redirects to new 2. Redirects to new

to create new entry shipment entry form shipment entry form
3. Click edit button for a 3. Redirects to shipment 3. Redirects to shipment

shipment entry editing form and populates editing form and populates
fields fields
MTC3 Shipments Pass
4. Click delete button for a 4. Prompts user for deletion 4. Prompts user for deletion
shipment entry confirmation confirmation
5. Fill up new entry form and 5. Adds entry to database 5. Adds entry to database
click submit and redirects to Shipments and redirects to Shipments
page page
6. Fill up new entry form with 6. Entry creation fails 6. Entry creation fails
mistakes and click submit because details invalid because details invalid
Figure 28. Unit Testing
33
1. Click "Customers" on 1. Redirects to Customers 1. Redirects to Customers
sidebar page and lists respective page and lists respective
entries entries
2. Click "Create New" button 2. Redirects to new 2. Redirects to new

to create new entry customer entry form customer entry form
3. Click edit button for a 3. Redirects to customer 3. Redirects to customer

customer entry editing form and populates editing form and populates
fields fields
MTC4 Customers Pass
4. Click delete button for a 4. Prompts user for deletion 4. Prompts user for deletion
customer entry confirmation confirmation
5. Fill up new entry form and 5. Adds entry to database 5. Adds entry to database
click submit and redirects to Customers and redirects to Customers
page page
6. Fill up new entry form with 6. Entry creation fails 6. Entry creation fails
mistakes and click submit because details invalid because details invalid
1. Click "Items" on sidebar 1. Redirects to Items page 1. Redirects to Items page

and lists respective entries and lists respective entries
2. Click "Create New" button 2. Redirects to new item 2. Redirects to new item
to create new entry entry form entry form
3. Click edit button for a item 3. Redirects to item editing 3. Redirects to item editing
entry form and populates fields form and populates fields
4. Prompts user for deletion 4. Prompts user for deletion

MTC5 Items 4. Click delete button for a confirmation confirmation Pass
item entry
5. Adds entry to database 5. Adds entry to database
5. Fill up new entry form and and redirects to Items page and redirects to Items page
click submit
6. Entry creation fails 6. Entry creation fails
because details invalid because details invalid
6. Fill up new entry form with
mistakes and click submit
34
1. Click "Vessels" on sidebar 1. Redirects to Vessels 1. Redirects to Vessels
page and lists respective page and lists respective
entries entries
2. Click "Create New" button
to create new entry 2. Redirects to new vessel 2. Redirects to new vessel
entry form entry form
3. Click edit button for a
vessel entry 3. Redirects to vessel 3. Redirects to vessel
editing form and populates editing form and populates
fields fields
MTC6 Vessels 4. Click delete button for a Pass
vessel entry 4. Prompts user for deletion 4. Prompts user for deletion
confirmation confirmation
5. Fill up new entry form and
click submit 5. Adds entry to database 5. Adds entry to database
and redirects to Vessels and redirects to Vessels
page page
6. Fill up new entry form with
mistakes and click submit 6. Entry creation fails 6. Entry creation fails
because details invalid because details invalid
1. Click "Agents" on sidebar 1. Redirects to Agents page 1. Redirects to Agents page

and lists respective entries and lists respective entries
2. Click "Create New" button 2. Redirects to new agent 2. Redirects to new agent
to create new entry entry form entry form
3. Click edit button for a agent 3. Redirects to agent editing 3. Redirects to agent editing
entry form and populates fields form and populates fields
4. Prompts user for deletion 4. Prompts user for deletion

MTC7 Agents 4. Click delete button for a confirmation confirmation Pass
agent entry
5. Adds entry to database 5. Adds entry to database
5. Fill up new entry form and and redirects to Agents and redirects to Agents
click submit page page
6. Entry creation fails 6. Entry creation fails

6. Fill up new entry form with because details invalid because details invalid
mistakes and click submit
35
5.2 Performance Testing
Microsoft Azure provides built-in performance testing that simulates user visits to the
website based on criteria set by the tester. This feature was used to conduct user load tests on
the website for the three different standard pricing tiers – S1, S2, and S3. The performance
testing was done on the main web app hosted in the Central US region. Results obtained from
the testing reveal average response times and failed requests. Response time is measured in
seconds and refers to the time it takes for the entire webpage to load. Tests were conducted
with user loads of 150 to 600 with increments of 150 for three minutes each.
Figure 31. Performance Test Configuration
The above screenshot is the test configuration for the web app running on app service
plan S1 with user load 150. The last two digits in the test name identify which user load is
being used for the test and the second last two digits signifies the pricing tier being tested. The
following figures show the results for performance test USTest0101.
36
Figure 32. Performance Test Results
Figure 33. Performance Test Results
37
The number of successful and failed requests are depicted in a pie chart as shown in
figures above. For this test of a 150-user load for three minutes, there was a 100% success rate
among 10,548 requests. Other details provided in the results include helpful metrics such as
average response time, requests per second, CPU time, and memory working set. The last two
metrics are useful in evaluating the effectiveness of the app service plan being tested. The
following table contains the results of the tests done on the different configurations.
User Load
150 300 450 600
Service Plan
3.87 sec 9.55 sec 11.92 sec 13.72 sec
S1
0% Failed 2.54% Failed 3.31% Failed 6.09% Failed
3.32 sec 7.04 sec 9.54 sec 11.63 sec
S2
0% Failed 1.32% Failed 2.11% Failed 4.65% Failed
3.15 sec 6.87 sec 8.89 sec 10.85 sec
S3
0% Failed 0% Failed 1.13% Failed 1.52% Failed
Table 7. Performance Testing Results
5.3 Analysis
The data gathered in the performance tests has shown that the responsiveness increases,
and the failure rate decreases the higher the service plan. For instance, for a user load of 300,
the response time with S1 is 9.55 seconds while the response time with S3 is 6.87 seconds.
Likewise, the failure rate was brought from 2.54% to 0% with the S3 service plan. It is
important to note, however, that autoscaling was not taken into account when performing these
tests. Perhaps the results could be improved with the S1 service plan by scaling out the
application more, creating more instances.
In the future, Maersk could consider upgrading the service plan from S1 to S2. It was
concluded that S2 would provide more value for money than S3 as the results have shown that
the improvement from S2 to S3 was not as significant as that of S1 to S2. Depending on how
the needs of users evolve in the future, Maersk might increase its budget, allowing the
developer to scale up the application’s resources.
38
6.0 Managed Databases
Cloud services have been rapidly rising in popularity over the last few years. Database
management is crucial to the deployment of any web, app, or software, and it often the case for
most businesses that their IT team is too busy working on business-critical issues (Hedge, 2015).
This leaves little room for database management. As a result, businesses are turning to managed
databases which comes under what the industry calls database as a service (DBaaS) or platform
as a service (PaaS). Azure Database for MySQL is a cloud managed database by Microsoft that
offers several benefits not found in traditional databases. Azure Database for MySQL is a
service built on the well-known and trusted Azure relational database platform. Concerning the
offerings available, the following diagram illustrates the amount of administration power over
the infrastructure and the level of cost efficiency achieved by automation and consolidation on
the database level (Microsoft, 2018).
Figure 34. Microsoft Azure Offerings
39
As highlighted in the figure, using Azure SQL Database or Azure MySQL Database as a
PaaS benefits businesses with significantly reduced costs while reducing the effort required in
administration. This uses the pay-as-you-go model meaning that businesses only have to pay
for what they use as opposed to having to make heavy investments in hardware and
configuration.
Kumar (2017) breaks down the benefits of using managed database with Microsoft Azure
into three key points. First, the platform is intelligent. There is built-in monitoring, tuning
insights, and advisors that help users achieve the most performance out of the database. Next,
the platform is flexible. With Microsoft Azure, databases can be scaled on demand without
downtime, making performance predictable and resilient to sudden surges in traffic. Third, the
platform is trustable. It has built-in audit, security, and high availability with total resource
isolation.
Those are only some of the key benefits. Using a managed database allows quick
provision of database servers coupled with built-in high availability without the need for VMs,
configuration, or setup. Performance is also predictable with governance and provisioned
resources. Compute units can be scaled up or down in response to workload changes without
having to shut down the application. Security is also built in to protect sensitive data by backups
and encryption. Furthermore, automatic backups are made for recovery to any point up to 35
days.
40
7.0 Conclusion
The development and deployment of the Maersk Container Management System proved
to be a challenging but fruitful experience. A lot of new things were learned as this project
went beyond the usual which typically involves only development and basic deployment. The
scope of this project provoked a new dimension of thinking where thought was not only
required to be put into the structure of the system, but also into the way the system was
deployed and delivered to its end users. Being able to put the theory learned about cloud
architecture into practice really helped to further solidify the knowledge. With this new
dimension of thinking came new problems to solve. Subsequently, tools such as traffic manager
and autoscaling were provided by Microsoft Azure to simplify the tackling of these issues. The
process of learning these tools and designing the cloud architecture has ultimately provided the
developer with a deeper understanding of cloud computing, as well as an increased interest in
the field.
41
References
Bharath, S. (2013). Advantages of Bootstrap framework | Vmoksha. [Online]. 2013.

Vmokshagroup.com. Available from: https://vmokshagroup.com/blog/bootstrap-
advantages/. [Accessed: 10 April 2018].
Guckenheimer, S. (2018). What is Continuous Delivery? | DevOps. [Online]. 2018. Visual

Studio. Available from: https://www.visualstudio.com/learn/what-is-continuous-
delivery/. [Accessed: 11 April 2018].
Hedge, M. (2015). 4 Benefits of Database as a Service - Contegix. [Online]. 2015. Contegix.

Available from: https://www.contegix.com/4-benefits-of-database-as-a-service/.
[Accessed: 11 April 2018].
Kumar, R. (2017). Microsoft extends Azure managed database services with introduction of
MySQL and PostgreSQL. [Online]. 2017. Azure.microsoft.com. Available from:
https://azure.microsoft.com/en-us/blog/microsoft-extends-azure-managed-database-
services-with-introduction-of-mysql-and-postgresql/. [Accessed: 11 April 2018].
Microsoft (2018). Azure Autoscale | Microsoft Azure. [Online]. 2018. Azure.microsoft.com.

Available from: https://azure.microsoft.com/en-us/features/autoscale/. [Accessed: 11
April 2018].
Microsoft (2018). SQL (PaaS) Database vs. SQL Server in the cloud on VMs (IaaS). [Online].
2018. Docs.microsoft.com. Available from: https://docs.microsoft.com/en-us/azure/sql-
database/sql-database-paas-vs-sql-server-iaas. [Accessed: 11 April 2018].
Tardif, B. (2013). Scaling Up and Scaling Out in Windows Azure Web Sites. [Online]. 2013.
Azure.microsoft.com. Available from: https://azure.microsoft.com/en-us/blog/scaling-
up-and-scaling-out-in-windows-azure-web-sites/. [Accessed: 11 April 2018].
iv
Appendix
Bitbucket repository: https://bitbucket.org/naseelemak/ddac/
Video presentation: https://goo.gl/UkRBLA
Maersk CMS Links:
• Traffic Manager: http://ddac-maersk-traffic.trafficmanager.net

• US Region: https://ddac-maersk.azurewebsites.net
• SEA Region: https://ddac-maersksea.azurewebsites.net
• US Region Staging Slot: https://ddac-maersk-staging.azurewebsites.net
• SEA Region Staging Slot: https://ddac-maersksea-staging.azurewebsites.net
• Database: ddac-maersksql.mysql.database.azure.com

Intake: Student: Lecturer: Hand in Date

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intake: Student: Lecturer: Hand in Date

Uploaded by

Copyright:

Available Formats

MODULE: CT071-3-5-3-DDAC

1. From import, export and transhipment processing to gate operations.

Figure 1. Gantt Chart

3.1 Design Considerations

1. The Container Management System (CMS) is to be used by Maersk Line’s

3.2.1 Use Case Diagram

Figure 2. Use Case Diagram

Use Case Name Login

If user logs out

Use Case Name View Shipments

If user edits shipment

If user deletes shipment

Use Case Name View Customers

If user edits customer

If user deletes customer

Use Case Name View Items

If user edits item

If user deletes item

Use Case Name View Vessels

If user edits vessel

If user deletes vessel

Use Case Name View Agents

If user edits agent

If user deletes agent

Figure 3. Activity Diagram – Login

Figure 4. Activity Diagram – Logout

Figure 5. Activity Diagram – View Shipments

Figure 6. Activity Diagram – Create Shipment

Figure 7. Activity Diagram – Edit Shipment

Figure 8. Activity Diagram – Delete Shipment

Figure 9. Entity Relationship Diagram

Figure 10. Cloud Architecture Diagram

4.1 Application Development

Figure 11. System Project Files

Figure 12. Header and Footer Inclusion

Figure 13. Configuration File

Figure 14. Website Home Page

4.2.1 Resource Provisioning

Figure 16. Maersk Resource Groups

Figure 17. S1 Standard

Figure 18. Azure MySQL Minimal Configuration

Figure 19. Staging Deployment Slot

Figure 20. Production Slot

Figure 21. Staging Slot

Figure 22. Continuous Delivery

Figure 23. Successful Swap To Production

Figure 24. Traffic Manager Endpoints

Figure 25. Pricing Tiers

4.3.2 Scaling Out – Autoscaling

Figure 26. Autoscaling for the Web App

Figure 27. MySQL Scaling Options

5.1 Unit Testing

1. Click "Shipments" on 1. Redirects to Shipments 1. Redirects to Shipments

2. Click "Create New" button 2. Redirects to new 2. Redirects to new

3. Click edit button for a 3. Redirects to shipment 3. Redirects to shipment

Figure 28. Unit Testing

2. Click "Create New" button 2. Redirects to new 2. Redirects to new

3. Click edit button for a 3. Redirects to customer 3. Redirects to customer

1. Click "Items" on sidebar 1. Redirects to Items page 1. Redirects to Items page

4. Prompts user for deletion 4. Prompts user for deletion

Figure 29. Unit Testing

1. Click "Agents" on sidebar 1. Redirects to Agents page 1. Redirects to Agents page