Microservices or a monolith – which one are you?

Written by

microservices or monolith

Subscribe to our Blog

Get the Latest News and Content

Microservices by Way of External Services

Microservices Internally and Externally

One analogy of a microservice architecture that I personally like is the idea of a large office setting with disparate departments communicating through an internal mail system. I imagine manilla envelopes being passed around, carried on carts through hallways, up elevators—passing the information one department needs to the next department. In this situation the system is all serving one goal, much like a microservice architecture where the microservice appears as one unified “app” (the whole office) to the user, but underneath it is made up of so much more.

I think this view can be limiting, however. The same way you can have a complex architecture that is internal to an organization you can have a small simple architecture that is dependent on a much more complex system outside. For example, imagine a small building in an otherwise towering metropolis. One lone worker makes this business go, but she spends all day on his bike as a courier running between buildings, gathering one bit from here, dropping it off there, and carrying some parcels home to be shipped off elsewhere in the world.

In this example the “simple app” of a single small building (perhaps it is a shipping business by trade), really doesn’t need much itself, but relies heavily on the external world—the places it’s picking up packages and shipping them off to. It ends up being a simple system itself, but it’s deeply intertwined with complex systems around it to make it go.

I think our definitions of what “microservice” means vs. “monolith” are often much too narrow.

“We’re really more of a monolith”

Similarly, recently I was talking with a friend and discussing the system architecture of his company’s main application. He described it to me as “not really very microservice-y,” but then went on to talk about it in more detail. There is “only” a database and one front end service that calls a single backend API—however that backend is working with many external services to process what it needs to feed around to the front end.

In this world he’s like the example of the small shipping shop above. It may appear small and simple compared to some other systems which are built with their complexity largely being internal… But even this small shop may have more “departments” than the huge one. It’s not a monolithic architecture, it’s still very microservices—in the sense that it is a simple system but has many external dependencies. It’s just that not all of those services are internal, or owned by him and his company.

There are a few other ways seemingly “simple” architectures actually look more like microservices as well. Another one we see at Helios is having a “monolith” that has an asynchronous jobs framework (like Celery in Python). We can look at a job type like a microservice, even though physically it runs on the same node. Visualizing, and troubleshooting these architectures looks much the same as complex “traditional microservice” architectures.

Microservices architecture
A “simple service” made micro service architecture by way of interacting with many outside services.

The reason the distinction matters is when it comes time to troubleshoot problems. When the system breaks down, it doesn’t matter if the services are internal services or external services falling apart—what matters is that you have tooling in place to find out where the breakdown is.

Troubleshooting Microservices with Helios

If an app is truly a monolith, you can simply read the errors on the compiler or the interpreter and add the missing semicolons. But when an app is actually a microservice (due to internal or external services) you’ll need tooling in place to show you where and how each bit of data is being communicated, whether something was lost in translation, or if you’re just not meeting (API) expectations.

That’s where Helios comes in, whether your microservices are your own or someone else’s, you’ll want to know what was sent, when it was sent, what went wrong, and you’ll love the ability to generate tests to avoid the same problems in the future.

Helios does this for you—internal, external, all of the above—so your devs can spend less time trying to figure out what went wrong and get back to doing what’s moving the needle forward.

Try Helios out for yourself.

Subscribe to our Blog

Get the Latest News and Content

About Helios

Helios is a dev-first observability platform that helps Dev and Ops teams shorten the time to find and fix issues in distributed applications. Built on OpenTelemetry, Helios provides traces and correlates them with logs and metrics, enabling end-to-end app visibility and faster troubleshooting.

The Author

Related Content

Adopting distributed tracing while meeting privacy guidelines
How to adopt distributed tracing without compromising data privacy
Engineering teams can both drive productivity and comply with their company’s privacy policy when introducing distributed tracing into their tech stack...
Read More
Kubernetes Monitoring with Open-Telemetry
Kubernetes Monitoring with OpenTelemetry
Unlocking the Full Potential of Kubernetes: Revolutionize Your Monitoring with OpenTelemetry Organizations increasingly deploy and manage their applications...
Read More
Developer observability, data insights
Beyond Observability and Tracing: Doing More With The Data We Have
What is observability and why isn’t it enough? Here’s more we can do with system and instrumentation data from OTeL & more sources to provide development...
Read More