Pietro Menna Home page

My understanding of Microservices

No matter where you look into the Internet, of the trends you always read the same buzzwords: Big Data, DevOps and Microservices. I plan to explain what I understood the talks I watched here, here and some others, but I am in no way an expert on the subject.

Monoliths and Microservices

Before begin, lets imagine that we are a shop with three “components”: Finance & Accounting, Distribution and the Store. A component would be a working group of the organization represented in the system.

Usually applications are built as monoliths. In our example, it means, that in the same system, we have all the components together. They share the same source code, technology stack and datastore. It also runs everything on the same server. So imagine that we have to reset the system because of a problem with the Distribution; the “Finance & Accounting” will also be down during the system reset.

Oh, I forgot, there is the IT group which is in charged of all the applications!

Lets imagine now the same shop, but that runs as microservices. We have the same “components” with the only exception of the IT group. Instead, each of the groups has like 3 - 4 people working on only on their specific application. For example, the “store” group, only works on the “store”. The people from the Store may decide to use NodeJS and MongoDB while the Finance & accounting people would prefer Ruby on Rails and Postgres.

Each group decides its own technology stack, and if one of the groups needs to reset their system, not all groups are offline because of it.

It is time to add another buzzword: The Conway`s law, which states:

“…Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations…”

Back to our example, everyone agrees that in the shop all the “components” needs to talk to each other in real life. They all depend on each other so the “Store” is successful.

In microservices world, every user request is a sequence of requests

Let’s say I am an external user, I want to buy something on the “store”, when I buy something on the store, I do not know and I do not care if they are all in one system. I just expect my goods to be delivered and to pay for it.

When I buy something, behind the scenes, the Store component would communicate with the distribution component in charged with the shipping. Also after getting billed, probably the F&A component would get notified.

As you can see in this example, since they are all different systems (maybe even computers), as a user I do not know that. Also, you can see that the system is distributed.

Let’s talk in “Developer’s terms”

  • RESTful Architecture: the communication should occur in RESTful way. In many places you can read this as the Smart endpoints, dumb pipes.
  • Distributed Data Governance: each of the components decides its technology stack, also its data store. This is because you can choose depending on the requirements of each component. Remember, not every problem is a nail and not every solution is a hammer.
  • Single Responsibility: The store component, is only responsible for being a good store for customer`s to buy. Nothing else! One Component: one responsibility.
  • You share nothing: A developer from the Store does not have access to the datastore or even code from the F&A component. All the communication should occur via the common interface.
  • Infrastructure automations: Since you own your stack, you probably need to know how to generate your own system and how to run it. Developers probably woud need to have code as infrastructure to take care of its own system.

Some of the origins

It is said that Microservices is a consequence of Conway’s Law and DevOps. It is also said many ideas come from Amazon.

In particular, Amazon is known for the two pizza size team (a team should have no more people than the amount of people who can be fed with 2 American pizzas). This means, the team should have a size of less than 10-12 people, and most important have the accountability and autonomyto execute its task.

Microservices teams also follow the “Products, not projects” mentality. We can say “Product” is “Component”. Each team should take care of its Product even the operations side: this is also known as the “You build it, you run it!”.

Implications & Conclusion

For developers, everything should be thought from day zero to be externalizable to be able to work on a microservices world.

Also, it has some drawback, since it is distributed system, the problems which may occur are more difficult!

Patterns and Integrations

I admit that I am upset that I have to consume an API from a front-end application that reads like methods from something like Java methods. Something like whatever-domain.com/getBusinessAreas.

I hear arguments like no one will consume the link directly, or access this address directly. I am still not convinced it is a good practice.

Patterns, patterns, patterns…

Why do we have Patterns in the Software Industry? to communicate with other developers.

Just like design patterns, there are other types of patterns. The king of Pattern that was violated by the API mentioned before is called an Integration Pattern.

There are a lot of Integration Patterns, just to name some: RMI, SOAP, REST, Message Channels, Pipes, and many others. The ones I am interested here are SOAP and REST.

Choosing between SOAP and REST


SOAP exposes a service, by using a Service Descriptor (right, the WSDL file). All communication is via this service, and it uses an XML “Envelope”.

SOAP in the web came in disuse. I will not say it is dead, a lot of services still use it. Eg: Jira.

I still believe it might be useful in some scenarios. But I am quite sure it not designed for UI-centric consumptions such as browser consumption. So, if a front-end in HTML5 will consume, do not go for SOAP.


It is an Architecture Style. Every RESTful service must respect certain constraints: Client-Server, Stateless, Cacheable, Layered System and Uniform Interface.

A simple example: putting the previous service to REST.

The example from the beginning of this post, could have easily have been named as: GET /BusinessAreas. It would retrieve the list of “Business Areas” that exist in the system.

We could have retrieved the details of one specific, like BusinessArea “1” simply by GET /BusinessAreas/1.

To create a new “Business Area”, we could use POST /BusinessAreas/. In the body of the POST we send the details required to create one.

To update the details for a given business area, we could use PUT /BusinessAreas/1

At last, in order to delete one Business Area, we could use DELETE /BusinessAreas/1. The example would have updated Business Area 1.


The REST approach allowed to remove the ugly camelCase Java like. But actually, the architectural style significantly improves the readability of the service. Imagine you have more entities, they would all follow the same pattern for access.

Does it look simpler? To me at least, yes. It looks a lot better thanks to uniform access pattern gained by following a simple standard.

Jekyll adjustments for Blaggregator post-rc

It has been a long time since I got back from Recurse Center, and only now I realized that everything I write here still will appear on Blaggregator (An awesome service that I check out like every two days that contains blog posts from recursers).

How does Blaggregator works?

Once you subscribe to Blaggregator, it is possible for you to “Add your blogs” to it. By adding your blogs I mean you are able to add feed urls (RSS and Atoms I guess).

I there is a job which grabbs the feeds and parses it to see if there is a new entry.

Awesome, so what is the problem?

It turns out, I am using Jekyll, and when I suscribed to blaggregator I added the feed that came with the theme I use. All my posts are going to Blaggregator.

In order to be able to select what gets into Blaggregator, I will need to adjust the file which is generated by Jekyll as atom.xml or create a new one specially for the service.

Jekyll Adjustments##

  1. I copied the current atom.xml to atom_rc.xml. This way, I will have one full feed for the site, and one only for blaggregator for the RC related posts.
  2. I marked the relevant posts, with category recurse-center. Each post which shall be included in this new file requires this “tag”.
  3. Added the code which only picks if category contains “recurse-center”. Lines 18 and 27 of this GitHub gist.
  4. Remember to update your link at Blaggregator!

Conclusions & maybe apologies!

Maybe this is useful for other recurses which may also would like to select the posts which gets listed in blaggregator. This is the intention!

Apologies if by making this change in my blog all my old posts gets re-published! :-(