From 0 to 1

Abstract

Welcome to the information age, a period in human history that shifts the focus of our economy from traditional industry to one based on data processing and information technology. The Internet is the invention that stands at center of this new age, it connects billions of people around the planet in a single network. The apps on our smart phone, laptop and tablet are at one side of this network, while “servers” are the computers on the other side. These machines handle and store our most precious family photos, intimate emails and financial information. Consumers expects the software that runs on these servers to handle thousands of simultaneous connections while being secure, safe and always online. As the number of customers grew, so grew the complexity of this software in order to meet the increasing demand. “Microservices” is a novel approach thats aims to cope with the complexity of server software. In such architectures, large software processes are turned into many smaller programs that are each responsible for a specific subset of the overall functionality. This in turn, makes it easier to split the work across multiple developers. One person (or team) can be made responsible for the complete life-cycle of a single microservice and is therefore able to innovate independently. This makes sense in an “Agile” environment: a methodology that encourages iterative development and fast failures. But will only work when services can be put in operation quickly after a new iterations has finished development; often driven by automation this practice of bringing operations closer to development is called “DevOps”. Even though microservices are separated in terms of innovation, on a technical level it is often impossible to decouple them completely from one another. During user research it was shown that such coupling between services causes problems for the DevOp when he is developing and testing new code on his workstation. The coupling makes it very hard to isolate a single microservice: working on it means installing and running all the other services it depends on, and the services that those depend on, and so forth. First, this lack of isolation forces the DevOp to install, update and configure dozens of programs before he or she can begin development. Secondly, due to the nature of microservices, a single test can cause the environment to change in many different places; resetting the environment for another test becomes tedious, error prone and time consuming. “Docker” is a new technology that has seen rapid adoption in 2014. It allows software processes to be encapsulated in a standardized fashion, so called “containerization”. While large firms are focusing on developing Docker solutions for data center operations, industry analysis shows there is little competition when it comes to using Docker for the development and testing of server software. With a series of prototypes it is shown that Docker can be used to solve the before-mentioned isolation problems and help the DevOp with developing and testing his microservice. With further prototyping, the solution was developed into a concept called “Dockpit”. Dockpit provides an interface that allows DevOps to quickly fix the dependencies of their microservice into place and store this information in a single file that lives next to the source code of the service. On command, it reads this file and passes the instructions to Docker to let it take care of (re)setting the environment. Dockpit makes it possible to isolate a microservice in minutes and reset the environment in seconds with the push of button. Two user validation studies were setup to verify if Dockpit was capable of delivering value to the target group. The first study was setup to measure product-solution fit and took place at the company Giant Swarm. Through multiple hands-on sessions it was shown that the lack of isolation was an important barrier for the company and prevented them from testing their microservices consistently to gain a better grip on the stability of their product. The second validation was aimed at measuring product-market fit. A minimal viable product was created and released online, three press released were published to drive initial traffic from the marketplace. A total 336 subjects visited the homepage and only 9% of them continued to download Dockpit, none of the users were retained after 2 days. These results show that product-market fit has not yet been reached. Continued effort will be put into simplifying and reshaping the product towards a better product-market fit. Additionally, more emphasis needs to be put on the design and validation of a business model.