Microservices?! We Don't Need No Stinkin' Microservices!

EDITOR'S NOTE: Special thanks to Jeff Lutzenberger, Ph.D., for writing today's blog post. You can connect with him on LinkedIn. 

We don’t use the microservice pattern - but we’re still changing healthcare! I know what you’re thinking, “No microservices? Whelp, I can just stop reading now.” BUT WAIT! I promise you’ll still enjoy this article.

First things first, what is a microservice? Some dude named Martin Fowler has this to say about it:

"In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API."

In most growing development organizations with a monolithic codebase, it becomes increasingly difficult to know who owns a particular feature/module and even more difficult to work on code in parallel without managing merge conflicts all day. This is where the microservice pattern has been found to be useful [Amazon, Netflix].

While folders, libraries and namespaces help us organize code and decouple modules, the microservice pattern goes a step further by moving a module, compute resources and release cycle into an isolated environment. The pattern gives teams complete ownership of their module, and it has the added benefit of enforcing a strict, public API.

It is sometimes helpful to think of a service (or microservice) team as a company inside a company. Microservice teams may be expected to manage releases of their service, support older versions, provide a service level agreement (SLA) and provide general technical support for the service. All of this enables developers to focus on a smaller, more manageable piece of a much larger system. Sounds like a pretty good thing to me; and obviously not a concept limited to just software.

Ok, that sounds great; and if Amazon and Netflix do it, why don’t we? Well, for one, we have 13 people in our development organization. These folks are responsible for server code, Android, iOS, web, and mobile automation. We’re slightly smaller than the other guys :) Second, our codebase is just not that big.

If you’re reading this article, I promise you that you could hold the gist of our server or mobile code in your head. It would be a bit of an intellectual challenge and you’d be blinded (forever changed?) by the sheer awesomeness of the code, but you could do it. Now compare that to what we can only imagine (unless you work there) a Netflix or Amazon platform looks like. No one could possibly know the inner workings of every service at either of those companies; but you could probably navigate the service layer APIs. Especially with the help of service discovery and a little API documentation.

So does that mean we don’t think about scalable software development patterns? Of course not. Our goal is to make a high quality product as efficiently as possible. Currently, microservices would be overkill. If, on the other hand, we achieve our ultimate goal and really transform healthcare in this country, then our development process absolutely must scale. Maybe microservices will be the way we do that. Hopefully we’ll have some cool new choices when that time comes. In the meantime, our focus is on good engineering practices with, of course, services in mind. Here are a few things we’re doing now to prepare for the future:

• We’re writing isolated, decoupled code.
• We’re doing our best to minimize leaky abstractions.
• We create strict, public APIs for modules.
• We use private methods and expect that if we don’t, someone, somewhere will use our non-private methods.

We’re laying the groundwork for a service oriented architecture. As always, we’d love to hear from you. What are you doing to prepare your codebase for world domination?