BT

What Scares You Most About Adopting a Microservice Architecture?

| by Werner Schuster Follow 9 Followers on Apr 10, 2015 |

InfoQ's research widget has been deprecated. It should continue to work however, and we hope to relaunch it at some point in the future.

 

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.

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

I'm logged in but voting doesn't work by Paulo Merson

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

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

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

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

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

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

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

6 Discuss

Sponsored Content

BT