In the recent years, microservice architecture has emerged as a popular method for building software. It develops software as an organized set of independent and modular services, where every service having specific function, interacts with one another through a well-established and lightweight procedure like Protobuf, HTTP/REST along with JSON.
Traditionally, software was developed by putting together and testing the entire app as a monolith. The major challenge to the monolith-approach was the lack of independence to individual services. Whenever a minor change had to be brought about, the entire app had to go through testing again. This issue is resolved in the microservices approach, where modules are built and run independently along with a well-setup API. Thus, an app could be delivered without delays, as changes could be progressively introduced without destabilizing the entire application.
Every software development approach comes with a series of benefits and challenges. The task of any team is to choose an approach which would sync with the nature of their app. The advantage of picking the microservices approach is that it brings together the best strategies of software design: componentization through services, smart end-points, architecture automation and evolutionary development. However, the amount of expertise required in microservices might put off some companies.
Here are five principles which qualify an approach as microservices:
- Functional Completeness: Microservices approach stands out in the software-development world for being functionally integrative. Every microservice carries out its function with low dependency on the other services within the application. This allows to smoothly upgrade and shift versions of the services alone. In his book “Microservices from Day One: Build robust and scalable software from the start”, Cloves Carneiro and Tim Schmeler comment on this feature pointing out: “An API needs to be able to fulfill its raison d’être; the functionality you advertise to be properly implemented.”
- Integrative, yet Independent: A microservice integrates within the app, yet independently operational. The aim of any software design approach in case of a service failing is to keep up stability of the app. This becomes possible with microservices approach.
- High Cohesion: A microservice has smooth functioning amongst its components! Cohesion is defined as the degree to which components in a system can be synced with one another. A module has high cohesion in case all the components contained in it can work together for carrying out a particular task. Since a single microservice is oriented to finish only one specific task, the design is considered to follow Single Responsible Principle (SRP). When the microservices are cohesive, there is higher performance in the app.
- Scalable: A microservice can scale depending on load and other demands, independent of other services! Depending on the performance, resource use and availability of your application, the microservice must be able to scale up or down. The common method for implementing scalability is by creating the system such that many stateless instances can be run, of each microservice. This is accompanied by a procedure for naming the service, for registering it and for discovering it (apart from load-balancing of the requests and routing).
- Uniform Interface: A microservice has APIs which share the common design of detection, representation and handling of resources! A microservice with uniform interface is guided by the following four principles: identifying of resources, manipulation of such resources through representations, self-descriptive messages and hypermedia as engine of application state (HATEOAS). This constraint allows us to characterize the interface between servers and clients.
Resources are generally identified through URIs in requests. If a client carries representation of a resource, then this can be used to remove or alter the resource on the server. Every message has adequate information which instructs one the method of processing the message. HATEOAS is a short way of referring to hyperlinks within the hypertext. While clients send across state through body-content, request headers, query-string parameters and requested URI, the services deliver states through response codes, body content and response headers. Write to us back with your comments on this blog.
Related blog:
How do enterprises benefit from Microservices Architecture?
