Microservices architecture is a type of application infrastructure that separates the functions of an application into smaller, self-contained parts, which can then be reused for other purposes.
To explain, picture an application that is made to enter an active state when it receives an SMS message. Within traditional application development, every aspect of its function is coded as part of one central codebase.
However, under microservices architecture, the three main functions of the app are instead split into three: one that's designed to receive SMS messages and process them, one created to interpret the content of messages, and one more built to take this interpretation and initiate a command of 'on' or 'off'.
Because each component of the overall application is working independently of the rest, they can be deployed, updated, or replaced without having to rebuild the entire product. In the above example, it would allow you to change what happens when an SMS is received without having to rewrite the function that detects them, or change the application to activate when an email is received instead.
The same is not true for 'monolithic' applications, which have to be rewritten as an entire unit in order to add or remove features, or apply updates.
How do microservices work?
Many firms that deploy microservices architecture use containers to house the individual functions as described above. Each container is its own self-contained unit of software, within which lies the necessary libraries and functions to ensure it can carry out its designated task regardless of its surrounding environment.
Containers are a very helpful way for a development team to make microservices architecture a reality, due to their versatility and small size compared to virtual machines (VMs).
It is typical for administrators to maintain oversight of these containers through Kubernetes, a popular tool for orchestrating multiple containers wherever they are deployed, and this can also be used to group containers and allocate resources depending on demand.
Although microservices can be established and run independently of the wider software application, it is still necessary for communication to be maintained across the application so that it works correctly. Application programming interfaces (APIs) are the chief route through which this form of communication can be established, as these allow microservices to pass commands between each other as and when required. HTTP and REST (representational state transfer) is normally used for this.
Benefits of microservices architecture
Achieving software health in the microservices age
Tips and tricks for the new and emerging remediation methods
The main benefit of microservices architecture is stability, with components being easy to exchange when they need to be modified or replaced. One microservice failing does not necessarily affect the performance of the wider ecosystem, with one function instead ceasing to work properly in a manner that can be identified and fixed with little overall impact.
Adopting this kind of architecture can also have benefits for the speed of development, too. Because functions within a microservices architecture are not interdependent, different teams within an IT organisation can be working on different microservices in the same application simultaneously. This means bug fixes and new features can be added faster, which is one of the reasons why DevOps and microservices often go hand in hand.
If a business chooses to use containers to deploy microservices, these can also be reused. This can free up resources that might otherwise be lost to application redundancy. Another benefit is the fact that, because they're self-contained, microservices can be coded in any programming language.
This article was first published on 23/09/19 and has since been updated
