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

Microservice Transition and its Granularity Problem: A Systematic Mapping Study

Microservices have gained wide recognition and acceptance in software industries as an emerging architectural style for autonomic, scalable, and more reliable computing. The transition to microservices has been highly motivated by the need for better alignment of technical design decisions with improving value potentials of architectures. Despite microservices' popularity, research still lacks disciplined understanding of transition and consensus on the principles and activities underlying "micro-ing" architectures. In this paper, we report on a systematic mapping study that consolidates various views, approaches and activities that commonly assist in the transition to microservices. The study aims to provide a better understanding of the transition; it also contributes a working definition of the transition and technical activities underlying it. We term the transition and technical activities leading to microservice architectures as microservitization. We then shed light on a fundamental problem of microservitization: microservice granularity and reasoning about its adaptation as first-class entities. This study reviews state-of-the-art and -practice related to reasoning about microservice granularity; it reviews modelling approaches, aspects considered, guidelines and processes used to reason about microservice granularity. This study identifies opportunities for future research and development related to reasoning about microservice granularity.Comment: 36 pages including references, 6 figures, and 3 table

Developing A Multi Application Real-Time Platform Using Cloud Serverless Technologies

Magycal Interactive is a software company that has produced a significant impact in the Portuguese television sector. Magycal is Magycal Interactive’s cloud based server-side framework that was developed to standardize common services (chats, polls, authentication) provided by applications such as Viva Ronaldo, Secret Story e SPORT TV Digital Hub. As popularity and success of each application increases, Magycal becomes more technically outdated. Its monolithic architecture, which previously allowed for easy development is becoming a development bottleneck. Scaling the server is increasing in cost as the platform grows, and developing updates and new features is more difficult since services are becoming more tightly coupled with each release. In this work, we propose an architectural shift for Magycal where we decouple services for better scalability, development and deployment. After a study of existing architectural options, we have concluded that the most suitable candidate architecture that meets the demands of Magycal is the microservices architecture. To test our hypothesis and determine the feasibility of the architectural change, we have selected a service of Magycal that was implemented following a microservice-oriented design. Our implementation was validated via API calls to ensure the modifications maintained correct behavior of the framework. The new service had its implementation benchmarked and compared to the corresponded Magycal existing service. We concluded that the changes to Magycal yield a more robust framework with reduced costs of maintaining, development and deployment.A Magycal Interactive é uma empresa de software que produz um impacto significativo no setor televisivo português. Magycal é a plataforma servidor da empresa na cloud desenvolvida para padronizar serviços comuns (canais de conversa, votações, autenticação) fornecidos por aplicações como Viva Ronaldo, Secret Story e SPORT TV Digital Hub. À medida que a popularidade e o sucesso de cada aplicação aumenta, o Magycal tornase tecnicamente mais desatualizado. A sua arquitetura monolítica, que anteriormente permitia desenvolvimento fácil, torna-se um problema. O custo de escalabilidade do servidor está a aumentar à medida que a plataforma cresce, e o desenvolvimento de atualizações e novos recursos é mais difícil, pois os serviços tornam-se mais fortemente acoplados a cada nova versão. Neste trabalho, propomos uma mudança de arquitetura para o Magycal, onde dissociamos os serviços para melhor escalabilidade, desenvolvimento e deployment. Após um estudo das opções arquiteturais existentes, concluímos que a arquitetura candidata mais adequada às necessidades do Magycal é a arquitetura de microserviços. Para testar nossa hipótese e determinar a viabilidade da mudança arquitetural, selecionamos um serviço do Magycal que foi implementados seguindo um design orientado a microsserviços. A nossa implementação foi validada com chamadas API para garantir que as modificações mantiveram o comportamento correto da estrutura. O novo serviço teve a sua implementação medida e comparadas ao serviço existente no Magycal. Foi concluído que as mudanças no Magycal produzem uma estrutura mais robusta, com custos reduzidos de manutenção, desenvolvimento e implementação

Microservice-Based Integration Framework for a Back-Office Solution

