Developing an OpenStack Public Cloud Storage€¦ · DEVELOPING AN OPENSTACK PUBLIC CLOUD STORAGE Óskar Eiríksson 60ECTSthesissubmittedinpartialfulﬁllmentofa Magister Scientiarum

Faculty of Industrial Engineering, Mechanical Engineering andComputer Science

University of Iceland2016

Faculty of Industrial Engineering, Mechanical Engineering andComputer Science

University of Iceland2016

Developing an OpenStackPublic Cloud Storage

Óskar Eiríksson

DEVELOPING AN OPENSTACK PUBLICCLOUD STORAGE

Óskar Eiríksson

60 ECTS thesis submitted in partial fulfillment of aMagister Scientiarum degree in Software Engineering

AdvisorsHelmut Neukirchen

Matthias Book

Thesis ExaminerJón Ingi Einarsson

Faculty of Industrial Engineering, Mechanical Engineering and ComputerScience

School of Engineering and Natural SciencesUniversity of IcelandReykjavik, May 2016

Developing an OpenStack Public Cloud StorageA Proof of Concept Deployment of OpenStack with a Public Cloud Storage using Swift60 ECTS thesis submitted in partial fulfillment of a M.Sc. degree in Software Engineering

Copyright c© 2016 Óskar EiríkssonAll rights reserved

Faculty of Industrial Engineering, Mechanical Engineering and Computer ScienceSchool of Engineering and Natural SciencesUniversity of IcelandHjarðarhagi 2-6107, Reykjavik, ReykjavikIceland

Telephone: 525 4000

Bibliographic information:Óskar Eiríksson, 2016, Developing an OpenStack Public Cloud Storage, M.Sc. thesis,Faculty of Industrial Engineering, Mechanical Engineering and Computer Science, Uni-versity of Iceland.

Reykjavik, Iceland, May 2016

DedicationTo my family. Björg, Guðjón Erik and Árni Valur.

Abstract

Communication service providers worldwide have been facing a digital disruptionfor the telecommunication value chain with digitization of their services which arechanging the consumer behavior. These organizations are looking for new revenue,ways to retain customers, e.g. by adding value, while also trying to drive down bothCapital Expenditure (CapEx) and Operational Expenditure (OpEx).

OpenStack is a cloud management platform, offering flexibility, interoperability andopen APIs, that potentially will help service providers simplifying the operationand deployment of new components in the telecommunications network. This thesisdescribes the development of a public cloud storage exploiting different OpenStackservices intended as a proof of concept for the viability of using OpenStack at acommunication service provider. We believe utilizing Agile methods in a DevOpssetting has helped in both proving and deploying OpenStack, as well as creating acloud storage that will add value for the consumers while retaining them as customersin the long-term.

Útdráttur

Fjarskiptafyrirtæki út um allan heim hafa undanfarin ár staðið andspænis miklumbreytingum á tækniumhverfi sínu sem veldur breyttu hegðunarmynstri neytenda,sem krefst umbreytinga á viðskiptamódelum fyrirtækjanna. Þessi fyrirtæki leitaleiða til að finna nýjar tekjur, minnka brottfall viðskiptavina t.d. með virðisaukningu,á meðan þurfa þau einnig að lækka bæði rekstrar- og fjárfestingakostnað.

OpenStack er skýjalausn sem býður upp á sveigjanleika, virkni og opnar vefþjónustursem munu mögulega hjálpa fjarskiptafyrirtækjunum að einfalda rekstur og innleiðingunýrra eininga í kerfum sínum í framtíðinni. Í þessari ritgerð er kynnt þróun oginnleiðing á ytri skýja-geymslulausn fyrir viðskiptavini sem notfærir sér mismunandieiningar innan OpenStack kerfis. Reynslan sýnir að með því að hafa notað Agileaðferðir í „DevOps“ umhverfi hafi innleiðing OpenStack gengið betur en án þeirra.Einnig var sýnt fram á hagkvæmni kerfisins og sýnilega virðisaukningu meða því aðbúa til geymslulausn fyrir neytandann, á sama tíma og það minnkar líkur á brottfalliviðskiptavina.

v

Contents

List of Figures xi

List of Code Excerpts xiv

List of Tables xv

Abbreviations xvii

Acknowledgments xxi

1. Introduction 11.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

I. Technical Aspects 7

2. Foundations 92.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2. OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1. OpenStack Compared to Other Providers . . . . . . . . . . . . 112.2.2. Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3. Other OpenStack Services . . . . . . . . . . . . . . . . . . . . 20

2.3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4. Programming Platforms . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.2. JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5. MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6. Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3. Design and Architecture 313.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2. End User and Load Balancing . . . . . . . . . . . . . . . . . . . . . . 323.3. Applying Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

vii

Contents

3.4. Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 343.4.2. Web Application . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.5. Using OpenStack Swift . . . . . . . . . . . . . . . . . . . . . . . . . . 433.5.1. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.5.2. Developer API . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6. Back End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.1. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.2. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.3. MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.7. Scalability and Automation . . . . . . . . . . . . . . . . . . . . . . . 493.7.1. OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.7.2. Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4. Implementation 514.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2. Example Code Excerpts . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.1. Permissions with Express.js routing . . . . . . . . . . . . . . . 514.2.2. User Model in MongoDB . . . . . . . . . . . . . . . . . . . . . 534.2.3. OpenStack Swift Pipeline . . . . . . . . . . . . . . . . . . . . 554.2.4. Ansible Playbook for a New Queue Node . . . . . . . . . . . . 55

4.3. Project Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.3.1. Lines of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3.2. Cyclomatic Complexity . . . . . . . . . . . . . . . . . . . . . . 59

4.4. Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5. Evaluation 73

II. Management Aspects 77

6. Methods Used 796.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2. Agile Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.1. Comparison between Scrum and Kanban . . . . . . . . . . . . 796.2.2. Adapting Methods . . . . . . . . . . . . . . . . . . . . . . . . 81

6.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.3.1. Whiteboard, Post-its and Jira . . . . . . . . . . . . . . . . . . 856.3.2. Usabilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.3.3. GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7. Challenges and Lessons Learned 897.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

viii

Contents

7.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.2.1. Human Resources . . . . . . . . . . . . . . . . . . . . . . . . . 897.2.2. Keeping Schedule . . . . . . . . . . . . . . . . . . . . . . . . . 907.2.3. Missing a Development Environment . . . . . . . . . . . . . . 907.2.4. Challenges in a DevOps Environment . . . . . . . . . . . . . . 917.2.5. Tailoring Agile Methods . . . . . . . . . . . . . . . . . . . . . 917.2.6. “Cowboy Coding” . . . . . . . . . . . . . . . . . . . . . . . . . 937.2.7. Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 947.2.8. Selection of Tools . . . . . . . . . . . . . . . . . . . . . . . . . 947.2.9. Beta Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

7.3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 957.3.1. Scrum and Kanban . . . . . . . . . . . . . . . . . . . . . . . . 957.3.2. Scrumban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.3.3. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967.3.4. Beta Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

III. Conclusion 99

8. Summary and Outlook 1018.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

ix

List of Figures

2.1. A diagram that demonstrates the traditional OpenStack Swift con-figuration in a simple manner . . . . . . . . . . . . . . . . . . . . . . 16

2.2. A flow chart that demonstrates how middleware wraps the Swift corefunctionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3. A figure taken from Github’s official blog that shows popularity ofprogramming languages over time [60] . . . . . . . . . . . . . . . . . . 23

2.4. A diagram of Angular’s Model-View-Controller (MVC) approach . . . 25

2.5. A graph from Indeed.com that shows the job trends, advertised An-gular jobs versus React ones, between July 2012 to July 2015 [8] . . . 26

2.6. Comparison between a traditional relational database and a docu-ment model based database, like MongoDB . . . . . . . . . . . . . . . 28

2.7. A high level diagram that shows how Ansible runs on servers . . . . . 29

3.1. A simple technical overview of Safnið . . . . . . . . . . . . . . . . . . 32

3.2. Auðkenni asks an iPhone user whether to he/she wants to log in toSafnið . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3. A high level diagram that demonstrates the JWT authenticationmechanism in Safnið . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4. A flow graph that shows where and how Express.js helps with requestand response handling within the web application . . . . . . . . . . . 38

3.5. An example of Material Design from the Angular Material website [9] 42

xi

LIST OF FIGURES

3.6. An overview of the web application that shows flow of data fromAngular.js front end, to the Express.js web framework, Node.js webserver and data stores. . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.7. A diagram, based on official MongoDB documentation, that showshow sharding is carried through in MongoDB . . . . . . . . . . . . . 48

4.1. A screenshot from the web application: The first view the user seesafter opening the web. . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2. A screenshot from the web application: The front page of Safnið,showing media in a timeline. . . . . . . . . . . . . . . . . . . . . . . . 65

4.3. A screenshot from the web application: Various information aboutthe media object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.4. A screenshot from the web application: An overview of end usercreated albums. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.5. A screenshot from the web application: A document structure viewof all uploaded objects. . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.6. A screenshot from the web application: Operations possible on objects. 67

4.7. A screenshot from the web application: An upload form. . . . . . . . 67

4.8. A screenshot from the web application: A feature that allows the enduser to search for his/her objects. . . . . . . . . . . . . . . . . . . . . 68

4.9. A screenshot from the web application: Objects marked as favorites. . 68

4.10. A screenshot from the web application: An overview that allows theuser to see all shared objects. . . . . . . . . . . . . . . . . . . . . . . 69

4.11. A screenshot from the web application: The trash lists all newlydeleted objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.12. A screenshot from the web application: An overview of the user settings. 70

4.13. A screenshot from the web application: The feedback form. . . . . . . 71

xii

LIST OF FIGURES

5.1. A screenshot from the web User Interface (UI) that shows how toboth share an object and create a publicly accessible link to it . . . . 75

6.1. A figure, inspired by Kniberg and Skarin [48], that explains how aKanban board can be managed by different teams . . . . . . . . . . . 81

6.2. An intersection diagram of the Lausnir domain within Síminn . . . . 83

6.3. A screenshot of the Jira board . . . . . . . . . . . . . . . . . . . . . . 85

6.4. A screenshot from the Usabilla feedback dashboard . . . . . . . . . . 87

xiii

List of Code Excerpts

2.1. React templating example . . . . . . . . . . . . . . . . . . . . . . . . 262.2. Angular templating example . . . . . . . . . . . . . . . . . . . . . . . 272.3. An example from the Ansible documentation [50] . . . . . . . . . . . 30

4.1. Permissions with Express.js routing . . . . . . . . . . . . . . . . . . . 524.2. User and Device Model in MongoDB . . . . . . . . . . . . . . . . . . 534.3. OpenStack Swift’s pipeline configuration . . . . . . . . . . . . . . . . 554.4. Queue Server Playbook . . . . . . . . . . . . . . . . . . . . . . . . . . 564.5. Lines of Code statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 574.6. An excerpt of the function that takes care of translation . . . . . . . 61

List of Tables

6.1. Comparison between Scrum and Kanban [48] . . . . . . . . . . . . . . 80

6.2. Comparison of the benefits of using either Scrum or Kanban . . . . . 82

xv

Abbreviations

4DX 4 Disciplines of Execution

API Application Programming Interface

ASL Apache License

AWS Amazon Web Services

BSON Binary JavaScript Object Notation

BT British Telecom

BaaS Backup as a Service

CPU Central Processing Unit

CSP Communication Service Provider

CSS Cascading Style Sheets

CapEx Capital Expenditure

DBA Database Administrator

DBaaS Database as a Service

DOM Document Object Model

DoS Denial-of-Service

EB Exabytes

EC2 Amazon Elastic Compute Cloud

EOL End-of-life

xvii

Abbreviations

Exif Exchangeable image file format

FIFO First In First Out

GCHQ Government Communications Headquarters

GCM Google Cloud Messaging

GUI Graphical User Interface

HAProxy High Availability Proxy

HTML HyperText Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Over Secure Sockets Layer

I/O Input/Output

IDC International Data Corporation

IP Internet Protocol

IPTV Internet Protocol Television

ISP Internet Service Provider

IT Information Technology

ITIL Information Technology Infrastructure Library

IaaS Infrastructure as a Service

IoT Internet of Things

JSON JavaScript Object Notation

JWT JSON Web Tokens

KVM Kernel-based Virtual Machine

LBaaS Load-Balancing-as-a-Service

xviii

LOC Lines of Code

MD5 Message Digest 5 Algorithm

MEAN MongoDB, Express, AngularJS, Node.js

MVC Model-View-Controller

MaaS Monitoring as a Service

NASA The National Aeronautics and Space Administration

NFV Network Function Virtualization

NPM Node.js Package Manager

NSA American National Security Agency

NTT Nippon Telegraph and Telephone

NaaS Network as a Service

NoSQL Non Structured Query Language

ORM Object-Relational Mapping

OS Operating System

OTT Over-The-Top

OpEx Operational Expenditure

PIN Personal Identification Number

PM2 Process Manager 2

POC Proof of Concept

PaaS Platform as a Service

REST Representational State Transfer

S3 Amazon Simple Storage Service

xix

Abbreviations

SDN Software-Defined Networking

SHA-1 Secure Hash Algorithm 1

SHA-2 Secure Hash Algorithm 2

SIM Subscriber Identity Module

SKT South Korea Telecom

SOAP Simple Object Access Protocol

SSH Secure Shell

SSL Secure Sockets Layer

SSO Single Sign On

STB Set-Top Box

SaaS Software as a Service

TDD Test-driven development

UI User Interface

URL Uniform Resource Locator

UX User Experience

VPNaaS Virtual Private Network as a Service

VPS Virtual Private Server

WIP Work in Progress

WSGI Web Server Gateway Interface

XML Extensible Markup Language

xx

Acknowledgments

First of all I would like to thank my advisor, Dr. Helmut Neukirchen, for his ex-tremely valuable guidance and help throughout the project. Dr. Matthias Bookand Jón Ingi Einarsson also deserve gratitude for investing their time in being aco-supervisor and thesis examiner.

I would also like to thank my employer, Síminn, for giving me the platform and fundsthat allowed me to both work on the project and the degree in general, while workingfull-time at the company. I am also thankful to my boss, Davíð Gunnarsson, for hisunderstanding, counsel and giving me the authority to make a difference. Also, ofcourse, all my colleagues at Síminn, that did all the actual work.

Lastly, I want to thank my future wife, Björg, for all her patience and proofreadingof the thesis.

xxi

1. Introduction

1.1. Motivation

Síminn is an Icelandic Communication Service Provider (CSP), incumbent in theIcelandic market, offering fixed line, mobile, Internet, Internet Protocol Televi-sion (IPTV) along with media content for both TV and radio [114]. Like otherCSPs worldwide, Síminn is looking for new revenues while lowering both CapitalExpenditure (CapEx) and Operational Expenditure (OpEx). According to GartnerCSPs need to find new ways of revenue, do to the digitization of its business. Over-The-Top (OTT) services are quickly replacing the older telecommunication services.CSPs face four critical challenges to survive on the market [26]:

1. Use data growth on the Internet by capitalizing on video traffic and Internetof Things (IoT).

2. Increase operational efficiency via e.g. virtualization of the network, exploitingopen platforms with open interfaces.

3. Offering personalized customer experience.

4. Digitalizing the business, internally as well.

Like Gartner explains, CSPs need to exploit the data growth in some way. Usingan object storage, offering end users or internal services at Síminn an access to anopen, robust, carrier grade solution for the long term is considered optimal for aCSP such as Síminn.

By deploying a cloud platform with open standards, Network Function Virtualiza-tion (NFV) and Application Programming Interfaces (APIs) it is possible to cutdown CapEx, reuse commodity hardware, software and code over different projects,exploiting the same human resources in different components of the platform. ChrisDonley at CableLabs noted back in October 2015 that deploying OpenStack withtheir research and development team helped shortening the development cycle forsoftware projects from four months down to 6 weeks [117].

1

1. Introduction

Not a focus in this thesis, but it is worth mentioning that deploying a platform likeOpenStack enables the CSP for the future of networking with NFV and Software-Defined Networking (SDN). It is in fact possible to abstract the underlying hardwarewith its complexity and exploit open APIs to configure on a software level. CSPshave needed to encompass hardware from many different vendors on their networksfor a long time and it seems only to be growing even more complex. NFV actuallygrew out the requirement from CSPs, as an effort to simplify interoperability betweenthose vendors [61].

This thesis covers the Proof of Concept (POC) development and deployment ofan public cloud, object storage, running in OpenStack. Offering the customer astorage solution for small or no service fee, allowing him/her to upload media, evenautomatically could bring great value to him/her. It will be even more personalizedfor the customer when the cloud storage gets integrated with other services, likeIPTV, which is already on the roadmap for a phase two of this solution. Duringthe project the author of this thesis serves as a technical lead, a consultant, aScrum/Kanban master and a small part developer.

Deploying and operating a cloud platform within Síminn requires, in our opinion, aDevOps centric approach which brings operation and development employees closerto each other [65]. In our environment this boundary between employees is even morevague, where most staff members are both responsible for operation of differentsystems while taking part in development, either in the same or other systems.Introducing a DevOps culture into the organization can in deed lead to culturalhurdles, but the payoff is still faster delivery of software, better collaboration betweendifferent teams with more sophisticated and better overall processes [2, 125].

Many CSPs have a big opportunity in the public cloud market. In many countries,CSPs are considered to be the technical authority, sometimes with a governmentbacking. Occasionally, because of data sovereignty issues or laws, OTT companiescannot penetrate into some markets as easily. In Iceland, there are not direct lawsthat apply to data sovereignty that impede foreign OTT companies, but rather theopportunity for Síminn to stay closer to the customer. By that stopping foreignagencies like American National Security Agency (NSA) the British GovernmentCommunications Headquarters (GCHQ) to have access, as well as developing somefuture use cases for the customer, that gives our solution a big differentiation forthe local market.

Offering a cloud storage to customers is as much to increase affinity and reducechurn as it is to create new revenue streams. Síminn aims to add value to currentcustomers, increase the affinity and to reduce the customer churn which is a priceyevent for all CSPs.

2

1.2. Requirements

First when cloud solutions surfaced, CSPs tended to buy a solution out of the box,with high CapEx. The relationship with the vendor was then a supplier-customertype of a relationship. Now, the focus has shifted on partnerships. Instead ofbuying expensive solutions out of the box, CSPs have taken what Gartner’s reporton the changing business has stated and have begun deploying cloud solutions,either with partners, or with open-source solutions that have a strong community,like OpenStack’s. Avoiding all lock-ins with any vendors, using the hardware of theirchoosing, each time.

While OTT service providers have a long standing experience and relationship withend users it is really nothing compared with the history many CSPs have with theircustomers. The affinity, business history and the proximity to the end user thatCSPs have is something that OTT companies cannot match.

A public cloud storage product like covered in this thesis aims to add value tocustomers, give some revenue, serve as a POC where deployment and operations ofan OpenStack cloud will unveil the possibilities in a telecommunications InformationTechnology (IT) environment.

It is not considered as an option for an Icelandic telecommunication company, likeSíminn, to utilize international cloud providers, like Amazon Web Services (AWS),other than for pure fallback in emergency circumstances. Síminn has responsibilitiesto deliver services to rural areas in Iceland. Because of Síminn’s feasibility of closeproximity with the customer via physical locations and the possibility of an Internetoutage with the outside world, the chosen solution will always have to reside for thelong term in Síminn’s datacenters.

