Seems like every 5 to 10 years our industry, especially in the enterprise integration, or enterprise application space, we’re introduced to some new methodology or architectural style. We’re told that it’s the-best-thing-since-toaster-strudel and will make you 10 times more productive and make your enterprise more agile, flexible, able to respond to change, and whatever else that CIOs are willing to spend huge giant piles of money on. We’ve seen Enterprise Application Integration, Web Services, SOA, Component based architectures, ESBs, and on and on.

Today’s hot technology: Microservices

Well, guess what: chances are you’re not going to get microservices architecture right.

Honestly, I’m not saying that to dump cold water on your burning desire to try out new things. I do think there is legitimacy to microservices, and it’s an approach that grew organically over the years of watching failed committee-driven implementations.

But guess what? There is a foundation of prerequisites that must be in place first to be successful with this architecture (or any architecture 🙂 ) that, based on my observations, is lacking in more places than it’s prevailing.

By all means, fire up Spring Boot or Dropwizard, or no container. You’re not doing microservices just because you’re following the lemmings away from the App Server. Places like Netflix, Amazon, etc. seem to have some of the right combination of prerequisites to make it work…But ask your VPs of engineering, ask your Directors of computing what they would say if their internal teams were organised like Amazon. They would spoil their pants. Your company probably doesn’t and probably won’t get microservices right.

Most organizations are not structured for microservices

We all hear about Conway’s law, but this fact is the strongest reason why you’re not going to do microservices. People win. Culture wins. Paper processes and paper structure does not win. If you have a UI team, DB team, “services” team, each specialising in its own right, you’ll end up with systems that look like those tiers. There’s nothing wrong with that per se. But a tree-like structure and layers of managers above technological-grouped teams is an impediment to microservices-based teams.

REST is not a silver bullet

REST is great! I like the concepts, and the fact that for enterprises, it’s basically the HTTP implementation we talk about. I’m happy to get away from SOAP. HTTP and REST is understood, has great tools, networking equipment, proxies, etc. are all built with it in mind…But REST is not a silver bullet.

Modularizing applications is hard

How big should the service be? How deep should it be? Single responsibilities? Domain Driven Design bounded contexts, etc. This is all difficult to get right in practice. Doing it a few times and failing is the best (in my opinion) way to learn how to avoid the sharp edges, but properly modularizing your applications and your domain services is not easy.

We still don’t understand how to do event-based architectures

Why are we still connecting everything by RPC?! This one aggravates me than most. We still don’t know how to do event driven architectures correctly, and when a “new” architectural style comes about, we revisit all of the same mistakes we did with the previous one. BTW…. Microservices = REST.

Alright, this was a bit of a rant, but just wanted to bring some reality to the discussion around microservices.

At the end of the day, isolating “services” or systems at the process level is still not really loose coupling or “decoupled” systems. Runtime coupling is still very much present and maybe even more so. Never mind that the Fallacies of distributed computing still hold true. So maybe when we re-invent architectural styles, we frame them within the lessons learned?

You’re Not Going to Do Microservices: Sorry to Ruin Your Cheerios

About The Author
-

11 Comments

  • sleroy0
    Reply

    Nice article. Reminds me the caveats of EJB and such distributed system.
    I agree on the complexity to setup an event driven system when a lot of required components are not enough matures or very difficult to master.

  • skeptic of new technologies
    Reply

    Rest and microservices are for those scripting languages/frameworks like RoR, PHP, Python etc., because they don’t have other way to modularize applications, and communicate between these modules. Stop pushing this into Java Enterprise world. We have mature technologies like CORBA or JAX-WS.

  • Pablo
    Reply

    So basically you’re assuming that everyone is dumb enough to screw things up, that organizations can’t change is they see advantages in using microservices, that people is so dumb that they are not going to spend time investigating the foundations of microservices and the requisites for running microservices successfully, like if nobody had access to youtube and amazon books where people ten times more capable than you teach how to evolve from monoliths to microservices, how to do things correctly, etc..

    • WB
      Reply

      I’d tend to agree with you Pablo!
      I also think part of the problem is that everything is overly complex, and it is hard and time consuming to build reusable microservices. However there are new technologies emerging all the time that make this simpler and easier, like Warewolf ESB, which uses prebuilt services and you can very easily build and manage microservices into your architecture. It’s a nice platform for developers.

    • Carnot Antonio Romero
      Reply

      There’s a difference between saying “microservices are a bad idea” or “you personally and individually are too dumb to get microservices” vs. “many institutions won’t get it together to do them right, so proceed with caution.” I take this post as cautionary, a sign to proceed with eyes open.

  • Kai Wähner
    Reply

    I really like this post, Christian!

    Even though I have posted a Microservices article here, too, which explains how to create a good Microservices archtecture…

    “Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus?” (https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/)

    … I still think that these are good arguments of Christian!

    Especially, I agree that many organizations are not ready for Microservices.

    I also absolutely agree that REST is no silverbullet. That is why I usually do not say Microservices = REST. Mobile and Internet of Things are coming “these days”. REST is not the right choice. We will see other technologies such as WebSockets, MQTT, AMQP, etc. to be used for this (see my linked article for that, too).

    Working for TIBCO, I disagree on the “event-based part”, of course 🙂 Yes, not every enterprise is ready for it yet, but technology and products are. With good consulting, enterprises are ready or getting ready soon.

    Best regards,
    Kai Wähner (@KaiWaehner)

  • Ian Goldsmith
    Reply

    Nice article, well-written and well thought out. Only minor quibble I have is that I don’t think your statement that Microservices = REST is accurate. I’ve seen quite a lot of impetus around lightweight messaging (Rabbit and other AMQP implementations).

    Ian

Leave a Reply to sleroy0 Cancel reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>