Over a million developers have joined DZone.

Microservices: Organizational Practices, Part 1

DZone 's Guide to

Microservices: Organizational Practices, Part 1

In this article, we will firstly look at the primary benefits of deploying microservices and the company culture necessary to adopt a microservice-based product.

· Microservices Zone ·
Free Resource

In a cloud environment, microservices are often the architectural style of choice. This is primarily due to the many benefits associated with microservices as compared to a more traditional monolithic architecture. In this article, we will firstly look at the primary benefits of deploying microservices. In the second part of the article, we will familiarize ourselves with the Westrum culture model and learn how the culture of a company itself may impose significant challenges on any technical transition undertaken as part of a modernization drive. Lastly, we will show how to use Conway's law to our advantage, when transforming the monolith towards the use of finer-grained services. We round up the article with a recommendation on how changes in the deployment of DevOps can have a significant impact on process improvement.

The (Many) Benefits of Microservices

Moving forward, it is important to keep in mind that the use of microservices is no silver bullet — in fact, many companies have struggled when trying to rework their applications towards the use of microservices.

Independent Release Cycle

Firstly, microservices (as individual parts of our software) have an independent lifecycle. This means that each and every service is improved upon and released (in a backward compatible manner) without extensive communication between teams. Fortunately, due to the nature of microservices, there is a guarantee that the majority of changes will not negatively affect other components across the system. This is possible because microservices always communicate through an API — and if the existing API does not change, the change is compatible with all other existing clients.

From a time-to-market standpoint, this implies reduced mean time to delivery, because multiple unrelated changes in multiple modules do not need to wait for one big (and risky) deployment, each change can be deployed individually as part of the continuous delivery process. Utilization of microservices also reduces the mean time to recovery, as (if there is a bug in the solution) the team is able to deploy a new version swiftly, with only testing of the affected component being required.

Seamless Horizontal Scaling

Secondly, microservices can be easily scaled horizontally, because they are (generally) stateless — there is no state (cache, session) bound to an individual instance. Adding capacity to the pool is usually as simple as adding a new microservice instance behind your Load Balancer or queue.

The benefits of such a flexible deployment are quite clear: in the case that there is a surge in requests, the application can be easily automated to scale up. If the application is not utilized enough, it can scale down (and therefore reduce operating costs).

Team Scaling

In many cases what is more important than the horizontal scaling of components is the scaling of the company itself. That means an increase in the number of teams that can work independently. An increase in the number of teams working on a component cannot be done easily with monolithic architecture as its quite hard for new programmers to be brought up to speed, because they must grapple with complex modules, tangled by years of development.

Microservices, on the other hand, are designed to be rather small (for one dedicated team) and targeted at one business concept (such as user management). With this type of product, it is quite easy to onboard a new member, as he needs to gain experience only in a limited subdomain of the service itself. The new team member is able to get acquainted with the complexities of the system gradually.

Also, there is no longer the obligation to use the same technology throughout the entire system, as the modules are isolated by APIs. Technically speaking the system may be written using a variety of frameworks or languages (which may ease the spinning up of new teams). Nevertheless, this approach should be taken with caution, as the utilization of additional technologies also means that the company needs to have either more universal/polyglot programmers or simply more experts in general. Of course, there are also crosscutting concerns such as logging, security, and deployment, which require additional attention and implementation if there are various frameworks or languages used across the system.


Microservice architecture, when implemented correctly, is very resilient to hardware malfunctions. This is a very important quality, as microservices are usually deployed on cheap commodity hardware — and when an installation contains 30 microservices, each deployed in 3 instances, it is very probable that the underlying hardware will fail from time to time.

Running on hardware which is likely to fail may not seem beneficial at first glance, but it is! It's much cheaper to buy capacity on commodity hardware in the cloud (and to be able to handle it) than to try to achieve four nines availability with ones own DC running on high-end machines.

Work Culture and Organization

Now that we have been introduced to the benefit of microservices in the cloud let's dive into the next topic — company culture. The importance of the organization of the work itself cannot be overstated, as it often predetermines if any change will be successful or not. On the other hand, if we are able to address possible issues before we start, we can improve our chances of success quite significantly.

Westrum Culture Model

First of all, let's get acquainted with the Westrum Culture Model. While the model is not specific to the development of microservices, understanding the state of the company is very helpful when implementing any change. According to an excellent book Accelerate (Forsgren et al.), the Westrum Culture Model can be used to predict software delivery performance of the team.




Low cooperation

Modest cooperation

High cooperation

Messengers shot

Messengers neglected

Messengers trained

Responsibilities shirked

Bridging tolerated

Bridging encouraged

Failure leads to scapegoating

Failure leads to justice

Failure leads to inquiry

Novelty crushed

Novelty leads to problems

Novelty implemented

(Source: Accelerate)

Implications for Microservice Transition

If we apply the Westrum model to changes in the architecture and our shift towards the use of microservices, we do not want to be in a company with a Pathological Culture, because one thing is certain — there will be major challenges along the way. If this is the case, then it is likely that negativity within the team will lead to apathy or staff attrition (people will stop trying, or will quit). There is no real advice that can be provided in this situation, but if change is required and the company culture falls within the realm of Pathological, the team should have a dedicated stakeholder who is able to shield it from the rest of the company... and protection will be needed. Generally speaking, a pathological work environment is not suitable for any change (let alone a major shift in architectural design), as there is a significant chance that it will be a painful experience for everyone involved, if not an outright failure.

On a positive note, if the company has a Generative Culture, we can be sure that when the team will hit the wall (and it will happen, many times), the company will be capable of helping the team to overcome the hurdle and move forward. The only consequence will be new knowledge and experience.

If the company has a Bureaucratic Culture, we can mitigate some of the issues through the application of the Inverse Conway's maneuver.

That's all for Part 1. Tune back in tomorrow when we'll discuss Conway's Law, implementing microservices in a DevOps workflow, and more. 

microservices ,devops ,conways law ,microservices adoption

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}