Telecommunication companies seem to have the trust of the general public, morethan most American companies like Google, Microsoft and Apple have, especiallyrelevant to news regarding to NSA and GCHQ with their unlimited access to net-works and user data. Síminn guarantees that it will not sell information from theirusers to a third party or allow any public institutions access to their data without acourt order. In Iceland, agencies are not given any backdoors to applications or anyaccess to regular users or ways to intercept user communications, like has proved tobe the case with both NSA and GCHQ [24].

1.2. Requirements

In the spirit of agile [25], the final product itself is not defined or decided at thismoment. A successful product, especially a software one, is never fully finished andhas a development cycle through its entire lifespan.

3

1. Introduction

For this thesis we emphasize on the first deployment of the product and require-ments for version 1.0, with the working title Safnið. Safnið was actually the nameof its predecessor, an online storage, originally deployed by Síminn back in 2008and still being used by a small percentage of Síminn’s customers [109]. The namecould possibly change before launch, but at this point it is still undecided. Therequirements are:

1. The software will be operated and maintained via OpenStack, utilizing thevarious OpenStack services, enabling scalability, disabling single point of fail-ure, exploiting the Swift object storage for documents, spreading the servicebetween different physical locations, etc. Dispersing the service to different lo-cations helps the company, being an Internet Service Provider (ISP), to keepbandwith contained to smaller areas. With that in mind, it should also aimto reduce the response time for the customer, with routing and load balancingto the closest, physical location each time.

2. Using OpenStack and Safnið as a proof of concept, the company hopes to showthe viability utilizing the cloud to save bandwith around the country.

3. It is also fair to mention virtualizing more of the server hosting saves expensesto a great amount. Although it has been an ongoing project for the last decadeor so, it is only a small percentage of the whole number of servers that havebeen virtualized of the possible lot.

4. The application will help the end user keeping their media safe, by upload-ing all media automatically to the object storage from the client on his/hersmart device. The user is also capable of keeping his/her manual backup ofdocuments, either via the native, mobile application or the web user interface.

5. The user will be able to create sub-accounts on his/her own account wherehe/she can grant access to a subset of his/her own data. The user will be ableto share documents with a public URL or on social media.

6. Síminn wants to avoid storing passwords. Using authentication services, likeoffered by the Icelandic-based company Auðkenni [22], for authentication andother passwordless methods will be optimal.

7. Safnið will have the option to allow the user to change the UI language, tosatisfy different requirements in the modern, multi-cultural country that Ice-land has become in the past decade. Icelandic, English, and Polish are thelanguages that will be supported at first.

8. The possibility of integrating Safnið to other Síminn products will be present.

4

1.3. Thesis Outline

Some examples could be electronic signatures, hosting videos recordings fromweb cameras from the smart home platform being developed at Síminn andthe option to display media in the IPTV services, via Síminn’s STB.

9. An API will be published so third party software developers can utilize theobject storage for their own projects. The API will be purely based on theOpenStack Swift API, with the addition of a few read-only queries to an addi-tional database, which enables users to search for objects via other parametersthan the unique ID.

10. The development team will use a version of Scrum, with daily standups andother transparent agile methods.

1.3. Thesis Outline

The remainder of the thesis is structured as follows:

1. The thesis is split in three main parts: Technical Aspects, Management As-pects and Conclusion.

2. The Technical Aspects cover the technical part of the thesis. It is split intothe following chapters:

a) In chapter 2 the foundations and technologies used are introduced to thereader.

b) In chapter 3 the architecture of Safnið, along with OpenStack is described.

c) In chapter 4 interesting aspects of the implementation are demonstrated,where code excerpts are shown, with screenshots from the web UI andother interesting facts about the project are explained.

d) In chapter 5 the fulfillments of the requirements from this Introductionsection is evaluated.

3. The Management Aspects cover the Agile practices and tools used in theproject. It consists of the following chapters:

a) In chapter 6 the methods used, Scrum and Kanban, are explained, alongwith the tools that were exploited.

5

1. Introduction

b) In chapter 7 the challenges that emerged in the development cycle areexplained and lessons learned listed up.

4. The Conclusion Part consists of chapter 8 where the project is summarizedand possible future work is discussed.

6

Part I.

Technical Aspects

2. Foundations

2.1. Introduction

CSPs worldwide have identified the opportunity that emerges with cloud manage-ment platforms, with many of them already deploying a platform to some extent inoperations. While there are many proprietary solutions available, the most promi-nence seems to be with OpenStack because of its flexibility.

Verizon is an American CSP [122] that is moving their environment to OpenStack,though only at a rudimentary state at this point. AT&T, also an American CSP [21],have been using OpenStack in their production environment since January 2012and just recently pledged some resources to contribute to the OpenStack project.Nippon Telegraph and Telephone (NTT) and South Korea Telecom (SKT) are bigAsian CSPs that are using OpenStack for various services. CableLabs is an non-profit research and development consortium that is using OpenStack as a part oftheir research, especially around NFV, that has been identified as one of the biggestopportunities with OpenStack, for CSPs, although its functions is not ready yet for amass market deployment [117]. British Telecom (BT) have deployed OpenStack upto some extent, but recently threatened to drop the project to adopt a proprietarysolution instead, if some key issues were not resolved shortly, where lack of NFVwas one of them [30].

After deciding on OpenStack with Swift as an object storage, it was still not theobvious course to develop inhouse the public cloud software solution on top of thestorage. Numerous software vendors were evaluated by Síminn. The main reasonsfor ending up with an inhouse solution were that other solutions are:

1. Not compatible with OpenStack Swift. Since OpenStack was chosen as thebackbone and Swift as the storage, the solution should of course be built ontop of that.

2. Hosted solution. It is not an option to host Safnið elsewhere than OpenStackin Síminn’s datacenters.

9

2. Foundations

3. Priced too high. Emphasis has been on keeping CapEx risk at a minimal fromthe start. That ruled out a few expensive solutions.

4. Bloatware with a complicated UI. A single software vendor offered technicallyeverything Síminn needed for a reasonable price: Rebranded web and mobileapplications with an integration with a Swift object storage. After a fewmeetings and demos it became evident that they would not comprehend thesimplicity requested by Síminn in Safnið. Their solution was a feature rich,have-it-all, and a complicated, sluggish software that was not near to fulfillingUI standards expected by Síminn’s customers.

2.2. OpenStack

The OpenStack project [94] started back in the year 2010 with the partnershipof Rackspace Hosting and The National Aeronautics and Space Administration(NASA). It is managed by the OpenStack Foundation, a non-profit organizationestablished in 2012 to promote the OpenStack platform.

OpenStack is a cloud operating system that controls large pools of resources via adatacenter, usually managed throughout a web interface dashboard called Horizon,which is a part of the optional OpenStack services. It gives the operator options tocontrol and configure all other services via its UI. The core services in OpenStackare:

1. The compute service called Nova.

2. The storage services, called Cinder for block storage and Swift for object stor-age.

3. The networking service, named Neutron.

There is a vast of optional services available, described below.

Since April 2016 the current stable version of OpenStack is labeled Mitaka. Thecurrent version at Síminn is the predecessor, labeled Liberty. An upgrade to Mitakais planned in May 2016, since Liberty is closing to an End-of-life (EOL) in November2016, and no security patches will be made available after that time [95].

10

2.2. OpenStack

2.2.1. OpenStack Compared to Other Providers

By introducing OpenStack into the telecommunication network it gives the oppor-tunity for virtualization of the telco/IT environment. Other platforms, similar toOpenStack, can be categorized into two types: Ready made, hosted cloud platformson the one hand and modular software components that together construct a cloudplatform hosted by the operator on the other hand. OpenStack naturally belongsto the latter type.

Some hosted and ready made cloud platforms providers include:

1. AWS – Amazon offers a collection of hosted cloud computing services, operatedfrom twelve different geographical locations. The two most known services arethe Amazon Elastic Compute Cloud (EC2), equivalent to OpenStack Nova,and Amazon Simple Storage Service (S3), which is equivalent to OpenStackSwift [6].

2. Google Cloud Platform – A cloud management platform offered by Googlewhere they provide hosting for customers in the same infrastructure as internalGoogle services. Like AWS above, equivalent to OpenStack, most servicesexist [43].

3. Other cloud platform providers include e.g. Linode and Heroku. Linode is arobust Virtual Private Server (VPS) provider and Heroku is a cloud applicationplatform that focuses on the web application and development, getting rid ofthe server operation responsibility for the developer. Both of the solutions arequite monotonic and therefore unsuitable for the scope of this project [62, 49].

Other, on premise, modular cloud platform software solutions, other than Open-Stack, include:

1. CloudStack – An open-source cloud computing software offered by the ApacheSoftware Foundation. Similar to OpenStack in many ways, but not as matureand widely adopted [17].

2. Azure – A proprietary cloud computing platform created by Microsoft. Itoffers a traditional Infrastructure as a Service (IaaS), with compute, storageand more. [70].

3. VMware – A proprietary cloud computing platform that was founded in 1998and mostly focused on hypervisors. Since then the company has grown, offeringother services, like an object storage, plus many others that are comparableto most of the OpenStack services [123].

11

2. Foundations

It is worth mentioning that it is of course possible to utilize ready made OpenStackhosting services. Rackspace, one of OpenStack’s founders, offers Platform as aService (PaaS) with off the shelf OpenStack [103]. Also, SwiftStack offers a hostedobject storage built on OpenStack Swift [116].

Also, OpenStack supports using various hypervisors and containers, like Kernel-based Virtual Machine (KVM), Xen, VMware ESXi, Hyper-V fromMicrosoft, Dockerand more. Proprietary solutions like VMware only support their own hypervisors.

OpenStack’s interoperability and flexibility is a long term strategy that fits betterto every CSPs requirements than the solutions above. While the Amazon offeringis a good one, their target group is hardly CSPs. While OTT providers knowledgewithin the datacenter is plenary, CSPs can add to that a working knowledge of whereand how the data moves to and from each and every customer. OpenStack givesthe CSP the opportunity of still being physically close to the customers. Amazoncannot compete with all the real estates that CSPs have scattered around everyapplicable country that, along with the network, gives the CSP proximity to everycustomer that is a key differentiator, as to OTT cloud providers.

While Azure and VMware can surely deploy a stable and suitable solutions forSíminn in the short term, Síminn needs to take the future roadmap of telecom-munication companies into the account and eliminate the risk of possible vendorlock-ins.

2.2.2. Swift

OpenStack released Swift back in in 2011 [20]. The objective was to handle thegrowth of data that was forecast in the coming years. Designed to store unstructureddata at a large scale with high availability, Swift can be deployed first with as few astwo nodes with a few disk drives and then be scaled up to thousand nodes withouthaving to restructure initial deployment or setup. According to research conductedby the International Data Corporation (IDC) in 2013 the worldwide storage capacitywill grow from 2596 Exabytes (EB) in 2012 to 7235 EB in 2017 and even more to35840 EB in 2020 [20]. The need for a different, robust and scalable storage solutionshas been obvious for some years.

There are three different types of data storage:

1. Block Storage – Stores structured data, represented as equal-sized blocks. Thisis a useful way of storing data the application needs to tightly control thestructure of the data. A prevalent use for block storage is databases which useraw block devices to read and write structured data.

12

2.2. OpenStack

2. File Storage – Most common for desktop users. File storage takes the harddrive and uncovers the filesystem. Although it is a simple and efficient way toabstract storage, it creates scalability challenges.

3. Object Storage – It does not provide a file-based access to the data, but ratheran access to the whole blob of data, usually through an API, via UniformResource Locators (URLs) using the Hypertext Transfer Protocol (HTTP)protocol. These URLs provide an abstraction between the data, so the under-lying mechanism is not really dependent on the data it self. Object storageis therefore ideal for systems that tend to grow and scale up in capacity orprocessing power, or even both.

Characteristics of OpenStack Swift

Swift is an object storage platform, that is easy to scale up or down. It allows usersto communicate with it via its HTTP interface, or various command line tools.Swift offers high availability, redundancy, high throughput and capacity. It has acommunity of many hundreds of contributors which has helped it to get stabler andfaster with a vast of features. It is possible to install Swift on low prices hardware,since it is easy to horizontally scale it in an unending manner. It is not a monolithicsystem that easily breaks down, but a distributed system that tolerates failing serverswithout dangering data availability. Swift’s key characteristics are:

1. Scalability

a) Swift is flexible and unopinionated of how big the deployment has to be.It is possible to run Swift on a few server nodes with a handful of harddrives, or thousands of server nodes with unrestricted amount of datastorage.

b) Performance does not decline because Swift is designed for scalabilitywith no single point of failure.

2. Serviceability

a) Swift’s distributed architecture offers a durable storage and stored objectswill always stay available.

b) Swift copies objects and distributes them across the cluster. The totalminimum of distributed copies spreadness is considered to be at least tothree different physical locations of the storage platform. This is some-thing easily configurable for the administrator, if data integrity policiesare higher or lower.

13

2. Foundations

c) In the case of a failed server, Swift promptly redistributes objects that be-longed to the broken device and replicates them elsewhere in the cluster,to comply to serviceability policies.

3. Distribution

a) It is easy to spread Swift across multiple data centers, which even mayhave high latency between them.

b) Swift incorporates distribution capabilities by allowing the operator todefine different regions and zones within the Swift cluster. Regions areusually specified by geographic boundaries, while zones are portions ofregions, for example two datacenters within the same building.

4. Concurrency

a) Because Swift can be distributed across multiple servers and locations, itallows high concurrency with handling many requests at the same time.This increases the throughput available, independent of single bottlenecksthat could belong to particular zones.

5. Flexibility

a) Swift offers flexibility to the operator, by allowing him to tailor the storageto meet the explicit requirements of the product or its users. Differentstorage policies, like different durability levels, performance levels, andmore, allow the operator to customize Swift to fit the organization’s needsto an optimal level.

b) Higher availability for some objects, restricting other objects to a singlelocation, or spreading some objects to all locations. These are just afraction of possibilities offered by Swift’s feature set.

6. Open-Source

a) Swift is open-source as a part of the OpenStack project, under the ApacheLicense (ASL).

b) Since 2014 Swift has over 150 active developers contributing to the plat-form. Potential bugs tend to be found and fixed quickly.

c) Unlike many open-source projects, Swift is backed up by multiple com-panies that test and deploy Swift in their production environment. Manytools, libraries, clients and applications support the Swift API and evenmore have support on their roadmap.

14

2.2. OpenStack

7. Low-cost Hardware

a) Since Swift is designed to handle failures without affecting the rest ofthe platform, individual components of Swift are less critical. Because ofthat Swift can operate on commodity hardware.

b) This means there is no lock-in with any particular hardware vendor ofany kind. Deployments can take advantage of lowering hardware pricesand enlarging hard drive capacities.

8. Feature Rich

a) Developers and operators benefit from the feature rich tool set available inSwift made by the community. Swift has of course many built-in featuresof storing and serving objects in a quick and safe manner, but other lessknown features that we could possibly exploit in Safnið are for example:

i. Automatically expiring objects. Objects can be given an expirationtime. After the expiration time has passed the object becomes un-available and gets deleted.

ii. Time-limited URLs. URLs can be generated in a way that theyare only available for a certain time. They can also be configured inSwift so they prevent hotlinking from a third party. Temporary writepermissions can also be granted without giving out full credentials.

iii. Quotas. Storage limits can be defined on containers and accounts.

iv. Uploading directly from HyperText Markup Language (HTML) forms.Web forms can be created that upload object directly into Swift.

v. Version control. An user can modify a document and Swift keeps theold documents and allows the user to review the history of changes.

vi. Access control list. Users can configure the access to their objects,give and deny access.

vii. Customization. Swift allows the development of middleware that canintercept the object before or after Swift manipulation. This will beexplained in detail below.

15

2. Foundations

viii. Different storage policies, like erasure coding. It allows the operatorto store objects with erasure coding instead of or with the stan-dard replication model of Swift. It is a method of data protectionthat splits the data into fragments before replicating those fragmentsbetween storage nodes and different zones. Erasure coding allowsquicker reconstruction of corrupted data, since it does not have toreplace the whole object.

In figure 2.1 the traditional Swift architecture is demonstrated. The end user orsoftware application communicates with the High Availability Proxy (HAProxy)load balancer [44] which redirects the request to an available Swift proxy node.The proxy node knows on which storage node the data is retrievable or where it issuitable to start placing the uploaded content.

Figure 2.1: A diagram that demonstrates the traditional OpenStack Swift configura-tion in a simple manner

Nodes

The Swift nodes are physical servers that execute the Swift services. They areproxy, account, container and object. A collection of nodes running these servicesare usually referred to as a cluster.

16

2.2. OpenStack

The proxy layer is the only part of the Swift service that communicates with clientsoutside the Swift environment. It manages and applies the read and write requestsfrom clients. When the client sends a write request the proxy process decides whichstorage nodes should store the data and sends the data to all the nodes at thesame time. If one of them is offline or unreachable the proxy process promptlyfinds another suitable node. Locating data for read requests is handled by rings, asdescribed in the next paragraph.

Swift replicates the objects as configured by the cloud administrator, so looking it upresults in many different locations for the same object. Rings are defined as tablesthat are distributed to all nodes in the Swift cluster. When an object is stored aMessage Digest 5 Algorithm (MD5) hash is taken of the object authorized name,described below, which is then used to decide the storage location.

Swift allows the user to store unstructured objects with an authorized name thatcontains three parts, where each part is an independent Swift process:

1. /account – The account storage location. The term account is often confusedwith the term user identity, but in Swift’s case it is the storage area. Theaccount stores a list of containers that belong to it along with miscellaneousmetadata about the account. It is often compared to filesystem volumes, but itis worth mentioning that the account does not store any objects or metadata ofobjects. It is possible to manage specific user access roles to different accounts,that can for example administer fully all containers and objects within a singleaccount, but nothing more.

2. /account/container – The container storage location is a unique entity withinthe account that keeps metadata about the container itself along with a listof objects stored in the account. Often compared to directories or folders infilesystems, although they cannot be nested like regular folders. The containerdoes not contain any objects or metadata about objects.

3. /account/container/object – The object storage location, where the object isstored. Since the parts are concatenated together to make a unique location,containers and objects can have the different names just as long as they arestored in another account. From the users perspective there is only a singlefile that he/she has access to, but of course Swift is configured to replicate theobject across the cluster to guarantee reliability and availability.

17

2. Foundations

Consistency Processes

The real challenge Swift faces is not the regular operations, but the failures andhow they are handled. Within Swift are quite a few consistency processes that areresponsible for finding and correcting failures and errors that help Swift maintainingdurability:

1. Auditor – It runs on all nodes that store data and ensures that stored data isnot corrupted.

2. Replicator – It runs on all nodes and ensures that a satisfiable amount of copiesexists of every object at the correct location in the cluster. It compares theaccounts, containers and object locally with remote nodes and pushes updatesto those that keep invalid data.

3. Account reaper – It runs on all nodes and processes accounts that have beenmarked for deletion.

4. Container and object updaters - Running on all nodes checking container list-ings on all accounts, ensuring they are all up to date, also updating object andcontainer count, amongst other things.

5. Object expirer – Running on all nodes and ensuring that object that have adesignated expiration time are purged.

Swift API

Swift offers a Representational State Transfer (REST)-ful API used by the projectto manipulate objects, using standard HTTP methods:

