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.
- Team communication overhead: interdependent services increase the need for communication and coordiation across teams to ensure updates to one service won't break others.
- 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?
- Lowered uniformity: microservices allow teams/services to choose their language, tool chains, etc. While fashionably polyglot, does this increase maintenance overhead?
- Ops overhead: herding microservices is only feasible with a mature devops processes.
- Increased resource use: bundling every tiny bit of functionality in its own container requires more memory and CPU. Is the increased modularity worth it?
- Increased network usage: microservices need to talk which nowadays usally happens via the network.
- 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.
- Securing communication between microservices: more chatter, more opportunities for a gap in transport security.
- 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?
- Testing: is testing a system of services harder or easier than testing monolithic applications?
- Difficulty in production monitoring: are existing monitoring tools up to the task?