Seven (More) Deadly Sins of Microservices
It seems like the development community is quite excited about microservices these days, but at OSCON Europe, Daniel Bryant, who is chief scientist at OpenCredo, continued to point out some of the mistakes that architects and administrators routinely make while adopting to this new “Loosely coupled service oriented architecture with bounded contexts,” as Adrian Cockcroft described microservices.
Earlier this year, Bryant compiled a list of common mistakes architectures made in working with microservices, in a talk enticingly entitled, “The Seven Deadly Sins of Microservices.” This week, at the conference he listed another list of gotchas, in a talk called “Seven (More) Deadly Sins of Microservices.”
According to Bryant, here is the list of microservices sins:
- LUST: Using the (unevaluated) latest and greatest tech.
- GLUTTONY: Communication lock-in.
- GREED: What’s mine is mine (within the organization).
- SLOTH: Getting lazy with NFRs.
- WRATH: Blowing up when bad things happen.
- ENVY: The shared single domain (and data store) fallacy.
- PRIDE: Testing in the world of transience.
1. Lust
Bryant claims we’re often like Magpies who just want the shiniest, latest and greatest technology, but we continue to trip ourselves up when we copy what other people are doing without taking the time to evaluate the right solution for our needs. Clients come to him saying, “give me some Docker” or “give me some DevOps” or “give me some microservices,” but they are just going after the shiny new tools without thinking about which problem they are really trying to solve by using them. He suggests that rather than arguing about tools, we should be having more discussions about needs and values.
2. Gluttony
Bryant cautions us not to rule out options because of past biases. Rather than ruling out RPC (Remote Procedure Calls), which a lot of people do, why not consider something like Google’s gRPC, which offer speed and other benefits? Another example is the ESBs (Enterprise Services Bus), which many people have found that, once you open one up, “it’s often a tire fire in disguise.” But the idea of inter-application communication is well-supported API gateways, like Kong, Apigee, Amazon Web Services’ API Gateway, and MuleSoft.
3. Greed
“Microservices are about people, as much as they are tech,” says Bryant, and the people element is really important. The temptation to blindly copy from other people is strong, but instead, we should understand our practices, principles, and values before making changes. He says that the “success of DevOps has been about empathy,” and that empathy is “the hidden ingredient in good software development.”
4. Sloth
The one is all about getting lazy with NFRs (Non-Functional Requirements). The technical requirements should be identified early on, to ensure they are handled properly in the design. Bryant talked about the pushback he gets from Agile coaches who want to “delay decisions to the ‘last responsible moment,’” but sometimes the last responsible moment is up-front when you are using microservices.
Bryant also mentioned that being aware of security in containers is useful, since a lot of microservices are deployed in containers, and he’s a “big fan of getting everything in the build pipeline” where security testing can be performed along with performance and load testing.
5. Wrath
Technical pain points include distributed transactions, and Bryant cautions against pushing transactional scope into a single service. However, there are also people pain points, and he mentions that while “DevOps at it’s core is really important,” the notion of a full-stack engineer is a myth. It’s too much for one person, so you should define responsibilities and focus on what matters (CI/CD, logging, monitoring, etc.)
6. Envy
With microservices, Bryant mentions that you should be aware of the implications of the technologies that you are bringing into the design. In particular, you should be careful not to treat other databases as relational databases; for example, tuning or modeling data in Cassandra will be different than what you would do for a relational database. He also mentions that you should always “be aware of the operational overhead.”
7. Pride
Testing is a lot more challenging in a microservice environment as your various microservices interact with each other. “Microservices should be disposable,” Bryant says. With disposable, transient microservices, testing can be quite difficult, but possible with service virtualization and API simulation, like Hoverfly.
It’s worth taking some time to think about these seven deadly sins of microservices before you start working on that next big application!