1. GET – Downloading objects or listing contents of either containers or ac-counts.

2. PUT – Uploading objects or creating containers.

3. POST – Updating metadata in accounts or containers, overwriting metadataor creating containers if they do not exist.

4. DELETE – Deleting objects and empty containers.

5. HEAD – Getting various header information.

18

2.2. OpenStack

Middleware

If there is any functionality missing from the core Swift deployment, Swift offersquite a lot of helpful middleware packages that extend the functionality of the objectstorage service. It is also possible to create and develop a middleware from scratch,using OpenStack’s open architecture.

Middleware wraps the core Swift in, where requests are passed through layers ofmiddlewares where objects could be altered on the way in, or the way out. Figure 2.2explains the process with an example of a Swift configuration:

1. Client or user sends the upload request.

2. Firstly, the File Classification Middleware receives the request and classifiesthe object and stores metadata about the type of the file being stored. Video,audio, text, image or something else.

3. The modified request, with the added classification metadata goes into the nextmiddleware wrapper, the encryption. In this example, the objects are storedin the storage with some kind of encryption. It also worth mentioning that theorder of middleware is key, where the classification would not be possible if theencryption middleware had finished first and modified the request beforehand.

4. After encryption the Swift core receives the request and responds back withan appropriate status.

5. If the client would have sent in a read request, the decryption middlewarewould manipulate the object after the Swift core responds positively.

Figure 2.2: A flow chart that demonstrates how middleware wraps the Swift corefunctionalities

19

2. Foundations

2.2.3. Other OpenStack Services

The OpenStack deployment at Síminn is a long-term project, still in its infancy.There is a vast variety of different services available from the OpenStack servicesthat could help with other projects in the future. Service worth mentioning thatwe could possibly exploit later include Trove as a Database as a Service (DBaaS),Heat for orchestration, Keystone for identity management, Tempest for integrationtesting between different interfaces, Monasca as a Monitoring as a Service (MaaS),plus many more. The OpenStack services being used today are:

1. Nova – The compute service that provides hosting and managing runningvirtual instances [90].

2. Horizon – The canonical dashboard for administering various OpenStack ser-vices in a web Graphical User Interface (GUI) [93].

3. Cinder – Cinder is the block storage service for OpenStack [33]. It providesstorage resources that can be used by the compute service.

4. Neutron – The networking service that offers Network as a Service (NaaS) [79].

5. Glance – Glance is the image service for OpenStack and is designed to store andkeep data assets used by other services, where they are kept available for lateruse [42]. Glance is mostly used in keeping images of Operating Systems (OSs)ready to be launched by Nova.

2.3. Authentication

Auðkenni [22] offers a secure way for authentication using mobile phones with Ice-landic Subscriber Identity Module (SIM) cards. The user writes his/her mobilenumber in a text input on the website, almost instantly gets a message on his/herphone where he/she is asked whether he/she wants to allow the log in to proceed,finishing the process with entering a Personal Identification Number (PIN) on thephone. The certificate has the benefit of being stored on the phone’s SIM card,instead of the OS, where it is more vulnerable to viruses or identity thefts. Insection 3.4.1, figure 3.2, a screenshot from an iPhone shows how the user is askedwhether to allow the log in to proceed.

All the user needs to be able to login to the project is an Icelandic, Auðkenni-enabledSIM card on their phone.

20

2.4. Programming Platforms


Choosing the correct programming language for a software project requires informa-tion about the feature set required by the end-product, as well as suitable developerswith the correct skill-set and capacity in the chosen programming language. Open-Stack is written in Python [102]. Safnið itself is mainly developed in JavaScript [52].

2.4.1. Python

Python is a widely used, simple with clear syntax and easy to learn, interpreted,high-level and object-oriented programming language with dynamic data typing. Itis considered very appropriate for rapid software development which is key for Open-Stack development, as well as a scripting language where existing components areintegrated. Python interpreters are available for most OSs. Although languages likeC/C++ [31] are much faster, the real bottleneck in OpenStack is disk and networkInput/Output (I/O), rather than the alleged slow speed of Python processes.

Síminn’s development in Python in this project is almost exclusively middleware forOpenStack Swift. This is explained in detail in section 3.5.1.

2.4.2. JavaScript

The JavaScript programming language has mainly been used in the past with webbrowsers and been executed client-side. In its early days there were only simplescripts that changed the behaviour and appearance of web pages up to a smallpoint. JavaScript grew fast, where vendors, like Mozilla and Google implementedan elaborate runtime engine within their browsers.

Node.js

In 2009, Google decided to take the JavaScript engine out of the browser and makeit able to run on servers. Node.js was created, enabling JavaScript to run server-side [89].

Everything in Safnið, both in the front-end and back-end, except datastores andloadbalancing, operate on Node.js server instances.

21

2. Foundations

There are many practical reasons why developers choose to use Node.js. To elaboratewhy we chose it for Safnið, most of them are listed below:

1. Homogeneity – The same programming language being used both client-sideand server-side. Thus giving the possibility of sharing code between thebrowser and server. Web developers already know JavaScript and while coding,it is helpful to use the same programming language when shuttling JavaScriptObject Notation (JSON) back and forth between the web application andweb server. If the web server is not implemented using JavaScript, the devel-oper constantly has to be translating code. By using JavaScript throughoutSafnið we gain practicality, save time and most likely re-use code. ChoosingJavaScript also ensures compatibility, as JavaScript is supported on all per-sonal computers in the world, plus a vast majority of smaller devices, liketablets and smartphones. In Safnið, conformity is also ensured with bothMongoDB, that utilizes JavaScript and OpenStack Swift, that offers an offi-cial toolkit that implements JavaScript of the OpenStack API.

2. Speed – Like mentioned above, the JavaScript engine behind Node is fast.The Google V8 engine processes thousands of instructions per second andhandles concurrency very well with its asynchronous nature. The magic be-hind Node.js is the event loop. It is a single thread that processes all I/Ooperations asynchronously. The traditional way of I/O operations it to runeither synchronously or asynchronously by spawning off many parallel threadsthat do the actual work. This way consumes a vast of memory and makes itcomplicated to code. When Node.js needs to do I/O operations, it sends theasynchronous task to the event loop with a callback function and then contin-ues to execute the rest of the code. When the operation finishes the event loopreturns to the task to execute the callback function. With this feature, Node.jsallows the developer to build fast and scalable applications maximizing usageof a single Central Processing Unit (CPU) and memory.

3. Community – The Node.js and JavaScript community is big. Because of itssize, the tools and modules available are numerous and well supported. Node.jsPackage Manager (NPM) is the default package manager for Node.js and comespre-installed with it [91]. It makes it easily manageable for developers to shareand re-use code. It manages dependencies for modules and installs them as wellon the go. The total number of open-source modules available via NPM is over200.000. Also, many large corporations use Node.js, which in a way ensureslongevity to the platform. The official Node.js Github repository includes a listof many of them [100]. The list includes LinkedIn, which use Node.js for theirserver interface for mobile applications. Microsoft is a core contributor to theproject and uses the platform internally and offers Node.js cloud hosting withWindows Azure. Paypal created the KrakenJS framework [59], which extendsExpress.js (Described below) and is exclusively used today when new web

22


applications are developed. Other companies that run extensively on Node.jsinclude Yahoo!, Trello, Uber, Zendesk, Netflix, plus many more.

4. Performance – Because of the non-blocking event loop previously mentioned,the data comes in and the responses return really fast. Node.js does notcomplicate setting up the separate threads. There is no overhead at all whichwould slow anything down. The developer writes code and Node.js promptlyprocesses it.

The alternative choice to Node.js would possibly be Tomcat, which is well establishedand stable at Síminn, Apache with the PHP programming language, which has beenthe most popular web development platform in the world for a long time, or thePython-written Django web development platform, that has gained much popularitythe last decade. All the pros listed above were the main reason for Node.js beingchosen for this project. Also, one should consider the framework’s popularity tobe able to attract top talent employees. Figure 2.3 from the official Github blogshows that JavaScript has been the most popular programming language since atleast 2008 and does not seem to be going anywhere [60]. The most recent bump inpopularity can be assumed to be because of Node.js entry into the mix in recentyears and subsequent client libraries that followed, like Angular.

Figure 2.3: A figure taken from Github’s official blog that shows popularity of pro-gramming languages over time [60]

23

2. Foundations

Express.js

Express.js is a minimal and unopinionated Node.js web application framework [37].Without any application frameworks, writing a rich application directly on Node.jsinstances becomes a really demanding task. Express.js is really a thin layer overthe built-in Node.js HTTP module, providing a light weight wrapper. Express.jsleverages different middlewares to offer some functionalities, like:

1. Parsing HTTP headers, request parameters, bodies, cookies and more,

2. Automatic response headers based on different data types,

3. Routing.

One of the fundamental features that Express.js offers is routing [108]. With it, it isdetermined how the web application responds to the client’s request to a particularendpoint. That could be a specific path and a specific HTTP request method. Everyroute can have one or more handler functions that react to the client’s request.

Angular.js

Like Node.js, Angular is originally developed by Google [12]. It is meant to enrichHTML web pages with tags that help creating single page web applications. Like theofficial Angular web page states: “HTML enhanced for web apps!" [12]. Angular is anopen-source JavaScript framework that exclusively runs client-side and is supportedon all modern web browsers. It uses the MVC programming paradigm to isolate theapplication logic from the UI [1]. One of its purposes is to move some responsibilitiesfrom the server-side to the client-side, to where they are actually better suited.

Figure 2.4 explains the MVC approach we have tried to assimilate and exploit inthe project. In short:

1. The model represents the current state of our web application. It delivers theweb application data after the view has sent a request and instructions fromthe controller to update the data in itself. It is just a JavaScript object thatcan be of primitive type like string, number, boolean or some complex typelike an object.

2. The view displays the data in a chosen format. It is what the end-user seeswhen displaying the web application, the Document Object Model (DOM).The developer can put an Angular expression in the view that binds data from

24


Figure 2.4: A diagram of Angular’s MVC approach

the model inside the controller. Angular has two-way data binding so the viewwill actually update automatically if and when there are model changes donefrom the controller.

3. The controller controls the relations between the model and the view. Theweb application logic is put there, using classes. The controller gets inputfrom the user, validates it and performs operations that modifies the model.The model actually lives within the controller. The so called $scope object isthe binding part between the view and the controller.

There are many JavaScript web development frameworks out there that are com-pliant with Node.js, and most of them open-source, just like Angular. Angularemerged quickly and took the web development community by storm in 2014. But,web development changes fast and by the end of the year 2015 React [105] seems tohave the stage as the trendiest platform. In figure 2.5 from the online employmentagency web site Indeed.com [8], shows clearly that although React has gained pop-ularity, Angular does not seem to be losing traction. In other words, Angular is notgoing anywhere soon.

To rationalize the decision to choose Angular instead of React could be explainedas follows:

25

2. Foundations

Figure 2.5: A graph that compares Angular versus React job adverts between July2012 and July 2015 [8]

1 var createItem = function(itemText) {2 return <li >{ itemText}</li >;3 };4 return <ul >{this.props.items.map(createItem)}</ul >;

Listing 2.1: React templating example

1. The development started early 2015. React had not gained all that attentionthen as it has today.

2. The development team at Síminn was familiar with Angular. Although Reactis considered to have a lower learning curve, the knowledge was already inhouseat the company so it was an easy decision.

3. Templating: The Angular templating system is powerful. The React code syn-tax within the HTML document makes it complicated compared to Angular.UI development takes a high percentage of the development effort. It couldquickly get complicated in React. Writing a simple iterator to display data inthe UI with React could look something like can be seen in Listing 2.1, whileAngular’s more simpler approach can be seen in Listing 2.2.

4. React has no built-in routing.

5. Angular has two way databinding, like explained above, whereas React usesexplicit updates.

26

2.5. MongoDB

1 <ul>2 <li ng-repeat="item in items">{{item}}</li>3 </ul>

Listing 2.2: Angular templating example

This being said, it will be a difficult decision choosing between Angular and Reactin the next project. One concern is that at this point it is not clear for how longAngular 1.x will be supported. As of May 2016, a stable version of Angular 2.0 isnot yet available, but the difference seems to be big between the two versions, wheree.g. $scope objects and controllers are replaced by components and directives. Andirect upgrade path will not be available, but an incremental upgrade that helps tointroduce Angular 2 features in to the Angular 1.x application gradually [120]. Thepossible effects on upgrading Safnið have not been investigated.

2.5. MongoDB

Derived from the word humongous, MongoDB is an cross-platform, open-source doc-ument model database, designed for scalability and high performance [73]. Insteadof the traditional relational and table-based database structure, Binary JavaScriptObject Notation (BSON) (JSON for MongoDB) like documents are operated to cre-ate a simple to administer and robust Non Structured Query Language (NoSQL)database solution. Another similar document model NoSQL database worth men-tioning is CouchDB from the Apache Foundation [18].

The typical MongoDB document can contain one or more fields that each containa typed value, but instead of spreading a record to different tables via foreign keys,every record and its intended relatives are kept together in a single document. Thismakes access to the data simpler and counts out the need for any bothersome JOINoperations [72]. Figure 2.6 compares the same scheme between a traditional databaseversus a document based database like MongoDB. The example demonstrates howthe document model eliminates the need for relations between tables.

Multistructured data-types in high volumes are designed to fit into the flexible datamodel and robust architecture that MongoDB offers.

In Safnið, MongoDB is used for storing user information along with object metadata,where Node.js modules extract information from them to store in the database. Itis easy to rationalize when the following items are taken into account:

1. High availability with replica sets, in a scalable environment. Scaling the Mon-

27

2. Foundations

Figure 2.6: Comparison between a traditional relational database and a documentmodel based database, like MongoDB

goDB environment is both easy and quick. Also, recovery is fast. When theneed to partition or shard the database arises, MongoDB offers an easy solutionfor horizontal scaling. For our project, sharding is covered in section 3.6.3.

2. A lesser need for a specific Database Administrator (DBA). Just like SDNaims to lessen the future need for specific network engineers, with specific set ofskills; managing a MongoDB database is similar to the rest of the environment.That being said, there are many best practises that need to be followed to avoidmany pitfalls. That will of course require resources.

3. Flexible. Documents can have different fields, it is easy for the agile developerto change direction without having to worry too much about the old structure.

2.6. Ansible

OpenStack offers an easy way to quickly set up virtual instances and OpenStackservices. But to automatically deploy the custom made and developed solutionwith all configurations in place, scale up or down Safnið as a whole or just selectedcomponents, it is required to deploy a configuration management software, such asAnsible [16].

Ansible is considered a simple tool for configuration management, configuring weband application files, application deployments, service orchestration and more. Fig-ure 2.7 demonstrates how Ansible manages different servers:

1. The Ansible server logs in to the server via Secure Shell (SSH). The server

28

2.6. Ansible

only needs to have an user for Ansible and Python installed. There is no needfor a specific Ansible agent to be installed.

2. Ansible then gathers various information from the server: Installed OS, in-stalled packages, running services, plus more.

3. Ansible finishes by running playbooks on the server.

Figure 2.7: A high level diagram that shows how Ansible runs on servers

