As technology is undeniably evolving every day, monolithic systems are becoming too large and difficult to deal with. Many enterprises are then making the change to microservices architectures, so it is easier, quicker, and more efficient to manage.

Microservice architecture is a distinctive method of developing software systems that seek to focus on building single-function modules with well-defined interfaces and operations. This trend is slowly gaining in popularity, especially as many companies are adopting Agile and DevOps methodologies.

Hence, we talked to experts in the industry to share their insights about migrating to a microservices architecture.

Why migrate to a microservices architecture?

First of all, let’s explore why, according to them, should businesses migrate to a microservices architecture.

Mike Skaife, Principal Software Engineer at Jaguar Land Rover, starts by telling me that there are plenty of great reasons to migrate from a monolith to a microservice architecture.

Indeed, he says, if you’re finding that you are struggling to scale your system appropriately, or if you’re finding it’s increasingly difficult to make changes to your application and respond to user demands, microservices could be the answer.

‘As the technology and tooling to enable microservices architectures keeps on maturing, the barrier to successful entry into this space is lowering all the time.’

However, Mike warns, you should still tread carefully as microservices are not the silver bullet they may often seem.

Moreover, Guillermo Toro-Bayona, a Software Developer at Nando’s, thinks that microservice architecture allows businesses to have more flexibility in how all the different systems work together to resolve complex business rules.

Usually, for a very complex problem one of the strategies is divide and conquer, he says. So, this strategy helps to have multiple aspects of the problem that could be tackled separately.

‘Each microservice should be focused on solving a particular area of the problem.’

In the end, all the microservices will be part of a big architecture resolving complex problems by chucking them into smaller workable units.

For Venkataraman Purushothaman, Automation Architect at U.S. Bank, the rapid digitization is causing substantial shifts in client expectations across businesses. Hence, many are struggling to adapt to this accelerated change. As a result, many industries are aggressively pushing IT to cut delivery time, reduce cost and improve quality – all simultaneously.

He highlights that microservices architecture (MSA) has emerged as one way to address these challenges. MSA describes a new way of designing software applications as suites of small, loosely coupled independent services.

While there is no precise definition of this architectural style, he continues, these architectures encompass certain common characteristics around the organization, business capability, automated deployment, intelligent service endpoints, and decentralized control of languages and data.

‘Like their predecessors, they bring their own set of unique challenges that should be addressed upfront to prevent the architecture from turning into a tangled mesh of point-to-point communication paths.’

Achieving a successful migration

In order to achieve a successful migration, Guillermo emphasizes the fact that you need to first identify which parts of the business could benefit from a microservice architecture.

Indeed, sometimes we have monoliths pieces of software that try to solve everything, and it does a good job. However, when the problem evolves is a bit more difficult to get the monolith to solve the same problem.

He points out that changing the monolith is not as easy as it could affect other areas as everything is in one place, so a single change could affect the entire business. With a microservice architecture changes to smaller pieces of software are dealt in a better way. Identifying those areas where the monolith could be split to cut a small dependency is a good candidate to start the migration to a microservice architecture.

Hence, if you’ve decided that a move to microservices is the right thing to do, there are a number of pre-requisites that are important to have in place to enable a microservices approach to work effectively.

According to Mike, these are the following:

• Continuous Integration and Delivery – when your system is made up of multiple different microservices, and you’re planning to make changes much more frequently, it’s important you have a really solid build, test, and deployment process in place which is ideal as an automated as possible. Managing change across multiple microservices in a manual way gets very complicated and time-consuming very quickly
• Containers and Deployment Environment – you will probably want to be working with containers, which is very different from deploying a monolithic application onto a single server. You should be familiar with things like 12 Factor principles, have an environment where you can deploy and manage containers, and also then consider things like security and how that changes in a containerized environment
• Monitoring and Observability – a monolith is simple enough to understand, you can follow transactions within a single application and just about make sense of log files. But a microservices architecture is a distributed system and exponentially more complex to understand. How do you know where the root of an error is? How do you know which part of a system is causing a bigger issue? Good monitoring and observability toolings such as log aggregation and distributed tracing are essential to be able to understand your system more completely
• Testing – similar to the operations side, it’s also key to have the right approach to testing. You need to test each individual microservice, the integrations between them, and the end-to-end system and user journeys as a whole. This again needs to be as automated as possible to be effective
• Integrations and Versioning – when you have multiple microservices and multiple teams working independently, you need a solid approach to helping them work together as part of one overall effective system. That might mean API contracts in place, a centralized event stream, or some other design. Similarly, you need to have an effective solution to managing what version of each service is running in each environment at any time
• Architecture and Domain-Driven Design (DDD) – although following a Domain-Driven Design approach isn’t essential, you do need to ensure your microservices are appropriately sized and scoped, that you’ve got the right boundaries for each microservice based on business domains, and that the integrations between them are designed appropriately

Venkataraman adds that microservices are a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, lightweight mechanism to serve a business goal.

He highlights that microservices characteristics include the organization of a logical block of functionality around a specific business capability, programming language agnosticism, and decentralized control of data.

Hence, each microservices project will have its API interface and implementation classes, its own data persistence and management module, client libraries required to efficiently communicate with other microservices, and the operational governance infrastructure. It may also include the client classes required to connect with back-end resources.

The benefits of microservice architecture

Microservices can bring a lot of advantages when used appropriately.

Indeed, Mike states that moving from a monolithic architecture to multiple separate microservices enables teams to work more independently. Teams can be built around specific business domains or value streams; engineers no longer need to understand the context of an entire system in their heads which helps with cognitive load.

Besides, he continues, it allows you to scale parts of your system independently based on need as well. For example, at Jaguar Land Rover, they may often need to scale one part of their Software Over the Air (SOTA) platform if they’re launching a software update campaign for a particularly large number of vehicles at any one time, but they don’t want to scale the whole system because other areas aren’t as impacted.

Similarly, if you’re an e-commerce organization you might want to scale up some of your user-facing services during Black Friday, but the parts of the system that deal with deliveries can still churn along at a lower scale. That’s important from a cost perspective as it’s much more effective to scale up small parts of a system than a giant monolith.

Moreover, he adds that technology choices will become more flexible. You can build different parts of the system with different technologies as appropriate. For example, Jaguar Land Rover has a part of their system which is well suited to relational data so they use MySQL as the database, but other areas work more effectively with something like MongoDB.

‘With microservices, teams are able to make those independent technology choices, as well as giving individual microservices control of their own data in a more granular way.’

Finally, Mike emphasizes that microservices allow you to have more flexibility. You can better react to users changing demands when you’re able to limit that change to a smaller independent part of the system rather than having to work with a fragile and tightly coupled monolith.

According to Guillermo, a microservice architecture brings flexibility – easier to adapt your platform to solve constantly changing problems in your business domain – and maintainability – easier to keep a single focus for a single piece of software.

Besides, he continues, adding changes or fixing features is becoming easier if the scope of one microservice is well established.

For Venkataraman, there are a few benefits to consider including:

• Improves fault isolation: larger applications can remain largely unaffected by the failure of a single module.
• Eliminates long-term commitment to a single technology stack.
• Makes it easier for a new developer to understand the functionality of a service.
• Independently scalable, resilient.
• Independently deployable.

The challenges

Microservices are certainly not a silver bullet, and not some magical solution to all your problems as they are often sold, such as Mike tells me. This is why he emphasizes the need to move to a microservices architecture only if it will truly benefit the organization.

There are a lot of challenges to consider according to Mike. Distributed systems are one of them. Indeed, he says, they are complex to test, complex to deploy and manage, complex to understand as a whole. So, you need to not underestimate the increasing complexity.

