Microservices: Considerations before implementation

Microservices is a relatively recent pattern in software architecture, but it is in wide use already and is used to develop the flagship products of some of the world’s most popular services, such as Netflix and Spotify. The pattern is evolving organically from the development practices so there is relatively little formal academic research on it. This thesis explains the benefits and potential risks of moving from a monolithic software architecture to a microservices architecture, in a manner understandable to non-developers. In a nutshell, microservices architecture breaks up large, monolithic software projects into small, discrete and modular ‘services’. The services can be developed separately, sometimes by different teams, and can be deployed independently of each other. Some key benefits are the possibility of using specialized tech stacks for different services, smaller and easier to understand codebases, improved productivity and collaboration between development teams and more robust and flexible systems. Microservices based software is also better suited to cloud computing, which can reduce infrastructure costs. However, this does not mean that all software projects should be microservices. There are situations in which a monolithic pattern has advantages. First and foremost, applying microservices effectively needs a certain degree of expertise, and since the trend is recent, qualified developers can be hard to find. It is also arguably easier to manage a monolithic architecture with a small team, at least in the beginning. Secondly, microservices architecture is said to move the complexity from the code base to the infrastructure. Microservices can be needlessly complex and expensive if the project isn’t meant to scale for many users or is a prototype or proof-of-concept.Tutkielman nimiössä ja tiivistelmässä näkyvät vuosi-merkinnät ovat epäselviä.The year entries showing in the title page and in the abstract of the thesis are unclear

Challenges When Moving from Monolith to Microservice Architecture

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.Peer reviewe

Implementation of Role-Based Access Control on OAuth 2.0 as Authentication and Authorization

As today’s technology transition from monolithic towards microservices architecture, the authentication and authorization system also becomes a new concern because of the difference between monolithic and microservices pattern. Monolithic mostly uses role-based access control while microservices uses scope with OAuth 2.0. With this in mind, there is a need for a model that can integrate OAuth 2.0 with role-based access control. With rolebased access control implemented on OAuth 2.0, we expect a simpler authorization process and a more secure authentication and authorization system for microservices backend architecture. This paper proposes a model to implement role-based access control on OAuth 2.0 using Laravel framework, we also test the performance of the system following by response time, data transferred and throughput. From the performance test, this approach has a good performance and can handle certain requests with simulated users even with limited resources

An In-Switch Architecture for Low-Latency Microservices

In recent time, there is has been a movement away from standard monolithic architecture in cloud and web services towards what is known as a microservice architecture. Microservice architecture decomposes the previous monolithic architecture into multiple independent services called "microservices". Examples of applications that use a microservice architecture include Netflix and Amazon. These applications typically send large numbers of microservice requests, which go through the OSI network layers to establish a client server connection. This trend towards microservices has developed interest by other researchers to make improvements in this field, due to the growing reliance importance on such architectures by consumers. There have been studies regarding the security of these microservices, performance analysis of various applications, and the use of these microservice applications in cloud technology. Any improvements in the speed, security, or organization of such network architecture would be very beneficial of these popular API's, and their user base. This project's objective is to investigate the potential of moving some of the processing that is done for these microservices within a network switch, and as a result the performance at the application level, by alleviating network communication. We formulate a high-level design for an in-switch architecture for low-latency microservice leveraging existing programmable-switches support. We investigate the implementation of NetCache as a microservice in our model and predict a significant latency reduction and subsequent performance increase

The OpenDC Microservice Simulator: Design, Implementation, and Experimentation

Microservices is an architectural style that structures an application as a collection of loosely coupled services, making it easy for developers to build and scale their applications. The microservices architecture approach differs from the traditional monolithic style of treating software development as a single entity. Microservice architecture is becoming more and more adapted. However, microservice systems can be complex due to dependencies between the microservices, resulting in unpredictable performance at a large scale. Simulation is a cheap and fast way to investigate the performance of microservices in more detail. This study aims to build a microservices simulator for evaluating and comparing microservices based applications. The microservices reference architecture is designed. The architecture is used as the basis for a simulator. The simulator implementation uses statistical models to generate the workload. The compelling features added to the simulator include concurrent execution of microservices, configurable request depth, three load-balancing policies and four request execution order policies. This paper contains two experiments to show the simulator usage. The first experiment covers request execution order policies at the microservice instance. The second experiment compares load balancing policies across microservice instances.Comment: Bachelor's thesi

Building scalable digital library ingestion pipelines using microservices

CORE, a harvesting service offering access to millions of open access research papers from around the world, has shifted its harvesting process from following a monolithic approach to the adoption of a microservices infrastructure. In this paper, we explain how we rearranged and re-scheduled our old ingestion pipeline, present CORE's move to managing microservices and outline the tools we use in a new and optimised ingestion system. In addition, we discuss the ineffciencies of our old harvesting process, the advantages, and challenges of our new ingestion system and our future plans. We conclude that via the adoption of microservices architecture we managed to achieve a scalable and distributed system that would assist with CORE's future performance and evolution