Playbooks are the configuration, deployment and orchestration language for Ansible.The playbooks describe the policy the administrator wants to enforce on remotesystems and groups of servers. Each playbook is represented by at least one playand consist of files in YAML format (Recursive acronym and stands for “YAML Ain’tMarkup Language"). Ansible is custom made for deployment and orchestration ofSafnið, but it is also convenient for enforcing policies on to multiple servers, askeeping software up to date, and more.

Below in Listing 2.3, an example directly from the Ansible documentation is demon-strated [50], showing how to ensure the Apache web server is at the latest versionfor all nodes that belong to the webservers group, writing the correct content to theApache configuration and finally making sure the service is running on the node.

29

2. Foundations

1 ---2 − hos t s : w e b s e r v e r s3 vars :4 http_port : 805 max_clients : 2 0 06 remote_user : r o o t7 t a sk s :8 - name: e n s u r e a p a c h e i s a t t h e l a t e s t v e r s i o n9 yum: name=h t t p d s t a t e= l a t e s t

10 - name: w r i t e t h e a p a c h e c o n f i g f i l e11 template : s r c =/ s r v / h t t p d . j 2 d e s t =/ e t c / h t t p d . c o n f12 no t i f y :13 - r e s t a r t apache14 - name: e n s u r e a p a c h e i s r u n n i n g ( and e n a b l e i t a t

b o o t )15 s e r v i c e : name=h t t p d s t a t e= s t a r t e d e n a b l e d=y e s16 handler s :17 - name: r e s t a r t a p a c h e18 s e r v i c e : name=h t t p d s t a t e= r e s t a r t e d

Listing 2.3: An example from the Ansible documentation [50]

30

3. Design and Architecture

3.1. Introduction

The aim of the setup of Safnið in OpenStack is to be robust, scalable and to deliver apowerful and a price friendly product. In this chapter the technical design of Safniðis explained, using figure 3.1:

1. Section 3.2 describes the user’s entry point into Safnið with load balancing.

2. The cloud proxy is served with NGINX, which is explained in section 3.4.2. Onthe same servers lie other Node.js applications: GUI, API and Authentication.They are explained in section 3.4.

3. Other Node.js applications that run in the back-end are: ImageTasks, Video-Tasks and Queue. They are described in section 3.6.

4. Load balancing in the back-end, to the Swift proxy, follows the same principleas described in the front-end, in section 3.2.

5. The MongoDB stores various meta- and user data that is discussed and ex-plained in section 3.6.3.

6. Automation and scaling with Ansible is covered in section 3.7.2.

31


Figure 3.1: A simple technical overview of Safnið

3.2. End User and Load Balancing

The end user connects via HTTP to the Internet Protocol (IP) address of the loadbalancer. Load balancing is handled by the Load-Balancing-as-a-Service (LBaaS) [80],which is a component of the Neutron OpenStack Service [79]. The HAProxy driver [46]for OpenStack is used. HAProxy [44] is an open-source load balance software thatclaims to be the de-facto standard for load balancers. Well known websites runningon HAProxy include Twitter, Tumblr, Github, Reddit, plus many more [45].

The default, simplest and easiest to implement load balancing method for HAProxyis the Round Robin first-come, first-served algorithm. If used, the servers behindthe load balancer are sequentially used, for a given time period. The servers behindthe the load balancer should have the same capacity and treat similar tasks. The

32

3.3. Applying Node.js

Round Robin does not take into account the load on each server and that is why theLeast Connections algorithm was chosen. It uses the Round Robin approach, butrefers traffic to the server with the least active connections [63]. Since the differentservers are identical, there is no reason for the Weighted Least Connection, wheredifferent server capabilities are also taken into account.

3.3. Applying Node.js

In section 2.4.2 the Node.js JavaScript runtime environment essentials and benefitswere covered. The project is modeled into a few different applications that many runon Node.js, listening on different ports on different OpenStack virtual nodes thatcan bee seen in figure 3.1. Using the NPM package manager, many of the Node.jsmodules make the development process much simpler. Node.js modules being usedin our web application include:

1. Express.js. Covered in section 3.4.2.

2. Morgan [76]. An HTTP request logger middleware for Node.js that extendsIntended for automated logging of HTTP requests and responses. It logs theusers IP address, request method, HTTP version, response status and more.

3. Body-parser [27]. Node.js body parsing middleware that extends Express.js.It provides amongst other things a JSON body parser.

4. JSONWebToken [56] and Express-jwt [38] that provide JSON Web Tokens(JWT) authentication and authorization functionalities, providing and vali-dating permission tokens.

5. Passport [97]. A flexible authentication middleware for Node.js that works ontop of Express.js. Its flexibility allowed Auðkenni’s authentication methods tobe implemented there.

6. Mongoose [74]. Used to connect and model data between Node.js and Mon-goDB.

33


3.4. Front-End

Referring to figure 3.1 again, the front-end of Safnið consists of server nodes thatinclude the Cloud Proxy, GUI, API and Authentication, which are covered in thissection. OpenStack Swift also belongs to the front-end, but because of its extent, itis covered in section 3.5.

3.4.1. Authentication

One of the requirements for Safnið is to avoid storing the passwords for users inSíminn’s databases.

All the user needs to be able to log in to the project is an Icelandic, Auðkenni-enabled SIM card on their phone. Although the idea is to keep it open and alloweveryone to use Safnið that are able to log in, it is currently restricted to a list ofmobile numbers belonging to beta testers, which is briefly covered in sections 7.2.9and 7.3.4.

The web services offered by Auðkenni have been converted by Síminn from SimpleObject Access Protocol (SOAP) to REST ones, mainly to maintain compatibilitywith other components of the solution. This service is maintained on a Tomcat webserver on a virtual instance in the OpenStack cloud and already used by few otherservices at Síminn. The reason why REST is almost always chosen ahead of SOAPby developers is because it is much simpler in just about every way, e.g. just relyingon standard HTTP methods. Also, widely considered modern compared to SOAP.

The reason why Auðkenni chooses SOAP is unknown, but it is likely because ofextra security features offered in the standard. While possibly considered a legacystandard by some, it is also more mature.

After the user successfully logs in using Auðkenni, a JWT [55] is saved client side,in the local storage. This is a big change from the old method of keeping the sessionalive with a cookie stored on the server side. When the user tries to access protectedroutes he/she sends his/her token to the server. The server checks whether the tokenis valid and returns an appropriate response.

JWT is based on a web standard and mainly used to securely communicate JSONobjects, even across insecure HTTP sessions. A single token consists of a header,payload and a signature. All the information needed to encrypt and decrypt themessage within the JSON is stored in the JWT, so it is not dependant on otherservices (self-contained).

34

3.4. Front-End

Figure 3.2: Auðkenni asks an iPhone user whether to he/she wants to log in toSafnið

1. The JWT header usually holds the type, which is JWT and the encryptionalgorithm used on the JSON.

2. The JWT payload contains the claims. The claim is an overview of the userwith additional metadata.

3. To create the JWT signature the user will need the encoded header and pay-load, a chosen secret and the algorithm used and stated in the header.

Figure 3.3 depicts the authentication process:

1. The end user logs in via Auðkenni and the getToken() method is executed.

2. When login is successful the cloud authentication module asks the JWT nodefor an authentication token, which is instantly sent back to the end user.

35


3. The end user queries the Swift proxy with the token and an HTTP method.

4. A middleware in the Swift proxy, cloud_auth.py, that is placed in the Swiftpipeline queries the JWT node and asks it to verify the authentication token(The pipeline is demonstrated in section 4.2.3).

5. The JWT node replies with either a validation or rejection.

6. Swift either rejects the end user’s request or returns according to his/her re-quest.

Figure 3.3: A high level diagram that demonstrates the JWT authentication mecha-nism in Safnið

Both Node.js and Express.js, mentioned in section 3.4.2, offer middleware to supportJWT.

36

3.4. Front-End

3.4.2. Web Application

The web site is served with a NGINX proxy web server [85] in front of the Node.jsserver. The web server is responsible for serving all static data, such as markup,stylesheets and client-side scripts and also API calls to the backend.

While it is easy to locate many reasons to choose NGINX to operate in front of theNode.js applications, these two reasons are considered fundamental:

1. Performance – Using NGINX to serve static content increases throughput.A simple test executed by Cannaday at Modulus, which is an applicationcontainer platform, showed that letting Node.js serve all the content on hissite, it was able to serve less than 900 requests per second, while using NGINXserving the static content, the same site served just over 1600 requests persecond [32].

2. Security – Vulnerabilities sometimes found in Node.js can be mitigated whenNGINX is in front of Node.js. An example of this would be the vulnerabilityCVE-2013-4450 found in 2013, where remote attackers could easily cause aDenial-of-Service (DoS) by sending a large number of requests to the Node.jsapplication without waiting for the response. This easily caused memory andCPU consumption on the server to slow down or crash the application [124].While there can of course be similar vulnerabilities within NGINX itself, NG-INX has e.g. a number of features to mitigate DoS attacks [77].

Another reason is that using Node.js as the main server forces the administra-tor to either:

a) Configure privileges with the Node.js processes, since only the root user(The super user) can bind to ports 80 and 443 on the server (The de-fault HTTP and Hypertext Transfer Protocol Over Secure Sockets Layer(HTTPS) ports),

b) or just run the Node.js as the root user. If the Node.js application has anyvulnerabilities the the hacker could potentially cause even more damage.

While the Apache HTTP Server [19] could also be deployed with Node.js, since bothservers are considered powerful, flexible and capable, we chose NGINX because itconsumes less memory than Apache and serves static content at a much higherrate [126].

The web site is a MongoDB, Express, AngularJS, Node.js (MEAN) stack applica-tion [69], development application generated with the AngularJS Full-Stack gener-ator [13], which helped to kickstart the application.

37


Express.js

Some of the Node.js modules mentioned in section 3.3 are in fact manipulated asExpress.js middleware. One example is Morgan, mentioned in section 3.3, that logsevery request before the next middleware comes in. After Morgan, the Passportmiddleware authenticates the user, and so on. Express.js is in fact just a seriesof a middleware function calls. Without a framework like Express.js the developerneeds to do a lot if things from scratch: He/She needs to enable support for cookies,multiple formats and media types, cache data and pages, parsing URL for queryparameters and finally enable flexibility in loading up resources. Express.js, alongwith other Node.js web application frameworks, does all that, so the developer willnot have to reinvent the wheel every time.

Figure 3.4 shows where Express.js fits within the web application architecture.Firstly the user sends a request for something. Secondly, the Node.js HTTP webserver hands that same request over to the Express.js application which enrichesit with extra features for the developer to work with. After that, the codebase ofSafnið handles the request and sends the response back to the Node.js web server,which ends with sending the response to the user.

Figure 3.4: A flow graph that shows where Express.js fits within the web application

38

3.4. Front-End

In section 4.2.1 it is presented how Express.js secures the web application, handlingpermission and access responsibilities with routing.

AngularJS

There are a few different Angular modules developed by the community being ex-ploited in the project. A few of them are worth mentioning:

1. ng core module – The core module is loaded in all Angular web applicationswhen they are initialized. The module includes essential components andfunctions that Angular needs to have to be able to work [81].

2. ngAria – The purpose of ngAria is improving Angular’s accessibility by en-abling ARIA [4] attributes that help users with disabilities [3].

3. ngAnimate – A module that offers support for both JavaScript-based andCascading Style Sheets (CSS)-based animations of different sorts [82].

4. ngResource – A module the provides the functionality to communicate withREST services [86].

5. ngCookies – A wrapper to read and write browser cookies [83].

6. ngSanitize – A directive that sanitizes HTML strings and eliminates, or tries toeliminate, the possibility of malicious code being executed via the web UI [88].

7. AngularUI Router – Instead of the default ngRoute module provided by An-gular [87]. It provides routing and linking services and directives within theweb UI. AngularUI Router is organized around states, instead of URL routes,like ngRoute. When a state gets activated in the UI, AngularUI Router ma-nipulates the DOM directly [15].

8. Angular File Upload – A module that offers file uploading functionalities, thatsupport drag-and-drop, showing upload progress, validation, filters and anupload queue [78].

9. ngInfiniteScroll – Instead of the default web browser pagination, an infinitivescroll is introduced. It detects when the user is at the bottom of the screenand evaluates an expression that can be used to load more data. It is mainlyused in the media view of the application [84].

10. AngularJS HTML5 Fullscreen – A service and a directive that allows media

39


to be easily displayed in a full screen mode in the web browser. We use it inSafnið to allow full screen, especially in slideshows [14].

The Angular team has manipulated the JQuery [54] JavaScript library and calledit jqLite [11]. Developers tend to include jQuery in their application for the fullfeature rich functionalities, but the fallback that Angular uses is jqLite. jqLite isa trimmed down version, actually just using about 35 jQuery methods, that allowdifferent DOM manipulations.

Another library used in the web application that deserves a mention is lodash [64].Lodash offers many utility functions that help developers efficiency and reducingLines of Code (LOC) in their programs. Good lodash use case examples of operationsthat simplify code would be iterations, mapping, finding substrings, filtering andmore. A method frequently used within Safnið is the merge method that mergesobjects in a recursive manner. The developer can declare which object takes in dataas a parameter, and then as a second parameter input an array of other objects thatget merged in the first object. Lodash is used throughout the project, but mostextensively exploited at the client-side in the web application.

Using Angular’s MVC pattern, the web application is split up in different compo-nents. Some worth mentioning include:

1. Albums

2. Images and videos

3. Favorites

4. Various dialogs

5. APIs

6. User settings

7. Translation

All these components comply to a similar pattern, but the Albums component isparticularly convenient to explain. When the Album state is activated in the webUI, the AngularUI Router module re-routes the user to the Album module, wherethe album.js file has the following declarations:

1. URL route: /albums

40

3.4. Front-End

2. Template URL: app/albums/albums.html

3. Controller: AlbumsCtrl

4. Authentication needed: True

The album.html file holds Angular extended HTML syntax, where directives arereferenced. There we have the AlbumsCtrl controller. It is the Angular controller,running client-side. There are a few methods there interacting with the UI; listingup the albums already available (actually within the constructor function), creatingan album, renaming an album and removing an album. In the controller, the $scopeis initially defined and behaviour added to it. Right at the top in the controller,the dependencies are declared and there is where the API module, running in theback-end, is referenced. There we have the album controller, server-side, and model.Other modules mentioned below follow the same logic.

UI Design Principles

It is easy to see why many choose Google’s Material Design [66] for their layouts inapplications as often and widely as it is today. The goal of Material Design is tounify the experience and make it the same across different platforms, no matter thescreen size. It is very cohesive and makes the job for the front developer a wholeless time consuming, plus furthering him to practice better design processes. Googleuse the design themselves for most of their applications. Whatsapp [127] use it bothon their website and for their mobile applications. SwiftKey [115] uses it for theirautocorrect and keyboard mobile applications. Tumblr [119], Pocket [99], plus manymore employ it as well, as it has become the industry standard for many developers,that choose to extend frameworks like Material Design, instead of writing somethingthemselves from scratch.

To make the implementation between the Angular application and Material Designeasier the Angular team has introduced Angular Material [9], which is a referenceimplementation of Material Design. It offers full set of well tested components withextensive online documentation. Including Angular Material into the Angular webapplication code is as simple as with any other Angular module.

Implementing Material Design into this project was a rather effortless process,changing to another design framework would presumably prove to be painless also.Soon, Síminn’s UI standards will be taken into account and the project’s UI revisedwith that in mind. Other web applications within the company have either beendeployed with Material Design or Bootstrap [28] in recent past.

41


Figure 3.5 shows an example from the Angular Material website [9], where MaterialDesign is exploited.

Figure 3.5: An example of Material Design from the Angular Material website [9]

Overview of Web application

In figure 3.6 a graphical and simple overview of the web application architecture isrepresented. It shows how Express.js serves as a middle layer between the front-endand back-end of Safnið. The Angular controllers serve as communication middlelayers between user views and server.

Figure 3.6: An overview of the web application that shows the flow of communication

42

3.5. Using OpenStack Swift

3.5. Using OpenStack Swift

In section 2.2 of the Foundations chapter the motivation for using OpenStack inthis project was introduced. It is an obvious choice to adopt an object storage, andwhen OpenStack is already deployed for a part of the project, the OpenStack Swiftis an even more obvious choice. Swift is the object storage project that offers cloudstorage software which allows the user to store and retrieve a big amount of data athighest procurable speed, with a simple API.

Every user defined in Safnið gets his/her own account in Swift to ensure segregationof data between users. The unique path to objects that belong to the user is on theformat:/v1/cloud/<telephone_number >/< account_creation_timestamp >/<

container_name >

Explanation of this string is as follows:

1. The API current version is 1.

2. When the user logs in for the first time his/her account gets created, with themobile number he/she used to log in via Auðkenni and the timestamp of thecreation.

3. Each object belongs to a container. The user will be allowed to create specificcontainers for other users to restrain access or for specific integration withother services. In general, there are two containers:

a) Cloud. For all regular uploaded objects.

b) Thumbnails. For different sizes of the images resized automatically for abetter user experience. Also, thumbnails cropped from video files.

3.5.1. Middleware

Swift’s behaviour before and after object, container and container manipulation isusually altered with some Python Web Server Gateway Interface (WSGI) middle-ware, that it usually adapted to the Swift proxy server.

Some chosen middlewares, ideal to illustrate the usage of Swift WSGI middlewareare:

43


1. cloud_auth – Used with JWT. Used to confirm authentication tokens fromJWT and grant or decline access to the object store. Earlier illustrated infigure 3.3.

2. encrypt_decrypt – The idea is to allow advanced users to encrypt their datain the object storage, using Secure Hash Algorithm 1 (SHA-1) or Secure HashAlgorithm 2 (SHA-2). By default, encryption will be disabled in Safnið tospeed up the process of sending and retrieving objects in Swift, as well tominimize CPU work for users that do not require encryption.

3. media_class – Media Classification for Swift. Arrays defined in top keepknown file extensions for classification. An example of one array is IM-AGE_LIST_EXT which contains five strings of known image format exten-sions: jpg, jpeg, png, gif, and tiff. Using the classification it is easy for theback-end to define how to retrieve and manipulate the metadata of each filetype.

3.5.2. Developer API

The OpenStack Swift object storage is open-source, freely available and a part ofthe OpenStack project. Swift offers a RESTful API that can be accessed withHTTP requests directly. This API is exploited for Safnið, but it is also offered toany interested, third party developers that want to use their account directly withSwift [96] when developing their own software. In user settings the option is givento the end user to enable access to the development API. Enabling it will permitdirect access to the API and make documentation available in the web UI.

Other web service calls are via the MongoDB REST API, to fetch account or meta-data specific information. Mongoose is the object modeling package used to com-municate with MongoDB via the Node.js server. It essentially works just like aregular Object-Relational Mapping (ORM). Body-Parser is the parsing middlewareand parses the requested metadata as JSON. Both modules were earlier mentionedin section 3.3. This MongoDB REST API is in fact in a read-only mode, since theonly modifications done in MongoDB’s metadata is done via the back-end of theproject with automated processes, like ImageTasks and VideoTasks described be-low. Express.js routing checks whether the request is coming from an authenticatedand authorized source and returns a relevant error code if that fails.

44

3.6. Back End

3.6. Back End

Most of the CPU load is in the back end due to jobs as ImageTasks and VideoTasks,which are described in this section. Also, the Queue stores all jobs waiting for openslots to be worked on by tasks that vary depending on the type of the object. Thesecomponents all reside on identical virtual servers in the back-end, running Node.jsapplications.

3.6.1. Queue

The Queue Node.js application stores all the objects waiting in line to be handled byImage- or VideoTasks components in the back-end. The Queue sorts the documentsby timestamp and lets task fetch them in a First In First Out (FIFO) manner.

When an object is changed in the storage, information about that change and objectgets added to the Queue collection in the database as a document. A changedobject in this case can be a new object, edited or even a removed one. The tasksmentioned below constantly work on the Queue, removing all finished documentsfrom the database.

The Queue document holds various information about the object itself: For examplethe account it belongs to, the storage container, actions to be done on the object,type of file and more.

Although the MongoDB storing the object metadata is backed up and executedsafely in OpenStack, there is no problem to make temporary resources available forthe Queue to redo all the metadata for all objects stored in Swift.

3.6.2. Tasks

In the back-end different components reside to work on the existing documents inthe Queue model. At this moment there are only tasks for image and video types ofobjects. It is a natural next step to add more for other types like text documents,spreadsheets, audio, and more.

45


ImageTasks

ImageTasks is an independent Node.js application that runs in the back-end andtakes on all relevant documents in the Queue model created by the Queue applica-tion described above. Some examples of functions running within the ImageTasksapplication are:

1. generateThumbnails – Generates different thumbnails for different devices withvarious resolution and operating systems.

2. removeThumbnails – Removes thumbnails for objects that have been deletedfrom the object storage.

3. setMetadata – Retrieves Exchangeable image file format (Exif) data from theimage. Makes it possible for the end user to search for images by somethingelse than the unique name of the object in Swift. It makes it possible to searchimages by location, camera type or other explicit metadata tags.

VideoTasks

VideoTasks is an independent Node.js application, very similar to the ImageTasksapplication, that manipulates video objects. The application generates and removesthumbnails and retrieves metadata from the video files. The thumbnail generationis done with a powerful Unix utility called FFmpeg [39]. It spawns a FFmpegchild process on the server, for the video file, which executes asynchronously in thebackground and snaps a few thumbnails to make previewing of videos for the usera more pleasant experience. To prevent most of the possible security vulnerabilitiesrelated to executing FFmpeg the following preventive actions are constructed:

1. The application is compiled with only most necessary features.

2. The child process spawned by Node.js executed with a limited OS user that hasonly access to the working directory, which is configured with POSIX accesscontrol lists [40].

In some cases FFmpeg processes seem to hang and consume all the CPU, so itwill presumably become essential to monitor and force kill the processes, instead ofscaling up the back-end of Safnið.

46

3.6. Back End

Other Possible Tasks

It is easy to continue with this methodology on other types of files. It is possibleto retrieve authors, editors, creation and modification dates, even the modificationsthemselves, and excerpts from the text documents. Music files often store the per-former, title of song and album, year of release, plus other music related attributes.Most files contain metadata of some kind and it is mostly restricted by ones imag-ination and the actual requirements of what it can be considered useful to retrievefrom files.

3.6.3. MongoDB

The MongoDB stores all metadata about objects, fetched with the tasks mentionedabove [73]. The database subsides in the back-end but selected data is exposed viaa REST web services with Express.js routes explained in section 3.4.2, available forthird party developers.

The MongoDB scheme is described as follows:

1. Albums – The user can create albums and insert objects, that is photos andvideos, into it.

2. Objects – Metadata about objects, including:

a) Account it belongs to.

b) Container it belongs to.

c) Filename.

d) Public link. Where applicable.

e) Is this object marked as a favorite object? A boolean value.

f) Does this object belong to any albums?

g) Plus more.

h) Encryption key. Used by the encrypt_decrypt Swift middleware describedin section 3.5.1.

47


3. Reports – User statistics, based on daily activity by the user.

4. Users – Various user information is stored in the MongoDB, although not anypasswords, since Auðkenni takes care of that. In section 4.2.2, the user modelis demonstrated.

5. Devices – It will be possible to link Android mobile devices to the users. Themobile application is still in a pre alpha state, but the model stores informationabout the OS version, Google Cloud Messaging (GCM) token and the publickey of the device. Also demonstrated in section 4.2.2.

Sharding

