BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Bad Practices Building Microservices

Bad Practices Building Microservices

Bookmarks

Although it’s interesting and inspiring to read about others success stories implementing a microservices architecture there are traps to avoid falling into by learning from mistakes made by others, Vladimir Khorikov writes sharing some bad practices he experienced during his work with a company on its way to adopt a microservices architecture.

Using an external architect creating the design leaving only the implementation for the teams interferes with product team’s responsibility which Khorikov believes is one of the more important aspects of microservices and breaks the feedback loop from the actual code back to the design. His advice is to instead make the architect work as an internal consultant helping the teams to make their own decisions about design and implementation.

A dedicated DBA that takes full control of all databases, including design and profiling, with an approval needed for most changes, effectively prevents a team from optimising their database structures. Khorikov instead favours a developer with DBA experiences that is also part of a team and giving full database control to the teams.

A shared code base delivered to the teams with no access to the source code and not able to fix bugs by themselves slows the teams down. Code reuse is a core practice in development but the code must be shared by all teams with each developer able to send a pull request. Khorikov emphasizes that only utility logic should be shared; sharing domain logic breaks the boundaries between contexts in different microservices, a subject David Dawson wrote about recently.

Preferring SDKs over APIs means a library has to be created for each platform in use. Unless you are a large company this often leads to one platform enforced on all teams. Khorikov believes that a SDK introduces another level of complexity, forcing a team to support both a service’ public API as well as the client code that uses the API.

A shared environment with e.g. the same database instance for all services can very quickly create confusion about who owns the different tables and reluctance of removing anything in fear of destroying products for other teams. A main principle for Khorikov is organization around business capabilities with one data store for each service.

Outsourcing implementation of a whole service because of the in-house teams lacking experience means the teams won’t have the required knowledge to maintain the service later on. What Khorikov instead recommends is to work side-by-side with the external developers making it possible for the in-house teams to adopt the required experience.

Khorikov concludes by claiming that although a microservices architecture can bring competitive advantage, every aspect of the development process should be considered to avoid adding program structures without real purpose, cargo cult programming.

Rate this Article

Adoption
Style

BT