BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Experiences from Failing with Microservices

Experiences from Failing with Microservices

Bookmarks

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.

Rate this Article

Adoption
Style

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.

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

Community comments

  • Problems with microservices just highlight hidden generic problems

    by kem net,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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?

  • Re: Problems with microservices just highlight hidden generic problems

    by Igor Roháľ,

    Your message is awaiting moderation. Thank you for participating in the discussion.


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


    being the first client of other team's service can be a source of valuable feedback for that team

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

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

BT