Figure 3.7 explains the high-level idea of sharding in the MongoDB [112]. Instead ofscaling vertically, by adding disk space and CPU power to a single server node, thedatabase is partitioning data into the so called shards, on different database servers.Soon, the Metadata collection in the database could reach 1 terabyte. Instead ofstoring all that data in a single resource heavy machine, the data is divided to anundecided number of database servers, which proves to be much more cost effective.Sharding is in fact just horizontal scaling of the database content.

MongoDB offers methods of adding shard servers into the cluster of database servers,as well of removing them. If the cluster of sharded server becomes imbalanced be-cause of a possible empty database it quickly gets balanced with automatic processesin MongoDB.

Figure 3.7: A diagram that shows how sharding is carried through in MongoDB

48

3.7. Scalability and Automation

3.7. Scalability and Automation

Typical legacy applications require some larger hardware to scale up, defined asvertical scaling. Cloud-based applications, as this solution, do not depend on asingle server in a rack and can therefore be more easily modified and scaled up ordown in a horizontal manner, which OpenStack is designed to be. Rather thanswitching to even larger servers that could even end up being idle for long periods oftime, it is easier to either expand the virtual host instance in OpenStack or scale outhorizontally by creating identical hosts of desired amount and install a load balancerin front of them.

3.7.1. OpenStack

The OpenStack environment is currently only one region, but a expansion to thesecond region is planned in the second half of 2016. The first region is divided intotwo zones, just like the second region will be. Today, the first region is located atSíminn’s headquarters in Ármúli, Reykjavík, and the second one will be in Síminn’sdatacenter in Breiðholt, Reykjavík.

The need to expand to even more regions is evident in the coming years, like ex-plained in the Introduction chapter.

3.7.2. Ansible

To quickly enable scaling of the project, even only to scale up a certain componentfor a short period of time, Ansible is exploited.

For this project there are a number of playbooks consisting of more than one playseach. To name and describe a few:

1. Bootstrap – Mutual settings and configurations between all servers. All ofthem need to have the same public and private access keys, with applicationslike Vim, Git and more installed. Along with smaller configurations, changesare made to various OS files, like hosts and locale, to ensure homogeneitybetween project nodes.

2. Monit – Has the simple responsibility to install the Monit monitoring agent [75].

49


3. Load Balancer – Installs and configures HAProxy for Load Balancing nodesin the project. The specific configuration for both front end and back enddeployments are stored on the Ansible server and pushed and saved for everyapplicable instance.

4. Process Manager 2 (PM2) – Installs and configures the PM2 process managerfor all Node.js nodes that ensures the Node.js processes are kept alive andstarts them again if they hang or crash [98].

5. Queue Server – Defined for nodes that have the queue role, already describedin section 3.6.1. The implementation of this playbook is demonstrated insection 4.2.4.

50

4. Implementation

4.1. Introduction

In this chapter some of the aspects of the implementation of the project are outlined,with code excerpts, statistics from the source code along with screenshots from theweb UI.

4.2. Example Code Excerpts

In the following section some interesting lines of example code are extracted fromthe project for demonstration: Express.js routing done in JavaScript, a MongoDBmodel example, an Ansible playbook used for deploying one type of node, and theconfiguration of OpenStack Swift’s pipeline.

4.2.1. Permissions with Express.js routing

Listing 4.1 demonstrates how the Express.js router examines whether the user islogged in, has an admin status and can therefore do certain operations. It is easilypossible to push in permission checks into the Express.js middleware pipeline toobserve whether the end user has the appropriate right to be there.

This particular routing code snippet covers the user settings. It describes as follows:

1. Line 1 – The Express.js dependency is defined with the Node.js require()function.

2. Line 2 – The user controller is referred, where different functions reside thatinteract with the model, such as destroy and changePassword (Explained be-low).

51

4. Implementation

1 var express = require(’express ’);2 var controller = require(’./user.controller ’);3 var auth = require(’../../ auth/auth.service ’);45 var router = express.Router ();67 router.get(’/’, auth.hasRole(’admin’), controller.index);8 router.delete(’/:id’, auth.hasRole(’admin’), controller.destroy);9 router.get(’/me’, auth.isLoggedIn (), controller.me);

10 router.put(’/:id/password ’, auth.isLoggedIn (), controller.changePassword);

11 router.post(’/’, controller.create);1213 module.exports = router;

Listing 4.1: Permissions with Express.js routing

3. Line 3 – The authentication service is referred, where the hasRole and isAuthen-ticated methods reside, meant to authenticate and authorize the user.

4. Line 5 – The express.Router [108] is a complete routing system in Express.jsthat offers modular route handlers or functions. Functions being used in thisexcerpt are in fact based on the standard HTTP methods: GET, PUT, POSTand DELETE.

With the express.Router, it is possible to create multiple instances of theRouter and apply them accordingly. In this case, the route is only appropriatefor the logged in user.

5. Line 7: router.get(’/’) – It first calls the hasRole method from the authenti-cation service to validate if the user has the administration role. If or whenthe user is validated as an administrator the router calls the index functionfrom the controller, which depicts administrative functions to him/her.

6. Line 8: router.delete(’/:id’) – Just like in line 7, the router first validates theuser as an administrator. It finds an end user by his/her unique ID stored inthe MongoDB and calls a destroy function from the controller, which deletesthe end user from Safnið.

7. Line 9: router.get(’/me’) – Calls the isLoggedIn method from the authentica-tion service. If the user is logged in, he/she received his/her user informationvia the me function from the controller.

8. Line 10: router.put(’/:id/password’) – Allows the user to change his/her pass-word after validating he/she is logged in, with the changePassword functionin the controller.

52


9. Line 11: router.post(’/’) – Posting creates a new user, with required variablesin the body of the request.

10. Line 13: module.exports – It encapsulates the result from the router and re-turns it.

4.2.2. User Model in MongoDB

In this section the user model in MongoDB is discussed. MongoDB was alreadycovered in section 3.6.3. For the separation of concerns, regarding the authentication,where Auðkenni takes care of the process, the user model is simpler than usuallyanticipated. When Auðkenni confirms user authentication it returns the kennitalaof the user, so that is sufficient to validate the user on Síminn’s side.

In listing 4.2 the user model is demonstrated. Also, because it is referenced in theschema, the device model is there as well.

1 var mongoose = require(’mongoose ’),2 Schema = mongoose.Schema;34 /**5 * Device Schema6 */7 var DeviceSchema = new Schema ({8 name: String ,9 os: String ,

10 gcm_token: String ,11 public_key: String12 });1314 /**15 * User Schema16 */17 var UserSchema = new Schema ({18 telephone: String ,19 photo: String ,20 account: String , // unique21 kennital: String , // unique22 active: {type: Boolean , default: true},23 devices: [DeviceSchema],24 role: String ,25 email: String ,26 terms: Boolean ,27 api: {type: Boolean , default: true}28 });2930 module.exports = mongoose.model(’User’, UserSchema);

Listing 4.2: User and Device Model in MongoDB

53

4. Implementation

Explanation of the code is as follows:

1. Lines 1-2 – The Mongoose schema (The Mongoose module briefly explained insection 3.3) is defined at the top. The schema maps to the relevant MongoDBcollection and defines the structure of the documents in that collection.

2. Lines 4-12 – The Device schema is defined first, device being the mobile deviceconnected to the end user. The name, OS, GCM token and the public keyare considered enough to validate the authenticity of the mobile. With thismethod the end user does not have to log in via Auðkenni into Safnið morethan once. He/She will in the near future be able to disassociate the mobiledevice from his/her user account.

3. Lines 14-29 – The User schema or model is then declared:

a) Telephone number of the user. Already enriched after first authentication.

b) Photo. The user is allowed to upload a profile picture.

c) Account. A unique path to the Swift account belonging to the user.Created at first log in.

d) Kennitala. The unique kennitala belonging to the user. Auðkenni sendsthis after validating the authentication.

e) Active. A boolean that represents whether the user is defined as enabledor disabled.

f) Devices. An array that stores the object IDs of the device schema definedabove. In practice, this way a device can belong to more than one user.This can possibly help with sharing later.

g) Role. Can be defined as an administrator in the system.

h) Email.

i) Terms. A boolean that confirms whether the user has accepted the termsoffered by Síminn.

j) API. It is possible for the user to enable the third party API for devel-opment. Enabled by default.

54


1 [pipeline:main]2 pipeline = catch_errors gatekeeper healthcheck proxy -logging

rewrite_token cache bulk_metadata bulk ratelimit cloud_authrestrictions media_class container -quotas account -quotas proxy -logging proxy -server

Listing 4.3: OpenStack Swift’s pipeline configuration

4.2.3. OpenStack Swift Pipeline

Listing 4.3 demonstrates the ease of configuring the Swift pipeline. The pipelinecomposes a succession of middleware, ending with a single application. Each andevery middleware has a chance to see over and treat the request or response andthen pass it to the following middleware. The last component in the pipeline is theactual application, the Swift proxy server:

4.2.4. Ansible Playbook for a New Queue Node

Deploying a new component for the project is easily done. Below is an example ofhow to deploy a new Queue Server. Ansible was discussed earlier in section 3.7.2and the object of the Queue Server in section 3.6.1.

Firstly, the playbook is initiated:ansible -playbook -i production queue_tasks_deploy.yml

The Queue Server Playbook can be seen in listing 4.4 and its content, line by line,is as follows:

1. Lines 1-3 – A new node will be created, and sudo permissions will be neededto finish the task.

2. Lines 4-9 – Roles are declared for the Queue Server:

a) The Bootstrap role consists of the typical settings and configuration thatbelong to most of the servers in the project.

b) The Node.js role installs Node.js on all nodes and configures custom set-tings that are common with all nodes within that role.

c) The Queuegit role gets the relevant code source from the Git server,newest master.

55

4. Implementation

1 ---2 − hos t s : new3 sudo : y e s4 r o l e s :5 - r o l e : b o o t s t r a p6 - r o l e : n o d e j s7 - r o l e : q u e u e g i t8 - r o l e : pm29 - r o l e : mon i t

10 vars :11 pm2_startup: ubuntu12 pm2_apps: [ " / opt / cloud / queue / pm2 . json " , " / opt /

cloud / image / pm2 . json " , " / opt / cloud / video / pm2 .json " ]

13 app_packages : [ " imagemagick " , " ffmpeg " , " monit " ]14 monit_conf : q u e u e_mon i t r c . c o n f . j 2

Listing 4.4: Queue Server Playbook

d) The PM2 role installs PM2 and configures so that the Node.js processescan be kept alive in production.

e) The Monit role installs a Monit monitoring agent to secure that the nodeis monitored.

3. Lines 10-12 – Variables are defined related to starting up PM2 at boot up.Also, some custom configuration is pushed from the Ansible server to the node.

4. Line 13 – Packages are installed. Imagemagick, FFmpeg and Monit.

5. Line 14 – Monit configuration is pushed from the Ansible server to the node.

4.3. Project Statistics

In this section some of the project’s statistics are discussed. In particular, informa-tion about LOC and McCabe’s Cyclomatic Complexity method [67].

56


1 oskar@laptop :~$cloc source_master_2016 -03 -22/ --ignored=ignored.tmp2 445 text files.3 353 unique files.4 Wrote ignored.tmp5 633 files ignored.67 http://cloc.sourceforge.net v 1.60 T=0.78 s (341.8 files/s,

32030.4 lines/s)8 ---------------------------------------------------------------9 Language files blank comment code

10 ---------------------------------------------------------------11 Javascript 184 1599 2125 1159712 XML 39 2 0 719813 HTML 43 153 356 236514 Python 7 159 254 119315 CSS 2 14 14 8916 YAML 2 0 0 1317 ---------------------------------------------------------------18 SUM: 277 1927 2749 2245519 ---------------------------------------------------------------2021 oskar@laptop :~$

Listing 4.5: Lines of Code statistics

4.3.1. Lines of Code

Using a simple LOC tool called cloc [34], a beneficial overview of the size of theproject is possible. Below in listing 4.5 the cloc command is shown with its output.

1. The cloc command is executed on the whole of the source code, that is, themaster from March 22nd 2016. Many files are ignored by the tool and alist of them is written out to a temporary file, to validate there is nothingbeing mistakenly missed out on. These ignored files are mostly Git and JSONconfiguration files.

2. 431 text files are discovered, with 353 of them considered unique. Many of thesimple configuration files between different components are identical.

3. 633 files are ignored by cloc. Many of them are text files, discovered above,but most from folders configured to be ignored by the tool, like the .git folder,which stores repository information from the Git server. At the bottom of theoutput it can be seen that the sum of all files considered applicable for thissource code are 277. 168 text files are therefore ignored, 92 of them becausethey are considered duplicated.

57

4. Implementation

4. The project is split up in the different languages:

a) JavaScript. Safnið is mostly built using JavaScript.

b) Extensible Markup Language (XML). Some configuration files.

c) HTML. The front end, bundled with Angular.

d) Python. The Swift middleware developed at Síminn’s side is considereda part of Safnið.

e) CSS. Only two files, extending the Material Design structure.

f) YAML. Only two files, both Ansible playbooks. Ansible playbooks arenormally not considered part of Safnið, but this exception is because ofNode.js setup in the web application.

The last column shows LOC, whereas the commented and empty lines areignored. Still, there are other columns showing how many lines are empty andcommented.

5. The sum of the project LOC as it stands March 22nd 2016 is 22455 linescontaining some kind of code.

Two things have to be mentioned about code not taken into these calculations:

1. The OpenStack platform and services, like Swift with its built-in middleware,is not taken into account in these calculations.

2. Safnið depends heavily on Node.js packages, which are not taken into accountin these calculations.

The project’s LOC is in fact much lower than could be expected from a comprehen-sive project like Safnið. Reasons behind that can be rationalized as:

1. JavaScript is a high-level programming language. Generally, using a high-level language means the developer is able to create more functionalities withless code. While it is easy to understand and enables rapid development, itnever compiles directly on the computer, but through a runtime environment,like Node.js. Lower level programming languages clearly take more time indevelopment and a higher number of LOC on average.

58


2. Using a single programming language throughout Safnið, remembering thatbuilt-in OpenStack code is not taken into account, allows reusing the same codethroughout the whole project. The developers can unify the efforts betweenthe client and server, simplifying the model and increasing productivity withless LOC.

3. Like previously mentioned, Angular exploits the MVC architectural pattern.Angular splits the application into components and then takes care of thepipelining that connects them. That way the developer will not have to writeshortcuts or functionalities that would break the abstraction between thosecomponents.

4. Community driven Node.js packages are heavily utilized in Safnið. That isnot taken into the account in the LOC calculations. While abstracting evenmore functionalities from the developer, it saves up time for the developer andnaturally reduces LOC greatly. Like discussed in section 2.4.2 the Node.jscommunity with the NPM package manager offers a big variety of modules.

Counting only the lines with code:

1. 51.6% of the whole code is JavaScript.

2. 32.1% of the code is XML.

3. 10.5% of the code is HTML, with Angular.

4. 5.3% of the code is independent OpenStack Swift middleware, used to extentthe built-in middlewares that come with Swift.

4.3.2. Cyclomatic Complexity

This section is based on McCabe’s formula for Cyclomatic Complexity [67]:

v(G) := e− n+ p

Using a simple tool called complexity-report [35] and small calculations the Cyclo-matic Complexity of Safnið is concluded. This tool does not work on anything elsethan JavaScript code, so the Swift middleware is not taken into account in thesecalculations.

59

4. Implementation

The average complexity of the 1781 functions in the Safnið is 2.66. While manyfunctions stand at complexity 1, the most complex function in the code stands at309.

Like Shepperd stated [113], this really reflects the drawbacks of McCabe’s Cyclo-matic Complexity method, whereas a simple sequence of roughly 300 if statementsis considered just as complex as 300 times nested if statements. This particularAngular function handles all translations within the system and lists up a simplesequence of if statements, which by this method results in a high complexity.

It is possible to argue for a better translation method, but McCabe’s method canhardly be considered fair in this case. But even though we consider it unfair, theresulted complexity brought up the attention to the translation method. There nowexists a task in the backlog, to include a more efficient method into the projectto take care of translations, something equivalent to the Angular module angular-translate [10].

In listing 4.6 an excerpt from the translation function is demonstrated, with twoexamples of translations. The product offers English, Icelandic and Polish, whichthe user can set him/her self in his/her user settings.

60


1 angular.module(’guicloudApp ’)2 .factory(’Translation ’, function (Settings) {3 var translation = {};4 var EN = "EN";5 var IC = "IC";6 var PL = "PL";78 // Two examples of translation mapping9

10 translation.getSearchTabTitle = function () {11 if (Settings.language === EN) return "Search";12 if (Settings.language === IC) return "Leita";13 if (Settings.language === PL) return "Szukaj";14 };1516 translation.getTrashTabTitle = function () {17 if (Settings.language === EN) return "Trash";18 if (Settings.language === IC) return "Rusl";19 if (Settings.language === PL) return "Kosz";20 };2122 // ... and so forth2324 return translation;25 });

Listing 4.6: An excerpt of the function that takes care of translation

61

4. Implementation

4.4. Screenshots

In this section functionalities from the web UI of Safnið are demonstrated witha number of screenshots from all of the different views in the application. Thesescreenshots cover the following aspects:

1. Figure 4.1 shows the login screen, which is the first view the user sees whenhe/she opens up Safnið in a web browser. After inserting his/her mobilenumber, Auðkenni’s authentication service takes over. Auðkenni is explainedin section 3.4.1.

2. Figure 4.2 shows the front page of Safnið after Auðkenni has validated the useraccess. A timeline shows thumbnails of images and videos previously uploadedby the user. As seen with the first thumbnail, hovering over it gives the userthe possibility to manipulate the object. More precisely:

a) To add or remove the object to favorites.

b) To move the object to trash.

c) A check mark allows the user to select one or more objects and movethem to an album.

d) To click and get more information about the object

e) Finally, the user can also click the object to view the full size and start aslide show.

3. Figure 4.3 shows an example of what the user sees when he/she chooses to seemore information about the object. The metadata shown is extracted witheither the ImageTasks or VideoTasks, explained in section 3.6.2.

4. Figure 4.4 shows user created albums. The possibility to create a new albumis in the top right corner of the view.

5. Figure 4.5 shows the document structure of uploaded objects. If the useruploaded an object that is not considered a media object at this time, like atext document or a spreadsheet, this is the only view that the user can accessthat object. Up in the right corner of this view the user can choose to uploadnew objects or create a virtual directory. Since an object storage stores allobjects in a flat structure this directory is in fact concatenated in front of theunique object name stored in Swift, but not an actual directory. To the rightin the view the user is given an opportunity to manipulate the objects.

62

4.4. Screenshots

6. Figure 4.6 shows the possibilities given to the user when he/she chooses to dosome operation on a single object. That is:

a) Download the object to the his/her local storage.

b) Add or remove the object to or from favorites.

c) Share the object with other users in Safnið.

d) Create a publicly accessible link to the object.

e) Remove the object, that is move it to the trash.

7. Figure 4.7 shows the upload form given to the user when he/she chooses toupload new objects to Safnið. The user can either select objects from the harddrive or choose to drag and drop them directly into the browser.

8. Figure 4.8 shows the object search. At this time it is only possible to searchby the object name.

9. Figure 4.9 shows objects that have been marked as favorites.

10. Figure 4.10 shows the sharing status of different objects. That is:

a) When the user clicks the PUBLIC link at the top he/she will get a list ofall objects that have a public link generated.

b) In the middle the user sees another user with the name “Sigurveig” thathas shared one or more objects with the logged in user. When “Sigurveig”is clicked the list of object from that user that he/her has chosen to sharewith the logged in user is shown.

c) And finally, the user can see a list of users he/she has chosen to sharewith other users of Safnið. When “Roland” is clicked a list of objectsshared with him/her is shown.

11. Figure 4.11 shows a list of newly deleted objects in the trash. The user canchoose to empty the trash with the button in the top right corner.

12. Figure 4.12 shows the user settings that can be explained as follows:

a) The “Information” frame at the top shows personal information about theuser. It is only possible to change the email, since the name and mobilenumber come embedded with the authentication.

63

4. Implementation

b) The “Your available space” frame shows the current status of the user’sstorage quota.

c) The “Language” frame gives the user the possibility to change the lan-guage between English, Icelandic and Polish.

d) The “Registered devices” frame is intended for mobile devices attached tothe account. The idea is to give the user the possibility to revoke accessto chosen devices in the list. This feature is not yet available.

e) The “Developers” frame allows the user to enable the third party API,earlier discussed in section 3.5.2.

13. In all the screenshots described above the feedback button intended for betatesters, provided by Usabilla and described later in section 6.3.2, is shown tothe right. When the user clicks the button he/she will see a feedback formthat is shown in figure 4.13.

Figure 4.1: A screenshot from the web application: The first view the user sees afteropening the web.

64

4.4. Screenshots

Figure 4.2: A screenshot from the web application: The front page of Safnið, showingmedia in a timeline.

Figure 4.3: A screenshot from the web application: Various information about themedia object.

65

4. Implementation

Figure 4.4: A screenshot from the web application: An overview of end user createdalbums.

Figure 4.5: A screenshot from the web application: A document structure view ofall uploaded objects.

66

4.4. Screenshots

Figure 4.6: A screenshot from the web application: Operations possible on objects.

Figure 4.7: A screenshot from the web application: An upload form.

67

4. Implementation

Figure 4.8: A screenshot from the web application: A feature that allows the enduser to search for his/her objects.

Figure 4.9: A screenshot from the web application: Objects marked as favorites.

68

4.4. Screenshots

Figure 4.10: A screenshot from the web application: An overview that allows theuser to see all shared objects.

Figure 4.11: A screenshot from the web application: The trash lists all newly deletedobjects.

69

4. Implementation

Figure 4.12: A screenshot from the web application: An overview of the user settings.

70

4.4. Screenshots

Figure 4.13: A screenshot from the web application: The feedback form.

71

5. Evaluation

In section 1.2 all the requirements were listed up. It is worth mentioning them againhere, reviewing the result and observe the attainment.

Requirement 1: The software will be operated and maintained via OpenStack, uti-lizing the various OpenStack services, enabling scalability, disabling single point offailure, exploiting the Swift object storage for documents, spreading the service be-tween different physical locations, etc. Dispersing the service to different locationshelps the company, being an ISP, to keep bandwith contained to smaller areas. Withthat in mind, it should also aim to reduce the response time for the customer, withrouting and load balancing to the closest, physical location each time.

Result 1: Safnið operates successfully on OpenStack. It is possible to scale up anddown, manually at this time (automatic scaling possible, but not tested yet), evenjust small components of Safnið at a time. OpenStack is still only physically locatedat Síminn’s headquarters, but it will soon move to other real estates, which in turnshould eliminate any single point of failure in the platform.

Requirement 2: Using OpenStack and Safnið as a proof of concept, the companyhopes to show the viability utilizing the cloud to save bandwith around the country.

Result 2: The deployment of the OpenStack platform is proofing to be successful,but still needs more hardware dispersed to different locations to be declared carriergrade.

Requirement 3: It is also fair to mention virtualizing more of the server hosting savesexpenses to a great amount. Although it has been an ongoing project for the lastdecade or so, it is only a small percentage of the whole number of servers that havebeen virtualized of the possible lot.

Result 3: Almost all new applications in development today are deployed on Open-Stack. Safnið along with an IPTV desktop application will be the first services infull operation in the summer of 2016, running within OpenStack.

Requirement 4: The application will help the end user keeping their media safe, byuploading all media automatically to the object storage from the client on his/her

73

5. Evaluation

smart device. The user is also capable of keeping his/her manual backup of docu-ments, either via the native, mobile application or the web user interface.

Result 4: The application helps the user keeping his/her data safe. It replicatesit to different hard-drives like required, although it will become even safer whenOpenStack hardware will be distributed to other locations. An automatic uploadfeature is still not available in the mobile application, but the development of arelatively simple Android application with this feature is undergoing (not coveredin this thesis).

Requirement 5: The user will be able to create sub-accounts on his/her own accountwhere he/she can grant access to a subset of his/her own data. The user will beable to share documents with a public URL or on social media.

Result 5: Creating sub-accounts to grant access to subset of objects is yet notavailable but still planned. It could be introduced after commercial deployment.Creating Public URLs is possible today. The feature is shown in figure 5.1, where itpossible to generate a public link with one click, as well as sharing individual objectswith other users. The brown globe icon next to the file’s name represents that theobject it accessible via a public URL.

Requirement 6: Síminn wants to avoid storing passwords. Using authentication ser-vices, like offered by the Icelandic-based company Auðkenni [22], for authenticationand other passwordless methods will be optimal.

Result 6: Auðkenni is today the only authentication method available to accessSafnið. That allows us to avoid storing any user passwords in our database.

Requirement 7: Safnið will have the option to allow the user to change the UIlanguage, to satisfy different requirements in the modern, multi-cultural countrythat Iceland has become in the past decade. Icelandic, English, and Polish are thelanguages that will be supported at first.

Result 7: Safnið is available today in Icelandic, English and Polish. It is still on theroadmap to introduce a better method to handle the translations, like mentioned insection 4.3.2.

Requirement 8: The possibility of integrating Safnið to other Síminn products willbe present. Some examples could be electronic signatures, hosting videos recordingsfrom web cameras from the smart home platform being developed at Síminn andthe option to display media in the IPTV services, via Síminn’s STB.

Result 8: There is a possibility to integrate the Swift object storage with otherservices, not necessarily all of them directly with Safnið, but possibly just with

74

Swift and its standard API. Both approaches are applicable and will be done, asthere is no real need to integrate all internal services at Síminn directly with Safnið.

Requirement 9: An API will be published so third party software developers canutilize the object storage for their own projects. The API will be purely based on theOpenStack Swift API, with the addition of a few read-only queries to an additionaldatabase, which enables users to search for objects via other parameters than theunique ID.

Result 9: An API is available for interested third party application developers.Standard Swift API [92] with additional MongoDB search capabilities yet to bedocumented.

Requirement 10: The development team will use a version of Scrum, with dailystandups and other transparent agile methods.

Result 10: A mixed version of Scrum and Kanban was practiced, and still is, inthe development. The practices are described in detail in the Management aspectssection of this thesis.

Figure 5.1: A screenshot from the web UI that shows how to both share an objectand create a publicly accessible link to it

75

Part II.

Management Aspects

6. Methods Used

6.1. Introduction

Within Síminn, different methodologies exist to improve business procedures. LeanManagement has been utilized in different sections of the company since 2013, withmost success in sales and support departments. A big focus was put on the Infor-mation Technology Infrastructure Library (ITIL) some years back, aiming to deliverIT services more effectively and efficiently [51]. Recently the 4 Disciplines of Exe-cution (4DX) methodology has been introduced to help all employees concentratingon the corporate objective, like McChesney explains [68], “to execute on a plan inthe midst of the whirlwind of distractions”. The whirlwind being the everyday op-erations; answering emails and going to meetings. Agile methodologies have beenexploited heavily within the technical division of Síminn for many years. Most widelyused has been Scrum [57] within software development, as well as Kanban [58].

This project is handled by the a division within Síminn’s technical domain calledLausnir. We decided to use a combination of Scrum and Kanban practices, notadjusting our processes to the methodologies, but the other way around.

6.2. Agile Methods

Seeing as “Scrum-ish” practices have the history of being successful within Síminn,it seems a natural step to carry on the tradition in some way in this project.

6.2.1. Comparison between Scrum and Kanban

While Scrum is best described as an adaptive (more prescriptive than Kanbanthough) methodology that, for example, constraints the developers to time boxediterations, or sprints, and cross functional teams, while Kanban is even more adap-tive, just constraining the team to use visible boards and limiting work in progress.

79

6. Methods Used

Scrum Kanban

An Agile framework An Agile frameworkUses pull scheduling and splits work intopieces

Uses pull scheduling and splits work intopieces

Scrum prescribes time-boxed iterations Kanban does not prescribe any time-boxed iterations

Three roles prescribed: Product Owner,Scrum Master, Development Team

Kanban does not have any roles pre-scribed

Scrum limits Work in Progress (WIP)per unit of time

Kanban limits WIP per workflow state

Self-organizing teams Self-organizing teamsCross functional teams Cross functional teams not specified.

Specialist teams allowedNot possible to add tasks to ongoingsprint

Possible to add tasks whenever the ca-pacity allows

Scrum board is resetted between sprints Kanban board is persistent since therearen’t any sprints

Board is owned by a team Board does not need to be owned by aspecific team

Table 6.1: Comparison between Scrum and Kanban [48]

Kniberg and Skarin compared the two practices [48] and table 6.1 tries to list thatup in a readable fashion.

We will not ever consider limiting us to a single methodology, Scrum or Kanban.We will find the convenient and suitable practices and adapt them to our needs.Practices and traditions cannot be set in stone either. The team should be preparedto change to new practices with the collective objective in mind to make the workmore efficient between different projects or even different phases of the one project.In Kanban, the board does not need to be owned by a single team, but can in factbe managed by multiple teams. Table 6.1 explains this and figure 6.1 demonstratesour approach: The Product Owner prioritizes the backlog for the developers, whiledifferent subsets of other teams take on the tasks available to them. The backlogcan even sometimes be empty for one set of specialists for some period of time.

Both Scrum and Kanban have pros and cons. Table 6.2 tries to list up benefits ofthe practices compared between them.

80

6.2. Agile Methods

Figure 6.1: A figure, inspired by Kniberg and Skarin [48], that explains how a Kanbanboard can be managed by different teams

6.2.2. Adapting Methods

Since the Lausnir division was established within Síminn the aim has been to de-molish the so called “brick-walls” between different departments at the company.Bringing together capable DevOps specialists to work together (already describedin section 1.1), eliminating potential “gaps” between different teams, enabling coop-eration amongst them, both in development as well as operation.

Figure 6.2 shows the intersection between different teams or departments in theSafnið project.

1. The Network team takes responsibility of the OpenStack networking and po-sitioning it within Síminn’s network.

2. The Internet Development team takes responsibility of deployment and dailyoperation of OpenStack and its components. Although part of the team’sname is “Development”, it both takes care of development and operations.The name should of course be “Internet Development and Operation”, but forobvious reasons, longer names do not really stick. Also, before the introductionof the DevOps culture, the name was “Development”, so it’s origination is alsoa heritage from another time.

3. Within the IPTV team are programmers that took on the task writing Safnið.

81

6. Methods Used

Scrum Kanban

It is a known problem to meet dead-lines in software development. Scrumhelps the development team schedulingthe project in unison with the dead-line. Stakeholders can always see howmuch work will be done in the comingsprint and by the deadline, prioritizingthe most vital features first. During this,the process ensures that the developmentcontinues at a sustainable pace.

A Kanban board gives the team oppor-tunity to visually communicate informa-tion that is otherwise difficult to process.When customer’s expectations are notbeing met the team has the opportunityto give directions to correct the courseduring iterations.

Helps individual developers to focus onwork in hand, day by day.

When tasks are properly prioritized, anindividual developer does not have toquestion what to do next. Instead hejust pulls the next Kanban card from thefront of the queue.

It focuses on continuous delivery in a pre-scriptive manner, in time boxed sprints,by delivering small portions of the prod-uct continuously

It focuses on continuous delivery, justlike Scrum, but in a more flexible man-ner, by delivering small portions of theproduct continuously. There are no pre-scribed sprints, but priorities should con-stantly be reassessed based on the newestinformation.

With improved communication andstreamlined processes it is possible to re-duce development costs.

With improved communication andstreamlined processes it is possible to re-duce development costs.

Brings business and technical peoplecloser to each other, talking the samelanguage, in a way.

Brings business and technical peoplecloser to each other, talking the samelanguage, in a way.

Table 6.2: Comparison of the benefits of using either Scrum or Kanban

We started the project using Scrum’s two week time-boxed sprints, including allemployees that would work on the project in the next sprint. After two sprints in fourweeks, we decided against planning the third sprint after seeing in the retrospectivemeeting how far off the planning was from the reality. Also, taking the time frommembers that would only take a small part in the sprint was considered an overhead.

After this, we started involving Kanban practices into our work, where developmentwas done in a mostly event-drive manner. A planning meeting was scheduled wheneither the management or business side decided it was necessary, or when old taskswere close to being either finished or irrelevant. At first, deliverable software wasonly showed in a closed demo since the OpenStack environment was not close tooperational. After that Safnið was usually up to date on the Internet with the mostrecent features. Retrospective was not done in a formal fashion with the whole team.

82

6.2. Agile Methods

Figure 6.2: An intersection diagram of the Lausnir domain within Síminn

A daily standup was considered an overhead for two reasons:

1. The cross-department team members would already have attended a dailymeeting within their own department.

2. The team consisted of different and fluctuated members between differentphases of the project. Many times the actual team only consisted of a sin-gle programmer.

There were in fact different teams that supplied resources to the solutions, duringdifferent phases of the project. Sometimes different tasks of the project were solvedwithin other teams running their own version of Agile practices. An example of thiswould possibly be a specific network concerning a service within OpenStack wouldbe owned by a network engineer that consulted with his own team with a specificissue to get the best result. The OpenStack engineer would own that task withinthe deployment of OpenStack and define it as an impediment while the networkteam worked on it. Usually this did not hinder development of the Safnið, since the

83

6. Methods Used

developer or developers usually used their own virtual machine with OpenStack’sDevStack [36] to try new features at first.

All team members had other obligations to other platforms or projects during thewhole development life-cycle, both in other development projects and in day to dayoperation of core services at Síminn. Safnið was never considered a top priority, sothat caused the development to halt from time to time, where the tasks were pauseduntil resources became available again.

It is possible to argue that this approach bears resemblance to Scrum of Scrums [111],where the chosen ambassador from the sub-team is the one reporting to the otherproject. This of course is only relevant for this one project, but not all the otherprojects the so called sub-team is working on.

Scrum has well defined roles. Below is a comparison of the official definition withthe practical workflow at Síminn:

1. Development Team

• There were in fact four different teams with intersections. Safnið and theOpenStack deployment consisted of a single team with different memberswith all members working in some of the other three teams as well. Theoutcome of this was at times that many tasks were in fact being solvedoutside of the project within the other teams.

2. Scrum Master

• While different employees handled the role as Scrum (or Kanban) mas-ter in the three different teams, there was a professional communicationand understanding between them throughout this project. A separateScrum (or Kanban) board was always available for the Safnið and Open-Stack deployment projects, where tasks were kept up to date by differentScrum Masters and managed by the technical lead. While team membersusually attended the daily meetings with their proper department withinthe Lausnir domain, nobody hesitated to call in other developers to themeeting if the task needed some examination by more specialists.

3. Product Owner

• The product manager of the Internet services at Síminn belongs to thebusiness and marketing sector of the company, not the technical division,where Lausnir resides. While the product manager in the Internet servicesat Síminn, was the defined Product Owner, the ownership was taken bytechnical management as well, since Safnið was always thought as a POC

84

6.3. Tools

for the OpenStack deployment and operations at Síminn.

This informality sometimes led to Agile practices being neglected, but it was alwaysour intention to try fit Agile practices to this somewhat “unimportant” project,rather then going by the strictest definitions and rules of the chosen methodologies.

6.3. Tools

Actual tools used in the project, other than Agile methods, include a traditionalwhiteboard with markers and sticky notes, Jira project management software todigitally manage and prioritize the backlog [53], Usabilla to get feedback from testusers in the web application [121] and Git repository management from GitLab [41].

6.3.1. Whiteboard, Post-its and Jira

In the beginning of the project, the sprints were managed on a whiteboard withsticky notes in a Scrum and Kanban manner. The board had “To Do”, “Doing”,“Blocked” and “Done” columns on it. After the specific sprint methodology wasabandoned in this project the whiteboards were dedicated to each team definedin the Lausnir’s domain hierarchy. Every department has a whiteboard close totheir workstations. Every whiteboard is different, fitted to each departments re-quirements. All of the whiteboards have a some kind of hybrid between Scrum andKanban design.

Figure 6.3: A screenshot of the Jira board

85

6. Methods Used

Jira is a project management software used to digitally manage and prioritize thebacklog. It has been used from the beginning to keep track of the backlog itemsin the project. It is also a widely used tool at Síminn and has been for some time.Although the daily meetings and sometimes sprints are taken cared of in anotherteams, Jira takes care of prioritizing and showing current status of each task andthe project’s backlog. A board exists within Jira with three columns to show thecurrent status of tasks being done, by whom, in the near future. Swimlanes, thehorizontal rows a cross the board, are grouped after tasks assignees. Figure 6.3shows a simple screenshot of a small subset of tasks on the board that was used inthe project. The numbers above each column reflect the minimum and maximumnumbers of tasks allowed in each position. There is no correct number and we didedit the limits a number of times, depending on how many were in fact working ontasks in the project at each time.

Different approaches were tested with the physical whiteboard and Jira:

1. Whiteboard and Jira together – Like mentioned above, an actual whiteboardwas used at first, to maintain the WIP and sprints. Along with the whiteboard,a virtual board was maintained in Jira with all the tasks. The backlog wasmainly prioritized in Jira at that time. This was considered an overhead, sincekeeping both boards in sync led to wasted time with the benefit of this thoughtto be vague.

2. Only a whiteboard – This approach gave a beneficial overview of the project,but backlog management lacked and reporting to management was poor.

3. Only Jira – This was considered the best approach in this project. Theoverview of the project lacked compared to the whiteboard, but it was easier tomanage it with many informal meetings and more than one employee movingtasks between columns. The backlog was also easier to manage.

6.3.2. Usabilla

Usabilla is a Dutch Software as a Service (SaaS) company that specializes in websiteuser feedback. Their platform offers a simple integration to the customer. A HTMLand JavaScript widget is easily injected into the web application and after that theusers can easily send feedback to the team, where a screenshot of the user’s currentview is sent along with it. It also offers a dashboard where the feedback items canbe surveyed and dealt with, along with various statistics. This platform is also usedin other projects within Síminn. In figure 6.4 a screenshot of the Usabilla dashboardis shown, that shows the only two feedbacks received in a two week period. Anotherscreenshot of the feedback form presented to the end user of Safnið is demonstrated

86

6.3. Tools

in section 4.2.2.

Figure 6.4: A screenshot from the Usabilla feedback dashboard

6.3.3. GitLab

Git is the de facto repository tool at Síminn, used for most software projects at thecompany. GitLab offers a software package which enables customers to self-host thesolution with all their repositories. GitLab also offers a issue tracker, which we havenot used in this project, since Jira and Usabilla have covered all the requirementsfor issue tracking and user feedback.

