Fulltext available Open Access
DC FieldValueLanguage
dc.contributor.advisorvon Pilgrim, Jens Henning-
dc.contributor.authorŠkoric, Ante-
dc.date.accessioned2024-08-21T08:01:19Z-
dc.date.available2024-08-21T08:01:19Z-
dc.date.created2022-01-01-
dc.date.issued2024-08-21-
dc.identifier.urihttps://hdl.handle.net/20.500.12738/16176-
dc.description.abstractMicroservices und Serverless Deploymentstrategien unterscheiden sich in vielerlei Hinsicht. Bei Serverless kümmert sich der Cloud-Anbieter um die Skalierung und bietet zusätzliche Resilience. Im Gegensatz dazu müssen bei der containerbasierten Microservice-Anwendung die Container mithilfe eines Container-Orchestrierungssystems skaliert werden. In dieser Arbeit wird folgende Fragestellung beantwortet: ”Wie unterscheiden sich die Performance (Skalierbarkeit, Resilience und Cloud Latency) und Kosten zwischen einer Serverless-Deploymentstrategie mit AWS Lambda und einer containerbasierten Microservices-Deploymentstrategie mit Docker und Kubernetes?” Durch die Beantwortung dieser Forschungsfrage ergeben sich Use Cases, in denen die eine Deploymentstrategie der anderen vorgezogen werden kann. Zur Beantwortung der Fragestellung wurden Performance-Tests durchgeführt und eine Kostenberechnung vorgenommen. Dies geschah anhand von zwei verschiedenen Use Cases, einer event-driven Reporting-Anwendung und einer Employee-Time-Sheet-Management-Portal-Anwendung. Für die Implementierung und das Deployment der Serverless-Anwendungen wurde AWS Lambda verwendet, für die Microservice-Anwendungen wurden Docker und Kubernetes eingesetzt. Die durchgeführten Experimente zeigen, dass beide Deploymentstrategien Vor- und Nachteile aufweisen. Die Nachteile der Microservices-Deploymentstrategie bestehen darin, dass sie unter den Load-Balancing- und Trafficverteilungs-Problemen leidet und die Skalierbarkeits- und Ressourcen-Konfiguration ”aufwendiger” ist als die von Serverless. Die Vorteile sind, dass sie im Vergleich zu Serverless eine bessere Requestsbearbeitungsleistung bietet. Der Nachteil der Serverless-Deploymentstrategie ist der, dass sie unter dem Problem des Cold-Starts leidet. Die Vorteile sind, dass sie agiler in Bezug auf Skalierbarkeit als die Microservices-Deploymentstrategie ist und dass sie bei den Anwendungen mit geringem Traffic weniger Kosten verursacht. Aus diesen Erkenntnissen ergeben sich auch Use Cases, in denen die eine Deploymentstrategie der anderen vorgezogen werden kann. Die Microservices-Deploymentstrategie eignet sich für Real-Time-Data-Processing- Anwendungen und Anwendungen, bei denen es auf Bruchteile von Sekunden ankommt. In Gegenteil dazu eignet sich die Serverless-Deploymonetstrategie für die Anwendungen mit Traffic-Schwankungen, Job-Scheduler und automatisch skalierbare APIs. An dieser Stelle ist es wichtig, darauf hinzuweisen, dass die Empfehlungen anhand der Kriterien aus dieser Arbeit gemacht worden sind und keine weiteren Kriterien berücksichtigt wurden. Bei der Auswahl einer Deploymentstrategie in der Praxis sollten auch andere Kriterien, die in dieser Arbeit nicht behandelt wurden, berücksichtigt werden.de
dc.description.abstractMicroservices and serverless deployment strategies differ in many ways. With serverless, the cloud provider takes care of scaling and provides additional resilience. In contrast, with the container-based microservice application, the containers must be scaled using a container orchestration system. In this work, we answer the following research question: ”How do performance (scalability, resilience, and cloud latency) and cost differ between a serverless deployment strategy using AWS Lambda and a container-based microservices deployment strategy using Docker and Kubernetes?” By answering this research question, use cases emerge where one deployment strategy may be preferred over the other. To answer the research question, performance tests were conducted and a cost calculation was performed. This was done using two different use cases, an event-driven reporting application and an employee time sheet management portal application. AWS Lambda was used to implement and deploy the serverless applications, and Docker and Kubernetes were used for the microservice applications. The experiments conducted show that both deployment strategies have advantages and disadvantages. The disadvantages of the microservices deployment strategy are that it suffers from the load balancing and traffic distribution issues. Scalability and resource configuration is also ”more complex” than that of serverless. The advantages are that it provides better request handling performance compared to serverless. The disadvantage of the serverless deployment strategy is that it suffers from the cold start problem. The advantages are that it is more agile in terms of scalability than the microservices deployment strategy and it incurs less cost for the low traffic applications. From these findings, use cases (recommendations) emerge in which one deployment strategy may be preferred over the other. The microservices deployment strategy is suitable for real-time data processing applications and applications where fractions of seconds matter. In contrast, the serverless deployment strategy is suitable for the applications with traffic fluctuations, job schedulers and automatically scalable APIs. At this point, it is important to point out that the recommendations have been made based on the criteria from this work and no other criteria have been considered. When selecting a deployment strategy in practice, other criteria not covered in this work should also be considered.en
dc.language.isodeen_US
dc.subjectMicroservicesen_US
dc.subjectServerlessen_US
dc.subjectContaineren_US
dc.subjectPerformanceen_US
dc.subjectScalingen_US
dc.subjectResilienceen_US
dc.subjectContainer Orchestrationen_US
dc.subjectKubernetesen_US
dc.subjectAWS Lambdaen_US
dc.subjectClouden_US
dc.subjectCloud Native Computingen_US
dc.subjectKafkaen_US
dc.subjectClient-Reportsen_US
dc.subject.ddc004: Informatiken_US
dc.titleRealisierung und Gegenüberstellung einer serverless und einer containerbasierten Microservice-Architektur für das Client-Reportingde
dc.typeThesisen_US
openaire.rightsinfo:eu-repo/semantics/openAccessen_US
thesis.grantor.departmentDepartment Informatiken_US
thesis.grantor.universityOrInstitutionHochschule für Angewandte Wissenschaften Hamburgen_US
tuhh.contributor.refereeSarstedt, Stefan-
tuhh.identifier.urnurn:nbn:de:gbv:18302-reposit-191971-
tuhh.oai.showtrueen_US
tuhh.publication.instituteDepartment Informatiken_US
tuhh.publication.instituteFakultät Technik und Informatiken_US
tuhh.type.opusBachelor Thesis-
dc.type.casraiSupervised Student Publication-
dc.type.dinibachelorThesis-
dc.type.driverbachelorThesis-
dc.type.statusinfo:eu-repo/semantics/publishedVersionen_US
dc.type.thesisbachelorThesisen_US
dcterms.DCMITypeText-
tuhh.dnb.statusdomainen_US
item.advisorGNDvon Pilgrim, Jens Henning-
item.creatorGNDŠkoric, Ante-
item.languageiso639-1de-
item.cerifentitytypePublications-
item.openairecristypehttp://purl.org/coar/resource_type/c_46ec-
item.creatorOrcidŠkoric, Ante-
item.fulltextWith Fulltext-
item.grantfulltextopen-
item.openairetypeThesis-
Appears in Collections:Theses
Show simple item record

Page view(s)

69
checked on Nov 23, 2024

Download(s)

55
checked on Nov 23, 2024

Google ScholarTM

Check

HAW Katalog

Check

Note about this record


Items in REPOSIT are protected by copyright, with all rights reserved, unless otherwise indicated.