Why microservices may not be for everybody
A microservices architecture isn't for everybody. It may be untenable for small companies with limited IT resources. For companies with adequately performing legacy systems, it may not be worth the trouble to attempt to break parts of their systems down into microservices. It may not even fit well into a DevOps culture.
That's the word from Susan Fowler, engineer at Stripe, author of Production-Ready Microservices, and formerly an engineer with Uber's microservices team. Fowler recently spoke with InfoQ's Thomas Betts, noting that the best candidates for microservice projects are those companies that are running into scalability problems. Microservices may help manage applications in which "scalability limitations have introduced severe performance and stability problems, it is impossible to do any work on the application, and developer velocity has ground to a halt."
(Coincidentally, it was another Fowler, Martin Fowler, who laid the groundwork for microservices back in 2014, which included this working definition: "The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.")
For many organizations, a well-functioning microservice architecture may be difficult to reach. "Most systems weren't designed with microservice architecture in mind," Susan Fowler says. As a result, many microservices end up being designed in isolation or within siloed environments.
Microservices don't necessarily mesh well with DevOps environments, either. Fowler observes. Typically, especially in large-scale data centers, there is an obvious split between development work and operations work. In a microservice architecture, however, "there will be dozens, hundreds, or thousands of microservices and, consequently, microservice development teams, and dual-staffing each of these teams with both developers and ops engineers doesn't make any organizational sense."
Still, a microservices architecture needs to be a good fit within the organization. In a separate blog post, Fowler advocates a four-layer approach:
Hardware layer: Configuration management tools, databases, servers, host-level logging and monitoring, operating systems, resource isolation, resource abstraction
Communication layer: DNS endpoints, load balancing, messaging, network, remote procedure calls, service discovery, service registry
Application layer: Deployment pipeline, development environment, microservice-level logging and monitoring, self-service internal development tools, test, package, build, and release tools.
Microservice layer: The microservices.
.