Hivepod Blog

Microservices Standardization from Models

Posted by Pedro J. Molina on Jun 29, 2015 10:59:00 AM

Originaly posted on the Metalevel.

Microservices is emerging as an architectural pattern. They encourage small, autonomous and decoupled services exposing a stable contract implementing a business service with the minimum set of external dependencies.

For further discussions on Microservices, accurate definitions and its use cases read Lewis & Fowler, Richardson, or Crammon.

With no doubt, Microservices are gaining momentum. A lot, and too fast, as usual in the tech industry. So fast, that microservices abuse (just because has its buzz component and coolness factor) is already causing also problems:

  • No Silver Bullet (double check the problem is a good fit for this architecture)
  • Quick and Dirty build of such microservices (causing maintenance problems)
  • Deployment and configuration nightmares (deploy N components and configure them in M environments pointing to the right instances) A zoo of Microservices requires good Continuous Integration and DevOps capabilities, moreover Continuous Delivery when available.

Of course, we still lack of standards for describing microservices. Microservices are too young to been tamed yet.

You can use any technology to create a microservice, as soon it exposes JSON/XML over the HTTP to provide a REST API.

So, maintaining third party microservices is not trivial if the previous developer liked such old library for JSON parsing you detest or uses that other language you are not familiar with. There is no written rules or standards to follow when dealing with microservices. If you plan to use them, it would be nice to have a set of standards, architectures, frameworks and code styles to use homogeneous over all your zoo to keep code, maintenance cost and your personal health under control.

Back to basic, a microservice is supposed to do very little, but with a strict contract and with a good quality of service you can rely on. In terms of definition, we should be more interested in what the services does, instead of struggling with its current implementation (how is doing it).

Then, specifying the services, the contracts and its behaviour in a concrete spec is something doable we can see as concise documentation and also expect what the outcome is.

In that way, if we provide a neutral way of specifying microservices (for example using a simple language), we can automate and convert (code generate, compile and deploy, I meant) such spec into a running implementation for your microservices: choose here your favorite stack.

The MEAN Stack

I will choose one, for example: MEAN. A very popular one nowadays regarding its scalability. MEAN stands for:

  • MongoDB
  • Express (a NodeJS library for creating services)
  • AngularJS
  • NodeJS

MongoDB is one of the leading NoSQL databases providing very good scalability.

NodeJS is an engine for running JS on the server side with growing user base.

Express is the most popular library on NodeJS for creating services thanks to it conciseness and scalability.

Finally, AngularJS is a framework to create rich web-apps driven also by JavaScript. Using the same language in the back-end and front-end also is an added value for developers.

Therefore, the basic MEAN stack has everything we need to build our microservices.


Now, where to host it? If you plan to involve public web interfaces or mobile access, you will probably need a place on the cloud.

More and more cloud providers are providing support for MEAN apps. Heroku, MS Azure, and IBM Bluemix. Recently Google is also joining to the party offering MEAN support on Google Compute Engine.

If you want to run it locally, you can do it also, all you need as a prerequirements are NodeJS & MongoDB.

Quick build, quick deploy

Fast prototype: design-code-test is the cycle to speed-up for fast iteration. Can we also provide agility to microservice construction?

Well, judge for yourself this is our attempt:

(BTW This is a good moment to test it and come back to finish your reading :-) )

Or see a short video to see Hivepod in action and the final outcome.

Hivepod Studio

Hivepod Studio is an online tool to create and deploy microservices in the cloud with minimal effort.

Taking advantage of our experience with modeling, model checking and model web editors we have build a very small languaes (following the Minimal Viable Product approach) to define the structure of data exposed by a microservice using a resource and CRUD approach in the first attempt.

A sample spec has the form:

With this data, we opted to generate a MEAN microservice and deploy it on Heroku.

The code is provided for user extension and deploy on Heroku for direct manipulation.

The NodeJS services rely on the fantastic library Baucis (from making it more easily to expose auto-documented services using the Swagger standard.

Please feel free to try it and give your opinion on it.

Written by Pedro J. Molina