Teams also often end up with something more like a ‘distributed monolith’ than truly decoupled microservices, where they effectively have a collection of smaller but still tightly integrated services, he continues. That leads to teams getting into a mess where they can’t deploy one service independently without having to also deploy a few others, or where a change in one service frequently breaks functionality in other services. You can thus end up with the worst of both worlds: the complexity of working with separate services but none of the advantages that a loosely coupled architecture would bring.

Moreover, another important aspect that is often overlooked until teams start working with microservices is the developer experience. It’s usually easy enough to run your monolithic application on a developer’s laptop, but what about trying to run 10s or 100s of microservices on that same laptop? Developers get frustrated as their machine grinds to a halt which interrupts their flow when working with TDD, or maybe it’s just not even possible to run the whole system on one developers’ machine.

Finally, the last concern is technology sprawl. It’s great that each team can use whatever technology is appropriate to build their microservices, but you do still need some kind of constraints. Standardization is important to enabling teams to learn from one another, reuse code where appropriate, and so on. Hence, he advised to not use Java and .Net for example, pick one and encourage teams to adopt one.

Similarly, Mike recommends, with databases, don’t use MySQL and Postgres and SQL Server, try and constrain and pick one if you can. Some teams talk about the concept of a ‘golden path’, a tech stack that is widely adopted across the organization, where support and expertise are available in the organization, to encourage some level of standardization across teams. Teams can still go their own way with other technologies, but they’re on their own if they get stuck with any issues.

Venkataraman lists a few challenges to migrating to a microservices architecture:

• Large numbers of microservices are difficult to orchestrate.
• Understanding, managing, and testing dependencies is difficult.
• Software patterns (encapsulations and such) do not provide a uniform service abstraction.
• Message flow increases with the number of microservices and hampers performance.
• Service interface versioning needs to be managed for the multiple services

Finally, Guillermo states that complexity is one of the greatest challenges that come with microservices. Indeed, great power comes with great responsibility. Microservice architecture brings many pieces of software trying to work all of them together to try to resolve a problem.

Monolith solutions were “easy” to do housekeeping as all the different resources associated are in one place. Microservice architectures, on the other hand, bring many pieces with many other problems like latency, security, communication, networking, etc. that will add to the task of maintenance of the IT infrastructure.

Will more businesses adopt a microservices architecture in the future?

Mike does believe that more and more businesses will move to microservices. As compute resources get cheaper and cheaper, and the ecosystems around technologies like Kubernetes and Istio continue to mature and abstract away more of the underlying complexity, combined with advances in the distributed systems monitoring and observability space, more and more businesses will feel confident in moving to this approach.

He also tells me that, as long as there is a hype around microservices, and engineers see it as the current cool thing to do, adoption will continue to increase. This is obviously not a solid reason to move to microservices, so it is ever more important to make sure this is appropriate for your use case.

Yet, he recommends avoiding adding unnecessary complexity before you truly need it. He advises to not do it only because it feels like everyone else is. You need to be pragmatic, make sure you’ve got all the right practices in place, then consider making the leap.

Guillermo also thinks that businesses will adopt this architecture style more and more. Some businesses are struggling to keep up with a very competitive market, which requires being very fast in delivering your products and/or services to your customers to reduce the time to market of the business strategies and be more competitive.

Having an IT architecture that supports that environment is definitely the way forward, he continues. If a business is not adapting to these and keep most of its critical systems in a monolith approach, offering new services to customers will be at a very slow pace and it will impact the sustainability of the business.

‘Microservices will help to be faster in adding value to business strategies.’

Finally, Venkataraman highlights that there is a lot of hype around microservices today. The modern systems architecture idea, which can provide small services with full lifecycle control, is here to stay. Developers deploy only the services that are needed as part of a rollout, update them in place, spinning up additional instances as required.

He believes that businesses will establish cross-functional teams working on each microservice, delivering the same business capability across the enterprise, leveraging their inherent domain expertise in that business capability rather than “reinventing the wheel” within each system boundary.

Special thanks to Mike Skaife, Guillermo Toro-Bayona, and Venkataraman Purushothaman for their insights on the topic!