The dazzling and highly-publicized success stories from heavy-hitters Netflix, Amazon, eBay, Uber, and others have caused microservices to experience a surge in popularity. And, our product plan involves helping our customers ride that trend by building microservices with our platform. To get the word out, we wanted to write something that explained what microservices are and why our customers might be interested in them.

Thankfully, to help wrangle this poorly understood backend architecture, we had the perfect person for the job: me, a mobile developer who at, one point, assumed a server room was where restaurants kept their waiters. So without further ado, welcome to The Idiot’s Guide to Microservices: What Are They Even? I began this quest by Googling, “what is a microservice,” and, boy, will that take you down a rabbit hole of tech jargon.

De-Jargonizer: Activate

If you’re like me, you’re peering into this enterprise architecture world with first-timer eyes, then you will find this table of tech-to-English translations valuable. And if you know a heck of a lot more than I do, then I hope you at least find my interpretations entertaining.


An SOA, or service-oriented architecture, is the idea that you can take your entire business application and fracture it into interdependent services. These services generally (and I stretch that by a mile) provide a specific business value, communicate with one another, share their resources, and evolve independently.

However, there is no universal agreement as to the specific rules an organization must follow to qualify as an SOA enterprise, as documented by Martin Fowler, one of the founding fathers of agile. You may have had an idea of what SOAs look like, but throw a dart into a room of software architects, and you will puncture someone with a different opinion—and probably someone you should apologize to. Why did you actually throw that dart? The dart was a metaphor.


I could not resist placing this definition right after SOA, refresh this article in two weeks for a fascinating definition of SOAP OPERAS. Sorry, let’s rinse off that bad joke and lather our hands up with this spotless definition of SOAP.

SOAP, or Simple Object Access Protocol, is a popular way for services in an SOA to communicate with one another. Services can send and receive SOAP messages over any communication protocol (HTTP, TCP, UDP, etc.), which makes them platform-independent. The messages, crafted in machine-readable strings, come packed with a defining message structure, encoding rules that specify the data types within, and a representation of requests/responses made of/from each endpoint… I think.

TL;DR: heterogeneous services can use SOAP to communicate with one another over a network; and doing so enables loose coupling. Oh no, now I’m writing jargon…

Heterogeneous...ness (That’s a Word, Right?)

Real quick! Rather than restrict product teams to building every application component on top of an identical set of technology, a heterogeneous approach lets them choose the best tools for their use case. But what about that other jargony-thing I wrote?

Loose Coupling

I feel like we need to wrap this entire blog in “air quotes.” In software, two components are tightly coupled when a change in one requires a change in the other. More importantly, one component needs to know how the other does its work to draw a desired result.

Conversely, a loosely coupled pair of elements may rely on one another with limited or no knowledge of the other’s internal workings. SOAs promote loose coupling through the use of platform-agnostic messaging channels and protocols like SOAP, REST, and others.


The opposite of loose coupling. A monolith is the result of building every business value and functionality into a single core application. When first building a product, a monolithic strategy has significant upsides: development moves quickly, the tech stack remains consistent, data remains in a centralized location, access to functionality is at the fingertips of every developer, and others.

But as a product ages and the teams behind it get bigger, the downsides kick in. Release cycles slow considerably as changes of any kind (big or small) require a full-product release. Complexity can grow exponentially when even a single team ignores best development practices (invariably, at least one of them does). And conflicting priorities between business and development teams put a stranglehold on what actually gets through the product pipeline. Services were designed to change that.

The Promise of Services

Like a Phoenix, microservices were born in the ashes of their former incarnation: services. Still in use today, architects conceived services approximately one decade ago, and Microservices are here to fulfill their original promise. SOAs, like sideshow snake-oil salesmen, promised the IT world something of a miracle cure for intractable monolithic applications.

Enterprises were dealing with ever-growing backlogs and political in-fighting; meanwhile, their startup competitors built scalable, fast-moving products that ate away big-business market share. Presto-magico-service-o!? Enterprises could break apart their monoliths by pulling core business functionality out of the main application and into mini-monoliths.

These mini-monoliths or, better yet, miniliths (I call “trademark!” You just call trademarks out loud like shotgun, right?) were designed to encourage agile practices, assign full product ownership to a horizontal team, and provide easy access to the service for whoever required it. Pretty stellar! So what happened?

A Fall From Grace

We’re discussing a “hot tech trend” here, and nearly all tech trends follow the fad pattern—fads like breakdancing. Breakdancing found its renaissance in the 90s, exactly when I was growing up. Bboys and Bgirls threw down large slabs of cardboard, pumped up the bass on their boomboxes, and twisted their bodies in captivating ways.

I remember seeing someone perform a flare for the first time, then a spinning headstand. With their perfectly-executed moves, those dancers inspired me to become just like them, and that’s exactly what I did. Nearly 20 years later, I smile wide when I pass my hallway trophy case brimming with championship breakdancing medals–yeah, no.

Fads fade because the professionals that set them into motion have practiced for years; meanwhile, amateurs galvanized by their success struggle to replicate the results. While a few talented individuals crafted their services with care, the rest of the IT world went about it like a bunch of pre-teen Stanleys: enviously ogling at the people who made it look so easy.

According to Martin Fowler, the majority of enterprises do not migrate to true SOAs; rather, they simply move complexity from one place to another, specifically, to the ESB. An ESB (enterprise service bus) is a piece of middleware designed to handle the communication layer between services and their consumers. Companies employ ESBs to mitigate the difficulties of properly decoupling a business process from its monolithic mothership.

However, the result is a black-box solution that technically “works,” but is slow to change, impossible to test, and beyond the organization’s control. And this is why Jim Fowler rebranded ESBs to a more appropriate initialism: Erroneous Spaghetti Boxes.

Are Microservices Here to Save the Day?

Have you ever found yourself explaining something only to have your listener regurgitate a twisted, clearly misunderstood version of what you just described? If you’re not sure, think back to any conversation that involved a suspicious amount of head nodding. Yep, that’s it. And that’s precisely how developers felt when the enterprise world chewed up service-oriented architectures and spat out whatever this thing is:

Spaghetti Architecture

And in that social situation, one wishes to correct misunderstandings. Developers have done so by rephrasing their original point in the form of microservices. Microservices at their core provide the same benefits originally promised of services. Generally, they follow these conventions:

  • Network-accessible: No sign of custom spaghetti-box code here. Microservices strictly limit themselves to platform-agnostic network protocols like HTTP, TCP/UDP, etc. This practice, consequently, has spilled back into the SOA-world.
  • Deployed independently: True decoupling is a pillar of microservice architecture. Teams must be capable of deploying updates to their microservices independently of other components, especially their consumers.
  • Replaceable: Due to the first two conventions, one microservice may replace another simply by adhering to the service contract of the original. The contract in this case is an API specification.
  • Narrowly-scoped: A microservice limits itself to a specific business value or feature. Defining the scope of each microservice is challenging, but billing, photo storage, or location-based services are all par for the course.
  • Heterogeneous: I defined this before and now it’s coming into play. Microservices employ the libraries and technology that best suit their use case rather than those forced upon them by a monolith architecture.
  • Fully automated: Microservices are a terrific companion use-case for DevOps, the philosophy that bridges the gap between software development (the creators) and IT operations (the ones who get it up and running - and get it to work if it’s changed). Teaming up DevOps and microservices creates automated deployment, testing, and monitoring processes that improve service reliability and promote frictionless development cycles.

That all sounded like gravy to me, so I had to find the catch.

Microservice Architectures: Advantages and Disadvantages


  • Reduced Time to POC:Developers can build microservices using whichever tools best suit the business value they intend to provide. Combine that with complete data isolation and you have a formula for hyper-fast prototyping.
  • Owned by a TeamBy dividing business value into a collection of microservices, a small horizontal team can assume full ownership of a microservice. This empowers and motivates them to deliver an excellent product. By contrast, In large monoliths, developers are thrown from task to task; rarely do they feel their contributions are individually meaningful.
  • ScalableBuilt and published independently of other application elements, a microservice can scale as needed by the organization (which includes downscaling).
  • ReusableOnce built, the microservice is available to any consumer. And as it is meant to scale as needed, a microservice can handle the additional workload as well.
  • Fault TolerantBy isolating both its data and application servers from other components, microservices can fail without causing a full product shutdown. And when they do fail, their independent production cycle allows developers to patch them quickly with minimal bureaucratic oversight.
  • Easily GovernedBy definition, microservices provide a business value. And they mitigate risk by remaining independent of other components. Therefore, aligning their development with the interests of the organization is inherent in their design.
  • Budget-FriendlyTheir reduced time to POC, scalability, and independence make microservices affordable to launch and maintain. Their strict isolation helps organizations determine cost of operation for each microservice as well.


  • Network DependencyMicroservices communicate exclusively over standard network protocols, which means that a network outage or disruption of any kind (often beyond an organization’s control) will interfere with business operations. And, as the number of deployed microservices grows, so does the risk of a network outage putting one of these services in jeopardy.
  • Dependency HellImagine hundreds of application components relying on a microservice with an established contract (API spec). And now imagine the microservice team wants to redesign (or even slightly modify) their specification. Not only must the organization coordinate this change across myriad teams, they must also track who relies on whom at all times.
  • Strict ContractsSpeaking more to the point above, developers must be careful to define a microservice API specification robust enough to provide business value long after the initial release. That kind of foresight is rare, if impossible in some organizations, that renders microservices a tougher sell.
  • OverheadEach microservice requires its own DevOps processes. As the number of microservices within an organization grows, so does the amount of maintenance and monitoring required for up-keep.
  • Too Easy to LaunchThis is a strength-as-a-weakness scenario. The ability to deploy and incorporate microservices so simply can lead to overzealousness. Microservice-ifying everything before an organization fully understands the tradeoffs can lead to a failed or poorly executed re-architecting.

I think we’ve both learned a lot about microservices, wouldn’t you agree? A microservice is basically a software engineer’s fantasy come to life: an application component independent of its parent processes, built on whatever technology makes sense, and sparkly like a cyborg rainbow unicorn.

To learn more about cyborgicorns, err, microservices, I recommend the following resources: