8 ways to make sure you really need microservices
Microservices -- today's service oriented architecture du jour -- are great, but not for everyone. There are many situations where they may do more harm than good.
That's the word from Adam Drake, a technical business transformation expert, who posted some words of caution about microservices, warning of increased operational overhead, performance issues, and scalability problems.
Drake provides key steps in assessing an enterprise's need for microservices architecture. Once the first two steps are taken, he urges, "then consider again whether microservices are the right direction for your organization. Chances are, a lot of the issues you had previously will simply disappear."
- Clean up the application. This includes ensuring that the system "has good automated tests and is using the current versions of all libraries, frameworks, and languages," Drake says.
- Make use of APIs. "Refactor the application into clear modules with clear APIs," Drake says. "Don't allow bits of the code to reach into the modules directly. All interaction should be via the APIs presented by the module."
- Separate the services: Separate a module from its application, but keep it on the same host, says Drake. "This starts to give you some of the usefulness of totally separate microservices, but with fewer of the operations headaches," says Drake. There will still be communications issues to contend with, but without the accompanying challenges that will come up once the separate components are running across distributed networks.
- Move the separated module to a new host. "Now you'll have to deal with the issues surrounding communication over a network, but you will have bought yourself a little less coupling between the two systems," Drake says.
- Separate storage capabilities. Finally, Drake says, "if possible, refactor the data storage system so that the module on the other host now has total responsibility for storage of data within its context."
- Consider your organizational readiness. A microservices-savvy enterprise has teams who can provision resources on a moment's notice, with little or no outside assistance, Drake says. "If your organization has only one or a few people in your entire dev team who can set up new services, virtual or otherwise, you are not ready for microservices."
- Be ready to monitor. "If you don't monitor the system and application performance of your monolith, then you will have a miserable time with microservices," says Drake. Key metrics include "system-level metrics (such as CPU and RAM), application-level metrics (such as request latency per endpoint, or errors per endpoint), and business-level metrics (such as transactions per second, or revenue per second) to understand the performance of your systems."
- Be well-equipped for continuous integration and continuous deployment. Drake puts it perspective: If the monolith is lacking a good CI/CD approach, then a microservices architecture is going to be hundred times as challenging, "Imagine having 10 teams and 100 services, all of which require manual integration testing and deployment. Now imagine the same manual work, but with only one monolith. How many ways can things go wrong with 100 services? How many ways with one monolith?"
Updated May 21, 2020: Added new links and updated information.
Read more
Down an invisible road: Service mesh's unpaved path to practicality
Top cloud providers in 2020: AWS, Microsoft Azure, and Google Cloud, hybrid, SaaS players
5 ways technology progressed us in 10 years: The story so far
Python, microservices, and more tech trends for 2020, according to O'Reilly (TechRepublic)