Nowadays we are observing big buzz around microservices. Applications are designed as a set of small and interconnecting blocks that are built with the single responsibility principle in mind. Typically those services are separate WARs or processes that are exchanging information via different mechanisms, i.e. REST API, queues. A good summary description of microservices architecture can be found on wikipedia.

Although this architecture is promoting loosely coupled and highly cohesive elements, it does not come without potential pitfalls. Whenever we are considering an application that consists of 30+ microservices we need to more carefully take some risks into account. Those can be both technical and organizational and at the very least we should bear them in mind while delivering.

Fight against “silo” teams, promote “one team, one dream” thinking

On the surface it seems easier to assign dedicated team for 1-3 microservices depending on their size. It carries the danger of the team becoming a “silo” that limits communication with other teams. This can lead to “mini-waterfall” since it is very similar to component teams. Most likely local optimizations will happen that won’t decrease overall system lead time. On the other hand, cross-functional teams that are responsible for all 30+ microservices means no ownership in practice and substantial overhead related to communication. Additionally the “microservice entry cost” can significantly slow down delivery. The best solution lies somewhere between these two. Maybe it is worth considering cross functional teams for a group of microservices in the same business area? When considering team assignments it’s always worth clearly managing expectations up-front so that “one team, one dream” thinking is inherent in the team’s mind.

 Encourage fast integration

Architecture based on interconnected pieces talking via REST or queues tempts the deferring of integration. “Let’s agree on an API and integrate after a few iterations” – that’s what we often hear. Remember that the real value for customer is delivered when all elements are connected. Service A and B even with 10 features have zero value when they don’t talk to each other (when they should). Also it doesn’t bring a value if service C delivery goes at 30 km/h when the whole system speed is 5km/h. You may wake up too late for smooth integration without major issues. The idea is for microservices to be integrated as soon as possible having the “think big, prove small” principle in mind.

Introduce common standards

Although technical autonomy is one of the most important enablers for a team’s creativity and innovation, reasonable boundaries in form of common technical standards is a huge investment in consistency and system maintainability. Standards related to logging, monitoring, API conventions, UI etc., can greatly improve knowledge sharing or future troubleshooting. At the end all microservices will form a system seen as a whole from the end user’s perspective. But… like with any generalization we need to be careful and constantly verify the usefulness of common standards. In many cases allowing for diversity and experimentation (to some extent) is the best validator of introduced global rules.

Convey efficient testing vision

How are we going to test all those services connected with each other? How can we assure that while developing one part of the system we won’t break an other part? How many automated e2e tests can still be maintainable? How to tackle performance testing? With so many pieces it is extremely important to convey an efficient testing vision, with tests being our ally instead of a maintenance hell. It’s very easy to find yourself in the trap of unreliable testing that instead of benefit brings  frustration. Finding a clear distinction on what and how to test increases consistency, doing it right additionally promotes a quality mindset. There is an excellent read from Martin Fowler on Testing Strategies in a Microservice Architecture – a perfect starting point.

Assume your security is compromised

I recently came across very interesting article related to the security of microservices. It lists a set of questions that we should ask ourselves to make sure our application is secured. IoT and prevalence of network exposure makes security one of the hot topics. Security review must be inevitable aspect of every continuous improvement process. It is crucial for teams to grow in security awareness, security experts are more than needed to support system’s resilience and prevent future attacks.

All those things are universal, regardless of architecture we are using. It’s just the thing that with all the noise about fancy microservices we tend to neglect them. Bear them in mind in your pursuit for fast and efficient delivery of microservices.