Should I Use A Microservices Architecture?
Tags: architecture, microservices, webdev
Published: 2020-02-25 19:22:38

---
title: Should I Use A Microservices Architecture?
published: true
tags: architecture, microservices, webdev
description: Are you considering adopting a microservices architecture? Won’t it fix all your problems? Join me for a look into the realities of microservices!
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/mdgwj624zdcwh8d4z6c0.jpg
canonical_url: https://www.jamesmichaelhickey.com/microservices-architecture/
---

Microservices is a huge topic. However, it’s not a very _precise_ topic.

Martin Fowler agrees:

> While there is no precise definition of this architectural style...
>
> [https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)

# A Sea Of Confusion

Diving into the topic of microservices, you’ll quickly discover that there are many differing opinions.

For example, Martin Fowler suggests that [you shouldn’t start a new system using a microservices architecture.](https://martinfowler.com/bliki/MonolithFirst.html)

However, his peer Stefan Tilkov suggests that [you should always start with a microservices architecture.](https://martinfowler.com/articles/dont-start-monolith.html) 🤔

Udi Dahan has believed that microservices, as defined, are [still too fine-grained and potentially lack critical concerns around real boundaries and UI considerations.](http://udidahan.com/2014/03/31/on-that-microservices-thing/)

_Who should we believe?_

# Shifting Sands

Let’s face it: opinions in tech are always changing and are often not as black-and-white as we’d like.

“Best practices” are often shifting every few years.

Once we thought DRY was the best thing since sliced bread. Now we are told that sharing code can be one of the most damaging architectural decisions one could make.

_What about microservices?_

# Microservices And Distributed Systems

Most coverage about microservices is shallow, vague and contradictory.

> Sadly, however, there’s not much information that outlines what the microservice style is and how to do it.
>
> [https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)

To highlight this fact (it’s a very important fact), let’s look at [InfoQ’s Architecture And Design Trends Report for 2019.](https://www.infoq.com/articles/architecture-trends-2019/)

Notice that microservices is in the “late majority” section. This means microservices are fairly common in the industry.

![architecture and design report](https://dev-to-uploads.s3.amazonaws.com/i/u9qs9emyt7wqdn52x5y8.png)

Now, look at the 2nd section labelled “Early Adopters.” See that one called **_Correctly built distributed systems?_**

![architecture and design report](https://dev-to-uploads.s3.amazonaws.com/i/zr7kl5nqfr4qqoz2to98.png)

As an industry, in general, we’ve been _doing_ microservices, but _not well._

# When In Doubt, Clarify

However, let’s look at whether you should use a microservices architecture as a general concept.

We’ll begin by asking some fundamental questions about microservices:

- What is a microservice?
- What is a microservices architecture?
- How many microservices should be in my architecture?
- How big should they be?
- Should my entire architecture be comprised of microservices in order to have a microservices architecture?
- What about macro-services? Is there such a thing?
- If there is, are they better or worse than microservices? Why?
- What about my UI? Should that still be one massive single-page application?
- Can I use an MVC based web framework and still be using microservices?
- How autonomous should they be?
- How does this all relate to the cloud?
- Is serverless a kind of microservice architecture?
- If I do have a server can I still have a microservices architecture?

These _might_ seem like simple questions. But once you dig a little further you’ll find that the answers are not so straightforward.

# What Is A Microservice?

Martin Fowler recognizes that microservices don’t have a precise definition. However, he tries to clarify what a microservice might look like:

> ...services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams.
>
> [https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)


Given this definition, [the typical microservices architecture you’ll see](https://dev.to/educative/how-to-design-a-web-application-software-architecture-101-188b#monolith-or-microservice) will look like this:

![typical microservices architecture](https://dev-to-uploads.s3.amazonaws.com/i/nubo3oiq9q2qr2x4pvm2.png)

Each microservice can be deployed and scaled on its own. They are running as independent processes and communicate over the network. Each has its own database.

Ok. Now, take this example:

![Realistic Monolithic Architecture](https://dev-to-uploads.s3.amazonaws.com/i/c27k0wo3gvsjohwp2pdu.png)

This is a common architecture you’ll find in real companies who’ve been making money for a while.

Imagine that each of these monolithic applications handles separate areas like shipping, billing, etc.

The glaring problem here is that the shared database can lead to all kinds of issues that are typically avoided via proper encapsulation.

What some companies have done is _not_ re-architect their system to a collection of microservices, but applied proper encapsulation to their monoliths (via [bounded contexts](https://www.martinfowler.com/bliki/BoundedContext.html) from domain-driven design).

![Properly Bounded Monoliths](https://dev-to-uploads.s3.amazonaws.com/i/ev2llyaglx9z5kpik8s4.png)

# What’s The Point?

I have a question that exposes the general notion of what microservices are supposed to be:

**_What’s the difference between the microservices diagram and the properly encapsulated monoliths diagram?_**

The only difference is that the microservices architecture diagram is _sharing the user interface across the entire system._

What I find strange is that in most articles and discussions about microservices _the issue of UI is hardly ever mentioned._

Given the typical definition and explanation of microservices, the difference between the encapsulated monolith and “microservice” is _not_ immediately evident.

(What if we removed the UI from some of our monoliths, added a REST API to each and gave them all a shared UI? That sounds awfully similar to the typical microservices architecture diagram you’ll see…)

After all, _the biggest reason for moving to microservices is to enable different cross-functional teams to fully own their own products._

This works _very_ well given the properly bounded monolithic approach:

![Monoliths each owned by cross-functional teams](https://dev-to-uploads.s3.amazonaws.com/i/rhcb4l3mhl8885n0vvfm.png)

But, the general “microservices architecture” falls short on this:

![Typical microservices architecture ownership](https://dev-to-uploads.s3.amazonaws.com/i/okzpmqcu5e2cf7wr3ed0.png)

Who owns the UI? Everyone? No one? Create a new team?

# Putting On Our Big Boy/Girl Architectural Pants

The reality is that software systems are much more fluid and dynamic than we would like to think.

**It’s harder than we’d like it to be.**

Software architecture involves taking _many smaller ideas_ and putting them all together in a way that makes sense for your use case.

It’s _not_ about [taking one general idea and applying that to our entire system.](https://en.wikipedia.org/wiki/Law_of_the_instrument)

# A Practical Example
Imagine a business that has an existing legacy system.

This monolithic system is generally pretty risky to change. The business demands a faster time-to-market for some new features.

Should we rewrite the entire system as a collection of microservices?

It would make more sense to add new functionality via focused and encapsulated services that own dedicated business functions.

![Microservices add additional functionality to the overall system](https://dev-to-uploads.s3.amazonaws.com/i/tov649j8wedv6ltmnyir.png)

This would be more of an evolutionary approach to software architecture (keep reading).

# Some Reminders And Side Notes

Again, it’s just not so cut-and-dry. We have to **_think_** about our existing systems, where we want the business to be in the near future and apply techniques and approaches that allow our business to keep growing and making money.

Wasting time rewriting your entire system as microservices might not work out so well ([1](https://segment.com/blog/goodbye-microservices/), [2](https://medium.com/@steven.lemon182/why-our-team-cancelled-our-move-to-microservices-8fd87898d952), [3](https://itnext.io/microservices-c8b5dbdd58b8), [4](https://rclayton.silvrback.com/failing-at-microservices)).

> A poor team will always create a poor system – it’s very hard to tell if microservices reduce the mess in this case or make it worse.
>
> [https://martinfowler.com/articles/microservices.html](https://martinfowler.com/articles/microservices.html)

And don’t forget that most of us aren’t even building distributed systems correctly anyways:

> Awareness of the “microservices” architectural style may be moving into the late majority, but the related themes of “correctly designing distributed systems”, and designing for reactivity and fault tolerance are not so far along the adoption curve.
>
> [https://www.infoq.com/articles/architecture-trends-2019/](https://www.infoq.com/articles/architecture-trends-2019/)

# Evolutionary Architecture

This fluid and more adaptive approach to software architecture is sometimes called _evolutionary architecture_. This is, in my opinion, just a plain responsible approach to software architecture.

![Evolutionary Architecture](https://dev-to-uploads.s3.amazonaws.com/i/x5yndi6rvzqgc9iglo4b.png)

InfoQ has this approach listed in the “early adopters” phase. This indicates that most companies are still just “hammering away” with microservices.

> Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example.
>
> [https://www.infoq.com/podcasts/refactoring-evolutionary-architecture/](https://www.infoq.com/podcasts/refactoring-evolutionary-architecture/)

Since 2011, evolutionary architecture has been in the “adopt” category of ThoughtWorks’ technology radar.

**_It’s not really that new._**

> In contrast to traditional up-front, heavy-weight enterprise architectural designs, we recommend adopting evolutionary architecture. It provides the benefits of enterprise architecture without the problems caused by trying to accurately predict the future… We advocate delaying decisions to the latest responsible moment, which might in fact be up-front for some decisions.
>
> [https://www.thoughtworks.com/radar/techniques/evolutionary-architecture](https://www.thoughtworks.com/radar/techniques/evolutionary-architecture)

That sounds like doing responsible, reasonable and intelligent software architecture to me 😅.

If this interests you, I’d recommend watching [this 16-minute discussion by Randy Shoup.](https://www.infoq.com/interviews/randy-shoup-microservices/)

> Step zero is to take a real customer problem, something with real customer benefit, maybe a reimplementation of something you have or ideally some new piece of functionality that was hard to do in the monolith.
>
> Do that in the new way, first, and what you are trying to do there is to learn from mistakes you inevitably will make going through that first transition, right? You do it in a relatively safe way, but at the same time you do with real benefit at the end.
>
> [https://www.infoq.com/interviews/randy-shoup-microservices/](https://www.infoq.com/interviews/randy-shoup-microservices/)

As Randy later points out, it’s perfectly fine to leave certain parts of a system untouched if they have no real reason to change.

> There were still pages on this site that were on V2 architecture, simply because they continue to work, they got 100,000 hits a day, no big deal, and they were neither painful enough to migrate nor having the sufficient ROI to migrate. So, they just stayed and they happily stayed.
>
> [https://www.infoq.com/interviews/randy-shoup-microservices/](https://www.infoq.com/interviews/randy-shoup-microservices/)

# About That UI Issue…

You might be wondering about the shared UI that appears in most microservices architecture diagrams.

Is there a way to fix that?

Yes, there is. _But it’s not so simple as we’d like._

It boils down to allowing each microservice to own it’s UI components.

This allows individual teams to own the entire stack.

![Composite UI](https://dev-to-uploads.s3.amazonaws.com/i/a5dcu2fpe15uh829pclq.png)

# Composite UIs

_What happens when we have a UI that needs to display data from multiple services?_

The solution is to compose multiple UI components owned by those services.

![Composite UIs](https://dev-to-uploads.s3.amazonaws.com/i/s8rsuwzd8uhinqr7404t.png)

In many cases, composite UIs are much more complicated than the image above. But this is a starting point to help you understand where this approach leads.

# Not The Microservices I Knew

This isn’t what most people think of when they say “microservices.” Microservices usually don’t have the notion of having UI components that are owned by it.

In discussing this issue, Udi Dahan uses an example of a product’s price. Udi points out the fact that specific services need to own their UI. Otherwise, we break encapsulation.

> In this manner, no code outside the service boundary would know about the concept of the product price and thus could not end up coupled to it.
>
> ...I don’t really see how a [microservice] could end up having this level of ownership of data.
>
> [http://udidahan.com/2014/03/31/on-that-microservices-thing/](http://udidahan.com/2014/03/31/on-that-microservices-thing/)

# Size Doesn’t Matter… Or Does It?

You’ll hear that microservices need to be around 1000 lines of code or less. At least, I’ve heard that one before.

However, microservices need to own the data, behaviour and UI of a given business context.

We, as developers or architects, shouldn’t get to magically decide how big our services should be. It’s 100% totally dependent on the business context we are modelling.

In relation to the issues surrounding UI ownership, Udi Dahan points out:

> You’ll tend to see services that aren’t all that small, and probably not so many of them.
>
> [http://udidahan.com/2014/03/31/on-that-microservices-thing/](http://udidahan.com/2014/03/31/on-that-microservices-thing/)

Udi is considered one of the most highly respected experts in building distributed systems. And he’s told us – years ago – _that we’re doing it wrong._

Microservices are potentially _too micro_ because they aren’t respecting the boundaries of real business contexts. Instead of focusing on _size_ we ought to focus on _proper boundaries_ (which is a topic for another day).

# Conclusion

Should you use a microservices architecture?

**No.**

**_You should do what makes sense for your business._**

For example, your business might want to build new products that require a quick time-to-market.

You could add those new products as entirely separate monoliths that communicate with each other via event messaging to keep them loosely coupled.

![The new monolith is separated and encapsulated](https://dev-to-uploads.s3.amazonaws.com/i/awtb66jx6u63zyylm8vz.png)

They could be built as microservices that integrate back into the existing system via HTTP REST calls or event messaging?

![Existing monolith enhanced with microservices](https://dev-to-uploads.s3.amazonaws.com/i/bwmvxlpueu1w86nav4ge.png)

Perhaps there’s an existing off-the-shelf solution that exists which your company can purchase? You could build a custom API on top that will allow integration with the existing system.

![Off-the-shelf solution with a custom facade for integration](https://dev-to-uploads.s3.amazonaws.com/i/5k4lhqeqhl36o24rh26e.png)

There _are_ cases that call for splitting an existing system up into isolated components. They _could_ be microservices.

Or, you could use a [plug-in component-like system within a monolithic system.](http://www.kamilgrzybek.com/design/modular-monolith-primer/)

(I’ve written about [an approach to building modular monoliths using .NET Core.](https://www.blog.jamesmichaelhickey.com/How-To-Build-Modular-Monoliths-With-NETCore-Razor-Class-Libraries/))

We haven’t even talked about factors around team skill/competency, project management styles, organizational influences, etc. These are all factors that affect your software architecture!

In conclusion:

**It depends.**

> But, are there guidelines for smaller organizations? Absolutely. And again: the meta-point with all these things is “only solve problems that you actually have”.
>
> [https://www.infoq.com/interviews/randy-shoup-microservices/](https://www.infoq.com/interviews/randy-shoup-microservices/)

# Need Help?

I help Saas businesses improve their overall agility and time-to-market of new products and features.

I also offer guidance for teams using .NET Core who need help with building web APIs, framework migrations, improving development processes, etc.

[Get in touch!](https://www.jamesmichaelhickey.com)

Also, check out [my book about keeping your code healthy!](https://leanpub.com/refactoringtypescript)

# Keep In Touch

Don't forget to connect with me on:

- [Twitter](https://twitter.com/jamesmh_dev)
- [LinkedIn](https://www.linkedin.com/in/jamesmhickey/)