Born from the digital disruption of the modern business world and the relentless evolution of technology, microservices now sits at the core of DevOps philosophy.
An increasingly popular architecture pattern, it builds on the one-time promise of SOA (service-oriented architecture), breaking down monolithic code into manageable, flexible modules, each managing one single service.
As organisations rely on an increasing number of applications to underpin operations, the ability and agility to adapt and scale these applications is key.
It’s here that the microservices methodology comes into its own – upping the speed of innovation in an environment ruled, not just by survival of the fittest, but also the fastest.
In this article, we’ll chart the evolution of microservices – looking at where the concept came from and where it’s headed. In order to glimpse the future, we first need to look to the past…
The road to microservices – how did we get here?
Historically speaking, the software development industry has always run on the cycle of methodology, technology and platform.
Through the ages of structured programming, object oriented programming, component oriented programming and now service-oriented programming, that cycle has always remained the same.
Today’s methodology is service based – though that in itself is not necessarily a new thing. Developers of the web 2.0 era will recall that the concept of small, individual programs working together originated with SOA (service-oriented architecture).
SOA never really took off – but not because the methodology wasn’t sound. Indeed, many of the tenets of SOA still apply to microservices today, with explicit boundaries, autonomous services and share schema just some of the principles they have in common.
There are differences though. In a service-oriented architecture, individual components are more tightly integrated, sharing assets such as storage – and they communicate through a piece of specialised software called an enterprise storage bus. However, microservices are more independent, share fewer resources and communicate via more lightweight protocols.
It can be considered that microservices is the successor to the SOA concept – with microservices set to finally deliver what SOA promised in the first place.
‘Splitting the monolith’
In the service epoch we’re currently in, desirable system characteristics like extensibility, maintainability and scalability all stem from a modular design. The methods that previously worked for object and components of designing a system don’t work for service oriented architectures.
Businesses have often attempted to shift from an OO (Object-oriented) design to a microservice design by “splitting the monolith”. In other words, they would take the existing architecture they had and turn the components into services – effectively turning their architecture into a distributed monolith.
However, challenged with the fact that a bad decomposition of the system leads to an inability to respond to changes – plus the problem that distributed systems require a whole new set of skills from the development team – a lot of organisations were forced into a rethink.
In a few cases, an about-turn was performed – and the monolith resumed.
The skill of ‘decomposing’ a system into modules is more important still in this new world, predominantly because services have a cost. With too many microservices in play, the cost per service may be small, but the cost of integration is considerable.
What does the future hold for microservices?
Now in the platform phase of the afore-mentioned cycle, big cloud vendors such as Microsoft and Amazon have begun producing platforms for building services, adding to the likes of Istio and Linkerd.
These platforms come in the form of ‘service meshes’.
Service meshes are an emerging form of architecture which helps connect increasingly complex microservices with reduced programming – making it easier for enterprises to adopt microservices at scale.
They aim to solve the growing challenges of communication between microservices, as applications typically get bigger and multiple instances of the same service are required to run at the same time.
Such challenges serve as a timely reminder that microservices is not a silver bullet solution to software development, and that successful adoption and implementation of microservices requires the same meticulous approach and well-supported eco-system as traditional development.
Tools to support the microservices lifecycle will therefore continue to emerge and grow in the near future, making microservices faster, easier and lighter to develop, test, deploy and secure.
The question of security, in particular, will play a significant role in the future of microservices. Given their disposable nature, microservices can often be considered less secure than their monolithic counterparts – and as micro becomes the new normal, the need to adopt more rigorous governance levels with secure design patterns should form the foundations of all development.
Other trends too are sure to emerge – with observability touted as another key aspect of microservice development moving forward.
While not without its challenges, designing an application to expose information about its own performance and availability helps app support to determine where things went wrong in the event of failure – highly valuable in the context of microservices-based architectures.
Microservices are already the default methodology for industries that depend on complex software and applications, such as the gaming industry. But we expect other sectors to follow suit and fully switch over to the microservices approach, given the major advantages and relative low risk on offer.
Quick takeaways:
- Think about security
- Carefully plan the integration
- Use the right tools
- Appreciate that the approach is not a ‘silver bullet’
