Sean Kennedy
Sean Kennedy
June 3, 2016

Microservices without Mega Operations (Using BlueOak Server Services and npm)

When I first reviewed Darrell’s article, “Developing an Aggregation Tier with BlueOak Server,” I had an unexpected experience. The kind of experience that, by its nature, is unexpected, delightful and takes a while to fully understand: I learned something new about something I thought I knew.

In this case, that BlueOak Server Services can be used to implement a microservices-like architecture. Yes, it’s definitely not “full-out” microservices, as was well described in this video, “ Node, npm and Service Oriented Architecture,” but there are definitely significant similarities.

Now that I’ve had a month to mull over this “revelation,” let me try to share some of my “new thinking.” First, I’ll compare what we’ve been doing with BlueOak Server Services and npm to a “full-out” microservices implementation. Next, I’ll discuss the different trade-offs between the two approaches. Finally, I’ll outline some options for going from the aggregation tier architecture Darrell described, to a “full-out” microservices implementation, or perhaps a “hybrid” implementation that makes the most sense for your system.

Comparing Architectures: BlueOak Server Services vs Microservices
Let’s get the big difference out of the way: once it’s deployed, the integration tier architecture discussed by Darrell is a monolith, whereas a microservices architecture has its services deployed individually to form a distributed system.

But, looking at a BlueOak Server Service on its own, we see that it is a potential microservice (based on Wikipedia’s description of the properties of a microservices architecture):

  1. It is easy to replace, both for testing and deployment (using BlueOak Server’s dependency injection and test facilities, and using npm as described by Darrell and in the video from the npm team)
  2. It provides a unified set of related capabilities, such as interacting with a particular database or third-party service and applying business rules to transforming data to and from different sources
  3. It is technology independent and can be implemented independently of the technology choices made by other services (excepting the requirement for a Node.js module interface)
  4. It supports symmetrical interactions with other services, both depending on them and being a dependency for them

This was the heart of my revelation, that we’ve been realizing many of the benefits of microservices while deferring implementation of many of their complexities.

Discussing Trade-offs: BlueOak Server Services vs Microservices

Let’s take a closer look at the trade-offs between a BlueOak Server Services monolith and a “full-out” microservices architecture.

There are well-known benefits of a microservices architecture over a monolithic deployment, including improved scalability and fault-tolerance. These remain true for this comparison too. The other side of those benefits, however, is the additional complexity and overhead of managing and operating a microservice. It’s not that there isn’t benefit in taming that complexity and driving out that overhead through tools and automation, there is. But for many of the teams we work with, those tasks are better deferred to a future point after the immediate business needs are addressed and/or runtime profiles indicate a benefit of migrating to a microservices architecture.

Before deployment, however, teams using BlueOak Server Services and npm can realize many of the benefits of a microservices architecture, such as:

  1. Implementing, testing and delivering each service independently
  2. Being necessarily intentional about connections between services
  3. Having to think of all service APIs as public APIs

Meanwhile, the “traditional” operations team that likely already exists can ease their way into the DevOps world with a more familiar deployment process and runtime topology.

Turning BlueOak Server Services into “Full-Out” Microservices

Ultimately, I’ve come to see using BlueOak Server Services as a way to build a well-structured monolith that is ready to decompose into microservices when there is a need. Indeed, you can choose which bits of the monolith you “factor out” to meet the particular needs you’ve identified, and keep the rest integrated. You even have the option of running the BlueOak Server Service both in the monolith and as a separate microservice. Which could make a lot of sense if there are multiple uses for the service, but they don’t all cause it to ”run hot” (assuming load and scaling was the reason for moving it to a microservice).

Now, while I have several cases in mind for doing this on a system we’ve built, we’ve not actually extracted a production BlueOak Server Service as it’s own microservice, so take the following as hypothesis. If we get to implement it, I’ll report back with our results, but if you do it first, please let me know how it goes.

