Monday, 11 September, 2017

Managing the Architectural Change from Monolithic Systems to Microservices

Author
Lambros Photios

Share

Over the last decade, the rate of technology driven change has been incredible, and there are clear indicators that this change will only increase. If you’ve been paying attention, you’ll know there are global changes around the corner that are fundamentally changing much of how the world operates – advances in artificial intelligence (AI), the internet of things (IoT) and quantum computing, to name a few. These changes have the potential to cause massive disruption to existing communities and industries, while creating new industries and jobs. Companies that embrace change and find ways to adapt quickly to the new opportunities will thrive; while others that are unable to adapt will be left behind.

The cost of missed opportunities is now critical, and it’s becoming increasingly clear that traditional solutions (especially those in IT) aren’t up to the challenge. Traditional monolithic architectures (like SAP) often have extended delivery cycles and long regression testing cycles. Many organisations are still tied into quarterly release cycles, and it often takes 6-18 months for an idea to move from the conceptual stage to delivery. It is in this context that microservice architectures have arisen as a way of building technology solutions that allow companies to avoid some of the pitfalls of these monolithic architectures. In this blog, we’re going to work through what a microservice architecture is and the advantages and risks associated with the approach.

What is a microservices architecture?

So what do we mean by “microservices”? There’s no official definition, but a microservice architecture is usually defined by a roughly agreed set of features. The fundamental unit of a microservice architecture is the service and most agree that microservices are based on services that fulfil the following criteria:

Independent systems

Services are deployed and executed independently of each other, with communication between services via out-of-process calls. This means that each can be changed, deployed and scaled independently. Contrast this with a traditional monolith application, where a change to a single library or object results in redeploying the whole application; failures have the potential to bring down the whole system and horizontal scaling requests the full application to be replicated. Individual services can also be scaled quickly, easily, and independently scaled horizontally. Services can be individually restored/maintained, allowing for a much more resilient system.

Fine grained (micro) services

Services are defined at a granular level, in contrast to the coarse-grained modularisation of traditional architectures or even SOA (service oriented architecture) approaches.  Finding the right level of granularity can be more of an art than a science, and is one of the key challenges in the microservices approach. The impact of change is isolated, less regression testing is needed and new functionality can be brought to market extremely quickly.

Services composed by business function or entity

Services tend to be defined by a business capability or domain entity rather than a technical function.  Componentisation in traditional applications tends to be either by high level capability or technology components (data access layer or UI modules, for example). This provides a better alignment to business requirements, and drives a focus of business outcomes rather than technical ownership.

In addition to the above, microservice architecture solutions adopt various enablers – approaches, technologies and styles that enable the approach to achieve the advantages over a traditional approach.

Lightweight protocols

One of key implications of moving from a microservices architecture is that the process overheads from repeated inter service communication can be high. For this reason, a lightweight transport and protocol combined with a Tolerant Reader pattern are key to making this approach work. 

Continuous deployment and infrastructure automation

This allows changes to be moved quickly and efficiently through the build and deployment pipeline. This isn’t unique to microservices, but has great synergy.

Containerisation

Products like Docker or Kubernetes are incredibly aligned with a microservices approach, where a service built in a container can be built and scaled incredibly easily and reliably.

Products, not projects and cross-functional teams

Microservices work best when a team is focussed on building a product, not delivering to a project. This aligns nicely with Agile methodologies and brings development teams closer to the business. This also lends itself to cross functional teams supporting service capabilities rather than a specific technology layer. Under this model, teams focus on and take ownership of a business capability.

Decentralised governance

A traditional architecture tends to govern design decisions at an application level, rather than choosing the right tool for the job.  For example, different types of persistence (such as relational, document and graph) suit different use cases, instead of mandating a consistent approach.  This is also true at a service level, where the strengths and weaknesses of different technologies can be taken advantage of.

Comparing microservices with monolithic

Aspect

Microservices

Monolithic

Agility

  • Changes are isolated, only affected services need to be redeployed
  • Regression testing only redeploy services and affected processes
  • Short regression cycles allow for quick release cycles
  • Changes require entire application
  • Full regression testing cycles required
  • Usually requires long release cycles

Scalability

  • Individual services can be horizontally scaled
  • Requires the whole application to be scaled

Resilience

  • Failures are isolated to an individual service; a single failure is unlikely to bring down the entire system
  • Failures can potentially affect the whole application

Speed to Market

  • Short release cycles allow ideas to be rapidly delivered
  • Containerised services support rapid movement through delivery lifecycle
  • Support rapid prototyping approaches
  • New developers can focus on a small number of services, reducing on boarding time and the ability to rapidly upscale development efforts
  • Long release cycles delay time to market
  • New developers must understand all interdependencies before confidently making changes, long ramp up times for scaling development resources

Alignment to business

  • Cross functional teams supporting business capabilities
  • Product focussed delivery ensures alignment to business
  • Supports dev-ops models
  • Decentralised governance allows the specialised technology choices
  • Technology focussed breakdown
  • Centralised governance defines a common technology choice for every use case.
  • Project focussed delivery risks miscommunication and misalignment with business

Extensibility

  • Microservices can easily be combined/reused to deliver capability
  • Re-use can be difficult, and dependencies can be difficult to disentangle

Risks of microservice based architecture

The above highlights significant benefits over a traditional application architecture; however, there are some clear risks and challenges that need to be mitigated. Two risks are worth calling out briefly:

Complexity of microservices

A microservices approach doesn’t necessarily reduce complexity; instead, the overall complexity of the solution remains the same but it’s shifted. If anything, microservices may be more complicated.

Overheads of microservices

Inter-service communication adds additional physical resources; granularity of service needs to be very carefully managed to ensure the overheads don’t outweigh the benefits. Some ways to address this are through libraries rather than services, decreased granularity and redesign.

In a future post, we’ll look have a look at different ways to address and mitigate these risks, and some strategies for adopting microservices in a practical and effective way.

Conclusion

Adapting to change is a problem that IT has faced since the beginning, and we’re only slowly becoming better at it. At the same time, the pace of change is only increasing, and traditional ways of doing things are no longer sufficient to meet tomorrow’s challenges. Microservice architecture isn’t the only answer and it’s worth noting that for well-defined problems where you’re not looking to innovate, an out of the box application is usually a good fit (such as HR and finance applications). But when you’re looking for competitive advantage through ease of innovation, an edge in the microservices market is without a doubt the way to go.

About the Author.

Author
Lambros Photios

View on LinkedIn

I embarked on my entrepreneurial journey six years ago with one goal: To build a culture and technology focused company. Working with industry leaders, I’ve had the honour of delivering challenging projects with intricate specifications, and within tight deadlines.

Tags.