87

7. Challenges and Lessons Learned

7.1. Introduction

In this chapter challenges in the project, with their possible reasons and resolutions,are discussed. Also, the lessons learned in the project and how similar challengeswill be approached in future projects.

7.2. Challenges

No matter how intensively best practise methods or management processes are uti-lized during a software development project, challenges are bound to come up. Onecould insist that the response and reaction to issues defines the quality of the pro-cess. Some number of challenges surfaced during the planning, designing and devel-opment of Safnið and deployment of OpenStack. Challenges, possible reasons andresolutions if applicable are covered in this chapter.

7.2.1. Human Resources

When visiting other cultures and organizations in different countries an Icelanderoften experiences a vast difference in how a company approaches software projects, oreven projects in general. The development cycle of a new software product generallyhas a bigger group of engineers, with individual employers only responsible for smallparts of the product. This approach is of course in general much better when theteam is trying to both follow schedule and some approved practices, like Scrum.

Scrum has many different roles and assumes the development team consists of atleast three cross functional members. In practice, this can be quite difficult to followin environments like Síminn’s. The company usually compares itself with CSPs inother countries, that are even incumbents like Síminn. Although these companieshave a similar foundation and challenges, their reality is most likely vastly bigger

89


than here in Iceland. Although Scrum is not prescriptive, it generally assumes it’sroles to be siloed.

Making OpenStack operation ready has proved to be a strenuous task, but withcapable engineers, although being few, has not turned out to be a delay factor inthe commercial launch of Safnið.

In this environment with a project like this one, it is both important to keep highlycapable employees and mind to adapt the Agile practices to the project needs,instead of the other way around.

Keeping a small team like in this project did of course delay the deployment.Occasionslike summer holidays of individuals impacted the work profusely.

7.2.2. Keeping Schedule

The original deployment schedule for Safnið was beta testing by employees in May2015 and a commercial launch in October that same year. Now, approximatelya year later Safnið is still in its infancy, beta testing by staff (issues described insection 7.2.9) is in progress and the launch currently scheduled June 2016.

This project was never considered a high priority project, but more as a POC forOpenStack in general and a value added service for Síminn’s current customer base.This caused some unprepared delays when other projects with higher priority, orissues in operation (DevOps issues explained in section 7.2.4), surfaced.

Other interesting aspect of delay causing actions is the Scrum definition of self-organizing teams. When a team is dispersed like explained below, in section 7.2.5,the risk of an unclear leadership in the project may cause the team’s flow of work tobe distracted, like Broza [29] explains: “Self-direction does not imply smooth flow”.This implies no matter how capable the developer is, he/she will always drop someballs which cause a risk of delays. While this has often turned out to be the case ithas never caused long delays, since the different teams work closely together withmanagement interacting on a daily basis, with the tailored-made whiteboard for theproject.

7.2.3. Missing a Development Environment

At first, there was not an instance of OpenStack up and running and ready to beexploited by developers. But since the requirement was to develop Safnið on top

90

7.2. Challenges

of OpenStack, development was mainly done on virtual machines on laptops, usingDevStack. This did of course cause a slight opacity between the developer andother stakeholders, but it was solved with frequent and informal demos, performedanytime when questions, challenges or new requirements arised in the developmentcycle.

7.2.4. Challenges in a DevOps Environment

Developing a low priority software project in a DevOps environment with the fewestnumber of employees possible has its problems. Problems arised in the project havenot been traced to the DevOps culture for reasons articulated here. Walls [125]explained: “DevOps is as much about culture as it is about tools”, where communi-cation channels are open throughout the whole, no matter whether in developmentor operation. It is even more important to have employees susceptible to the culture,rather than all the tools available. While introducing a DevOps culture within aorganization can be difficult for various reasons. It has been prevailing within thetechnical division at Síminn for some years. New employees are introduced quicklyinto how things are exerted.

Because of this the problems related with this practice are more related to the lackof human resources and the balance between operations and development, ratherthan a culture that seems to work as a motivator for most employees.

As a product of the DevOps environment, the open dialog and innovational men-tality, new ideas for new projects within the division coming in at a rapid rate.Registration and prioritization of these ideas has been lacking and needs to be eval-uated further.

7.2.5. Tailoring Agile Methods

Transitioning and adapting between two or more different development practices,like Scrum and Kanban, is not a totally pain-free process. Like described in sec-tion 6.2.2, some effort went into adapting the Agile practices and making themefficient for us and our development. Problems that came up included:

1. Planning meetings proved inaccurate.

• In a DevOps culture, operation always trumps development. Planning asprint became a redundant task when we realized beforehand it would bedifficult to follow the plan, because we all anticipated an unknown amount

91


of operational issues. Introducing Kanban’s WIP limitation proved to beefficient.

2. Retrospective meetings were considered redundant.

• Right from the beginning these meetings were considered redundant be-cause all team members are in fact members of other teams, that havetheir own retrospective meetings. This was solved by escalating every-thing that came out of every retrospective meeting that affected theproject right to management. Also, keeping open communications chan-nels between all employees.

3. Daily meetings had to be adapted.

• Like mentioned in section 6.2.2, instead of daily meeting with a dedi-cated team, the process resembled the Scrum of Scrums [111] practice,where appropriate tasks relevant to the project were aggregated from ev-ery team’s whiteboard to the one of the project. The board was alwaysavailable and up to date, up for review by different team leaders.

4. Team consisted of different members throughout the whole project.

• Like explained in section 6.2.2, the project turned out to be a collectivemission for three different teams. While this turned out to be a ratherbeneficial approach for this particular project, it complicated tasks whenthe actual project team members were different on a daily basis. Thisoccasionally exposed weaknesses in product or task ownership. Who wasin fact responsible for individual tasks that were maybe even looked at asimpediments for other project members. This did of course lead to somewasted time.

5. Informality could cause waste.

• Like Broza [29] explains, members of development teams should not per-form activities outside of their development responsibilities, that they arenot informed on, like obtaining network or server access, or other sim-ilar activities. This is an unrealistic demand in Síminn’s environment.Weighing this risk, we have tried solving this with open and commoncommunication between staff members, enabled by the DevOps culture,explained in section 7.2.4. Because of that, this has not been consideredas a big problem as it could have been when considered beforehand.

• Ken Schwaber, one of the authors of the initial versions of Scrum wroteback in 2010 a note [110] that is good to keep in mind when putting in an

92

7.2. Challenges

effort to combine different Agile practices: “God help us. People foundways to have slack in waterfall, to rest and be creative. With Lean andKanban, those hiding places are removed. We now have a progressivedeath march without pause.”

6. Vaguely defined roles.

• This is heavily related to the informality issue described above. Scrumprescribes roles and assumes the people are working full time in that role.In practical environments, this is hardly ever that simple. The ScrumMaster role in fact moved around between a few different team leadersthrough different phases of the development cycle. As was the productowner never a single person, whereas a technical owner and a businessowner had different priorities regarding the functionalities of the project.This is of course, an ongoing challenge, that requires open communicationchannels between the technical and business side, which in fact is one thestrength of the Kanban and Scrum practices.

7.2.6. “Cowboy Coding”

With a small team, an individual coder with a secluded development environmentand employees practicing a rather informal blend of Kanban and Scrum, the risk of“Cowboy Coding” [107] being practiced, naturally becomes high.

The term “Cowboy Coding” can hardly be considered an academic one, but it de-scribes well the possible situation arising when working with a small team. It pos-sibly evolves into existence when a developer is allowed or forced to take a big oreven complete control of the development process, where things are done his/herown way, without consultation and consideration with best practices.

At times, best practices in software development were ignored in this project. Thatcan be possibly blamed on lack of disciplined usage of Agile methodologies and alack of human resources, like described in section 7.2.1 above. The biggest prob-lem we have today, and will face in the coming months, is the lack of testing inthe development. Although there are some unit tests available in the source code,there is no structured approach to them, as development processes like Test-drivendevelopment (TDD) were never practiced. The code coverage of current tests ishardly worth bringing up. When Safnið will be changed and developed further aftercommercial launch, regression testing will have to take place, so before evolving it,automatic testing will have to be a top priority. Finding the defects in the codelater on in the software life cycle can in fact become more expensive than the savingcost on resources during development.

93


Although testing might be optimal within a dedicated software testing team, thereality described in section 7.2.1 above eliminates that possibility. The developerknows the source code best so resources and time is saved by doing that, although thepossibility exists of mistakes happening because of fundamental misunderstandingsby the developer.

7.2.7. Documentation

Another thing missing from the project, because of possible “Cowboy Coding” isdocumentation describing Safnið and any special configuration done within Open-Stack.

Although the Agile Manifesto [25] states: “Working software over comprehensivedocumentation”, it could become an issue later on if there is knowledge lacking oncertain components on either OpenStack in general or Safnið and its source code ordeployment. With the limited human resources, mentioned in section 7.2.1, it is apossibility that the knowledge of the solutions could be gone overnight.

7.2.8. Selection of Tools

With different people there are different views and approaches. Some time has beenmisspent on different tools with similar functionalities, because of different views onwhat tools to utilize in the environment. This has probably been a smaller issuethan if the teams would have been split up between development and production,but is still present in this small and ever-changing group of specialists. Tools withsimilar functionalities worth mentioning are:

1. Monit [75] and Zabbix [128] for monitoring. Both are tools that cover mostof the requirements, but with Zabbix’s feature set it looks to be the tool thatwill be selected for most of the monitoring use cases in the environment inthe close future. Monit is the monitoring tool that has been used until now inSafnið.

2. Puppet [101] and Ansible [16] for automation. Although this thesis has mostlyfocused on Ansible, since it was used for Safnið and its deployment, mostlyPuppet is being used for OpenStack today. It is likely that Puppet will takeover Ansible’s responsibilities in the near future.

94

7.3. Lessons Learned

7.2.9. Beta Testing

In March 2016 there were over 20 beta testers registered within the system. UsingAuðkenni’s service, only users with a registered mobile number can log in. Feedbackfrom the testers has been lacking with only a few feedback items from the Usabillasystem, the reasons given by the testers, when debriefed, are two:

1. Uptime lacking. When development has been stalled because of other higherpriority projects within the company Safnið has even sometimes gone offline forsome periods of time. OpenStack’s deployment has also been in a developmentphase, that has caused down times. If the users cannot trust the platform willwork when they need to use a cloud storage, they will naturally soon start touse Google’s Drive or Dropbox as their main provider, forgetting about Safnið.

2. No mobile application available yet. With only the web UI available for betatesters, the practicality reduces heavily for the users that are used to mobileapplications.


In hindsight, with the experience acquired, a few things should have been donedifferently with the set of practices offered by the Agile methodologies. In thissection some lessons learned are covered.

7.3.1. Scrum and Kanban

When we first started, the chosen Agile practice was Scrum but when the projectprogressed we cherry picked methods from Kanban to tailor to our needs. Likementioned earlier we actually chose Scrum because the practice has a history ofbeing successful within Síminn. It was the easy choice because we knew it.

In hindsight, we should have started with Kanban and cherry pick Scrum methods,since we ended up using a practice that is much more like Kanban with a Scrumflavour to it, rather than the other way around.

Like mentioned earlier, it is important to really adapt the Agile practices instead offollowing them blindly. Using Scrum by the book would not have helped the projectin the long run and it was important to find that out soon in the development cycle.

95


Of course our development procedures are still developing and maturing, and prob-ably will do so while we keep working with Agile, with a different set of employeesworking on different projects. In this project it took some weeks finding the correctway of doing things and it can be reasoned that with more experience this evolve-ment of practices will likely keep existing within every project but take shorter timeon each occasion to adapt.

7.3.2. Scrumban

If we would have heard of Scrumban before we started tailoring Kanban and Scrumpractices to our needs, we would have studied that and found out that we did nothave to invent the wheel in just as many cases. That being said, we would of coursestill have needed to do some tailoring of the practices. The Scrumban practice canbe described as follows [106]:

1. WIP limits, not time committed sprints.

2. Retrospective and Review meetings are as often as needed, usually before thePlanning meeting.

3. Planning meetings are held as often as they are needed, when the backlogeither needs to be re-prioritized or is close to being empty.

4. Standup meetings are much like the Scrum ones, but instead of focusing oneach team member at a time, the team goes over every column and interactstogether on every task, discussing what is needed to move the task to the nextcolumn (the columns being something like To Do, Doing, Blocked and Done).

As a matter of fact, Scrumban strongly resembles our own tailored practices.

7.3.3. Testing

The lack of software testing will unquestionably become a problem later in thelife cycle of Safnið. Although knowledge of the importance of software testing waspresent, it unconsciously was neglected by us, for reasons explained in section 4.

Although TDD would have been optimal it is still possible to introduce unit testsinto the source code. With the lack of human resources in mind, it is decided to domost of the testing along with new changes implemented into Safnið from now on,with regression testing.

96


It is also worth mentioning, in a broader sense, that it is on the roadmap to intro-duce OpenStack Tempest into the OpenStack deployment, that enables integrationtesting between the OpenStack services [118].

7.3.4. Beta Testing

The importance of the mobile application was underrated beforehand. Agile method-ologies practice the importance of business value, and prioritizing with that in mind.Pushing Safnið out to beta testers, asking for feedback, without thinking about whatwould give the user the most value, was a mistake. Prioritizing the backlog with thebusiness value in mind is important and has to be emphasized on.

Planning poker [57] is the process of estimating the effort or the size of projectsduring the sprint planning, usually done with playing cards where each team memberestimates on his/her own how big the task or user story will be. This usually helpsthe team estimating on how many tasks will fit in the next sprint. We did notuse planning poker since time limited sprints were not used in the project. An ideacould be to use a similar way as is done with the planning poker, but instead of usingeffort points. It could be something as simple as business value points, that teammembers, Scrum Master and Product Owner could estimate together in a planningmeeting for every new task or story in the backlog.

97

Part III.

Conclusion

8. Summary and Outlook

8.1. Conclusion

Communication service providers worldwide, like Síminn in Iceland, have been facinga digital disruption for the telecommunication value chain. These organizations arelooking for new revenue, ways to retain customers by adding value, while also tryingto drive down both CapEx and OpEx. With these challenges in mind, we decidedto develop a public cloud storage for Síminn’s customers, based on OpenStack, asa proof of concept for the platform. It is our belief that Safnið will prove to be asuccess, helping to retain customers while giving them value. Although Safnið isnot quite ready yet, it is scheduled for a soft launch for the general public earlysummer 2016. Most of the requirements listed and discussed in chapter 5 are ready,but further development, mentioned below in section 8.2, is already being plannedand is hoped to help Safnið to obtain even more adaption.

The future of OpenStack at Síminn or other similar companies worldwide may notbe ensured yet, but the expectations are high with the chance of disrupting thebackbone of the telecommunication network and other IT services. OpenStack isalready being exploited to virtualize other services at Síminn, such as a desktopapplication for IPTV, which is currently in a beta phase, as well as other internalservices in TV and mobile.

8.2. Future work

Future work can be split into three categories; Safnið, further OpenStack usage, andfinally integration with other services at Síminn. Here is a subset of ideas that wehope to continue with in the near future:

1. Safnið

a) Enable sub-account creation. A requirement listed in section 1.2 thatwould for example allow the customer to create sub-accounts for other

101

8. Summary and Outlook

family members.

b) The stable release of Angular 2.0 is expected soon. While there is not adirect upgrade path from version 1, there seems to be a possibility to startusing version 2 of Angular within the version 1 and migrate slowly [7].

c) A Single Sign On (SSO) platform is in development at Síminn, that en-ables us to integrate different authentication methods to the same cus-tomer. This would ultimately allow us to enable Facebook authentica-tion [5], as well as various other providers, to Safnið, customer portal andmore.

d) Enable an integration to some photo developing company to allow theuser to directly order prints of his/her photos.

e) Desktop application for Safnið has been discussed, but not decided on.

2. Further OpenStack usage

a) Distribute the deployment to more physical locations, like explained insection 3.7.1, we plan to start by setting up another location of OpenStackin Breiðholt.

b) Exploiting OpenStack even further with more public facing services ispossible, but not yet discussed. E.g. offering Backup as a Service (BaaS)could be done either with the standard Swift API or even the Safniðdesktop client mentioned above.

c) Deploy more of the OpenStack services available. For example:

i. Tempest [118] to render integration testing between different Open-Stack interfaces.

ii. Rally [104] to do benchmarking measurements.

iii. Monasca [71] to introduce MaaS to OpenStack.

iv. Orchestration services with Heat [47].

v. Barbican [23] to securely store and provision passwords and encryp-tion keys.

vi. Plus other various OpenStack services that might be of value to theorganization.

102

8.2. Future work

d) Analyze NFV functionalities and hope to move functionalities from dedi-cated networking appliances to the commodity hardware which operatesOpenStack.

e) The SSO platform mentioned above is being developed on OpenStack.

3. Integration with other services

a) The IPTV service. This can be categorized into two aspects; the option toshow media stored in Safnið on the television screen and to use OpenStackto virtualize various IPTV services.

b) A connected home platform is being developed at Síminn with a homesurveillance feature. The idea is to upload media recordings directly toSwift from the security camera at the customer’s home, when an armedsensor is triggered.

c) The third party API allows any interested developer to create his ownapplication on top of Safnið. We hope to attract some interest frominspiring people.

103

Bibliography

[1] A Description of the Model-View-Controller User Interface Paradigm in theSmalltalk-80 System. 1988. url: http://kanjiteacher.googlecode.com/svn-history/r203/Non-Code/Papers/Krasner1988_and_Pope_MCV.pdf.

[2] A look inside the DevOps movement. 2016. url: http://searchdatacenter.techtarget.com/guides/A-look-inside-the-DevOps-movement.

[3] Accessibility with ngAria. 2016. url: https://docs.angularjs.org/guide/accessibility.

[4] Accessible Rich Internet Applications (WAI-ARIA) 1.0. 20 March 2014. url:https://www.w3.org/TR/wai-aria/.

[5] Add Facebook Login to Your App or Website. 2016. url: https://developers.facebook.com/docs/facebook-login.

[6] Amazon Web Services. 2016. url: https://aws.amazon.com/.

[7] Angular 1.3 meets Angular 2.0 - Michał Gołębiowski. 2015. url: https://www.youtube.com/watch?v=pai1ZdFI2dg.

[8] angular js, react js Job Trends. 2016-01-13. url: http://www.indeed.com/jobtrends?q=angular+js,+react+js&relative=1.

[9] Angular Material. 2016. url: https://material.angularjs.org/latest/.

[10] angular translate. 2016. url: https://angular-translate.github.io/.

[11] angular.element. 2016. url: https : / / docs . angularjs . org / api / ng /function/angular.element.

[12] AngularJS. 2015. url: http://angularjs.org/.

[13] AngularJS Full-Stack generator. 2015. url: https://github.com/angular-fullstack/generator-angular-fullstack.

[14] AngularJS HTML5 Fullscreen. 2016. url: https://github.com/fabiobiondi/angular-fullscreen.

[15] AngularUI Router. 2016. url: https://github.com/angularui/ui-router.

[16] Ansible. 2015. url: http://www.ansible.com/.

[17] Apache CloudStack. 2016. url: https://cloudstack.apache.org/.

105

http://kanjiteacher.googlecode.com/svn-history/r203/Non-Code/Papers/Krasner1988_and_Pope_MCV.pdf

