bibliography.bib

%% This BibTeX bibliography file was created using BibDesk.
%% https://bibdesk.sourceforge.io/

%% Created for Nik Sauer at 2022-01-17 23:52:28 +0100 


%% Saved with string encoding Unicode (UTF-8) 



@article{eeg2021,
	date-added = {2022-01-17 23:38:41 +0100},
	date-modified = {2022-01-17 23:52:17 +0100},
	journal = {Bundesgesetzblatt},
	month = {July},
	pages = {2860--2866},
	title = {Gesetz f{\"u}r den Ausbau erneuerbarer Energien (Erneuerbare-Energien-Gesetz - EEG 2021)},
	volume = {44},
	year = {2021}}

@webpage{kubernetesCronjob,
	date-added = {2022-01-16 22:37:28 +0100},
	date-modified = {2022-01-16 22:38:18 +0100},
	lastchecked = {16.01.22},
	title = {CronJob},
	url = {https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/},
	bdsk-url-1 = {https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/}}

@article{eu2016gdpr,
	author = {European Parliament and Council of the European Union},
	date-added = {2022-01-15 00:51:44 +0100},
	date-modified = {2022-01-15 00:53:30 +0100},
	journal = {Official Journal of the European Union},
	month = {May},
	pages = {1--88},
	title = {Regulation on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)},
	volume = {59},
	year = {2016}}

@inproceedings{kalske2017challenges,
	abstract = {One of the more recent avenues towards more flexible installations and execution is the transition from monolithic architecture to microservice architecture. In such architecture, where microservices can be more liberally updated, relocated, and replaced, building liquid software also becomes simpler, as adaptation and deployment of code is easier than when using a monolithic architecture where almost everything is connected. In this paper, we study this type of transition. The objective is to identify the reasons why the companies decide to make such transition, and identify the challenges that companies may face during this transition. Our method is a survey based on different publications and case studies conducted about these architectural transitions from monolithic architecture to microservices. Our findings reveal that typical reasons moving towards microservice architecture are complexity, scalability and code ownership. The challenges, on the other hand, can be separated to architectural challenges and organizational challenges. The conclusion is that when a software company grows big enough in size and starts facing problems regarding the size of the codebase, that is when microservices can be a good way to handle the complexity and size. Even though the transition provides its own challenges, these challenges can be easier to solve than the challenges that monolithic architecture presents to company.},
	address = {Cham},
	author = {Kalske, Miika and M{\"a}kitalo, Niko and Mikkonen, Tommi},
	booktitle = {Current Trends in Web Engineering},
	date-added = {2022-01-15 00:19:56 +0100},
	date-modified = {2022-01-15 00:20:38 +0100},
	doi = {10.1007/978-3-319-74433-9_3},
	editor = {Garrig{\'o}s, Irene and Wimmer, Manuel},
	pages = {32--47},
	publisher = {Springer International Publishing},
	title = {Challenges When Moving from Monolith to Microservice Architecture},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1007/978-3-319-74433-9_3}}

@inbook{casalicchio2019container,
	abstract = {Container technologies are changing the way cloud platforms and distributed applications are architected and managed. Containers are used to run enterprise, scientific and big data applications, to architect IoT and edge/fog computing systems, and by cloud providers to internally manage their infrastructure and services. However, we are far away from the maturity stage and there are still many research challenges to be solved. One of them is container orchestration that makes it possible to define how to select, deploy, monitor, and dynamically control the configuration of multi-container packaged applications in the cloud. This paper surveys the state-of-the-art solutions and discusses research challenges in autonomic orchestration of containers. A reference architecture of an autonomic container orchestrator is also proposed.},
	address = {Cham},
	author = {Casalicchio, Emiliano},
	booktitle = {Systems Modeling: Methodologies and Tools},
	date-added = {2022-01-15 00:14:46 +0100},
	date-modified = {2022-01-15 00:15:41 +0100},
	doi = {10.1007/978-3-319-92378-9_14},
	editor = {Puliafito, Antonio and Trivedi, Kishor S.},
	pages = {221--235},
	publisher = {Springer International Publishing},
	title = {Container Orchestration: A Survey},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1007/978-3-319-92378-9_14}}

@article{da2018containers,
	author = {Silva, Vitor and Kirikova, Marite and Alksnis, Gundars},
	date-added = {2022-01-15 00:10:04 +0100},
	date-modified = {2022-01-15 00:11:00 +0100},
	doi = {10.2478/acss-2018-0003},
	journal = {Applied Computer Systems},
	month = {May},
	pages = {21-27},
	title = {Containers for Virtualization: An Overview},
	volume = {23},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.2478/acss-2018-0003}}

@book{evans2004domain,
	abstract = {From the Book: Leading software designers have recognized domain modeling and design as critical topics for at least twenty years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been clearly formulated, a philosophy has developed as an undercurrent in the object community, which I call "domain-driven design". I have spent the past decade focused on developing complex systems in several business and technical domains. I've tried best practices in design and development process as they have emerged from the leaders in the object-oriented development community. Some of my projects were very successful; a few failed. A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project. This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences. Projects facing complex domains can use this framework to approach domain-driven design systematically. Contrasting Three Projects Three projects stand out in my memory as vivid examples of the dramatic effect domain design practice has on development results. Although all three delivered useful software, only one achieved its ambitious objectives and delivered complex software that continued to evolve to meet ongoing needs of the organization. I watched one project get out of the gate fast with a useful, simple web-based trading system. Developers were flying by the seat of their pants, but simplesoftware can be written with little attention to design. As a result of this initial success, expectations for future development were sky-high. It was at this point that I was approached to work on the second version. When I took a close look, I saw that they lacked a domain model, or even a common language on the project, and were saddled with an unstructured design. So when the project leaders did not agree with my assessment, I declined the job. A year later, they found themselves bogged down and unable to deliver a second version. Although their use of technology was not exemplary, it was the business logic that overcame them. Their first release had ossified prematurely into a high-maintenance legacy. Lifting this ceiling on complexity calls for a more serious approach to the design of domain logic. Early in my career, I was fortunate to end up on a project that did emphasize domain design. This project, in a domain at least as complex as the one above, also started with a modest initial success, delivering a simple application for institutional traders. But this delivery was followed up with successive accelerations of development. Each successive iteration opened exciting new options for integration and elaboration of functionality. The team way able to respond to the needs of the traders with flexibility and expanding capability. This upward trajectory was directly attributable to an incisive domain model, repeatedly refined and expressed in code. As the team gained new insight into the domain, the model deepened. The quality of communication improved among developers and between developers and domain experts, and the design, far from imposing an ever-heavier maintenance burden, became easier to modify and extend. Unfortunately, not all projects that start with this intention manage to arrive at this virtuous cycle. One project I joined started with lofty aspirations to build a global enterprise system based on a domain model, but finally had a disappointing result. The team had good tools, a good understanding of the business and gave serious attention to modeling. But a separation of developer roles led to a disconnect between the model and implementation, so the design did not reflect the deep analysis that was going on. In any case, the design of detailed business objects was not rigorous enough to support combining them in elaborate applications. Repeated iteration produced no improvement in the code, due to uneven skill-level among developers with no clear understanding of the particular kind of rigor needed. As months rolled by, development work became mired in complexity and the team lost its cohesive vision of the system. After years of effort, the project did produce modest, useful software, but had given up the early ambitions along with the model focus. Of course many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to name a few, but it is the approach to design that largely determines how complex software can become. When complexity gets out of hand, the software can no longer be understood well enough to be easily changed or extended. By contrast, a good design can make opportunities out of those complex features. Some of these design factors are technological, and a great deal of effort has gone into the design of networks, databases, and other technical dimension of software. Books have been written about how to solve these problems. Developers have cultivated their skills. Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won't matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software. The premise of this book is that For most software projects, the primary focus should be on the domain and domain logic. Complex domain designs should be based on a model. Domain-driven design is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, this book presents an extensive set of design practices, techniques and principles. Design vs. Development Process Design books. Process books. They seldom even reference each other. Each is a complex topic in its own right. This is a design book. But I believe that these two issues are inextricable if design concepts are to be put into successful practice and not dry up into academic discussion. When people learn design techniques, they feel excited by the possibilities, but then the messy realities of a real project descend on them. They don't see how to fit the new design ideas with the technology they must use. Or they don't know when to worry about a particular design aspect and when to let go in the interest of time. While it is possible to talk with other team members about the applica design principle in the abstract, it is more natural to talk about the things we do together. So, while this is a design book, I'm going to barge right across that artificial boundary when I need to. This will place design in the context of a development process. This book is not specific to a particular methodology, but it is oriented toward the new family of "Agile Development Processes". Specifically, it assumes a couple of process practices are in place on the project. These two practices are prerequisites for applying the approach in this book. Iterative development. The practice of iterative development has been advocated and practiced for decades, and is a corner stone of the Agile development methods. There are many good discussions in the literature of Agile development and Extreme Programming, among them, Cockburn1998 and Beck 1999. A close relationship between developers and domain experts. Domain-driven design crunches a huge amount of knowledge into a model that reflects deep insight into the domain and a focus on the key concepts. This is a collaboration between those who know the domain and those who know how to build software. Because it is iterative, this collaboration must continue throughout the project's life. Extreme Programming (XP), conceived by Kent Beck, Ward Cunningham and others Beck2000, is the most prominent of the agile processes and the one I have worked with most. To make the discussion concrete, I will use XP throughout the book as the basis for discussion of the interaction of design and process. The principles illustrated are easily adapted to other Agile Processes. In recent years there has been a rebellion against elaborate development methodologies that burden projects with useless, static documents and obsessive upfront planning and design. Instead, the Agile Processes, such as XP, emphasize the ability to cope with change and uncertainty. XP recognizes the importance of design decisions, but strongly resists upfront design. Instead, it puts an admirable effort into increasing communication, and increasing the project's ability to change course rapidly. With that ability to react, developers can use the "simplest thing that could work" at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer's true needs. This has been a much-needed antidote to some of the excesses of design enthusiasts. Projects have bogged down in cumbersome documents that provided little value. They have suffered "analysis paralysis", so afraid of an imperfect design that they made no progress at all. Something had to change. Unfortunately, some of these new process ideas can be easily misinterpreted. Each person has a different definition of "simplest". Continuous refactoring without design principles to guide these small redesigns developers can produce a code base hard to understand or change - the opposite of agility. And, while fear of unanticipated requirements often leads to over-engineering, the attempt to avoid over-engineering can develop into another fear: The fear of any deep design thinking at all. In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But design choices make refactoring itself easier or harder. The XP process attempts to increase team communication. But model and design choices clarify or confuse communication. What is needed is an approach to domain modeling and design that pulls its weight. This book intertwines design and development practice and illustrates how domain-driven design and agile development reinforce each other. A sophisticated approach to domain modeling within the context of an agile development process will accelerate development. The interrelationship of process with domain development makes this approach more practical than any treatment of "pure" design in a vacuum. The Structure of This Book The book is divided into four major sections: Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development that motivate the practices in later sections. Since there are so many approaches to software development, Part I defines terms, and gives an overview of the implications of placing the domain model in the role of driving communication and design. Part II: The Building Blocks of Model-driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. The focus of this section is on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design and makes it easy for team members to understand each other's work. Using standard patterns also establishes a common language, which all team members can use to discuss model and design decisions. But the main point of this section is on the kind of decisions that keep the model and implementation aligned with each other, reinforcing each other's effectiveness. This alignment requires attention to the detail of individual elements. Careful crafting at this small scale gives developers a steady platform to apply the modeling approaches of Parts III and IV. Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately. They require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make it's potential available to the application. Then, once in a while, this onion pealing leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes. Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search. Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: Bounded Context, Distillation, and Large-Scale Structure. Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network. Throughout the book, discussions are illustrated with realistic examples, drawn from actual projects, rather than oversimplified "toy" problems. Much of the book is written as a set of "patterns." The reader should be able to fully understand the material without concern about this device, but those who are interested in the style and format of the patterns can read Appendix A. Who This Book Is Written For This book is primarily written for developers of object-oriented software. Most members of a software project team can benefit from some parts of it. It will make most sense to people who are on a project, trying to do some of these things as they go through, or who have deep experience already to relate it to.Some knowledge of object-oriented modeling is necessary to benefit from this book. The examples include UML diagrams and Java code, so the ability to read those languages at a basic level is important, but it is unnecessary to have mastered the details of either UML or Java. Knowledge of Extreme Programming will add perspective to the discussions of development process, but the discussion should be understandable without background knowledge. For an intermediate software developer, a reader who already knows something of object-oriented design and may have read one or two software design books, this book will fill in gaps and provide perspective on how object modeling fits into real life on a software project. It will help an intermediate developer make the jump to applying sophisticated modeling and design skills to practical problems.An advanced or expert software developer should be interested in the comprehensive framework for dealing with the domain. The systematic approach to design will help them in leading teams down this path. The coherent terminology will help them communicate with peers. Readers of various backgrounds may wish to take different paths through the book, shifting emphasis to different points. I recommend all readers to start with the introduction to Part I, and Chapter 1. This book is a narrative, and can be read beginning to end, or from the beginning of any chapter. A skimmer who already has some grasp of a topic should be able to pick up the main points by reading headings and bolded text. A very advanced reader may want to skim Parts I and II, and will probably be most interested in Parts III and IV. In addition to this core readership, the book will be of interest to analysts and to relatively technical project managers. Analysts can draw on the connection between model and design to make more effective contributions in the context of an "Agile" project. Analysts may also use some of the principles of strategic design to better focus and organize their work. Project managers should be interested in the emphasis on making a team more effective and more focused on designing software meaningful to business experts and users. And, since, strategic design decisions are interrelated with team organization and work styles, these design decisions necessarily involve the leadership of the project, and have a major impact on the project's trajectory. While an individual developer who understands domain-driven design will gain valuable design techniques and perspective, the biggest gains come when a team joins to apply a domain-driven design approach and move the domain model to the center of discourse of the project. The team members will share a language that enriches their communication and keeps it connected to the software. They will produce an implementation in step with the model, giving leverage to application development. They will share a map of how design work of different teams relates, and will systematically focus attention on the most features most distinctive and valuable to the organization. A domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just at the stage when most software projects begin to ossify into legacy. Eric Evans, San Francisco, California, March 2003},
	address = {USA},
	author = {Evans},
	date-added = {2022-01-15 00:04:32 +0100},
	date-modified = {2022-01-15 00:04:56 +0100},
	isbn = {0321125215},
	publisher = {Addison-Wesley Longman Publishing Co., Inc.},
	title = {Domain-Driven Design: Tacking Complexity In the Heart of Software},
	year = {2003}}

@article{de2007geospatial,
	author = {Mills, Jacqueline W.},
	date-added = {2022-01-15 00:02:26 +0100},
	date-modified = {2022-01-15 00:03:04 +0100},
	doi = {10.1111/j.1467-9671.2008.01122.x},
	journal = {Transactions in GIS},
	number = {5},
	pages = {645-647},
	title = {Geospatial Analysis: A Comprehensive Guide to Principles, Techniques, and Software Tools, Second Edition - by Michael J. de Smith, Michael F. Goodchild, and Paul A. Longley},
	volume = {12},
	year = {2008},
	bdsk-url-1 = {https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1467-9671.2008.01122.x},
	bdsk-url-2 = {https://doi.org/10.1111/j.1467-9671.2008.01122.x}}

@article{ammar2018internet,
	abstract = {The Internet of Things (IoT) is heavily affecting our daily lives in many domains, ranging from tiny wearable devices to large industrial systems. Consequently, a wide variety of IoT applications have been developed and deployed using different IoT frameworks. An IoT framework is a set of guiding rules, protocols, and standards which simplify the implementation of IoT applications. The success of these applications mainly depends on the ecosystem characteristics of the IoT framework, with the emphasis on the security mechanisms employed in it, where issues related to security and privacy are pivotal. In this paper, we survey the security of the main IoT frameworks, a total of 8 frameworks are considered. For each framework, we clarify the proposed architecture, the essentials of developing third-party smart apps, the compatible hardware, and the security features. Comparing security architectures shows that the same standards used for securing communications, whereas different methodologies followed for providing other security properties.},
	author = {Mahmoud Ammar and Giovanni Russello and Bruno Crispo},
	date-added = {2022-01-14 23:57:40 +0100},
	date-modified = {2022-01-15 00:12:58 +0100},
	doi = {10.1016/j.jisa.2017.11.002},
	journal = {Journal of Information Security and Applications},
	keywords = {Internet of Things, IoT, Framework, Platform, Security},
	pages = {8-27},
	title = {Internet of Things: A survey on the security of IoT frameworks},
	volume = {38},
	year = {2018},
	bdsk-url-1 = {https://www.sciencedirect.com/science/article/pii/S2214212617302934},
	bdsk-url-2 = {https://doi.org/10.1016/j.jisa.2017.11.002}}

@inbook{dragoni2017microservices,
	abstract = {Microservices is an architectural style inspired by service-oriented computing that has recently started gaining popularity. Before presenting the current state of the art in the field, this chapter reviews the history of software architecture, the reasons that led to the diffusion of objects and services first, and microservices later. Finally, open problems and future challenges are introduced. This survey primarily addresses newcomers to the discipline, while offering an academic viewpoint on the topic. In addition, we investigate some practical issues and point out a few potential solutions.},
	address = {Cham},
	author = {Dragoni, Nicola and Giallorenzo, Saverio and Lafuente, Alberto Lluch and Mazzara, Manuel and Montesi, Fabrizio and Mustafin, Ruslan and Safina, Larisa},
	booktitle = {Present and Ulterior Software Engineering},
	date-added = {2022-01-14 23:53:24 +0100},
	date-modified = {2022-01-14 23:54:46 +0100},
	doi = {10.1007/978-3-319-67425-4_12},
	editor = {Mazzara, Manuel and Meyer, Bertrand},
	pages = {195--216},
	publisher = {Springer International Publishing},
	title = {Microservices: Yesterday, Today, and Tomorrow},
	year = {2017},
	bdsk-url-1 = {https://doi.org/10.1007/978-3-319-67425-4_12}}

@inproceedings{fathoni2019performance,
	abstract = {Traditional cloud computing has the challenge to serve many clients with many services. Spreading the services to across of edge server will reduce the load of traditional cloud computing. Kubernetes is one of the platforms used for cloud management. Kubernetes helps to deploy, and scaling the application. Nowadays, a lot of communities build a lightweight Kubernetes than suitable for edge device such as Raspberry Pi. This paper Investigate the performance of Kubernetes lightweight that installed in the Raspberry Pi.},
	address = {Cham},
	author = {Fathoni, Halim and Yang, Chao-Tung and Chang, Chih-Hung and Huang, Chin-Yin},
	booktitle = {Pervasive Systems, Algorithms and Networks},
	date-added = {2022-01-14 23:50:31 +0100},
	date-modified = {2022-01-14 23:51:43 +0100},
	doi = {10.1007/978-3-030-30143-9_25},
	editor = {Esposito, Christian and Hong, Jiman and Choo, Kim-Kwang Raymond},
	pages = {304--309},
	publisher = {Springer International Publishing},
	title = {Performance Comparison of Lightweight Kubernetes in Edge Devices},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1007/978-3-030-30143-9_25}}

@inproceedings{parsovs2013practical,
	author = {Parsovs, Arnis},
	booktitle = {Network and Distributed System Security Symposium},
	date-added = {2022-01-14 23:47:52 +0100},
	date-modified = {2022-01-14 23:48:46 +0100},
	doi = {ndss.2014.23036},
	month = {January},
	title = {Practical Issues with TLS Client Certificate Authentication},
	year = {2014},
	bdsk-url-1 = {https://doi.org/10.14722/ndss.2014.23036}}

@inproceedings{bohm2021profiling,
	author = {B{\"o}hm, Sebastian and Wirtz, Guido},
	booktitle = {Conference: 13th Central European Workshop on Services and their Composition},
	date-added = {2022-01-14 23:44:47 +0100},
	date-modified = {2022-01-14 23:46:57 +0100},
	month = {March},
	title = {Profiling Lightweight Container Platforms: MicroK8s and K3s in Comparison to Kubernetes},
	year = {2021}}

@misc{mell2011nist,
	author = {Peter Mell and Timothy Grance},
	date-added = {2022-01-14 23:40:20 +0100},
	date-modified = {2022-01-15 01:04:53 +0100},
	doi = {10.6028/NIST.SP.800-145},
	howpublished = {National Institute of Standards and Technology},
	month = {September},
	title = {The NIST Definition of Cloud Computing},
	year = {2011},
	bdsk-url-1 = {https://doi.org/10.6028/NIST.SP.800-145}}

@book{eurostat2020nuts,
	author = {European Commission and Eurostat},
	date-added = {2022-01-14 23:36:59 +0100},
	date-modified = {2022-01-14 23:37:36 +0100},
	doi = {10.2785/72829},
	publisher = {Publications Office},
	title = {Statistical regions in the European Union and partner countries : NUTS and statistical regions 2021 : 2020 edition},
	year = {2020},
	bdsk-url-1 = {https://doi.org/10.2785/72829}}

@phdthesis{fielding2000architectural,
	abstract = {The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system. The Web has been iteratively developed over the past ten years through a series of modifications to the standards that define its architecture. In order to identify those aspects of the Web that needed improvement and avoid undesirable modifications, a model for the modern Web architecture was needed to guide its design, definition, and deployment. Software architecture research investigates methods for determining how best to partition a system, how components identify and communicate with each other, how information is communicated, how elements of a system can evolve independently, and how all of the above can be described using formal and informal notations. My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. An architectural style is a named, coordinated set of architectural constraints. This dissertation defines a framework for understanding software architecture via architectural styles and demonstrates how styles can be used to guide the architectural design of network-based application software. A survey of architectural styles for network-based applications is used to classify styles according to the architectural properties they induce on an architecture for distributed hypermedia. I then introduce the Representational State Transfer (REST) architectural style and describe how REST has been used to guide the design and development of the architecture for the modern Web. REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. I describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles. Finally, I describe the lessons learned from applying REST to the design of the Hypertext Transfer Protocol and Uniform Resource Identifier standards, and from their subsequent deployment in Web client and server software.},
	author = {Fielding, Roy Thomas and Taylor, Richard N.},
	date-added = {2022-01-14 23:28:47 +0100},
	date-modified = {2022-01-14 23:30:11 +0100},
	isbn = {0599871180},
	publisher = {University of California, Irvine},
	title = {Architectural Styles and the Design of Network-Based Software Architectures},
	year = {2000}}

@inproceedings{savor2016continuous,
	abstract = {Continuous deployment is the software engineering practice of deploying many small incremental software updates into production, leading to a continuous stream of 10s, 100s, or even 1,000s of deployments per day. High-profile Internet firms such as Amazon, Etsy, Facebook, Flickr, Google, and Netflix have embraced continuous deployment. However, the practice has not been covered in textbooks and no scientific publication has presented an analysis of continuous deployment.In this paper, we describe the continuous deployment practices at two very different firms: Facebook and OANDA. We show that continuous deployment does not inhibit productivity or quality even in the face of substantial engineering team and code size growth. To the best of our knowledge, this is the first study to show it is possible to scale the size of an engineering team by 20X and the size of the code base by 50X without negatively impacting developer productivity or software quality. Our experience suggests that top-level management support of continuous deployment is necessary, and that given a choice, developers prefer faster deployment. We identify elements we feel make continuous deployment viable and present observations from operating in a continuous deployment environment.},
	address = {New York, NY, USA},
	author = {Savor, Tony and Douglas, Mitchell and Gentili, Michael and Williams, Laurie and Beck, Kent and Stumm, Michael},
	booktitle = {Proceedings of the 38th International Conference on Software Engineering Companion},
	date-added = {2022-01-14 23:27:44 +0100},
	date-modified = {2022-01-14 23:28:14 +0100},
	doi = {10.1145/2889160.2889223},
	location = {Austin, Texas},
	pages = {21--30},
	publisher = {Association for Computing Machinery},
	series = {ICSE '16},
	title = {Continuous Deployment at Facebook and OANDA},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1145/2889160.2889223}}

@article{dmitry2014micro,
	author = {Namiot, Dmitry and sneps-sneppe, Manfred},
	date-added = {2022-01-14 23:24:30 +0100},
	date-modified = {2022-01-14 23:24:52 +0100},
	journal = {Interenational Journal of Open Information Technologies},
	month = {September},
	pages = {24-27},
	title = {On Micro-services Architecture},
	volume = {2},
	year = {2014}}

@inproceedings{jabbari2016devops,
	abstract = {Context: DevOps, the combination of Development and Operations, is a new way of thinking in the software engineering domain that recently received much attention. Given that DevOps is a new term and novel concept recently introduced, no common understanding of what it entails has been achieved yet. Consequently, definitions of DevOps often only represent a part that is relevant to the concept.Objective:This study aims to characterize DevOps by exploring central components of DevOps definitions reported in the literature, specifying practices explicitly proposed for DevOps and investigating the similarities and differences between DevOps and other existing methods in software engineering.Method: A systematic mapping study was conducted that used six electronic databases: IEEE, ACM, Inspec, Scopus, Wiley Online Library and Web of Science.Result: 44 studies have been selected that report a definition of DevOps, 15 studies explicitly stating DevOps practices, and 15 studies stating how DevOps is related to other existing methods. Papers in some cases stated a combination of a definition, practices, and relations to other methods, the total number of primary studies was 49.Conclusion: We proposed a definition for DevOps which may overcome inconsistencies over the various existing definitions of individual research studies. In addition, the practices explicitly proposed for DevOps have been presented as well as the relation to other software development methods.},
	address = {New York, NY, USA},
	author = {Jabbari, Ramtin and bin Ali, Nauman and Petersen, Kai and Tanveer, Binish},
	booktitle = {Proceedings of the Scientific Workshop Proceedings of XP2016},
	date-added = {2022-01-14 23:02:25 +0100},
	date-modified = {2022-01-14 23:31:12 +0100},
	doi = {10.1145/2962695.2962707},
	keywords = {Software development method, DevOps practice, DevOps definition},
	location = {Edinburgh, Scotland, UK},
	publisher = {Association for Computing Machinery},
	series = {XP '16 Workshops},
	title = {What is DevOps? A Systematic Mapping Study on Definitions and Practices},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1145/2962695.2962707}}

@article{morabito2017virtualization,
	author = {Morabito, Roberto},
	date-added = {2022-01-14 23:01:44 +0100},
	date-modified = {2022-01-14 23:31:44 +0100},
	doi = {10.1109/ACCESS.2017.2704444},
	journal = {IEEE Access},
	pages = {8835--8850},
	title = {Virtualization on Internet of Things Edge Devices With Container Technologies: A Performance Evaluation},
	volume = {5},
	year = {2017},
	bdsk-url-1 = {https://doi.org/10.1109/ACCESS.2017.2704444}}

@inproceedings{virmani2015understanding,
	author = {Virmani, Manish},
	booktitle = {Fifth International Conference on the Innovative Computing Technology (INTECH 2015)},
	date-added = {2022-01-14 23:00:50 +0100},
	date-modified = {2022-01-14 23:16:54 +0100},
	doi = {10.1109/INTECH.2015.7173368},
	pages = {78-82},
	title = {Understanding DevOps \& bridging the gap from continuous integration to continuous delivery},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/INTECH.2015.7173368}}

@inproceedings{hummen2013towards,
	abstract = {The vision of the Internet of Things considers smart objects in the physical world as first-class citizens of the digital world. Especially IP technology and RESTful web services on smart objects promise simple interactions with Internet services in the Web of Things, e.g., for building automation or in e-health scenarios. Peer authentication and secure data transmission are vital aspects in many of these scenarios to prevent leakage of personal information and harmful actuating tasks. While standard security solutions exist for traditional IP networks, the constraints of smart objects demand for more lightweight security mechanisms. Thus, the use of certificates for peer authentication is predominantly considered impracticable. In this paper, we investigate if this assumption is valid. To this end, we present preliminary overhead estimates for the certificate-based DTLS handshake and argue that certificates - with improvements to the handshake - are a viable method of authentication in many network scenarios. We propose three design ideas to reduce the overheads of the DTLS handshake. These ideas are based on (i) pre-validation, (ii) session resumption, and (iii) handshake delegation. We qualitatively analyze the expected overhead reductions and discuss their applicability.},
	address = {New York, NY, USA},
	author = {Hummen, Ren\'{e} and Ziegeldorf, Jan H. and Shafagh, Hossein and Raza, Shahid and Wehrle, Klaus},
	booktitle = {Proceedings of the 2nd ACM Workshop on Hot Topics on Wireless Network Security and Privacy},
	date-added = {2022-01-14 23:00:18 +0100},
	date-modified = {2022-01-14 23:06:01 +0100},
	doi = {10.1145/2463183.2463193},
	keywords = {tls, internet of things, certificates, authentication},
	location = {Budapest, Hungary},
	pages = {37--42},
	publisher = {Association for Computing Machinery},
	series = {HotWiSec '13},
	title = {Towards Viable Certificate-Based Authentication for the Internet of Things},
	year = {2013},
	bdsk-url-1 = {https://doi.org/10.1145/2463183.2463193}}

@inproceedings{dyck2015towards,
	author = {Dyck, Andrej and Penners, Ralf and Lichter, Horst},
	booktitle = {2015 IEEE/ACM 3rd International Workshop on Release Engineering},
	date-added = {2022-01-14 22:59:38 +0100},
	date-modified = {2022-01-14 22:59:54 +0100},
	doi = {10.1109/RELENG.2015.10},
	pages = {3-3},
	title = {Towards Definitions for Release Engineering and DevOps},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/RELENG.2015.10}}

@inproceedings{hoque2017towards,
	author = {Hoque, Saiful and De Brito, Mathias Santos and Willner, Alexander and Keil, Oliver and Magedanz, Thomas},
	booktitle = {2017 IEEE 41st Annual Computer Software and Applications Conference (COMPSAC)},
	date-added = {2022-01-14 22:59:04 +0100},
	date-modified = {2022-01-14 22:59:13 +0100},
	doi = {10.1109/COMPSAC.2017.248},
	pages = {294-299},
	title = {Towards Container Orchestration in Fog Computing Infrastructures},
	volume = {2},
	year = {2017},
	bdsk-url-1 = {https://doi.org/10.1109/COMPSAC.2017.248}}

@article{leppanen2015highways,
	author = {Lepp{\"a}nen, Marko and M{\"a}kinen, Simo and Pagels, Max and Eloranta, Veli-Pekka and Itkonen, Juha and M{\"a}ntyl{\"a}, Mika V. and M{\"a}nnist{\"o}, Tomi},
	date-added = {2022-01-14 22:58:29 +0100},
	date-modified = {2022-01-14 22:58:36 +0100},
	doi = {10.1109/MS.2015.50},
	journal = {IEEE Software},
	number = {2},
	pages = {64-72},
	title = {The highways and country roads to continuous deployment},
	volume = {32},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2015.50}}

@inproceedings{Liu:2004:QCP:1013367.1013379,
	abstract = {The emerging Service-Oriented Computing (SOC) paradigm promises to enable businesses and organizations to collaborate in an unprecedented way by means of standard web services. To support rapid and dynamic composition of services in this paradigm, web services that meet requesters' functional requirements must be able to be located and bounded dynamically from a large and constantly changing number of service providers based on their Quality of Service (QoS). In order to enable quality-driven web service selection, we need an open, fair, dynamic and secure framework to evaluate the QoS of a vast number of web services. The fair computation and enforcing of QoS of web services should have minimal overhead but yet able to achieve sufficient trust by both service requesters and providers. In this paper, we presented our open, fair and dynamic QoS computation model for web services selection through implementation of and experimentation with a QoS registry in a hypothetical phone service provisioning market place application.},
	address = {New York, NY, USA},
	author = {Liu, Yutu and Ngu, Anne H. and Zeng, Liang Z.},
	booktitle = {Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers \& Posters},
	date-added = {2022-01-14 22:57:31 +0100},
	date-modified = {2022-01-14 23:18:01 +0100},
	doi = {10.1145/1013367.1013379},
	keywords = {web services, ranking of QoS, extensible QoS model, QoS},
	location = {New York, NY, USA},
	pages = {66--73},
	publisher = {Association for Computing Machinery},
	series = {WWW Alt. '04},
	title = {QoS Computation and Policing in Dynamic Web Service Selection},
	year = {2004},
	bdsk-url-1 = {https://doi.org/10.1145/1013367.1013379}}

@inproceedings{xavier2013performance,
	author = {Xavier, Miguel G. and Neves, Marcelo V. and Rossi, Fabio D. and Ferreto, Tiago C. and Lange, Timoteo and De Rose, Cesar A. F.},
	booktitle = {2013 21st Euromicro International Conference on Parallel, Distributed, and Network-Based Processing},
	date-added = {2022-01-14 22:56:20 +0100},
	date-modified = {2022-01-14 22:56:26 +0100},
	doi = {10.1109/PDP.2013.41},
	pages = {233-240},
	title = {Performance Evaluation of Container-Based Virtualization for High Performance Computing Environments},
	year = {2013},
	bdsk-url-1 = {https://doi.org/10.1109/PDP.2013.41}}

@article{alam2018orchestration,
	author = {Alam, Muhammad and Rufino, Joao and Ferreira, Joaquim and Ahmed, Syed Hassan and Shah, Nadir and Chen, Yuanfang},
	date-added = {2022-01-14 22:55:35 +0100},
	date-modified = {2022-01-14 22:55:43 +0100},
	doi = {10.1109/MCOM.2018.1701233},
	journal = {IEEE Communications Magazine},
	number = {9},
	pages = {118-123},
	title = {Orchestration of Microservices for IoT Using Docker and Edge Computing},
	volume = {56},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1109/MCOM.2018.1701233}}

@article{taibi2018definition,
	author = {Taibi, Davide and Lenarduzzi, Valentina},
	date-added = {2022-01-14 22:55:02 +0100},
	date-modified = {2022-01-14 22:55:09 +0100},
	doi = {10.1109/MS.2018.2141031},
	journal = {IEEE Software},
	number = {3},
	pages = {56-62},
	title = {On the Definition of Microservice Bad Smells},
	volume = {35},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2018.2141031}}

@article{balalaie2016microservices,
	author = {Balalaie, Armin and Heydarnoori, Abbas and Jamshidi, Pooyan},
	date-added = {2022-01-14 22:53:36 +0100},
	date-modified = {2022-01-14 22:53:49 +0100},
	doi = {10.1109/MS.2016.64},
	journal = {IEEE Software},
	number = {3},
	pages = {42-52},
	title = {Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture},
	volume = {33},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2016.64}}

@inproceedings{chen2018microservices,
	author = {Chen, Lianping},
	booktitle = {2018 IEEE International Conference on Software Architecture (ICSA)},
	date-added = {2022-01-14 22:52:53 +0100},
	date-modified = {2022-01-14 22:53:09 +0100},
	doi = {10.1109/ICSA.2018.00013},
	pages = {39-397},
	title = {Microservices: Architecting for Continuous Delivery and DevOps},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1109/ICSA.2018.00013}}

@article{thones2015microservices,
	author = {Th{\"o}nes, Johannes},
	date-added = {2022-01-14 22:51:56 +0100},
	date-modified = {2022-01-14 22:52:05 +0100},
	doi = {10.1109/MS.2015.11},
	journal = {IEEE Software},
	number = {1},
	pages = {116-116},
	title = {Microservices},
	volume = {32},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2015.11}}

@inproceedings{vayghan2019microservice,
	author = {Abdollahi Vayghan, Leila and Saied, Mohamed Aymen and Toeroe, Maria and Khendek, Ferhat},
	booktitle = {2019 IEEE 19th International Conference on Software Quality, Reliability and Security (QRS)},
	date-added = {2022-01-14 22:51:23 +0100},
	date-modified = {2022-01-14 22:51:31 +0100},
	doi = {10.1109/QRS.2019.00034},
	pages = {176-185},
	title = {Microservice Based Architecture: Towards High-Availability for Stateful Applications with Kubernetes},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1109/QRS.2019.00034}}

@article{khan2017key,
	author = {Khan, Asif},
	date-added = {2022-01-14 22:50:20 +0100},
	date-modified = {2022-01-14 22:50:30 +0100},
	doi = {10.1109/MCC.2017.4250933},
	journal = {IEEE Cloud Computing},
	number = {5},
	pages = {42-48},
	title = {Key Characteristics of a Container Orchestration Platform to Enable a Modern Application},
	volume = {4},
	year = {2017},
	bdsk-url-1 = {https://doi.org/10.1109/MCC.2017.4250933}}

@inproceedings{morabito2015hypervisors,
	author = {Morabito, Roberto and Kj{\"a}llman, Jimmy and Komu, Miika},
	booktitle = {2015 IEEE International Conference on Cloud Engineering},
	date-added = {2022-01-14 22:48:49 +0100},
	date-modified = {2022-01-14 22:49:01 +0100},
	doi = {10.1109/IC2E.2015.74},
	pages = {386-393},
	title = {Hypervisors vs. Lightweight Virtualization: A Performance Comparison},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/IC2E.2015.74}}

@article{limoncelli2018gitops,
	abstract = {GitOps lowers the bar for creating self-service versions of common IT processes, making it easier to meet the return in the ROI calculation. GitOps not only achieves this, but also encourages desired behaviors in IT systems: better testing, reduction of bus factor, reduced wait time, more infrastructure logic being handled programmatically with IaC, and directing time away from manual toil toward creating and maintaining automation.},
	address = {New York, NY, USA},
	author = {Limoncelli, Thomas A.},
	date-added = {2022-01-14 22:47:45 +0100},
	date-modified = {2022-01-14 23:10:36 +0100},
	doi = {10.1145/3236386.3237207},
	journal = {Queue},
	month = {June},
	number = {3},
	pages = {13--26},
	publisher = {Association for Computing Machinery},
	title = {GitOps: A Path to More Self-Service IT: IaC + PR = GitOps},
	volume = {16},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1145/3236386.3237207}}

@inproceedings{goethals2019fledge,
	abstract = {In recent years, containers have quickly gained popularity in the cloud, mostly thanks to their scalable, ethereal and isolated nature. Simultaneously, edge devices have become powerful enough to run containerized microservices, while remaining small and low-powered. These evolutions have triggered a wave of research into container placement strategies on clusters including edge devices, leading to concepts such as fog computing. These container placement strategies can optimize workload placement across cloud and edge clusters, but current container orchestrators are very resource intensive and are not designed to run on edge devices.This paper presents FLEDGE as a Kubernetes compatible edge container orchestrator. A number of aspects of how to achieve low-resource container orchestration are examined, for example the choice of container runtime and how to implement container networking. Finally, a number of evaluations are performed, comparing FLEDGE to K3S and Kubernetes, to show that it is a viable alternative to existing container orchestrators.},
	address = {Berlin, Heidelberg},
	author = {Goethals, Tom and De Turck, Filip and Volckaert, Bruno},
	booktitle = {Internet of Vehicles. Technologies and Services Toward Smart Cities: 6th International Conference, IOV 2019, Kaohsiung, Taiwan, November 18--21, 2019, Proceedings},
	date-added = {2022-01-14 22:46:28 +0100},
	date-modified = {2022-01-14 23:10:55 +0100},
	doi = {10.1007/978-3-030-38651-1_16},
	keywords = {Container orchestration, Edge computing, Edge networks, VPN, Containers},
	location = {Kaohsiung, Taiwan},
	pages = {174--189},
	publisher = {Springer-Verlag},
	title = {FLEDGE: Kubernetes Compatible Container Orchestration on Low-Resource Edge Devices},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1007/978-3-030-38651-1_16}}

@inproceedings{xiong2018extend,
	author = {Xiong, Ying and Sun, Yulin and Xing, Li and Huang, Ying},
	booktitle = {2018 IEEE/ACM Symposium on Edge Computing (SEC)},
	date-added = {2022-01-14 22:45:47 +0100},
	date-modified = {2022-01-14 22:45:56 +0100},
	doi = {10.1109/SEC.2018.00048},
	pages = {373-377},
	title = {Extend Cloud to Edge with KubeEdge},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1109/SEC.2018.00048}}

@inproceedings{celesti2016exploring,
	author = {Celesti, Antonio and Mulfari, Davide and Fazio, Maria and Villari, Massimo and Puliafito, Antonio},
	booktitle = {2016 IEEE International Conference on Smart Computing (SMARTCOMP)},
	date-added = {2022-01-14 22:45:22 +0100},
	date-modified = {2022-01-14 22:45:32 +0100},
	doi = {10.1109/SMARTCOMP.2016.7501691},
	pages = {1-6},
	title = {Exploring Container Virtualization in IoT Clouds},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1109/SMARTCOMP.2016.7501691}}

@inproceedings{villamizar2015evaluating,
	author = {Villamizar, Mario and Garc{\'e}s, Oscar and Castro, Harold and Verano, Mauricio and Salamanca, Lorena and Casallas, Rubby and Gil, Santiago},
	booktitle = {2015 10th Computing Colombian Conference (10CCC)},
	date-added = {2022-01-14 22:44:43 +0100},
	date-modified = {2022-01-14 22:45:02 +0100},
	doi = {10.1109/ColumbianCC.2015.7333476},
	pages = {583-590},
	title = {Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/ColumbianCC.2015.7333476}}

@article{merkel2014docker,
	abstract = {Docker promises the ability to package applications and their dependencies into lightweight containers that move easily between different distros, start up quickly and are isolated from each other.},
	address = {Houston, TX},
	author = {Merkel, Dirk},
	date-added = {2022-01-14 22:43:25 +0100},
	date-modified = {2022-01-14 23:11:41 +0100},
	journal = {Linux J.},
	month = {March},
	number = {239},
	publisher = {Belltown Media},
	title = {Docker: Lightweight Linux Containers for Consistent Development and Deployment},
	volume = {2014},
	year = {2014}}

@inproceedings{vayghan2018deploying,
	author = {Abdollahi Vayghan, Leila and Saied, Mohamed Aymen and Toeroe, Maria and Khendek, Ferhat},
	booktitle = {2018 IEEE 11th International Conference on Cloud Computing (CLOUD)},
	date-added = {2022-01-14 22:42:12 +0100},
	date-modified = {2022-01-14 22:42:21 +0100},
	doi = {10.1109/CLOUD.2018.00148},
	pages = {970-973},
	title = {Deploying Microservice Based Applications with Kubernetes: Experiments and Lessons Learned},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1109/CLOUD.2018.00148}}

@article{meyer2014continuous,
	author = {Meyer, Mathias},
	date-added = {2022-01-14 22:41:35 +0100},
	date-modified = {2022-01-14 22:41:46 +0100},
	doi = {10.1109/MS.2014.58},
	journal = {IEEE Software},
	number = {3},
	pages = {14-16},
	title = {Continuous Integration and Its Tools},
	volume = {31},
	year = {2014},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2014.58}}

@article{chen2015continuous,
	author = {Chen, Lianping},
	date-added = {2022-01-14 22:40:02 +0100},
	date-modified = {2022-01-14 22:40:10 +0100},
	doi = {10.1109/MS.2015.27},
	journal = {IEEE Software},
	number = {2},
	pages = {50-54},
	title = {Continuous Delivery: Huge Benefits, but Challenges Too},
	volume = {32},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/MS.2015.27}}

@article{cerny2018contextual,
	abstract = {Current industry trends in enterprise architectures indicate movement from Service-Oriented Architecture (SOA) to Microservices. By understanding the key differences between these two approaches and their features, we can design a more effective Microservice architecture by avoiding SOA pitfalls. To do this, we must know why this shift is happening and how key SOA functionality is addressed by key features of the Microservice-based system. Unfortunately, Microservices do not address all SOA shortcomings. In addition, Microservices introduce new challenges. This work provides a detailed analysis of the differences between these two architectures and their features. Next, we describe both research and industry perspectives on the strengths and weaknesses of both architectural directions. Finally, we perform a systematic mapping study related to Microservice research, identifying interest and challenges in multiple categories from a range of recent research.},
	address = {New York, NY, USA},
	author = {Cerny, Tomas and Donahoo, Michael J. and Trnka, Michal},
	date-added = {2022-01-14 22:39:29 +0100},
	date-modified = {2022-01-14 23:12:37 +0100},
	doi = {10.1145/3183628.3183631},
	journal = {SIGAPP Appl. Comput. Rev.},
	keywords = {self-contained systems, SOA, survey, microservices, architectures, systematic mapping study},
	month = {January},
	number = {4},
	pages = {29--45},
	publisher = {Association for Computing Machinery},
	title = {Contextual Understanding of Microservice Architecture: Current and Future Directions},
	volume = {17},
	year = {2018},
	bdsk-url-1 = {https://doi.org/10.1145/3183628.3183631}}

@article{bernstein2014containers,
	author = {Bernstein, David},
	date-added = {2022-01-14 22:37:48 +0100},
	date-modified = {2022-01-14 22:37:54 +0100},
	doi = {10.1109/MCC.2014.51},
	journal = {IEEE Cloud Computing},
	number = {3},
	pages = {81-84},
	title = {Containers and Cloud: From LXC to Docker to Kubernetes},
	volume = {1},
	year = {2014},
	bdsk-url-1 = {https://doi.org/10.1109/MCC.2014.51}}

@article{pahl2015containerization,
	author = {Pahl, Claus},
	date-added = {2022-01-14 22:37:00 +0100},
	date-modified = {2022-01-14 22:37:07 +0100},
	doi = {10.1109/MCC.2015.51},
	journal = {IEEE Cloud Computing},
	number = {3},
	pages = {24-31},
	title = {Containerization and the PaaS Cloud},
	volume = {2},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/MCC.2015.51}}

@inproceedings{singh2017container,
	author = {Singh, Vindeep and Peddoju, Sateesh K},
	booktitle = {2017 International Conference on Computing, Communication and Automation (ICCCA)},
	date-added = {2022-01-14 22:36:19 +0100},
	date-modified = {2022-01-14 22:36:24 +0100},
	doi = {10.1109/CCAA.2017.8229914},
	pages = {847-852},
	title = {Container-based microservice architecture for cloud applications},
	year = {2017},
	bdsk-url-1 = {https://doi.org/10.1109/CCAA.2017.8229914}}

@inproceedings{al2019container,
	author = {Jawarneh, Isam Mashhour Al and Bellavista, Paolo and Bosi, Filippo and Foschini, Luca and Martuscelli, Giuseppe and Montanari, Rebecca and Palopoli, Amedeo},
	booktitle = {ICC 2019 - 2019 IEEE International Conference on Communications (ICC)},
	date-added = {2022-01-14 22:35:36 +0100},
	date-modified = {2022-01-14 22:35:42 +0100},
	doi = {10.1109/ICC.2019.8762053},
	pages = {1-6},
	title = {Container Orchestration Engines: A Thorough Functional and Performance Comparison},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1109/ICC.2019.8762053}}

@inproceedings{kang2016container,
	author = {Kang, Hui and Le, Michael and Tao, Shu},
	booktitle = {2016 IEEE International Conference on Cloud Engineering (IC2E)},
	date-added = {2022-01-14 22:34:32 +0100},
	date-modified = {2022-01-14 22:34:38 +0100},
	doi = {10.1109/IC2E.2016.26},
	pages = {202-211},
	title = {Container and Microservice Driven Design for Cloud Infrastructure DevOps},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1109/IC2E.2016.26}}

@article{pahl2017cloud,
	author = {Pahl, Claus and Brogi, Antonio and Soldani, Jacopo and Jamshidi, Pooyan},
	date-added = {2022-01-14 22:33:56 +0100},
	date-modified = {2022-01-14 22:34:04 +0100},
	doi = {10.1109/TCC.2017.2702586},
	journal = {IEEE Transactions on Cloud Computing},
	number = {3},
	pages = {677-692},
	title = {Cloud Container Technologies: A State-of-the-Art Review},
	volume = {7},
	year = {2019},
	bdsk-url-1 = {https://doi.org/10.1109/TCC.2017.2702586}}

@article{burns2016borg,
	abstract = {Though widespread interest in software containers is a relatively recent phenomenon, at Google we have been managing Linux containers at scale for more than ten years and built three different container-management systems in that time. Each system was heavily influenced by its predecessors, even though they were developed for different reasons. This article describes the lessons we've learned from developing and operating them.},
	address = {New York, NY, USA},
	author = {Burns, Brendan and Grant, Brian and Oppenheimer, David and Brewer, Eric and Wilkes, John},
	date-added = {2022-01-14 22:12:04 +0100},
	date-modified = {2022-01-14 23:13:35 +0100},
	doi = {10.1145/2898442.2898444},
	journal = {Queue},
	month = {January},
	number = {1},
	pages = {70--93},
	publisher = {Association for Computing Machinery},
	title = {Borg, Omega, and Kubernetes: Lessons Learned from Three Container-Management Systems over a Decade},
	volume = {14},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1145/2898442.2898444}}

@inproceedings{felter2015updated,
	author = {Felter, Wes and Ferreira, Alexandre and Rajamony, Ram and Rubio, Juan},
	booktitle = {2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)},
	date-added = {2022-01-14 22:10:18 +0100},
	date-modified = {2022-01-14 22:10:24 +0100},
	doi = {10.1109/ISPASS.2015.7095802},
	pages = {171-172},
	title = {An updated performance comparison of virtual machines and Linux containers},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1109/ISPASS.2015.7095802}}

@article{boettiger2015introduction,
	abstract = {As computational work becomes more and more integral to many aspects of scientific research, computational reproducibility has become an issue of increasing importance to computer systems researchers and domain scientists alike. Though computational reproducibility seems more straight forward than replicating physical experiments, the complex and rapidly changing nature of computer environments makes being able to reproduce and extend such work a serious challenge. In this paper, I explore common reasons that code developed for one research project cannot be successfully executed or extended by subsequent researchers. I review current approaches to these issues, including virtual machines and workflow systems, and their limitations. I then examine how the popular emerging technology Docker combines several areas from systems research - such as operating system virtualization, cross-platform portability, modular re-usable elements, versioning, and a 'DevOps' philosophy, to address these challenges. I illustrate this with several examples of Docker use with a focus on the R statistical environment.},
	address = {New York, NY, USA},
	author = {Boettiger, Carl},
	date-added = {2022-01-14 22:08:35 +0100},
	date-modified = {2022-01-14 23:14:12 +0100},
	doi = {10.1145/2723872.2723882},
	journal = {SIGOPS Oper. Syst. Rev.},
	month = {January},
	number = {1},
	pages = {71--79},
	publisher = {Association for Computing Machinery},
	title = {An Introduction to Docker for Reproducible Research},
	volume = {49},
	year = {2015},
	bdsk-url-1 = {https://doi.org/10.1145/2723872.2723882}}

@inproceedings{Martinez-Ortiz:2016:QMW:3011141.3011203,
	abstract = {Web components improve Internet applications, empowering end-user development with encapsulation and interoperability. Public repositories contain a variety of web components implementing GUI elements, system components for mashup development and wrappers of popular web services. The distribution of this technology through public repositories has fostered a growing interest in quality metrics for web components, highlighting the absence of unified approach. This paper presents a reference model and evaluation framework for measuring the quality of web components. Preliminary results of an experimentation framework provide insights for comparing standard metrics with custom metrics based on curated user-perceived quality and data extracted from public repositories.},
	address = {New York, NY, USA},
	author = {Mart\'{\i}nez-Ortiz, A. L. and Lizcano, David and Ortega, M. and Ruiz, L. and L\'{o}pez, G.},
	booktitle = {Proceedings of the 18th International Conference on Information Integration and Web-Based Applications and Services},
	date-added = {2022-01-14 22:05:53 +0100},
	date-modified = {2022-01-14 23:14:50 +0100},
	doi = {10.1145/3011141.3011203},
	keywords = {components, quality, software, web},
	location = {Singapore, Singapore},
	pages = {430--432},
	publisher = {Association for Computing Machinery},
	series = {iiWAS '16},
	title = {A Quality Model for Web Components},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.1145/3011141.3011203}}

@misc{rapidapi2020,
	author = {RapidAPI},
	date-added = {2022-01-13 21:47:48 +0100},
	date-modified = {2022-01-15 01:04:10 +0100},
	title = {Developer Survey 2020 Report},
	year = {2021}}

@webpage{linuxManpage,
	date-added = {2022-01-13 21:12:28 +0100},
	date-modified = {2022-01-15 00:48:14 +0100},
	lastchecked = {12.01.22},
	title = {Linux man pages online},
	url = {https://man7.org/linux/man-pages/},
	bdsk-url-1 = {https://man7.org/linux/man-pages/}}

@misc{eia2021consumption,
	author = {Energy Information Administration},
	date-added = {2022-01-13 21:01:18 +0100},
	date-modified = {2022-01-15 01:06:32 +0100},
	howpublished = {Statista},
	title = {Net consumption of electricity worldwide in select years from 1980 to 2018},
	year = {2021}}

@misc{iea2020demand,
	author = {International Energy Agency},
	date-added = {2022-01-13 20:52:36 +0100},
	date-modified = {2022-01-15 01:08:37 +0100},
	howpublished = {Statista},
	month = {March},
	title = {Energy demand in data centers worldwide from 2015 to 2021, by type},
	year = {2020},
	bdsk-url-1 = {https://www.statista.com/statistics/186992/global-derived-electricity-consumption-in-data-centers-and-telecoms/}}

@webpage{kubernetesImperative,
	date-added = {2022-01-09 15:33:40 +0100},
	date-modified = {2022-01-15 00:43:59 +0100},
	lastchecked = {09.01.2022},
	title = {Managing Kubernetes Objects Using Imperative Commands},
	url = {https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/},
	bdsk-url-1 = {https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-command/}}

@webpage{kubernetesControllers,
	date-added = {2022-01-09 15:14:53 +0100},
	date-modified = {2022-01-15 00:45:22 +0100},
	lastchecked = {09.01.2022},
	title = {Controllers},
	url = {https://kubernetes.io/docs/concepts/architecture/controller/},
	bdsk-url-1 = {https://kubernetes.io/docs/concepts/architecture/controller/}}

@webpage{docker2020multi,
	author = {Jeremie Drouet},
	date-added = {2022-01-07 19:50:23 +0100},
	date-modified = {2022-01-15 00:40:30 +0100},
	lastchecked = {07.01.2022},
	month = {April},
	title = {Multi-arch build and images, the simple way},
	url = {https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/},
	year = {2020},
	bdsk-url-1 = {https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/}}

@webpage{bloomberg2020microsoft,
	author = {Ian King and Dina Bass},
	date-added = {2022-01-07 18:58:43 +0100},
	date-modified = {2022-01-15 00:41:07 +0100},
	lastchecked = {07.01.2022},
	month = {December},
	title = {Microsoft Designing Its Own Chips for Servers, Surface PCs},
	url = {https://www.bloomberg.com/news/articles/2020-12-18/microsoft-is-designing-its-own-chips-for-servers-surface-pcs},
	year = {2020},
	bdsk-url-1 = {https://www.bloomberg.com/news/articles/2020-12-18/microsoft-is-designing-its-own-chips-for-servers-surface-pcs}}

@webpage{lkml2018eol,
	date-added = {2022-01-07 18:25:32 +0100},
	date-modified = {2022-01-15 00:49:10 +0100},
	lastchecked = {07.01.2022},
	month = {November},
	title = {Linux 3.10.108 (EOL)},
	url = {https://lkml.org/lkml/2017/11/4/178},
	year = {2017},
	bdsk-url-1 = {https://lkml.org/lkml/2017/11/4/178}}

@webpage{dockerEngine,
	date-added = {2022-01-07 18:19:43 +0100},
	date-modified = {2022-01-15 00:41:45 +0100},
	lastchecked = {07.01.2022},
	title = {Install Docker Engine from binaries},
	url = {https://docs.docker.com/engine/install/binaries/},
	bdsk-url-1 = {https://docs.docker.com/engine/install/binaries/}}

@manual{arm2020v8a,
	date-added = {2022-01-07 17:49:12 +0100},
	date-modified = {2022-01-15 00:47:17 +0100},
	edition = {1.1},
	month = {July},
	organization = {Arm Limited},
	title = {Armv8-A Instruction Set Architecture},
	year = {2020}}

@webpage{raspberrypi4,
	date-added = {2022-01-07 17:35:10 +0100},
	date-modified = {2022-01-15 00:38:34 +0100},
	lastchecked = {07.01.2022},
	title = {Raspberry Pi 4 Model B specifications},
	url = {https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/},
	bdsk-url-1 = {https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/}}

@misc{vde2018sml,
	author = {Deutsche Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE},
	date-added = {2022-01-06 20:14:19 +0100},
	date-modified = {2022-01-15 01:05:03 +0100},
	month = {Februar},
	title = {DIN VDE 0418-63-9: Messeinrichtungen und -systeme - Teil 63-9: Intelligentes Kommunikationsprotokoll f{\"u}r Elektrizit{\"a}tsz{\"a}hler (SML)},
	year = {2022}}

@manual{nzr2011ehz,
	address = {Heideweg 33, 49196 Bad Laer},
	date-added = {2022-01-05 14:34:50 +0100},
	date-modified = {2022-01-15 00:50:08 +0100},
	edition = {09/2011},
	organization = {Nordwestdeutsche Z{\"a}hlerrevision},
	title = {Produkthandbuch Elektronischer Haushaltsz{\"a}hler eHZ}}

@misc{iec2002d0,
	author = {International Electrotechnical Commission},
	date-added = {2022-01-05 13:09:08 +0100},
	date-modified = {2022-01-15 01:04:25 +0100},
	month = {May},
	title = {Electricity metering - Data exchange for meter reading, tariff and load control - Part 21: Direct local data exchange},
	year = {2002},
	bdsk-url-1 = {https://webstore.iec.ch/publication/32782}}

@misc{iec2017obis,
	author = {International Electrotechnical Commission},
	date-added = {2021-12-18 21:00:43 +0100},
	date-modified = {2022-01-15 01:04:30 +0100},
	month = {August},
	title = {Electricity metering data exchange - The DLMS/COSEM suite - Part 6-1: Object Identification System (OBIS)},
	year = {2017},
	bdsk-url-1 = {https://webstore.iec.ch/publication/32782}}

@webpage{netflix2013api,
	author = {Ben Christensen},
	date-added = {2021-12-10 10:45:05 +0100},
	date-modified = {2022-01-15 00:39:33 +0100},
	lastchecked = {10.12.21},
	month = {January},
	title = {Optimizing the Netflix API},
	url = {https://netflixtechblog.com/optimizing-the-netflix-api-5c9ac715cf19},
	year = {2013},
	bdsk-url-1 = {https://netflixtechblog.com/optimizing-the-netflix-api-5c9ac715cf19}}

@mastersthesis{stoy2019broker,
	author = {Patrick Stoy},
	date-added = {2020-09-16 18:48:52 +0200},
	date-modified = {2022-01-14 23:35:20 +0100},
	month = {April},
	school = {Hochschule RheinMain},
	title = {Konzeption und Entwicklung standardisierter Schnittstellen zur automatisierten regionalen Vermarktung kleiner Mengen an erneuerbaren Energien},
	year = {2019}}

@webpage{fielding2008hypertext,
	author = {Fielding, Roy T},
	date-added = {2020-09-14 15:51:31 +0200},
	date-modified = {2022-01-14 23:43:04 +0100},
	lastchecked = {14.09.20},
	month = {October},
	title = {REST APIs must be hypertext-driven},
	url = {https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven},
	year = {2008},
	bdsk-url-1 = {https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven}}

@techreport{fielding2014rfc,
	author = {Fielding, Roy and Reschke, Julian},
	date-modified = {2020-09-20 15:19:53 +0200},
	institution = {Internet Engineering Task Force},
	number = {7230},
	title = {Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing},
	type = {Request for Comments},
	year = {2014}}

@misc{butt2004certificate,
	author = {Butt, Alan B and Hillyard, Paul B and Su, Jin},
	date-modified = {2022-01-15 00:23:49 +0100},
	month = {June},
	note = {US Patent 6,754,829},
	publisher = {Google Patents},
	title = {Certificate-based authentication system for heterogeneous environments},
	year = {2004}}

@misc{etchegoyen2013device,
	author = {Etchegoyen, Craig S and Harjanto, Dono},
	date-modified = {2022-01-15 00:08:13 +0100},
	month = {May},
	note = {US Patent 8,438,394},
	publisher = {Google Patents},
	title = {Device-bound certificate authentication},
	year = {2013}}

@webpage{fowler2006continuous,
	author = {Fowler, Martin},
	date-modified = {2022-01-15 00:43:04 +0100},
	lastchecked = {15.01.22},
	month = {May},
	title = {Continuous integration},
	url = {https://www.martinfowler.com/articles/continuousIntegration.html},
	year = {2006},
	bdsk-url-1 = {https://www.martinfowler.com/articles/continuousIntegration.html}}

@article{eder2016hypervisor,
	author = {Eder, Michael},
	date-modified = {2022-01-15 00:27:45 +0100},
	journal = {Future Internet (FI) and Innovative Internet Technologies and Mobile Communications (IITM)},
	title = {Hypervisor-vs. container-based virtualization},
	volume = {1},
	year = {2016}}

@inproceedings{messina2016simplified,
	author = {Messina, Antonio and Rizzo, Riccardo and Storniolo, Pietro and Urso, Alfonso},
	booktitle = {The Eighth International Conference on Advances in Databases, Knowledge, and Data Applications (DBKDA)},
	date-modified = {2022-01-14 23:14:34 +0100},
	doi = {10.13140/RG.2.1.3529.3681},
	month = {June},
	pages = {35--40},
	title = {A Simplified Database Pattern for the Microservice Architecture},
	year = {2016},
	bdsk-url-1 = {https://doi.org/10.13140/RG.2.1.3529.3681}}

@webpage{beck2001manifesto,
	author = {Beck, Kent and Beedle, Mike and Van Bennekum, Arie and Cockburn, Alistair and Cunningham, Ward and Fowler, Martin and Grenning, James and Highsmith, Jim and Hunt, Andrew and Jeffries, Ron and others},
	date-modified = {2022-01-15 00:54:35 +0100},
	lastchecked = {15.01.22},
	title = {Manifesto for Agile Software Development},
	url = {https://agilemanifesto.org/},
	year = {2001},
	bdsk-url-1 = {https://agilemanifesto.org/}}