The wave of hype and excitement about microservices continues unabated. And where there is hype and excitement marketing teams will follow. Sometimes they get it spot on – especially where their audience is technologists that already understand the terminology. But sometimes they miss the mark and create confusion.
In the case of microservices we are seeing a stark split. Application platform and development tool vendors mostly get it right – no surprise, since they are mainly focusing on engaging with technologists who probably know a microservice architecture when they see one. But vendors targeting IT leadership and business leadership are much more prone to microservice-washing – often just in the hope of sounding cool and getting your attention.
Of course “microservices” does not have a standard, universal definition – there will be many flavours and interpretations of microservices – but the “microservice-washing” of technology that has very little to do with microservices is not helpful to the marketplace. When architects and IT leaders have a different understanding of the same term it creates confusion and risk.
In my research document Assessing Microservices for Cloud Native Application Delivery I published the following list of things that are not microservices or microservice architecture. I share it here now in the hope that it will help you spot vendors, providers, and even architects and developers misusing the term and guide them in the right direction:
- A simple API to a more complex service implemented as part of a monolithic application
- A service implemented with a small amount of code – it could be a microservice, but a small amount of code may still be coupled to other code and services or not be independently deployable.
- A service built and delivered without automation of testing and deployment and operations
- A service built on mutable compute infrastructure that is updated and patched separately from software deployment
- A service that has dependencies on its peers that prevent it from being changed and updated independently
- A large, coarse-grained service or monolithic set of services packaged in a Docker container
- A service exposed via API by another party (no matter how it is implemented, if you don’t control the implementation, this is just a service, as far as your application is concerned)
- A component, module, service or capability, labeled as a “microservice” by a vendor, over which you do not have deployment and management control consistent with your (real) other microservices
And last but by no means least…
- A published API – microservice architecture is an implementation detail that should be separated from the published interface specification
The most common misuse of the term microservices is the last one: Calling a service delivered or exposed via web API a microservice. This drives me nuts because the whole point of an API is that it encapsulates the service implementation – which might be microservices or something much less glamourous. You, the user of the API, should not know or care what architecture the provider is using.
Microservices architecture is an implementation detail for the service provider that, if executed well, should allow them to deliver a more scalable, resilient and rapidly improving service. If you’re service provider is selling you “a microservice” then buyer beware – it, might be a great API, but it is highly unlikely to help you deliver microservices architecture for your organisation.
I hope the list above will provide a useful checklist. If you see examples of these or if you see other types of misuse of the term microservice please share them in the comments below or tweet them at me (@garyolliffe)
Also, if you are exploring or using microservices architecture check out our latest research (Gartner customer content):
- How To Design Microservices for Agile Architectures (Gartner for Tech Professionals)
- How to Succeed With Microservice Architecture Using DevOps Practices (Gartner for Tech Professionals)
- Innovation Insight for Microservices (Gartner for IT Leaders)
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.