What are microservices?
There are many ways experts describe microservices, but no single agreed upon definition. Basically, it’s the idea that instead of building monolithic applications, developers build a series of components that make up the app. IDC analyst Al Hilwa describes microservices as “a more granular software architecture in which application components are designed and evolved independently.” The components are stitched together using common APIs. Basically, an app or service is broken up into many different components and glued together with APIs.
Sound familiar? Microservices harken back to a buzzword of yesteryear: Service Oriented Architecture (SOA), which is the idea of building components of an application separately.
“Enterprise interest in microservices is driven by looking for a next generation approach to service oriented architecture, as well as the use of microservices with containers,” says David Linthicum, senior vice president at consultancy Cloud Technology Partners.
While they’re similar, most experts say SOA is typically more limited to a single programming language and development environment using more traditional infrastructure components. Microservices represent a comparatively more agile methodology of developing complex applications made up of small, independent processes. Microservices that make up an application can be written in different languages, communicating with each other using standardized APIs and hosted on next-generation infrastructure, such as in virtualized or public cloud environments while using application containers.
The microservice approach offers a number of advantages:
- Agility: By decoupling the components of an application, each individual part can be developed independently. “You no longer have to move your entire dev team in lock-step,” says Sid Sijbrandij, CEO of startup GitLab, which is a code repository that competes with GitHub. Instead of having a 100 people working on a single app, you could have 10 teams of 10 people each developing components of the app and deploying new features when they are ready. Instead of having scheduled updates and waiting for the entire app to launch, new features are launched as soon as they’re ready.
-Graceful degradation: If one component of the app fails it doesn't take down the entire app. “The goal is to minimize the blast radius of fails,” explains 451 Research analyst Donnie Berkholz. For example, if a bank’s site is built using a microservices approach, if the transfer money feature is broken, customers would still be able to check their balances. When services are independently built and deployed, then – theoretically -- if one service goes down it will not impact the others.
-Reduced synchronization across development teams. In a microservices architecture development teams create the pieces that make up an application independently of other teams. Each of those sections writes to a common API that all the components integrate with. Having development teams focus on just a single part promotes good coding practices, Sijbrandij says; single function teams become experts in that function.
Sign up for CIO Asia eNewsletters.