Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices approach for Websphere commerce


Published on

Document gives overview of Microservices and how Websphere commerce can be leveraged as microservices. It gives pros and cons of various approaches and challanges.

Published in: Software
  • Be the first to comment

Microservices approach for Websphere commerce

  1. 1. Micro services For Websphere Commerce (WCS) Hariharan Anantharaman @harianantha
  2. 2. 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 monolith applications  Pioneered by Netflix. –”Chaos Monkey”  Recommends smart end point and dumb transports. REST
  3. 3. 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 code.  Enables zero downtime deployment.
  4. 4. 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.
  5. 5. Micro Service- Challenges , Pre Requisites Challenges  Identifying services – Functionality and Team size  Data consistency across different services  Migration of existing services of Monolith applications Pre Requisites  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)
  6. 6. PaaS  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 resources.
  7. 7. Cloud Foundry  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 Services (AWS).  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 resilience.  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.
  8. 8. Cloud Foundry  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 are Services.  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 Console.  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.[18]  It is also possible to run Cloud Foundry instances on VMware Fusion or Virtualbox using Vagrant and on AWS
  9. 9. Containers  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 abstracted away.  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 machines.  Popular containers Available are Dockers and rkt
  10. 10. WCS Approach for Micro Services – My Thoughts WCS : Big monolith Ecommerce engine. Solution Options 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 independently. Pros  No Extra overhead or network hops to access WCS run time.  Any REST feature capable with WCS can be managed as Micro Service Cons  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 Pros:  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. Cons  Core WCS run time having all features as REST is not are micro services.  Extra network hop to reach core WCS services.
  11. 11. IaaS vs PaaS vs Containers – My Thoughts IaaS  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. PaaS  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. Containers  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
  12. 12. Micro services Use Cases in Commerce  Services to render content which are time bound like Festival pages, brand pages etc.  Account service.  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 etc).
  13. 13. References    trs/index.html    need-them.html    of-scope/a/d-id/1269190  of-scope/a/d-id/1269190