Micro Services- Characteristics
Flavor of SOA
Desperate services together forms a complete application.
Each service can scale up or down based on demand.
Instances of each services are load balanced separately.
Each service can have its own DB.
Driven by scalability provided by cloud platforms.
Developed to improve faster time to market, easier maintenance, zero downtime deployment
Requires change in team structure
Proposes each services to be deployed, scaled, maintained separately.
Each service is managed separately by separate team rather than big team managing big
Pioneered by Netflix. –”Chaos Monkey”
Recommends smart end point and dumb transports. REST
Why Micro Services
It takes SOA bit higher and reduces the risk of one Service breaking entire application.
Individual services can be scaled up or down easily. Helps in effectively managing costs by
spending on what is needed and for what service.
Since every service is treated and managed as independent units, release cycle of one service
can be different from other services. This helps is rolling out lot of features much faster than in
a monolith application.
Enables incremental roll out of features.
Roll back is much faster ,fool proof and does not affect entire system.
Ensure reusability of the services across channels, business lines etc.
As it proposes services based team structure, in ideal world same team takes care of service
enhancements and production fixes. This indirectly makes the developers to roll out quality
Enables zero downtime deployment.
Need For micro services in Digital Commerce
As retailers move towards omni channel experience, service readiness and availability is the first
step in that direction.
Helps business to try new features as services and roll them out ahead of the competition.
Supports sudden/seasonal spikes in traffic across different services.
Since it gives an option to deploy services in different geographies, it helps in both the
performance and disaster recovery.
Instability of a service does not affect entire application and promises a better customer
experience and retention.
Strengthens the API strategy of a retailer by reducing cost of ownership of individual services,
service offering and very minimal or zero down time.
Micro Service- Challenges , Pre Requisites
Identifying services – Functionality and Team size
Data consistency across different services
Migration of existing services of Monolith applications
De coupled interfaces
Architecture to support scalability
Investment on Tools for automated deployment (Custom Scripts), monitoring (APM)
Tools stack for centralized log monitoring for maintenance like ELK(Elastic Search, Log Stash, Kibana)
Leveraging Tools, dashboards for PaaS,Containers
Fool proof Disaster recover. Fail early.
Consoliidated dash board to monitor all services and depict health of entire system.
Reliable Service Discovery (etcd, Consul, Hystrix)
PaaS : A cloud provider delivers hardware and software tools -- usually those needed for
application development -- to its users as a service. A PaaS provider hosts the hardware and
software on its own infrastructure. As a result, PaaS frees users from having to install in-house
hardware and software to develop or run a new application.
PaaS functions at a lower level than SaaS, typically providing a platform on which software can
be developed and deployed
PaaS provider to provide hardware, operating systems, middleware (such as databases, Web
servers and so on) define user access or security, and then add the application to existing
systems management or application performance monitoring (APM) tools. users only need to log
in and start using the platform – usually through a Web browser interface.
Popular PaaS platforms are CloudFoundry, Heroku, Google App Engine
PaaS is built on top of virtualization technology. Businesses can requisition resources as they
need them, scaling as demand grows, rather than investing in hardware with redundant
Cloud Foundry is an open source cloud computing platform as a service (PaaS) originally developed by
VMware and now owned by Pivotal Software - a joint venture by EMC, VMware and General Electric
Cloud Foundry Open Source Software (OSS).Available to anyone. Deploying this version of Cloud
Foundry involves interfacing with the underlying infrastructure using the Cloud Foundry BOSH (bosh
outer shell)deployment scripting language, another open source tool from Pivotal.
Pivotal Cloud Foundry (Pivotal CF).A commercial product available from Pivotal. It provides extra
tools for installation and administration not included in the OSS product.
Pivotal Web Services (PWS). An instance of Pivotal Cloud Foundry hosted on Amazon Web
Products like IBM Bluemix etc are built on CloudFoundry.
When an application is deployed to Cloud Foundry, an image is created for it and stored internally.
The image is then deployed to a Warden container to run in. For multiple instances, multiple images
are started on multiple containers. This is where BOSH comes in - Cloud Foundry's internal Controller
uses BOSH to get the underlying infrastructure to spin up virtual machines to run the Warden
containers on. When an application is terminated, all its VMs can be recycled for another application
to use. If the application instance crashes, its container is killed and a new Warden container is
started automatically. A container only ever runs one application ensuring isolation, security and
A load-balancing router sits at the front of Cloud Foundry to route incoming requests to the correct
application - essentially to one of the containers where the application is running.
Applications deployed to Cloud Foundry access external resources via Services.
In a PaaS environment, all external dependencies such as databases, messaging systems, files systems and so on
When an application is pushed to Cloud Foundry, the services it should use also can be specified. Depending on the
application language, auto-configuration of services is possible - for example a Java application requiring a MySQL
database picks up the MySQL service on Cloud Foundry if it is the only one defined in the current space.
Services have to be deployed to the platform first and then are available to any application using it.
Advantage of Pivotal CF is that many pre-defined services can be deployed into it directly using the Administration
Users of the Open Source Cloud Foundry must make services available by writing and running BOSH scripts.
PWS provides services thanks to a partnership arrangement with App Direct.
The following services are available to Pivotal CF and on PWS:
Data Storage: MySQL, PostgreSQL, MongoDB, Redis, Riak, DataStax (Cassandra), Neo4J, Pivotal HD (Hadoop)
Messaging: Pivotal RabbitMQ
Development: CloudBees Jenkins (Continuous Integration)
Mobile: API Gateway, Data Sync, Push Notifications (Pivotal proprietary services to support Mobile Apps).
Typically, Cloud Foundry is installed on-premises running over VMware's vSphere virtualization infrastructure,
although deployment to OpenStack is an option using BOSH.
It is also possible to run Cloud Foundry instances on VMware Fusion or Virtualbox using Vagrant and on AWS
A container consists of an entire runtime environment: an application, plus all its dependencies, libraries
and other binaries, and configuration files needed to run it, bundled into one package. By containerizing the
application platform and its dependencies, differences in OS distributions and underlying infrastructure are
With virtualization technology, the package that can be passed around is a virtual machine and it includes an
entire operating system as well as the application. A physical server running three virtual machines would
have a hypervisor and three separate operating systems running on top of it.
By contrast a server running three containerized applications runs a single operating system, and each
container shares the operating system kernel with the other containers. Shared parts of the operating
system are read only, while each container has its own mount (i.e., a way to access the container) for
writing. That means the containers are much more lightweight and use far fewer resources than virtual
Popular containers Available are Dockers and rkt
WCS Approach for Micro Services – My Thoughts
WCS : Big monolith Ecommerce engine.
1. Have Separate Rest.war for each service. Create EAR for each Rest WAR .It will have WCS jars etc required for run time. Deploy each service
No Extra overhead or network hops to access WCS run time.
Any REST feature capable with WCS can be managed as Micro Service
Lot of Rest WAR files and tough to manage with out matured management model.
Changes in Core runtime will require re-deployment of all Rest WAR’s
2. Have the Core WCS platform running separately. Have new features which might not require core runtime developed as pure micro services .The Service can
leverage core services as HTTP REST API calls
All micro services are light weight
If core platform changes, deployment complexity does not increase as the number of micro services.
Similar approach is used by Guardian on top of their existing monolith software.
Core WCS run time having all features as REST is not are micro services.
Extra network hop to reach core WCS services.
IaaS vs PaaS vs Containers – My Thoughts
Going of IaaS provide platform , OS and Services agnostic environment.
If a new tech stack is adapted, IaaS is helpful as compatibility of PaaS with new tech stack could take time.
If we do not have fine grained services or highly interdependent services, IaaS could be a better option. It gives
technological independence and promises scalability as well.
Open Stack can be used to develop in house IaaS stack.
If we have matured technology stack and not much expertise on Infra setup , PaaS is the best fit.
Based on Open standards and vendors availability is high.
Reduces the time to deploy changes from Dev to Prod and reduces deployment complexity across environment.
More suitable for services with high velocity changes.
Compatibility in private cloud environment needs to be validated.
Only a few matured Container platforms.
Since it is recommended to run only one service in a container, it might tend to be expensive.
Popular PaaS and IaaS providers give Container services
Micro services Use Cases in Commerce
Services to render content which are time bound like Festival pages, brand pages etc.
Ancillary services like Rating and Reviews, blogs, education content etc.
Value added services which are not a core feature of commerce engine( e.g Personalization, room designer