What is a microservices architecture?
This software development method focuses on flexibility - but how does it work?
There has been a growing trend within software development over the past few years, moving away from traditional development methods towards newer techniques that are better suited to the modern IT landscape. The use of microservices, alongside containers and cloud infrastructure, is one such trend.
A microservices architecture, in short, is a form of application infrastructure which is based on splitting the application's functions up into multiple different, self-contained units and then combining those units to achieve the desired result. Let's say, for example, that you wanted to build a simple app that controlled an appliance's power when you sent a text containing 'on' or 'off' to a specific device.
In a traditional 'monolithic' application, all of these functions would be coded as part of a single cohesive codebase. In a microservices architecture, this app would be comprised of three separate microservices: one to receive and process the text message, one to interpret the content of the message, and one to trigger the appliance to turn on or off depending on the interpretation.
The beauty of a microservices architecture is that these components are not inherently dependent on each other, and are independently deployable. If one needs to be changed - for example, if you want to trigger the application with a tweet instead of a text - you can simply swap out the relevant component without having to recode the whole application.
This approach directly contrasts with monolithic applications, where every component is wrapped up into one package, and changes require the entire application stack to be modified and redeployed. Trying to change any of the components in a monolithic application is like baking a cake and then trying to take the egg out of it afterwards.
How do microservices work?
Microservices architectures are almost universally deployed in conjunction with containers. Much like microservices themselves, containers are small, self-contained packages that hold the minimum amount of libraries needed to execute their particular function, operating independently of the other containers around it.
Because they're built to be small, easily modifiable and self-contained, containers are the perfect way to host microservices, but you'll need an orchestration layer to manage all of the containers within your environment. Kubernetes has established itself as the tool of choice within most organisations, but a multitude of options are available.
While microservices exist and run independently of the rest of an application, they still need to communicate with other services within the application in order for the application to carry out its intended function. This is achieved by APIs, which allow different microservices to communicate and pass instructions between each other. HTTP and REST are commonly used for this task.
Benefits of microservices
We've already highlighted some of the advantages of microservices architectures, but there are a number of reasons why they've become so popular. Stability is a key one; not only are components easy to swap out when they need to be modified or replaced, but the failure of one microservice may not even have a noticeable impact on the application's performance. This will depend on the function being performed by the microservice, of course, but the failure of a non-essential component in a microservices architecture will often break a specific function, rather than the application as a whole. This also makes it easy to identify issues in the processing chain.
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 with an IT organisation can be working on different microservices within the application at the same time. 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.
Containers are re-usable, too. If you have two applications that require the same function to be performed, you can create one microservice to do it and copy it across both applications. Another benefit is the fact that, because they're self-contained, microservices can be coded in any programming language.