Microservices Standardization from Models

Alhambra Tiles by Roberto Verturini

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.

MDD and DSL to the rescue

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 DSL), 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.

Deployment

Now, where to host it? If you plan to involve public web intefaces 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 y 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: AppNow http://appnow.radarconline.com
(BTW This is a good moment to test it and come back to finish your reading 😉 )

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

AppNow

AppNow is a model driven tool to create and deploy microservices in the cloud in seconds.
Taking advantage of our experience with modeling, model checking and model web editors we have build a very small DSL (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:

class User
{
    string Name;
    string Surname;
    int Age;
    bool IsActive;
}
class Country
{
    string IsoCode;
    string Name;
    string Description;
}

Is compact, simple, direct and easy to understand. A concise DSL, no more, no less.

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 Kun.io ) 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.

Next steps

Of course this is not a complete work. A CRUD microservice is useful for many scenarios but not enough to cover all type of needed microservices. Take it as a it is: work in progress. But you can feel how it looks like and see the capabilities for extension in different areas:

1. The DSL can be extended:
Adding more semantics for the microservice definition such relations, contract definition, adding operations, service orchestration, workflows, security policies, scalability policies, etc.

2. The execution engine can be extented. Adding a more refined implementation over MEAN, or using a different technology such C# or Java if the market demand it.

3. The deploy target can be extented to other cloud providers different from Heroku. Once again, market will choose the favourite ones.

What do you think? What is the next feature you what to see implemented in AppNow?

The final outcome: Models a path for Microservices Standardization

To recap, with AppNow we are building and delivering in seconds a running microservice from a technology neutral specification.
If we are able to agreed on a common format for the specification of Microservices we will start having a good way to share, discuss and execute such microservices hiding the accidental complexity involved as much as possible.

Being able to change the design and deploy it in seconds for the technology stack and cloud provider of your choice. Is seductive, isn’t it?

Post a comment.