What Microservices Is Not

From what the term “Service” does not imply, from “What is a service (2016 edition)”:

  • “Cloud”
  • “Server”
  • “ESB”
  • “API”
  • XML
  • JSON
  • REST
  • HTTP
  • SOAP
  • WSDL
  • Swagger
  • Docker
  • Mesos
  • Svc Fabric
  • Zookeeper
  • Kubernetes
  • SQL
  • NoSQL
  • MQTT
  • AMQP
  • Scale
  • Reliability
  • “Stateless”
  • “Stateful”
  • OAuth2
  • OpenID
  • X509
  • Java
  • Node
  • C#
  • OOP
  • DDD
  • etc. pp.

We can apply a similar list to Microservices, where the term does not imply any technology. That’s difficult these days because so much marketecture conflates “Microservices” with some specific tool or product. “Simplify microservice-based application development and lifecycle management with Azure Service Fabric”. Well, you certainly don’t need PaaS to do microservices. And small is small enough when it’s not too big to manage, and no more. Not pizza metrics or lines of code.

So microservices does not imply:

  • Docker/containers
  • Azure/AWS
  • Serverless
  • Feature flags
  • Gitflow
  • NoSQL
  • Node.js
  • No more than 20 lines of code in deployed service
  • Service Fabric
  • AWS Lambda

Instead, focus more on the characteristics of a microservice:

  • Focused around a business domain
  • Technology agnostic API
  • Small
  • Autonomous
  • Autonomous
  • Autonomous

Most of the other descriptions or prescriptions around microservices are really just a side-effect of autonomy, but those technologies prescribed certainly aren’t a requirement to build a robust, scalable service.

My suggestion – go back to the DDD book, read the Building Microservices book. Just like DDD wasn’t about entities and repositories, microservices isn’t about Docker. And once you do get the concepts, then come back to the practitioners to see how they’re building applications with microservices, and see if those tools might be a great fit. Just don’t cargo-cult microservices like so many did before with DDD and SOA.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in DomainDrivenDesign, Microservices. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Betty

    People insisting that microservices/soa/service boundaries require/mean web services has bugged me for a while.

    Been trying to shift people towards a push messaging/cqrs/event sourcing mindset (tell don’t ask) but it can be a hard preconception to break.

  • > Technology agnostic API

    I think this inherently doesn’t exist. As close as you get is HTTP + data, but that still has some level of technological coupling.

    This also completely ignores queuing. Even AMQP isn’t truly agnostic. What about sockets? websockets are somewhat agnostic, but i still probably wouldn’t even count websockets to be agnostic.

    I definitely dream of a day of technology agnostic API access but it certainly isn’t here. Sadly, AMQP probably has at best a 1 in 10 chance of ever actualizing it. The WS* standards were supposed to have already solved all of this and we can clearly see the quagmire that became.

    People just are all about reinventing the wheel over and over and over resulting in their own fiefdoms. MEX->Swagger is a great illustration of this example.

    • jbogard

      Hmmm I think I might have not been specific. I meant platform – whatever server technology is being used. You couple to the protocol, not whatever server side technology was used. But I think it’s still a worthy goal – at least to favor technologies that skew on the spectrum?

      • In theory i’m likely in 100% agreement with you. It’s just reality doesn’t match up. Protocols definitely have platform dependence. SPDY and HTTP2 are further examples of platform dependence caused by protocol. Theoretically there will be mass market appeal of one or both of those and it will see a wide range adoption across server tech.

        However do you reasonably preclude all benefits of HTTP2 from your system, even if the benefits are the exact sweet spot your system lives in? (mostly rhetorical)

        I guess some of this also breaks down along internal vs external system access. Internally i’ll always choose a more robust protocol and tighter platform coupling. Externally my proxy will use whatever and then ingest into the opinionated network. Inside my system i own both ends of the wire, why should I lower my common denominator when i can easily require both ends support HTTP2, queues, fabric:// etc

  • Stephen

    My goodness. What outstanding advice. Clearly coming from a real world

  • Adi Bilauca

    Agree, totally technology agnostic. I guess microservices around bounded contexts tend to be more like self-contained systems?!

  • kiquenet kiquenet

    I’m new. Confused with WCF Service andMicroservices. Full source code sample Microservice in C# ?

    Focused around a business domain, may be
    Technology agnostic API… WCF SOAP (XML) and JSON …
    Small , WCF service can be small
    Autonomous ?

    • jbogard

      Man, I don’t even know where to begin. First of all, microservices are not dictated by any technology. I’d start with the Sam Newman Microservices book.