(Proposed) Exhaustive steps for creating a microservice from a BlueOak Server Service:

  1. Create a new BlueOak Server project
  2. npm install –save ${your-bos-service}
  3. Copy any service-specific config from the monolith’s configuration to the new project
  4. Write a Swagger spec to define the API contract for the new microservice (basically just exposing the API already implemented by your BlueOak Server Service)
  5. Implement a thin BlueOak Server Handler to pass requests to your service and responses back out to the client

(Proposed) Exhaustive steps for changing your monolith to use the new microservice

  1. npm uninstall –save ${your-bos-service}
  2. Replace the old service-specific config in the monolith’s configuration, with the configuration necessary to locate and authenticate with the new microservice
  3. Create a new BlueOak Server Service that has the same API as the one that’s been factored out, but which makes a REST call to the new microservice instead
    1. (if you give the new service the same name as the old service, you won’t have to change anything in the services that are already using it)

(If you’re not familiar with BlueOak Server, Trust Me™, these two sets of steps are straightforward to implement.)

If you repeat that process across all your BlueOak Server Services, you’ll end up with a “full-out” microservices architecture.

Of course, just because you have a BlueOak Server Service, doesn’t mean it will make a good microservice. Still, if you’ve taken the business mediation/service binding approach described by Darrell, those mediation and binding services will be the leading candidates for conversion to microservices. Ultimately, you should be using a combination of runtime metrics and (evolving) business needs to identify services to convert.

It may even turn out, which is my suspicion for most systems, that you only need to create microservices for a few of those BlueOak Server Services. In which case, you’ll have discovered the (current) “hybrid” topological equilibrium for your system’s runtime.

Getting to Goldilocks

Finding just the right balance for a new system is a process of discovery. The microservices architecture pattern is a powerful option to have available, but before paying its toll (time, cost, complexity, …), I would like to understand the expected benefits of that specific implementation. Even when it seems like there will be obvious benefits to implementing some functionality as a microservice, I would rather have real experience with a running system to confirm that assessment.

Building first, using BlueOak Server Services and npm, as a well-structured monolith, simplifies the development, testing, deployment and monitoring of the initial (MVP) delivery. With that MVP in place, real data can be analyzed and experiments can be run to answer questions like: “Which services do I need to deploy more frequently?”, “Does that service run really hot when this common use case is triggered?”, and “What services are part of the ‘functional kernel’ that must always be available?”.

Whether you’re starting a new “traditional” green field project, or building a new “microservice” (since it might ultimately be several microservices), BlueOak Server and npm give you a flexible platform for rapid delivery with a straightforward† “upgrade” path to a (“hybrid”) microservices architecture.

Personally, I’d love to hear and discuss your feedback on these ideas. If you want to explore how they could be applied in your environment, do contact us.

† Yes, we still have to prove that those migration steps are complete and the hypothesis is true or discover the problems with them, restate the hypothesis and try again. #computerSCIENCE

Resources, Related References, Remarks and Alliteration

While writing this article I came kept going back to three pages to try to keep me connect to the “state of the art” of microservices. (Definitely, I read many others, but once I started writing these were the ones I compared my work against.)

  1. Microservices – a definition of this new architectural term by James Lewis and Martin Fowler
  2. Don’t start with a monolith … when your goal is a microservices architecture by Stefan Tilkov
  3. What Is Microservices Architecture? By Tom Huston

If you’re new to microservices these are definitely a great place to start.

That second article, “Don’t start with a monolith …,” really helped me focus my thoughts on a business mediation/service binding approach to BlueOak Server Services. Especially how it can be used to overcome the pitfalls of building a monolith, while, at the same time, laying the groundwork for “upgrading” to a microservice.


Filed under:

If you like this, you'll like these:

More Blog Posts


With the strength of Globant behind us, we’re powering up our focus on transformative digital solutions.

On July 30, 2018, find all new content at

See More