Architecture based on microservices
29.07.2019 - Read in 3 min.
More and more often, we come across publications describing its adaptation in the process of software development, where it solved problems or even provided additional benefits. Is this the right direction when choosing an architecture for your app?
Architecture based on microservices becomes increasingly popular. More and more often, we come across publications describing its adaptation in the process of software development, where it solved problems or even provided additional benefits. Is this the right direction when choosing an architecture for your app?
What are microservices and where did they come from?
In order to understand the microservice-based architecture better, we have to define an individual service.
Microservice is standalone software that provides business functionality. The word “standalone” is the key, as it means that the service can be deployed, maintained, and developed independently from the remaining parts of the system. Readymade software comprising microservices can be combined just like LEGO blocks – to create new modules or using previously saved components, open source solutions, or paid services in the SaaS model.
There are some characteristic features of a service oriented architecture (SOA) – the app is divided into services, and their components are able to communicate with one another. However, in microservice architecture services are also loosely coupled, which means that they can function even when a part of them is unavailable, and the user should not experience unavailability of the entire system.
Pros and cons
This approach brings new possibilities in the area of software development. One of the most appealing ones is the increase of the number of developer teams participating in the project that can work almost independently to deliver business functionalities. Which means that the client’s requirements are met faster. Depending on a given task, services can be created in various, the most appropriate technologies. They can be deployed independently, with no impact on the operation of the entire system, which shortens the time for delivering functionalities and reduces software development costs. Services can be independently scaled, which enables better use of resources and cost management, as only a required part of the system is scaled.
Service-oriented architecture does not only offer multiple advantages. This selection comes with consequences, which can result in serious challenges in software development, especially for those unexperienced in this field. Higher number of services impacts the time required for the development, testing, and deployment of apps. Another factor is connected with managing the infrastructure in which our software will be run, deployed, and scaled. Using message brokers, transactions, service monitoring, and defining the scope of functionalities within a selected service – these are only a few aspects of building software this way. Therefore, apart from developers also new roles emerge – devops or solutions architects, or maybe the former is more of a culture supporting the process of software development in this architecture.
Microservice architecture as a perfect solution for everybody?
The goal of this text is to present what microservice architecture is, along with its main advantages and disadvantages. This architecture, often presented as a miracle solution to all problems, offers many advantages. It. also adds new challenges that need to be faced. The selection or change of architecture should be an informed decision, based on real needs e.g. resulting from the need for ensuring high availability or fast realisation of business requirements.
Are microservices good for everybody? Not necessarily. If you’re limited by the size of developer teams (e.g. you have one small team of 3-4 people, and there are no plans for increasing employment in this area). It may so happen that the workload connected with developing software in this architecture does not balance the advantages described above. Similar situation may occur when you build a solution that you plan to market as soon as possible in order to throw the product at a potential client. In case of new ideas, the number of changes in the operational framework of application may be so high that the architecture will cause more trouble than it is worth. Also, I would not recommend selecting microservices to those unexperienced in developing apps in this architecture.