BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Research What Scares You Most About Adopting a Microservice Architecture?

What Scares You Most About Adopting a Microservice Architecture?

Bookmarks

InfoQ's research widget has been deprecated and is no longer available.

 

Microservices are the industry's new favourite buzzword, silver bullet, and panacea. But while certain companies claim their microservices architectures are what enabled them to scale, is it suitable for every non-trivial project?

InfoQ would like to know: which are the key challenges with microservices architectures? If you think we missed some, let us know in the comments.

  1. Team communication overhead: interdependent services increase the need for communication and coordiation across teams to ensure updates to one service won't break others.
  2. Formalities overhead: good schemas and formal interfaces make good neighbours - but they need to be created, supported and updated. Are all teams up for the task?
  3. Lowered uniformity: microservices allow teams/services to choose their language, tool chains, etc. While fashionably polyglot, does this increase maintenance overhead?
  4. Ops overhead: herding microservices is only feasible with a mature devops processes.
  5. Increased resource use: bundling every tiny bit of functionality in its own container requires more memory and CPU. Is the increased modularity worth it?
  6. Increased network usage: microservices need to talk which nowadays usally happens via the network.
  7. CPU overhead for marshalling: in order to send data it has to be transformed from runtime data structures into external formats, be they JSON or binary formats.
  8. Securing communication between microservices: more chatter, more opportunities for a gap in transport security.
  9. Security audits: more moving parts and less coherence means more places for security vulnerabilities to hide and making security audits harder. Or does the compartmentalization in microservice architectures offset this?
  10. Testing: is testing a system of services harder or easier than testing monolithic applications?
  11. Difficulty in production monitoring: are existing monitoring tools up to the task?

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

  • I'm logged in but voting doesn't work

    by Paulo Merson,

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

    I have an InfoQ account and am logged in. When I click submit vote, it asks for yet another identification service. I click on Google but it doesn't work. :^(

  • Database

    by Jacek Helka,

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

    Cutting the database to hundreds of small databases, giving up referential integrity and transactions is scary.
    When using rest, the interface is usually not type safe. This is another scary thing.

  • Contract validation between services

    by Kai Lüdersdorff,

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

    How to ensure and enforce valid contracts in a Restful service environment to avoid breaking parts of the integration landscape.

  • Re: Database

    by Luis Espinal,

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

    Cutting the database to hundreds of small databases, giving up referential integrity and transactions is scary.
    When using rest, the interface is usually not type safe. This is another scary thing.


    You do not need to uber-cut the database in the way you mention to reap the benefits of microservices. Do the partition mostly (if not only) at the app layer. The backend, whatever that might be, applications should be pretty much agnostic to its location (or locations.)

    Lose typing is nothing to be scared off. That's what unit testing and continuous integration are for. And type safety does not make us anything safer. All we have to do is look at the state of Java applications to see how bad things are even though we are using a type-safe language.



    Type-safety is just a tool. It's all about the wielder of that tool.

  • Unclear service boundaries

    by Pavel Grushetzky,

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

    Given multitude of scenarios that need to read/write diverse data, defining microservice boundaries and yet keeping data access efficient is far from trivial.
    I'm not even sure both of these goals are achievable at the same time.

  • Re: Database

    by Ellen Anderson,

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

    I am right there with you on this one Jacek. I keep looking for something to tell me the micro-objects that are bits and pieces of the overall data subjects is OK. Not having that one comprehensive and unique view of something seems like a step backward

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