Thinking about Microservices - Part I

I’ve been reading a lot the past weeks about the Microservices Architectural stlye and I’ve been facing a difficult phase of understanding this approach completely. That’s because Microservices seems to be suffering the same problem that Martin Fowler described about SOA in Service Oriented Ambiguity. It seems to be one different description of the approach depending on who are you talking to.

So, my main goal in this post (or maybe set of posts, I’m not sure if all this thoughts should be on one post or a few of them) is to put it common all this different thoughts and think about them and I’ll try to have my own understanding.

We are going to start with the definition of the term that is perfectly accepted by all the community. The definition is from Martin Fowler and James Lewis:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

So, the main idea is we can highlight a few key aspects:

Application is a set of services.
Each services run in its own process.
Built around business capabilities.
Communication using lightweight protocols.
Minimum centralized management.
Different programming languages and data storage technologies.

Ok, we understand the key points but, if you are aware of Service Oriented Architecture, which are the key differences between them? We are going from one to another.

Application is a set of services

Ok, with SOA is the same. The main goal (and the sales pitch) about SOA is that you are going to create a lot of business services so you can create your own application only invoking those services to fulfill these needs. So, at the paper level, no difference here.

But I don’t want to be naive here, so many articles talks about an important difference between both of the architectural styles here. SOA it is for enterprise and Microservices it is for application. So, SOA is a wide-range architectural style where all the features across your enterprise are available to be invoke and to be reused. But, using the Microservices architectural design, you are decomposing your application logic among different services. So, if you follow that thoughts you should think about SOA as a high-level approach and Microservices low-level services approach.

For example, this article published on IBM DeveloperWorks from Kim J Clark covers this approach.

Each services run in its own process

Ok, with initial SOA probably this features of this approach couldn’t be fulfilled but nowadays Enterprise Services Bus, Distributed Computing Platform or every name you want to use to name the place where you deploy your services follows that approach. For example, I’m as a TIBCO expert with many years of experiences I’m used to see that approach since the begining. TIBCO AMX BusinessWorks since the first versions follows that approach with processes (its the way how the called their services) runs in their own OS processes and could be scale independently.

Once again, here you are going to find that using the Microservices Architecture style the container concept it is to related and the Infraestructure as Code approach but that is nothing that are owned by Microservices. So, you can use the same approach to your old-fashion SOA approach.

Built around business capabilities.

Ok, nothing here. The SOA business services should be created around business capabilities. In this topic, the only difference its the size of the services. If you are building an standard SOA probably your services are big than your microservices but that’s not a rule.

Some standard SOA architectures have fine-grained services deployed and never have been considerated as a new architectural design.

Communication using lightweight protocols.

This is one of the major difference but not because of the SOA paradimg but because of the SOA application. So many companys, and so many SOA implementation link SOA with SOAP. So, probably, you will have a lot of services using heavy-weight protocols like SOAP and that' a problem when you are facing a environment with so many mobile devices and third-party integrations.

Today, all the communication are focus on lightweight protocols, like REST or WebSockets, for example. But that’s not a new discover from the Microservices architecture, that’s a common approach for every modern architecture.

So, here, there is an important different between both of the approaches about the main protocols used to communicate the services.

Minimum centralized management.

With SOA you have your centralize management tool that handle all the things related to the services deployed. Using modern applications, close the gap with the microservices approach when you only have tools to do a minimum management to manage your containers or so.

When you are using a Microservices approach you cannot have a more sofisticated application management because you are going to have a lot of different technologies to your services so you cannot have a common way to do the operations between the services. So, normally you manage the containers because it its the only thing in common between your microservices.

Different programming languages and data storage technologies.

Normally with SOA, all your services are implemented using the same Programming Language. Once again, that is not true on all the Enterprise Services Bus. For example, TIBCO AMX Services Grid allow you to develop your services using different implementation types like: .NET, Java, Spring, Ruby or Propieraty way. But you don’t have all the flexibility you have with microservices.

With the microservices approach you are going to have all the posibilities in the world. You can use it the right tool for the right momment, but you cannot do the same with your SOA. You are limited by your vendor.

Regarding the data storage technologies is not usual to have different technologies inside your SOA architecture, normally if you use one approach all your services follows that approach (or maybe you have a few expection but it is no common). Once again, here you have more flexibility because you can use the right tool for your needs.

This is the first part of my study, but in the next post I want to focus on the things that makes Microservices so important for the next years in the Integration world.