Microservices – are they the solution or the problem?

For many organizations and tech teams, microservices are still the shiny ‘newish’ thing. With the pandemic accelerating the demand and implementation of digital transformation projects, increasingly more organizations are looking to shift from legacy, monolithic applications to microservices – even despite a little backlash in recent years.

While organizations certainly shouldn’t be disregarding microservices altogether, some may be being a little overzealous in their approach. Getting microservices wrong can create a jumbled mess, hindering the ability to scale and decreasing overall availability. But microservices should be the solution, not the problem, so how can organizations get that right?

Why microservices and why not?

Microservices are known for enabling better scalability and flexibility, as well as the smooth implementation of changes without disruption, through better fault isolation and the engenderment of true team ownership. When implemented properly and in the right contexts, microservices help to grow the business. But they may not always be the right option for everyone.

Microservices (or service separation) largely drive these outcomes — separating cost or availability, scaling differently or independently, and developer velocity (something small teams need not be concerned about initially). As such, microservices may not be the right choice for small tech teams. The term micro is also a bit of a red herring. Services need to be separated at the right size – too small and too many, will in fact make teams slower — the opposite of the desired impact.

Getting this wrong can then cause even greater issues later down the line. If there are too many services and they are badly structured, this can lead to low availability, the need for huge amounts of coordination, slow systems, even errors. Furthermore, unlike spaghetti code, they can significantly negatively affect transaction throughput, availability, and operating margins. Ideally, no organization wants to end up in this situation.

Starting up

If microservices are the right option, there are key elements to bear in mind before just diving in. Firstly, and something that is all too easily overlooked, make a business case. There needs to be strong reasoning behind the move to microservices and for organizational models to be clearly aligned and consistent.

To be clear, the value of microservices needs to be put in business terms: there must be a return on the investment to either split a monolith (new work and new investment) or to architect new with microservices (an endeavor that is typically more costly in engineering than building a monolith initially).

Secondly, and very importantly, is the relationship between services and teams. This is very rarely considered, but not doing so often leads to the over-segmentation of services and the problems outlined above. In an ideal scenario, every team will have one service, so if there are 20 teams, you will have 20 services. This means no two teams own the same service and each service is independent and autonomous, ensuring clear alignment and ownership. Of course, one team per service isn’t always possible, but ideally, no team should have more than two services.

Keeping it together

Having these key principles in mind, organizations can look at deploying services. While the aim is for these services to be autonomous, each with its own teams, there still needs to be structure with overarching guidance, governance, and a framework to ensure success. The rule book can’t be completely thrown out and a certain level of coordination is still needed. This is where tech leadership plays a vital role.

Think of it this way, if each team was in a race and told to chart their own path to get somewhere, it’s likely they would bump into one another, slowing each other down. Each team needs to have their own lane to do as they wish and to not interfere with other teams, but the destination and ‘rules’ are the same. It’s autonomy within a framework.

If despite best efforts, organizations struggle to keep this structure and services do get a little out of hand, luckily there are means to solve it. To rectify ‘spaghetti services’, the number of services needs to be collapsed and once again, it comes down to teams and organizational structure. It’s vital to also understand the affinity between services, where there are high degrees of connectedness and then bundle these services together. Multiple services then become one service and one team can own that service, moving back to that ideal structure outlined at the beginning. But as said before, best to not let it get this far.

 Microservices are the viable option for many an organization, but how they are approached is where the fundamental problems lie and issues are caused. The key elements to be successful are outlining business value, team and services relationships, and having an overarching framework for teams to operate in. Still, this all calls for a switch-up in attitudes and mindsets to ensure microservices do provide the great advantages they have the potential to and remain the solution not the problem.

 

 

Article contributed by Marty Abbott, Co-Founder and CEO of AKF Partners