Helios is now part of Snyk! Read the full announcement here.







Microservices or a monolith – which one are you?

Written by

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 an applied observability platform that produces actionable security and monitoring insights. We apply our deep runtime data collection capabilities to help Sec, Dev, and Ops teams understand the actual application risk posture, prioritize vulnerabilities, shorten troubleshooting time, and reduce MTTR.

The Author

Kendall Miller
Kendall Miller

Kendall, International Expansion at Helios has been working in cloud native for the last ten years helping businesses make sense of their infrastructure and ship software in a way that delights engineers. From sales and operations to work as an executive he can do many things well enough to eventually replace himself with someone who does it much better. Kendall holds two masters of religion which are both almost irrelevant to his day to day work.

Related Content

Challenges of existing SCA tools
Challenges with Traditional SCA Tools
Application security testing tools are designed to ensure that applications are put through rigorous security assessments to identify security flaws within...
Read More
Banner for blog post - Scaling microservices - Challenges, best practices and tools
The Challenges of Collecting Runtime Data
Collecting data in real-time plays a crucial role in securing, monitoring, and troubleshooting applications. This real-time data, often referred to as...
Read More
Helios Runtime for Appsec
Helios Runtime for AppSec: The missing link in application security
Modern development teams increasingly rely on open-source packages to rapidly build and deploy applications. In fact, most, if not all applications consist...
Read More