What the Heck is a Microservice Architecture, Anyways?

You're the Red Ranger, karate all-star and leader of the Mighty Morphing Power Rangers. You're sitting in the head of the Megazord; the alien-busting, sword-swinging robot formed by the individual Zords of each of the other Rangers. In the Megazord you're invincible—nothing Rita Repulsa sends at you is any match for your tremendous power. You stare at today's "monster-of-the-week"; a large alien covered in eyeballs with tentacles for arms. Your face twists into a coy smirk; this should be over with a single swing of your skyscraper-sized sword. "Alright Rangers," you yell out, "let's get him!"

It doesn't get much better than this.

"Uhh, there might be a problem?" Kimberly, the Pink Ranger says nervously.

"What's that?"

"Billy has mono, so he couldn't make it."

You stare down, realizing the left leg of the Megazord is missing. Almost if coming to the same realization, the Megazord starts to teeter uncontrollably. With a loud crash, you slam into the ground. The world moves in slow motion as you're tossed into the wall of the cockpit. As you slowly pull yourself out of a daze, you look up to see the monster quickly approaching.

"Pick us up!" you yell at Zack, the Black Ranger, who controls the arms of the Megazord.

"More bad news," he replies, "but QA is still doing regression tests on the bug we found in my Zord last week. It wasn't ready for release today."

Probably how you're feeling, right now.

Ignoring the fact that the Megazord is obviously more powerful than the individual components that make it up (because it would be less of a spectacle if a super cool giant robot ended up splitting into objectively less cool smaller robots), I wanted to try and introduce to you the idea of microservices, and why they've become a popular architectural pattern over the past few years. It's not a perfect analogy—really I just wanted the opportunity to make a Power Rangers reference.

If you've looked at job postings for software developers within the past couple of years, there's a really good chance you've seen the line "familiar with microservice architecture". You may not know exactly what it is, but there's certain things you can almost immediately infer: it involves small services, and it's a pattern of architecting something. You think to yourself, "well, I put Ruby on Rails on my resume, and all I did with that was write a Hello World app—I'm sure I can get away with the passing knowledge of microservices achieved by reading an article on the internet." I'm not going to make any promises, but hopefully by the end of my article you can look that interviewer in the face and say, "yeah, I AM familiar with microservice architecture!" before bellowing a guttural howl, tearing the sleeves off your interview top, and flipping the desk of the interview station in a single, explosive toss.

If you read my article about declarative programming, you may have seen me mention that declarative programming had an antithesis. Microservices also have an antithesis, known as Monolithic Architecture. This is just a way to describe a system built as a single logical unit. In simpler terms, this just means a single codebase that contains functionally different layers (for example: server-side application, presentation layer, database layer, etc). Historically, this is how enterprises have been building applications. There are, however, some downfalls to having all of your application code live in one spot. As a codebase grows through the never-ending cycle of operational churn, so does the ability to maintain it. You'll start to incur technical debt. New features become more difficult to implement. Bugs become harder to find. Developers will begin to stage revolts against upper-management. The Czar will be overthrown in a violent protest.

Too soon?

The microservice architecture pattern grew out of the need to mitigate the difficulties of maintaining an enterprise application as it scales in size. Patterns popped up over the years to help with this—for example—domain-driven design helps to manage side effects that might occur when functionality becomes too tightly coupled to different areas of your application. Over time, however, it becomes difficult to continue maintaining this structure—this is where microservices come in. Microservices seek to strip common functionality out of a codebase and abstract it into its own service. Because this service runs independently, it can now focus solely on a specific business boundary.

I'm going to try and break down a microservice into its individual characteristics (kind of like breaking an application into microservices—that's your first example, ha ha).

They're Small

"Alright Captain Obvious," you speak aloud to the screen you're reading this article on. Yes, I understand that this was probably implied from the name, but what might not be as obvious is how small they should be. The answer isn't as simple, unfortunately: it depends. What if you break a service up into too many microservices? What if you end up with one bloated microservice handling too much functionality?

Here's a good rule of thumb: decide the business boundaries of the service, and start from there. Here's an example, say you have an app where users can create profiles and write articles (boy, this sounds familiar). You've created a function to handle uploading photos. This photo needs to be transformed & uploaded to an AWS S3 bucket, and then metadata needs to be saved to a database. This has a pretty clearly defined business boundary (photo upload management), which seems like a good candidate for being stripped out and becoming a microservice.

You might hear talk online about the "two pizza" rule (popularized by Amazon), which means the microservice should be small enough that the team working on it can be fed with two pizzas. One time in college I ate an entire extra large pizza in one sitting, so I'm not too confident with this metric. I also think there's no exact formula, and while this exercise might work well for a large enterprise, the value of microservices is much more universal than that. This should be determined by whatever best suits your personal and/or organizational needs.

Not the exact pizza I ate, just a dramatization.

Single Responsibility Principle

You may be familiar with this term (it's the "S" in SOLID). If you're not familiar, let me explain. It's the idea of grouping things that change for the same reason. Now that I've given an incredibly vague answer, let's go into it a bit deeper.

SRP maintains that a class should only change for a single reason. If there's two reasons that it might change, it should be divided into two classes. This might sound a little overkill, but as your application grows in complexity, it's important to maintain resiliency in your code. When you have a class that has multiple reasons to change, it's hard to predict side effects. One change will unintentionally influence how other responsibilities are implemented by the same class. Everything becomes tightly coupled to each other; if something needs to change, it could potentially break other functionality in the class.

Microservices borrow this same principle, in that each service should only manage a single responsibility. Each service has its own task, but can communicate with other services to solve larger, more complicated business problems. Teamwork makes the dream work, after all.

If your microservice looks like this, you're doing it wrong.

Communication

In a microservice architecture, each service should encapsulate their own domain knowledge, and the implementation details of each service are hidden from the others (another throwback to my article on declarative programming). This means that in communicating with our photo uploading microservice, the client doesn't need to know anything about how it's actually processing the images. It just cares about handing off an image to be processed. With microservices, it's important to carefully design well-defined APIs. It's also paramount that you properly handle versioning as to not break the services that rely on it. Taking the time to properly draft out the APIs of your microservices will save you a big headache down the road.

They're Independently Deployable

One of the pain points of a monolithic system is that change cycles are tied together; a change to a single, small part of the application necessitates the entire application being rebuilt and deployed. Microservices should be able to be independently deployed without a need to make changes anywhere else. If a change to a microservice requires changes to the main application, chances are the functionality of your microservice is too tightly coupled to your codebase.

Decentralization

What is this, blockchain? (laugh track plays). Decentralized governance is an important component of microservices. If a service is too tightly coupled to other business processes, you lose out on some of the main benefits of a microservice architecture. If your services are decentralized, you're not bound to any specific technology stacks, libraries, or frameworks. You could be running your photo uploading functionality through Golang, but handling account management through a Node API.

It's not just the conceptual models of an application that can be decentralized, but data storage as well. Microservices are responsible for persisting their own data & state. Where a monolithic system would have a data layer to manage data persistence across the entire application, microservices are much more flexible. You can have your services run different instances of the same database—or, if you're feeling particularly sassy—an entirely different database system altogether.

Why Microservices?

Scalability

With a monolithic application, you can achieve horizontal scaling by running multiple instances of the app behind a load balancer. However, this requires scaling the entire application, and not just the parts that require additional resources. Theoretically speaking, if 90% of the traffic on your site was going through a single function, you'd need to scale out your entire application to manage that single endpoint. Because microservices are individually deployed, they can also be individually scaled to meet demand. Neat.

Resiliency

One of the benefits of a microservice is that if it fails, it doesn't torpedo your entire application to the bottom of the ocean. Keep in mind that the proper fault protection must be in place—because the services are autonomous, the client doesn't know the health/state of your microservices when they send requests to them. It's important to manage these scenarios through a combination of monitoring and other fault protection measures (retrying requests, short-circuiting to avoid bottlenecks, etc).

Faster Development

Having an autonomous service means it's easier to add features and manage bug fixes. Changes can be made independent from the main application. You can safely roll back to a previous version if an update goes wrong. You can implement changes without worrying if it's going to cause side effects somewhere else in the app; this means less time to test, and fewer overall concerns to address.

Designing Microservices

There's no perfect formula to designing microservices. It requires careful deliberation about the business domain and goals of the application. Defining the boundaries of the individual services will be the biggest challenge, but making sure to follow the Single Responsibility Principle will help to provide an idea if your service is doing too much. Microservices designed around a business boundary should be "vertical"—meaning—not designed around a horizontal layer of your application. You wouldn't move your entire data layer to a microservice, because different data is contextualized to different domains in your application. Microsoft has compiled a handy list of microservice design patterns you can read here.

It's Not Without Drawbacks

Hold on, we need to talk.

As cool as it sounds, microservice architecture doesn't always fit organizational needs. There's a sort of teeter-totter effect with microservices; for all of the benefits that come with them, so does the complexity of managing your architecture. You may be saying, "but Keith, wasn't microservice architecture born out of the need to manage application complexity in monolithic systems in the first place"? Don't worry, the irony isn't lost on me—but you're essentially trading one problem for another.

In monolithic systems, it becomes difficult to add new features or update existing ones, because responsibilities or functionality could be widely spread across the application. A change to one service might have a ripple effect across the rest of the app. This causes a lengthy integration process as all teams need to be aware of the changes being implemented. Microservices tidy this up by making sure the each service is managing a single responsibility (and to that effect, different teams can manage different microservices). This sounds great, but now you're left trying to manage a massive web of autonomous services.

Have you ever had a bunch of things you needed to carry into another room but you don't want to make more than one trip? So you carefully tuck items between your arms; your left pinky hooked around the handle of something much heavier than you should ever rely on your pinky to carry. You start to slowly shuffle your feet, carefully balancing the items as they inevitably start slipping through your grip. This is basically what managing a microservice architecture is.

There's also other things to consider. Because each microservice is responsible for its own data persistence, it's difficult to maintain data integrity across multiple services. Having overly chatty services could increase latency times as requests jump back and forth between services. Also because of decentralization, there's a lack of governance in the code. Without setting specifications or standards, the independent nature of these services can make things difficult to maintain (especially if they're being written in different languages). It requires a different set of skills to manage this sort of highly-distributed architecture, so this could be considered another deterrent for an organization.

The important thing is to understand your organizational needs, and weigh the costs against the benefits. If you decide that microservice architecture is a good fit for you, go wild! There's so much more to say about designing microservice architecture, and there's a lot of great resources out there if you want to continue your research.

So the next time an interviewer asks if you're familiar with microservice architecture, just think back to this article and say: "I think it has something to do with the Power Rangers?"

Thanks for reading, I hope I was able to teach you something!

Best Wishes,
Keith Brewster (Twitter)