Have you ever faced the following issues in your projects:

1. Roll Out Features Quickly to Production

The customer needs very minor changes to functionality/UI and would like that to be rolled out at the earliest possible time because they have a higher business impact. However, we are not able to deliver it, because even though it is a small change, we have to go through the whole nine yards of a release processes involving full regression, etc.

2. Move Your Application From One Datacenter to Another

You need to move your application to a different data center in a different geography due to various reasons (like legal, merger and acquisition etc). This might seem to be a herculean task to you. More often than not, you would get caught in a web of discovering (often surprising yourself!), a myriad of system configurations spread across file system, database, even worse within the code!!!. This is only going to make your task even more daunting.

3. Scale Out Your Application Based on Modules

You might observe that few modules of your application face a huge load compared to others, and you might want to dedicate more resources to these modules instead of scaling out the entire application. However, you are not able to do this at a module level, thus wasting money/resources by scaling the entire application.

Is there a better way out???

Think Microservices!!

Microservices help us break down the application which was a monolith hitherto, into smaller deployable units. So no more, one huge .ear  file having large number of war files. Typcially, they are built as stateless REST services providing a certain modular functionality. And each of these services could be built and deployed individually.

This loosely coupled architecture would allow us to seamlessly develop and deploy individual micro services quickly and be truly agile.
So Micro Services will try to address issues #1 and #3 above.

So, will just breaking down into smaller microservices serve as a magic bullet and solve all the problems?

Well, not really. It might introduce complications and more problems, unless we manage it better.

How Do You Manage Microservices?

Use of a PaaS (Platform As a Service) would help us to manage the microservices environment better. In this article, I would dwelve upon Pivotal Cloud Foundry (PCF), which is a PaaS offering from Pivotal Inc. which could be deployed on top of any IaaS offerings like VMWare, AWS etc.

Why Pivotal Cloud Foundry?
1. PCF supports a large number of run times including Java, Python, PHP etc. So there is no vendor lock-in and you can pretty much develop using the language of your choice (and which is supported by PCF).

2. One of the principles to be followed here is to isolate configuration from code. The same code/deployable artifact (like .war for example) should work in all environments without change. (This principle would address issue #2 mentioned earlier in the article) PCF provides a configuration server which would serve as a centralized server providing all the system configurations, thereby allowing the platform to spawn new instances of the application seamlessly.

3. PCF provides a wide range of services through marketplace. It includes (no sql databases like Mongo DB are provided a service), messaging system (like Rabbit MQ) etc. These services ease the development and deployment/configuration efforts. Even more, these services could be bound to our application with a single command. Look ma, no hands!!

Overall, PCF appears to be a suitable solution for quickly building and deploying microservice applications onto the cloud.