Five Most Common Questions About Microservices

Here are five frequently asked questions about microservices that you need to ask yourself before you embark on an adventure called developing an app based on microservice architecture. Of course, I suppose you know what an app based on microservice architecture is: an application that is designed as a set of loosely related services that implement application functionality and are independently developed and independently implemented, communicate over a network with a well-defined and standardized protocol (usually HTTP). Microservices provide an encapsulation of functionality and data that the rest of the application sees as a unit without the knowledge how that unit has been implemented and how it works. 

Bear in mind this text is written from the perspective of someone who deals primarily with DevOps and DevSecOps, and comes from the Ops world. Details regarding the use of the best library or environment for the development of microservices are not subject to this text.  

Note: The text expresses ‘microservice’ and ‘service’ as synonyms. The term ‘microservice’ is a bit of a misnomer because it implies that there is a ‘service’ that is significantly larger than ‘microservice’. In reality, there is no point where ‘service’ turns into ‘microservice’ and vice versa. 

How To Know If Microservice Is The Best Way To Build An App 

Microservices bring a number of advantages when creating an app: 

• You can break a complex application into smaller pieces and then develop those parts independently and in parallel almost as standalone applications. Of course, it is necessary to define the way in which microservices will talk to each other, but after that the implementation of specific microservice itself is a responsibility of its dev team – they determine the algorithms, the structure of the data, which database they will use, which programming language will be used, etc. 
• Microservices can be independently deployed and updated, most often without affecting the rest of the application, enabling continuous operation of the rest of the application while the specific microservice is updated. 

• The development of the entire application is accelerated, implementation of modifications and new functionality is easier since automation through DevOps/DevSecOps technologies is at the core of microservices. 

But nothing is for free, including microservices. This kind of architecture also brings some additional complications that often become a source of problems: 

• The basic idea of microservice architecture is to develop independently of each other, usually in parallel, by small teams of developers. But small teams of developers times the number of microservices equals quite a number of people working on a microservice-based app. 
• Microservices run independently from each other, which requires network communication. Network communication is significantly slower than communication between parts of a monolithic application so an intrinsic network communication delay can significantly impact the responsiveness of your application. 
• In theory, microservices implement Single Responsibility Principle (SRP), which is one of the essential elements of SOLID architecture. However, updating the existing service or introducing of a new service that would be uniquely responsible for the given functionality can easily lead to the build-up of services and create a complicated connection mesh between them that increases the complexity of the whole system. 

• Each microservice requires to be isolated and separated from other microservices which significantly complicates the implementation of the entire system. 

So, how do you know if microservice architecture is the right solution for you? If your app is initially very complex, with a bunch of different functionalities, and, perhaps most importantly, for which you expect to grow both in size (by adding new functionalities) and by the number of users, then it makes sense to think about using the microservice approach in the design of your new app. But if your app isn’t that complex and you have a small team and relatively limited means to start with, it might be better off starting with monolithic architecture as it reduces the cost of development and the initial cost of exploitation. If the application starts to grow, then there will be a need to refactor the existing monolithic application into micro-service architecture which in practice has proved to be a better and cheaper solution than to immediately start using microservice architecture. 

Should Smaller Companies And Start-ups Use Microservices? 

This question is related to the previous one – whether to move with microservice architecture at all. As I said, it all depends on what happens to your app in the future. If you assume that the app will certainly become more complex, get new functionality and frequently update existing functionality, become critical to the whole business (which implies that downtime has to be minimal) then it makes sense to start with microservices. 

But again, even though all start-ups want to create their own services/apps to serve the global market, that’s not going to happen with the most of them and, because of the lower initial investment, it’s better to start with a monolithic app that’s well designed and can scale up and out rather than go with microservices from the start. With some luck, the start-up business will grow so much that, at some point in time, the limitations of monolithic architecture will becume a problem, in which case it will be necessary to refactor that application into microservice architecture. But in that case the small company or a start-up will already grow enough that they are no longer a small company or a start-up so they will be able to afford the costs of refactoring and, thus, enable further grow. 

What Determines The Ideal Size Of A Microservice? 

Logic dictates that the application be split into basic services that apply SRP. So, by the definition of SRP,  the service must have only one reason to change. Example: The service that creates and prints reports can be changed because the contents of the report need to be changed or the report format needs to be changed. The theory requires that, in this case, this service should be broken down into two smaller services — one that creates the contents of the report, and the other that formats the specified content into the requested format. 

Microservices must be ‘smart’, because ‘stupid’ tubes are used for connections between microservices (‘stupid’ tubes equals less latency and logic has to be implemented somewhere). The more services there are, the more connections between them has to be established and that becomes the app’s narrow point. For this reason, the decision to determine what is right size and complexity of the microservice lies on the shoulders of the system’s chief architect and his experience. Unfortunately, there is no formula that can help with this decision. 

What Is The Role Of Containers In Microservices? 

Each microservice should be isolated, should have its own data storage system, and should have the ability to scale independently. This means that the microservice requires its own isolated environment which is achieved by some kind of virtual machine. However, since services are generally small in size, the use of the standard, ‘fat’ virtual machine would be excessive, both from the point of resources they require and the point of starting a new service instance when needed. For this reason, the most optimal solution for deploying microservices are containers. Containers provide optimal resource usage and startup speed, and container management systems can provide some functionality of the shelf that is necessary for microservices, like service discovery and API gateways.  

In addition, containers provide testing and deployment automation that is essential for microservice architecture. 

How Is The Security Of Microservices Achieved? 

Microservices bring additional security challenges compared to monolithic architecture because, basically, they increase the attack surface that must be defended. Separating the app into smaller, independent parts that communicate over the network brings a fundamental problem that the microservice must reliably verify who is on the other side of the communication channel. In the case of monolithic applications, this problem does not exist because communication between parts of the application is completely internal. 

The key thing for designing applications based on microservice architecture is that system security must be taken into consideration since the design phase. Communication channels must ensure that the parties that communicate can be reliably authenticated and authorised without increasing the complexity of the communication protocol itself. The principle of ‘defence in depth’ needs to be applied to establish layers of protection around specific microservice. DevSecOps tools need to be included in the continuous development in order to detect bugs in code and deployment.  

Conclusion 

This article should help you determine whether it is cost-effective to start an adventure called microservicel architecture, as well as avoid some major problems with the implementation of microservices. As you may have noticed, microservicel architecture is not the ideal solution to all problems, but on the right occasion, it is the most optimal solution that can bring you a lot of benefits.