BT

Experiences from Failing with Microservices

by Jan Stenberg on Aug 11, 2014 |

While being a correct philosophy regarding service design and composition, microservices can quickly lead into trouble, Richard Clayton, writes providing some observations and experiences from failing when implementing and maintaining a microservice architecture.

Richard, Chief Software Engineer at Berico Technologies, emphasizes that his team did fail while developing microservices although most of the reasons for their failure were not related to technology and implementation practices. During the project Richard found five major factors contributing to the failure.

Disagreement between developers
Different views within the team on the benefits of a microservice architecture versus a more traditional monolithic stack together with an encouraged democratic decision-making caused a lot of needless and time-consuming debate and also some emotional friction. Lack of skill among developers causing flawed implementations also led to loss of productivity.

Service boundaries causing barriers
Dividing the backend into 8 separate services followed by a decision to assign services to people enforced ownership of specific services by developers. This led to developers complaining of their service being blocked by tasks on other services and refusing to help out by working with these blocking tasks. The separation also lead to developers losing sight of the overarching system goals, instead only focusing on the service they were working on.

Independent services
Balancing the desire to share common utility code between services against independent services with replicated functionality became a huge tradeoff finally leading to a major refactoring.

Failing to specify an API for each service, particularly the model passed between each service, lead to regular issues especially for the frontend developers, a problem still not solved.

Not explicitly defining the services communication and using one mechanism for all use cases didn’t work well. Eventually they started moving towards a CQRS communication pattern, a work not yet fulfilled.

Service granularity
Starting with 8 services was a too big change for the team; probably just a couple of services would have been a better start, eventually splitting individual services into a few microservices as the need arose.

DevOps
Implementing a Continuous Delivery (CD) pipeline was probably where the team did the best, spending a lot of time learning a lot of lessons, e.g. the burden of maintaining many small services.

Richards’s recommendation for teams starting with microservices includes ensuring the team has the skills needed, and taking a pragmatic approach, adapting to teams and customers capabilities.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Problems with microservices just highlight hidden generic problems by kem net

This led to developers complaining of their service being blocked by tasks on other services and refusing to help out by working with these blocking tasks.


program to an interface, not implementation, so use interface only to stub the service

Failing to specify an API for each service, particularly the model passed between each service, lead to regular issues especially for the frontend developers, a problem still not solved.


it's hard to decompose problems in effective way, but if you could not decompose it to a set of microservices it means that it was not decomposed before so it was highly coupled solution

Re: Problems with microservices just highlight hidden generic problems by Richard Clayton

To address your title, I would agree that many of our issues were generic problems that you might find in any implementation. However, these issues are compounded when you implement a Microservice architecture because you tend to have a lot more boundaries and contracts. There's nothing fundamentally new about Microservice architectures (except maybe their popularity), so of course the issues in implementing them are likewise not going to be very novel.

Regarding your comment on interface-based development, we were not tightly coupled to an implementation as you are suggesting. The complaints about being blocked by tasks on other services were largely artificial. Often is had a lot to do with verification of the stated contracts between services. This issue could have been addressed if specifications were written in a way that they could have been automatically verified.

To your second point, the issue was not one of composition but of actual specification. We did not use an IDL or schema technology (when we should have) and encountered a number of issues related to differences in interpretation of the contract.

Re: Problems with microservices just highlight hidden generic problems by Jean-Jacques Dubray

"We did not use an IDL or schema technology (when we should have) and encountered a number of issues related to differences in interpretation of the contract."

-> What a novel idea! I thought our industry was passed contracts / schemas, did I miss something?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT