Microservices is an approach to software development that has seen a rising tide of interest over the last decade, going hand-in-hand with other trends such as cloud-native, agile development, and, most notably, the use of containers for deploying software components.
The adoption of microservices has been increasing over the past several years. A survey carried out by O’Reilly in 2020 of over 1,500 organizations found that only about a quarter was not using microservices at all. Of the 75%, only about 10% had been using them for more than five years, meaning the majority have taken the plunge with microservices during the past few years.
Microservices is not a specific technology but a software architecture style and an approach to designing applications and services. Instead of creating an application as a single monolithic entity, the microservices process breaks down the required functionality into a collection of more minor, independently deployable services that communicate with each other.
This approach has several advantages; one is more effortless scalability, as the individual components can be scaled independently. Only the parts of the application that might be experiencing high demand, for example, need to be mounted, typically by starting up new instances of that component to balance the workload rather than scaling the entire application.
Microservices also lend themselves to an agile development process because the smaller parts make continuous improvement easier and faster updates to the code. Because the pieces are small, it makes it easier for developers to understand the code, which can knock on reliability. It also allows different programming languages for various components, as some languages may be better suited to specific tasks.
Another advantage is the potential to reduce downtime through better fault isolation. If a single microservice instance fails, it is less likely to bring down the entire application or service.
Potential disadvantages
While there are advantages to a microservices approach, there are also some downsides that organizations need to consider. For example, although the development of each microservice component might be more straightforward, the application or service in its entirety might become more complex to manage.
This is especially so with the deployment of any scale, which might involve dozens or hundreds of individual instances of different microservice components. The complexity comes not just from managing the communication between all these separate instances but monitoring each to ensure they operate within expected parameters and do not consume more resources than they would typically require, which may indicate a problem.
Testing and debugging may also become more of a challenge with microservices simply because tracing the source of a bug can be more difficult among a web of microservice instances, each with its own set of logs. Testing the entire application can also be tricky because each microservice can only be adequately tested once all the dependent services have been tested.
In particular, monitoring is more critical in a microservices deployment, but the distributed nature of the components makes it more complex than traditional applications, which are largely self-contained. The monitoring system has to operate at the level of each microservice instance while at the same time keeping an eye on the web of dependencies between the different components.
The way that microservices operate also has implications for the organization’s infrastructure. Supporting automatic scaling to meet increased demand implies that resources for new microservice instances must be capable of being provisioned by application programming interface (API) calls, which means a certain level of cloud-like, software-defined infrastructure.
Data can be another thorny issue when building an application or service based on a microservices architecture or, more precisely, where to store data. Each microservice instance is likely to have its own data store, but some applications may call for the ability to access a shared repository. Different services will also have additional data storage requirements, with some in the industry saying that a NoSQL database makes the most sense. In contrast, others advocate sticking to SQL if the organization has already deployed that way.
There are other differing opinions on this issue, with some experts advising that a single database (but not perhaps a single schema) shared by multiple services is the best approach because, for one thing, it allows organizations to reuse the procedures they have in place for database backup and restore. Others advise against this because it creates a potential single point of failure against the microservices ethos.
Plan carefully
This all means that the microservices architecture may not suit every organization or every type of application. However, the reasons behind its growing adoption are that microservices make it easier to implement a more agile approach to deploying services, which many organizations are now seeking.
“Organisations going down the microservices route tend to be more cutting-edge than the rest,” says independent analyst Clive Longbottom. “As such, they will also tend to be more open to thinking of what a move to a new architectural topology needs. Historically, most changes have been evolutionary: successful microservices architectures are revolutionary, requiring a complete rethink of what is being done.”
In other words, microservices might be more suitable for a “greenfield” deployment built from scratch rather than organizations trying to refactor or update an existing application.
As already noted, Docker-style software containers are a technology that has become associated in the minds of many with microservices. However, they are just one way of implementing a distributed deployment such as microservices. Other courses might include lightweight virtual machines or deploying microservice instances as non-virtualized code running in a server environment, just like everyday applications. Serverless computing functions would be another way of implementing microservices.
Containers are better suited than virtual machines because they are less resource-heavy, and spawning a new container instance is much quicker than spinning up a new virtual machine. Containers are now a relatively mature technology with a broad ecosystem of tools to support orchestration (such as Kubernetes), communications (Istio), and monitoring.
Interestingly, the O’Reilly survey found that a higher-than-average proportion of respondents who reported success with microservices chose to instantiate them using containers, while a higher proportion of respondents who had described their microservices efforts as unsuccessful had not used containers.
This might suggest that containers are a less risky option when implementing microservices. Still, again it is more a matter of choosing the right technology for the organization’s specific application and requirements.
“If we just look at a microservice, it is just a functional stub,” says Longbottom. “The container should provide the environment the microservice needs, with orchestration and so on managing the provisioning, patching, updating and movement of the microservices as required across the broader platforms.”
In other words, building microservices involves different complexity from traditional, more monolithic application styles. For this reason, it may be regarded as a technology better suited for new-build modern or cloud-native applications or organizations overhauling their IT as part of a digital transformation process.
