Before we start talking about Architectural Patterns, I will suggest to go through my earlier article it talks about  Evolution of Microservices.

                           Fig 1.  Online Marketplace design using MSA

As mentioned in earlier article Microservices Architecture(MSA) is not for everyone & before it needs to be adapted ,it needs to be thoroughly thought through & you should have answer to some of below questions as “Yes”

• Any maintenance Issue with your Monolith ?
• Do you anticipate higher volume ?
• Is modularization and code re-usability the main priority?(like Multi tenancy)
• Do specific components need to be able to scale -on demand?
• Are you looking to bring agility in your software products development, build and release process?
• Do you have infrastructure supporting MSA ?

Now that you have made decision that MSA is the correct fit for your application designing. Then you should be ready with answers to some difficult questions related to infrastructure in order to meet your architecture, since MSA follows certain design principles/patterns and if those are not followed then there is possibility of you might end up in developing pseudo services & increase your maintenance overhead.

Also I want all to keep in mind that adapting MSA is a gradual process & in order to justify business value ,you just can’t execute a project which will do a overnight transformation of monolith into set of microservices. I will suggest you to take incremental approach when you are converting your existing monolith into microservices application. Also I can see hybrid approach also works ,which is also acceptable.

Deployment Patterns

With that let us visit our first architectural patterns in terms of deployment strategies which we should be using during designing of microservices. We will be concentrating around highlighted portion of our earlier architecture.

                                                               Fig 2 Deployment Patterns

Why do you need to consider this pattern ?

1.  Independently deployable service
2.  Individually scalable services
3.  Polygot Model
4.  Constrain the resources(CPU & Memory)
5.  Monitoring of each service
6.  Isolated services

What are the options ?

I am providing options in chronological order as per advantage of each option

• Serverless 
• VM per service
• Host per service
• Multiple runtimes per services
• Container Per Service

Serverless

This is recently very popular & every cloud service provider has this option in their service offering. This is one step ahead of current Application as a service & it more concentrate on Function as a service, where you deploy services on a completely invisible instance from application developers.

There are some cons associated with this approach but this is the best fit for services with FAAS.

VM per service

If you have existing infrastructure & everything gets procured through VM then this is the way to go, not necessarily cost effective.

This sometime turnout to be little costly because every VM needs to have minimum resources allocation, so you might end up in spending a lot on infrastructure.

I have also noticed in multiple IT organizations procurement of VM is done by different IT shared services team, which might delay your process as lot of time when things goes out of your team area for any support or dependency it hinders agility & increases maintenance issues.

Host per service

As the name indicates you procure or have different host for your different services. Only con I see is lot of infrastructure footprint is increased since you are running all the services on bare metal. It further affects your decision of identifying the service context & you try to club multiple domain into one which will cause to build a service rather than microservice.

Mutliple runtimes per service

If you are stuck with your existing infrastructure procurement related issues which I mentioned 2nd option, this is one of the approach you can take it.

You can carve out multiple runtimes for each microservice where you can control resource utilization & individually monitor it. Again there are some limitations to this approach where you can’t control CPU utilization but same constraints are applicable in your VM world also.

For example : If your deployment application selection is Java you can have your JVM separate per each microservice with proper JVM arguments set related to memory with proper elbow space considering GC needs, which sometimes fall out of JVM arguments.

Container Per Service

This is best way to achieve your deployment pattern is using containers. This needs to be thought through prior to following MSA practice at the organization level, since when it comes to Containers you have came out of VM or host world. Spawned up container is matter of seconds for your service. This gives you true agility in terms of deployment

Conclusion :-

Deployment pattern is very much important pattern & needs to be thought through & It should be thought during phase when organization is getting inclined towards microservices architecture. Container per service is the best approach for your microservices implementation but this is not end of the road & you can still achieve the same using other approaches as well but there are trade-off with every approach which needs to be carefully evaluated during each approach selection. 

*Cloud foundary provides solution for majority of the concerns here by internally providing diego cells for us to work on it & it internally again uses containers with droplets, which are formed from buildpacks with config information.