Microservices are a new software development pattern emerging from recent trends in technology and practice. Agile methods, DevOps culture, PaaS, application containers and the widespread adoption (both mentally and technically) of continuous integration and delivery methods are making it possible to build truly modular, large-scale systems.

What do teams that successfully build microservices do differently from those that don’t? It all boils down to how you start, according to Arun Gupta, director of technical marketing and developer advocacy at Red Hat. SD Times interviewed Gupta about how (and why) enterprises should build microservices.

Are microservices just a new term for service-oriented architecture?
Gupta: SOA is commonly defined as application components that communicate to provide services to other components over a network. Microservices are SOA 2.0 (or “SOA for hipsters,” as you quoted in a recent article), because they deliver on the original promise of SOA. Today, multiple microservices can provide a complete application experience to the customer.

The key difference is the lack of an Enterprise Service Bus, which was very vendor-specific and had a lot of built-in logic. Now, microservices logic is built into the endpoint, and different services exchange payload over a dumb HTTP pipe. SOAP and other heavyweight protocols are replaced by lightweight JSON over HTTP or REST. There is no centralized governance and persistence, and each microservice has its own data store. In addition, Continuous Integration/Delivery (CI/CD) are key. Polyglot programming and persistence, a crack DevOps team, containers (immutable VMs would do too) and PaaS also differentiate microservices from SOA.

What are the advantages of microservices?
The “micro” in microservices does not refer to size, it refers to scope, which often also requires less code. Skinny archives lead to faster deployment times, enabling CI/CD. Each service can scale independently on X-axis (horizontal scaling) and Z-axis (sharding or geolocation based). Fault isolation improves: A misbehaving service, such as one with a memory leak or unclosed database connections, only affects that service. Microservices eliminate any long-term commitment to a technology stack, giving you freedom of choice. In a nutshell, they are easier to develop, understand and maintain.

Saying they eliminate any commitment to a given technology stack is a bold statement.
To be even bolder, open-source technology is driving the microservices revolution. The problem with SOA was the vendor lock-in with proprietary middleware, too often focused on ESB, SOAP, and centralized governance/persistence. Now, true SOA is finally possible because we have an entire open-source stack for every element of the vision.
Well-defined interfaces (typically using REST, CI/CD, DevOps, PaaS or containers) are critical elements of microservices.


But what about what Martin Fowler calls the “microservices premium”?
As Fowler puts it, “Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith.” If you can’t build a well-structured monolith, what makes you think microservices are the answer? If your monolith is a big ball of mud, your microservice will be a bag of dirt. But if you can attenuate the complexity by decreasing the coupling in your system with well-defined microservices, you will increase your team’s productivity—eventually.