Document Properties
Kbid2F8184
Last Modified21-Feb-2017
Added to KB21-Feb-2017
Public AccessEveryone
StatusOnline
Doc TypeGuidelines, Concepts & Cookbooks
Product
  • ICM 7.8
  • ICM 7.9
  • ICM 7.10

Concept - Microservice Deployment

1 Introduction

With the release of the ICM 7.8 the microservices were introduced, which can be deployed separately. A discovery service (Eureka) is responsible to provide real instances (IP and port) for the different services.

The solution contains following services:

  • Recurring order service (as microservice)
  • Scheduling service (as microservice)
  • Basket service (inside ICM 7.8)

The ICM 7.8 contains service interfaces (internal and external). The external one is used by the Web Adapter only, to produce content for the outside world (e.g., real users) the internal interface is used by the microservice or ICM.

Note

Microservices provide their functionality internally, only to other services (incl. ICM). ICM is the API gateway for all external (user) requests. Conceptually, other gateways could provide other APIs, like a specific REST API.

The API gateway (ICM or another) has the responsibility to:

  • Provide a stable API for the outside world
  • Authorize the user request
  • Forward the request to the action specific microservice (via service discovery)
  • Collect information for monitoring and billing (if necessary)

2 Build

The builds of microservices are independent from the ICM. The component set a_responsive contains the deployment project microservices of our services for easier use in a developer environment. As an implementation partner, you can implement your own services with your preferred technology stack. Normally, the ICM must communicate with your service, therefore the service instances must be discoverable.

3 Deployment Scenarios

The component set a_responsive contains a sub-project called microservices. This is a component, which was introduced to simplify the deployment of the microservices and does not contain the microservices itself. For the project setup some adaptions are necessary: Recipe: Set Up Project Based on the Responsive Starter Store.

Typical deployment scenarios can be found here: Concept - Planning an Intershop 7 Deployment.

3.1 Development

  • Single-Host Deployment
    With a single-host deployment, all software components (and hence, all host types) are deployed on the same machine. The simple deployment is best suited for development and testing purposes. This deployment scenario is covered with the host type all.

Single Host Deployment

3.2 Production

  • Multiple-Host Deployment
    With a multiple-host deployment, only selected host types are deployed on individual machines. A multiple-host deployment allows full use of Intershop 7’s open architecture by distributing the components over as many machines and processors as you need, and configuring them optimally for your site.

The following example shows for simplicity reasons the multiple host deployment approach with only one instance of each type. Real life scenarios can contain of course more instances of each type.

Multiple Type Deployment

4 Deployment Scenarios - Scheduling and Recurring Order

The microservices scheduling and recurring order may be deployed together or separately. See: Cookbook - Microservice Deployment also for database configuration.

4.1 Development

In development environments microservices scheduling and recurring order are deployed together.

DIA composite deployment of microservices

4.2 Production

In production environment the microservices scheduling and recurring order can be deployed together, in separate processes or on separate machines. Since they are registered at a Eureka server they can find each other.

4.2.1 Deploy all Microservices Together

The deployment project microservices at a_responsive contains this scenario. The environment.properties contains all service implementations.

Service selection
services=Scheduling,RecurringOrder

DIA microservice deployment together

4.2.2 Separately Deploy Microservices

It is possible to copy and adapt the microservices project to apply combinations, which fits best for the operational requirements. The environment.properties file contains a list of services, which are deployed together and the name of the other services.

For each combination or deployment project a specific name must be defined, which is used to register the instance at service discovery (Eureka).

SchedulingService environment.properties
services=Scheduling
eureka.name=SchedulingService
intershop.naming.service.RecurringOrder=RecurringOrderService
intershop.naming.service.Scheduling=SchedulingService
RecurringOrderService environment.properties
services=RecurringOrder
eureka.name=RecurringOrderService
intershop.naming.service.RecurringOrder=RecurringOrderService
intershop.naming.service.Scheduling=SchedulingService