http://kanjiteacher.googlecode.com/svn-history/r203/Non-Code/Papers/Krasner1988_and_Pope_MCV.pdf

http://searchdatacenter.techtarget.com/guides/A-look-inside-the-DevOps-movement

http://searchdatacenter.techtarget.com/guides/A-look-inside-the-DevOps-movement

https://docs.angularjs.org/guide/accessibility

https://docs.angularjs.org/guide/accessibility

https://www.w3.org/TR/wai-aria/

https://developers.facebook.com/docs/facebook-login

https://developers.facebook.com/docs/facebook-login

https://aws.amazon.com/

https://www.youtube.com/watch?v=pai1ZdFI2dg

https://www.youtube.com/watch?v=pai1ZdFI2dg

http://www.indeed.com/jobtrends?q=angular+js,+react+js&relative=1

http://www.indeed.com/jobtrends?q=angular+js,+react+js&relative=1

https://material.angularjs.org/latest/

https://angular-translate.github.io/

https://docs.angularjs.org/api/ng/function/angular.element

https://docs.angularjs.org/api/ng/function/angular.element

http://angularjs.org/

https://github.com/angular-fullstack/generator-angular-fullstack

https://github.com/angular-fullstack/generator-angular-fullstack

https://github.com/fabiobiondi/angular-fullscreen

https://github.com/fabiobiondi/angular-fullscreen

https://github.com/angular-ui/ui-router

https://github.com/angular-ui/ui-router

http://www.ansible.com/

https://cloudstack.apache.org/

Bibliography

[18] Apache CouchDB. 2016. url: http://couchdb.apache.org/.

[19] Apache HTTP SERVER PROJECT. 2016. url: https://httpd.apache.org/.

[20] Joe Arnold. OpenStack Swift - Using, Administering, and Developing forSwift Object Storage. O’Reilly Media, 2014.

[21] AT&T. 2016. url: https://www.att.com/.

[22] Auðkenni. 2015. url: http://audkenni.is.

[23] Barbican. 2016. url: https://wiki.openstack.org/wiki/Barbican.

[24] Ashkan Soltani Barton Gellman and Andrea Peterson. How we know theNSA had access to internal Google and Yahoo cloud data. 2013. url: https://www.washingtonpost.com/news/the-switch/wp/2013/11/04/how-we-know-the-nsa-had-access-to-internal-google-and-yahoo-cloud-data/.

[25] et al Beck. Agile Manifesto. 2001. url: http://www.agilemanifesto.org/principles.html.

[26] Kamlesh Bhatia. Hype Cycle for the Telecommunications Industry, 2015.2015. url: https : / / www . gartner . com / doc / 3100721 / hype - cycle -telecommunications-industry-.

[27] Body-Parse. Node.js body parsing middleware. 2016. url: https://github.com/expressjs/body-parser.

[28] Bootstrap. 2016. url: http://getbootstrap.com/.

[29] Gil Broza. The Human Side of Agile - How to Help Your Team Deliver. 3PVantage Media, 2012.

[30] BT Group may give OpenStack the boot. 2015. url: http://www.pcworld.com/article/2993378/bt-group-may-give-openstack-the-boot.html.

[31] C Programming and C++ Programming. 2016. url: http://www.cprogramming.com/.

[32] Brandon Cannaday. Supercharge your Node.js Applications with Nginx. 2015.url: http://blog.modulus.io/supercharge-your-nodejs-applications-with-nginx.

[33] Cinder. 2015. url: https://wiki.openstack.org/wiki/Cinder.

[34] cloc. 2016. url: https://github.com/AlDanial/cloc.

[35] complexity-report. 2016. url: https : / / github . com / jared - stilwell /complexity-report.

[36] DevStack - an OpenStack Community Production. 2016. url: http://docs.openstack.org/developer/devstack/.

[37] Express. 2015. url: http://expressjs.com/.

106

http://couchdb.apache.org/

https://httpd.apache.org/

https://httpd.apache.org/

https://www.att.com/

http://audkenni.is

https://wiki.openstack.org/wiki/Barbican

https://www.washingtonpost.com/news/the-switch/wp/2013/11/04/how-we-know-the-nsa-had-access-to-internal-google-and-yahoo-cloud-data/




http://www.agilemanifesto.org/principles.html

http://www.agilemanifesto.org/principles.html

https://www.gartner.com/doc/3100721/hype-cycle-telecommunications-industry-

https://www.gartner.com/doc/3100721/hype-cycle-telecommunications-industry-

https://github.com/expressjs/body-parser

https://github.com/expressjs/body-parser

http://getbootstrap.com/

http://www.pcworld.com/article/2993378/bt-group-may-give-openstack-the-boot.html

http://www.pcworld.com/article/2993378/bt-group-may-give-openstack-the-boot.html

http://www.cprogramming.com/

http://www.cprogramming.com/

http://blog.modulus.io/supercharge-your-nodejs-applications-with-nginx

http://blog.modulus.io/supercharge-your-nodejs-applications-with-nginx

https://wiki.openstack.org/wiki/Cinder

https://github.com/AlDanial/cloc

https://github.com/jared-stilwell/complexity-report

https://github.com/jared-stilwell/complexity-report

http://docs.openstack.org/developer/devstack/

http://docs.openstack.org/developer/devstack/

http://expressjs.com/

Bibliography

[38] Express-jwt. Express middleware that validates a JsonWebToken. 2016. url:https://github.com/auth0/express-jwt.

[39] FFmpeg. 2016. url: https://ffmpeg.org/.

[40] FilePermissionsACLs. 2016. url: https://help.ubuntu.com/community/FilePermissionsACLs.

[41] GitLab. 2016. url: https://about.gitlab.com/.

[42] Glance. 2015. url: https://wiki.openstack.org/wiki/Glance.

[43] Google Cloud Platform. 2016. url: https://cloud.google.com/.

[44] HAProxy. 2013. url: http://www.haproxy.org/.

[45] HAProxy - They use it ! 2016. url: http://www.haproxy.org/they-use-it.html.

[46] HAProxyDriver. 2015. url: https://wiki.openstack.org/wiki/Neutron/LBaaS/HAProxyDriver.

[47] Heat. 2016. url: https://wiki.openstack.org/wiki/Heat.

[48] Mattias Skarin Henrik Kniberg. Kanban and Scrum making the most of both.C4Media Inc., 2010.

[49] Heroku. 2016. url: https://www.heroku.com/.

[50] Intro to Playbooks. 2016. url: http : / / docs . ansible . com / ansible /playbooks_intro.html.

[51] ITIL. 2015. url: http://www.itlibrary.org/.

[52] JavaScript.com. 2016. url: https://www.javascript.com/.

[53] JIRA Software. 2016. url: https://www.atlassian.com/software/jira.

[54] jQuery. 2016. url: https://jquery.com/.

[55] JSON Web Tokens. 2015. url: http://jwt.io/.

[56] JsonWebToken implementation for Node.js. 2016. url: https://github.com/auth0/node-jsonwebtoken.

[57] Mike Beedle Ken Schwaber. Agile Software Development with Scrum. Pear-son, 2001.

[58] Paul Klipp. Getting Started with Kanban. Kanbanery, 2014.

[59] krakenjs. 2016. url: http://krakenjs.com/.

[60] Language Trends on GitHub. 2015. url: https://github.com/blog/2047-language-trends-on-github.

[61] Leveraging OpenStack to Solve Telco Needs (Intro to SDN/NFV). 2014. url:https://www.openstack.org/summit/openstack-summit-atlanta-2014/session - videos / presentation / leveraging - openstack - to - solve -telco-needs-intro-to-sdn-nfv.

107

https://github.com/auth0/express-jwt

https://ffmpeg.org/

https://help.ubuntu.com/community/FilePermissionsACLs

https://help.ubuntu.com/community/FilePermissionsACLs

https://about.gitlab.com/

https://wiki.openstack.org/wiki/Glance

https://cloud.google.com/

http://www.haproxy.org/

http://www.haproxy.org/they-use-it.html

http://www.haproxy.org/they-use-it.html

https://wiki.openstack.org/wiki/Neutron/LBaaS/HAProxyDriver

https://wiki.openstack.org/wiki/Neutron/LBaaS/HAProxyDriver

https://wiki.openstack.org/wiki/Heat

https://www.heroku.com/

http://docs.ansible.com/ansible/playbooks_intro.html

http://docs.ansible.com/ansible/playbooks_intro.html

http://www.itlibrary.org/

https://www.javascript.com/

https://www.atlassian.com/software/jira

https://jquery.com/

http://jwt.io/

https://github.com/auth0/node-jsonwebtoken

https://github.com/auth0/node-jsonwebtoken

http://krakenjs.com/

https://github.com/blog/2047-language-trends-on-github

https://github.com/blog/2047-language-trends-on-github

https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/leveraging-openstack-to-solve-telco-needs-intro-to-sdn-nfv



Bibliography

[62] Linode. 2016. url: https://www.linode.com/.

[63] Load Balancing Scheduling Methods Explained. 2013. url: http://loadbalancerblog.com/blog/2013/06/load-balancing-scheduling-methods-explained.

[64] lodash v4.0.0. 2016. url: https://lodash.com/.

[65] Mike Loukides. Revisiting "What is DevOps". 2014. url: http://radar.oreilly.com/2014/06/revisiting-what-is-devops.html.

[66] Material design. 2016. url: https://www.google.com/design/spec/material-design/introduction.html.

[67] Thomas McCabe. “A Complexity Measure”. In: IEEE Transactions on Soft-ware Engineering SE-2 (1976), pp. 308–320. doi: 10 . 1109 / TSE . 1976 .233837.

[68] Chris McChesney. The 4 Disciplines of Execution: Achieving Your WildlyImportant Goals. Free Press, 2012.

[69] MEAN. 2015. url: http://mean.io/.

[70] Microsoft Azure. 2016. url: https://azure.microsoft.com/.

[71] Monasca. 2016. url: https://wiki.openstack.org/wiki/Monasca.

[72] MongoDB. Top 5 Considerations When Evaluating NoSQL Databases. 2016.url: https://s3.amazonaws.com/info-mongodb-com/10gen_Top_5_NoSQL_Considerations.pdf.

[73] MongoDB for GIANT Ideas | MongoDB. 2016. url: https://www.mongodb.org/.

[74] Mongoose ODM. 2015. url: http://aheckmann.github.io/gm/.

[75] Monit. 2016. url: https://mmonit.com/monit/.

[76] Morgan. HTTP request logger middleware for Node.js. 2016. url: https://github.com/expressjs/morgan.

[77] Rick Nelson. Mitigating DDoS Attacks with NGINX and NGINX Plus. 2015.url: https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/.

[78] nervgh. Angular File Upload. 2016. url: https://github.com/nervgh/angular-file-upload.

[79] Neutron. 2015. url: https://wiki.openstack.org/wiki/Neutron.

[80] Neutron/LBaaS. 2015. url: https://wiki.openstack.org/wiki/Neutron/LBaaS.

[81] ng. 2016. url: https://docs.angularjs.org/api/ng.

[82] ngAnimate. 2016. url: https://docs.angularjs.org/api/ngAnimate.

[83] ngCookies. 2016. url: https://docs.angularjs.org/api/ngCookies.

108

https://www.linode.com/

http://loadbalancerblog.com/blog/2013/06/load-balancing-scheduling-methods-explained

http://loadbalancerblog.com/blog/2013/06/load-balancing-scheduling-methods-explained

https://lodash.com/

http://radar.oreilly.com/2014/06/revisiting-what-is-devops.html

http://radar.oreilly.com/2014/06/revisiting-what-is-devops.html

https://www.google.com/design/spec/material-design/introduction.html

https://www.google.com/design/spec/material-design/introduction.html

http://dx.doi.org/10.1109/TSE.1976.233837

http://dx.doi.org/10.1109/TSE.1976.233837

http://mean.io/

https://azure.microsoft.com/

https://wiki.openstack.org/wiki/Monasca

https://s3.amazonaws.com/info-mongodb-com/10gen_Top_5_NoSQL_Considerations.pdf

https://s3.amazonaws.com/info-mongodb-com/10gen_Top_5_NoSQL_Considerations.pdf

https://www.mongodb.org/

https://www.mongodb.org/

http://aheckmann.github.io/gm/

https://mmonit.com/monit/

https://github.com/expressjs/morgan

https://github.com/expressjs/morgan

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

https://github.com/nervgh/angular-file-upload

https://github.com/nervgh/angular-file-upload

https://wiki.openstack.org/wiki/Neutron

https://wiki.openstack.org/wiki/Neutron/LBaaS

https://wiki.openstack.org/wiki/Neutron/LBaaS

https://docs.angularjs.org/api/ng

https://docs.angularjs.org/api/ngAnimate

https://docs.angularjs.org/api/ngCookies

Bibliography

[84] ngInfiniteScroll. 2016. url: https://sroze.github.io/ngInfiniteScroll/.

[85] nginx. 2015. url: http://www.nginx.org/.

[86] ngResource. 2016. url: https://docs.angularjs.org/api/ngResource.

[87] ngRoute. 2016. url: https://docs.angularjs.org/api/ngRoute.

[88] ngSanitize. 2016. url: https://docs.angularjs.org/api/ngSanitize.

[89] Node.js. 2015. url: http://nodejs.org/.

[90] Nova. 2015. url: https://wiki.openstack.org/wiki/Nova.

[91] NPM. 2015. url: http://npmjs.com/.

[92] Object Storage API v1 (SUPPORTED). 2016. url: http://developer.openstack.org/api-ref-objectstorage-v1.html.

[93] OpenStack Dashboard ("Horizon"). 2015. url: https://wiki.openstack.org/wiki/Horizon.

[94] OpenStack Open Source Cloud Computing Software. 2016. url: https://www.openstack.org/.

[95] OpenStack Releases. 2016. url: http://releases.openstack.org/.

[96] Openstack Swift Documentation. 2015. url: http://docs.openstack.org/developer/swift/ (visited on 04/07/2016).

[97] Passport. 2016. url: http://passportjs.org/.

[98] pm2. 2016. url: https://github.com/Unitech/pm2.

[99] Pocket. 2016. url: https://getpocket.com.

[100] Projects, Applications, and Companies Using Node. 2016. url: https://github.com/nodejs/node-v0.x-archive/wiki/Projects,-Applications,-and-Companies-Using-Node.

[101] Puppet - The shortest path to better software. 2016. url: https://puppet.com/.

[102] Python. 2016. url: https://www.python.org/.

[103] Rackspace. 2016. url: https://www.rackspace.com/.

[104] Rally. 2016. url: https://wiki.openstack.org/wiki/Rally.

[105] React. 2016. url: https://facebook.github.io/react/.

[106] Ajay Reddy. The Scrumban [R]Evolution. United States of America: Addison-Wesley, 2015.

[107] Margaret Rouse. Cowboy Coding. 2014. url: http://searchsoftwarequality.techtarget.com/definition/cowboy-coding.

[108] Routing. 2016. url: http://expressjs.com/en/guide/routing.html.

[109] Safnið | Vefur Símans. 2016. url: http://safnid.is/safnid/webui.

109

https://sroze.github.io/ngInfiniteScroll/

http://www.nginx.org/

https://docs.angularjs.org/api/ngResource

https://docs.angularjs.org/api/ngRoute

https://docs.angularjs.org/api/ngSanitize

http://nodejs.org/

https://wiki.openstack.org/wiki/Nova

http://npmjs.com/

http://developer.openstack.org/api-ref-objectstorage-v1.html

http://developer.openstack.org/api-ref-objectstorage-v1.html

https://wiki.openstack.org/wiki/Horizon

https://wiki.openstack.org/wiki/Horizon

https://www.openstack.org/

https://www.openstack.org/

http://releases.openstack.org/

http://docs.openstack.org/developer/swift/

http://docs.openstack.org/developer/swift/

http://passportjs.org/

https://github.com/Unitech/pm2

https://getpocket.com

https://github.com/nodejs/node-v0.x-archive/wiki/Projects,-Applications,-and-Companies-Using-Node



https://puppet.com/

https://puppet.com/

https://www.python.org/

https://www.rackspace.com/

https://wiki.openstack.org/wiki/Rally

https://facebook.github.io/react/

http://searchsoftwarequality.techtarget.com/definition/cowboy-coding

http://searchsoftwarequality.techtarget.com/definition/cowboy-coding

http://expressjs.com/en/guide/routing.html

http://safnid.is/safnid/webui

Bibliography

[110] Ken Schwaber. Waterfall, Lean/Kanban, and Scrum. 2010. url: https://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/.

[111] Scrum of Scrums. 2016. url: https://agilealliance.org/glossary/scrum-of-scrums/.

[112] Sharding and MongoDB. 2016. url: https://docs.mongodb.org/master/MongoDB-sharding-guide-master.pdf.

[113] Martin Shepperd. “A critique of cyclomatic complexity as a software metric”.In: Software Engineering Journal Volume:3 , Issue: 2 (1988), pp. 30–36. doi:10.1049/sej.1988.0003.

[114] Síminn. 2016. url: http://siminn.is.

[115] SwiftKey. 2016. url: https://swiftkey.com/en (visited on 03/12/2016).

[116] SwiftStack. 2016. url: https://www.swiftstack.com/.

[117] Telco OpenStack Roadmap Panel. 2015. url: https://www.youtube.com/watch?v=LnVXJzRLgS4.

[118] Tempest Testing Project. 2016. url: http://docs.openstack.org/developer/tempest/.

[119] Tumblr. 2016. url: https://www.tumblr.com/.

[120] UPGRADING FROM 1.X. 2016. url: https://angular.io/docs/ts/latest/guide/upgrade.html.

[121] Usabilla. 2015. url: http://usabilla.com.

[122] Verizon. 2016. url: http://www.verizon.com/.

[123] VMware. 2016. url: http://www.vmware.com/.

[124] Vulnerability Summary for CVE-2013-4450. 2013. url: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4450.

[125] Mandi Walls. Building a DevOps Culture. O’Reilly Media, 2013.

[126] Web Server Performance Comparison. 2015. url: http://wiki.dreamhost.com/Web_Server_Performance_Comparison.

[127] WhatsApp. 2016. url: https://www.whatsapp.com/.

[128] Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution.2015. url: http://www.zabbix.com/.

110

https://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/



https://agilealliance.org/glossary/scrum-of-scrums/

https://agilealliance.org/glossary/scrum-of-scrums/

https://docs.mongodb.org/master/MongoDB-sharding-guide-master.pdf

https://docs.mongodb.org/master/MongoDB-sharding-guide-master.pdf

http://dx.doi.org/10.1049/sej.1988.0003

http://siminn.is

https://swiftkey.com/en

https://www.swiftstack.com/

https://www.youtube.com/watch?v=LnVXJzRLgS4

https://www.youtube.com/watch?v=LnVXJzRLgS4

http://docs.openstack.org/developer/tempest/

http://docs.openstack.org/developer/tempest/

https://www.tumblr.com/

https://angular.io/docs/ts/latest/guide/upgrade.html

https://angular.io/docs/ts/latest/guide/upgrade.html

http://usabilla.com

http://www.verizon.com/

http://www.vmware.com/

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4450

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4450

http://wiki.dreamhost.com/Web_Server_Performance_Comparison

http://wiki.dreamhost.com/Web_Server_Performance_Comparison

https://www.whatsapp.com/

http://www.zabbix.com/