Gartner Blog Network


What a Microservice Is Not

by Gary Olliffe  |  January 31, 2017  |  8 Comments

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):

Category: application-architecture  soa  trends-predictions  trends-and-predictions  

Gary Olliffe
Research Director
1 year at Gartner
21 years IT Industry

Gary Olliffe is a Research Director in the Application Platform Strategies (APS) team in Gartner for Technical Professionals (GTP). He covers a range of technical topics, including application architecture, service-oriented architecture, application modernization and business process management. Read Full Bio


Thoughts on What a Microservice Is Not


  1. Jim Bugwadia says:

    Gary, excellent points!

    At Nirmata (yes, our focus is application delivery and management!), we came up with five constraints to help qualify what a microservice is.

    A microservice needs to be 1) elastic 2) resilient 3) composable 4) resilient; and 5) complete

    More at: http://www.nirmata.com/2015/02/microservices-five-architectural-constraints/

    Any others you would add?

    Regards,

    Jim

    • Jim Bugwadia says:

      That should have read:

      A microservice needs to be 1) elastic 2) resilient 3) composable 4) minimal; and 5) complete

      • Gary Olliffe says:

        Here’s a definition we used in a recent research note – “A microservice is a tightly scoped, strongly encapsulated, loosely coupled, independently deployable and independently scalable application component”
        most of this matches up with your list. When it comes to designing a service “cohesion” also comes into play, things that change together stay together, since you are trying to avoid ripple effects of change and any need for coordination of updates/releases between independent services – you could argue that is an aspect of your “complete” constraint.

        • Jim Bugwadia says:

          Gary, thanks for sharing!

          Yes, I agree ‘cohesion and coupling’ principles very much apply in service design; like they do in OO / modular design.

          Since a service offers an interface, I opted for “minimal and complete”. Credit: Bjarne Stroustrup’s interface design principles.

        • Mike lowndes says:

          The issue I am seeing with vendors and clients in the commerce and other applications markets is that they use this definition… except the last word. This is a pretty fundamental discontinuity.

  2. Johan Theunissen says:

    See: The Expert (https://www.youtube.com/watch?v=BKorP55Aqvg)

    My conclusion; The expert makes a big mistake at the end of the clip, he gives up and says: “Of course I can … I can do anything … I can do absolutely anything … I’m an expert!”

    The Expert should have said:
    “Of course I can NOT! What you are asking is not consistent, not realistic. It is what we as experts call … business bullshit. Get back to your room, start using your brains, and come back when you have something useful, logic and realistic to ask me!”



Leave a Reply

Your email address will not be published. Required fields are marked *

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.