DIA microservices on separate machines

5 Configuration

Additionally to the configuration for service discovery other environment specific configurations are necessary, e.g., database connections. The config directory is part of the classpath and will be read via resource loading algorithm. Both new services (recurring order and scheduling) reading their configuration from the environment.properties resource.

show properties at deployed server
cat server/local/microservices/config/environment.properties

5.1 Database Configuration

Note

It is not recommended to use the derby database in a production environment.

The connection parameter are part of the configuration (environment.properties, which is deployed into <SERVER>/local/microservices/config/). It is possible to use for all services the same database or different connections, also in the case that both services are deployed together.

a_responsive/microservices/src/dist/config/environment.properties
#example section using specific database connection for recurring oder service for postgres
# RecurringOrdersPU.javax.persistence.jdbc.driver=org.postgresql.Driver
# RecurringOrdersPU.javax.persistence.jdbc.url=jdbc:postgresql://<HOST>:<PORT>/postgres
# RecurringOrdersPU.javax.persistence.jdbc.user=<USERNAME>
# RecurringOrdersPU.javax.persistence.jdbc.password=<PASSWORD>

#example section using specific database connection for scheduling service for derby
# SchedulingPU.javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver
# SchedulingPU.javax.persistence.jdbc.url=jdbc:derby:build/testdb;create=true
# SchedulingPU.javax.persistence.jdbc.user=test
# SchedulingPU.javax.persistence.jdbc.password=test

#example section using one database connection for all services for derby
javax.persistence.jdbc.url=<@databaseURL@>
javax.persistence.jdbc.user=<@databaseUserName@>
javax.persistence.jdbc.password=<@databaseUserPassword@>
javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver

The configuration follows a simple pattern:

  • javax.persistence prefix for all persistent units (PU)
  • <PeristentUnitName>.javax.persistence for unit specific configurations

The configuration of the database is divided in two parts

  1. Selection of the database driver
    1. This step has to be executed before the publication of the project assembly. See Recipe: Set Up Project Based on the Responsive Starter Store for details.
  2. Definition of connection (URI, user, passwords etc)
    1. This step has to be executed before the deployment of the project assembly.

5.1.1 Selection of Database Driver

The database driver can be declared as dependency at the deployment project. As example remove the comment of the postgresql driver at line (8) and remove the line (5) of the derby driver. It is up to the DevOps team to use another database, which is JPA compliant.

a_responsive/microservices/build.gradle
dependencies {
    runtime "com.intershop.microservice.lib:platform-scheduling"
    runtime "com.intershop.microservice.lib:checkout-recurringorders"
    /** driver for derby */
    runtime 'org.apache.derby:derby:10.12.1.1'
    /** driver for postgres */
    // runtime 'org.postgresql:postgresql:9.4.1209'
    /** driver for oracle */
    /** this configuration uses the prepared oracle drivers **/
    /** see 'Cookbook - Setup CI Infrastructure', 7.2.5 Process for Building the Oracle JDBC Drivers Component **/
    //runtime 'com.intershop:ojdbc7:12.1.0.2.0.0'
} 

Furthermore, the JDBC driver has to be adapted into the environment.properties. As example replace 'org.apache.derby.jdbc.EmbeddedDriver' by 'org.postgresql.Driver'.

a_responsive/microservices/src/dist/config/environment.properties
javax.persistence.jdbc.driver=org.apache.derby.jdbc.EmbeddedDriver

5.1.2 Definition of Connection Parameters

The connection parameters contain placeholders (<@PLACEHOLDER@>), which are replaced during deployment.

a_responsive/microservices/src/dist/config/environment.properties
javax.persistence.jdbc.url=<@databaseURL@>
javax.persistence.jdbc.user=<@databaseUserName@>
javax.persistence.jdbc.password=<@databaseUserPassword@>

There are two ways to define values to replace the placeholders:

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets