USE CASES

RESOURCES

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 microservicey—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 developer platform that helps you increase dev velocity when building cloud-native applications. With Helios, dev teams can easily and quickly perform tasks such as getting a full view of their API inventory, reproducing failures, and automatically generating tests, from local to production environments. Helios accelerates R&D work, streamlining activities from troubleshooting and testing to design and collaboration.

The Author

Related Content

microservices visualization
Seeing vs. Understanding — The Power of Visualization
Is it enough to see into your microservices? Or do you need to understand what's going on to troubleshoot? Here's how visualization can help.
Read More
Asset 37@2x-100 (1)
Unlock the power of OpenTelemetry and Helios through the OTel community demo
Developers can now experience hands-on the combined value of OTel and Helios when building distributed applications   OpenTelemetry (OTel), the emerging...
Read More
jaeger vs. helios, opentelemetry, distributed tracing
Jaeger vs. Helios: Which One Should You Choose?
Jaeger and Helios both offer distributed tracing capabilities. Look into the pros and cons of each for visualization, testing, APIs & replays.
Read More