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.
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:
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.
I will choose one, for example: MEAN. A very popular one nowadays regarding its scalability. MEAN stands for:
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.
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.
If you want to run it locally, you can do it also, all you need as a prerequirements are NodeJS & MongoDB.
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: https://studio.hivepod.io
(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 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.
Please feel free to try it and give your opinion on it.