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.
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.