Dissertação de Mestrado em Engenharia InformáticaNot long ago, monolithic applications ruled among production servers – these applications had massive scopes which made them difficult to maintain, with constraints of libraries shared between modules and where every change or update is attached with big downtimes. To stray from this approach, enterprises chose to divide their big applications into smaller ones with fewer responsibilities, a clearer notion of boundaries and for the better part of it, more maintainable and scalable. The microservice approach allows enterprises to better divide themselves among teams that follow the full stack and spectrum of development in each application, from the persistence layer through the API and to the client, and from planning, through development to later support. The project exposed in this paper enlightens the scenario of an e-commerce platform’s back-office - where the implementation of a strangler pattern divided a large monolithic application into smaller microservices – leaving the door open for the integration of the multiple client applications to interconnect. The proposed solution intends to integrate the various systems of Jumia and take on this exposed opportunity, resorting to a microservice architecture and integration patterns with the objective of easing the flow of operations for processes that involve several management tools.Recentemente, o desenvolvimento de aplicações mudou à escala mundial, os sistemas distribuídos permitiram a introdução de um novo paradigma. Este paradigma baseia-se na redução de uma grande aplicação (monólito) em pequenos sub-módulos (micro-serviços) que comunicam perfeitamente entre si como se de uma única aplicação se tratasse. Este paradigma veio também refrescar as estruturas internas das empresas, ao distribuir os diversos serviços entre equipas, de forma a que cada uma delas esteja presente em todo o ciclo de vida das aplicações, desde o conceito até ao lançamento, passando pelo desenvolvimento e posterior manutenção e suporte da mesma. As mesmas equipas são também responsáveis por toda a stack que cada micro-serviço contém partindo da user interface (UI), passando por toda a API que contém a lógica de negócio até à camada de acesso de dados. Esta nova abordagem oferece algumas vantagens quando comparada com outras soluções disponíveis no mercado, tais como a liberdade de cada um dos serviços em ser desenvolvido nas tecnologias e linguagens que melhor se adequam ao seu propósito, sem que estejam presas a uma decisão tomada numa ocasião anterior para um propósito diferente ou a restrições de dependências incompatíveis entre si. Sendo que um dos principais problemas da computação distribuída é a possível indisponibilidade de cada um dos seus intervenientes, a arquitetura orientada a micro-serviços (microservice architecture, MSA) prevê que cada um dos seus serviços esteja contido no seu contexto (bounded context) e que disponha de todos os dados que lhe correspondem, desta forma a indisponibilidade de qualquer serviço não deve impactar o desempenho de nenhum dos seus pares. A reduzida dimensão de cada um destes serviços permite a existência de processos de deploy mais rápidos o que acaba por se refletir em downtimes mais reduzidos. Outra das vantagens da redução das dimensões e dos contextos de cada um dos serviços é a sua fácil manutenção, uma vez que o código se torna mais conciso e específico ao propósito que prevê cumprir. A modularidade dos micro-serviços permite-lhes também ajustar o número de réplicas de cada um deles de forma independente de acordo com as necessidades e previsões de volume de tráfego a cada momento. Apesar de todas as vantagens acima expostas, uma MSA traz consigo também alguns desafios tais como os testes de integração, debugging, deploying, retrocompatibilidade com outros serviços, entre outras abordadas em maior detalhe neste documento. O projeto exposto neste documento é um projeto proposto pela Jumia, uma empresa que disponibiliza uma plataforma de comércio online no continente africano. Esta plataforma está disponível em onze países africanos com mais de cem armazéns espalhados por todo o continente e que conta com mais de cinco mil colaboradores espalhados pelo mundo. Tal como muitas outras empresas no mercado a Jumia idealizou os seus processos de operações numa aplicação única que controlava todos os fluxos de negócio e continha em si toda a informação de armazenamento, produtos, entregas, pagamentos, encomendas entre outras. Rapidamente a aplicação de back-office da Jumia tornou-se insustentável e, tal como tinha sido executado noutras empresas do mesmo ramo, foi implementado um strangler pattern. Desta forma tornou-se possível fazer uma separação de dependências gradualmente, isolando cada um dos processos de negócio num serviço independente que persiste todos os dados necessários para a execução de cada uma das operações. No entanto, a implementação deste padrão deu origem a uma lacuna nos processos da empresa, uma vez que cada um dos serviços possui o seu user interface, algumas das operações requerem que os agentes de operações transitem entre aplicações, e necessitem de se autenticar novamente. Este processo acaba por ter impacto no fluxo de operações, refletindo-se no número de encomendas processadas e por consequência nas receitas da empresa. O presente documento pretende explorar a oportunidade de negócio proposta, assim como os mais essenciais padrões de integração de micro-serviços, de forma a apresentar uma solução que consiga colmatar a lacuna apresentada sem pôr em causa a segurança das aplicações e as normas de conformidade exigidas. Esta proposta foi elaborada através da conceção de uma arquitetura orientada a micro-serviços de forma coreografada tendo como objetivo ser integrada nas diversas aplicações de Back-Office com recurso a uma biblioteca importada através do gestor do Node Package Manager

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