1. DEPLOYMENT Fredhopper Cloud Infrastructure

2. Outline • Problem • Approach • “Demo”

3. The Problem • Multiple products, in different versions • Custom on-premise deployments • Many manual steps for routine operations work • Diverse environments • Hardware differences • Operating Systems and versions • Java VM versions

4. Approach

5. Deployment Agent - Concepts • Installation: The ”bits”, factory for instances • Instances: Keeps configuration and index, provides processes • Processes: Daemons/Services/Tools in the context of an instance • Verbs: Primitives for invoking processes

6. Controller - Concepts • Service: a particular deployment model • Specific to the product • Service Instance: a particular instance of the service, owned by a customer • Triggers: requests from a user for a change • Available triggers depend on service instance

7. Controller Configuration (1) <service-plans> <load-balancer name="rightscale" factory="com.fredhopper.controller.rightscale.RightScaleLoadBalancerClientFactory"> ... </load-balancer> <installation-directory name="default" directory="/data/distributions" allow-upload="true"/> <service-plan customer="internal"> <service-instance name="dm:dm" installation=“fredhopper-data-manager-1.0.4“ load-balancer="none" factory="com.fredhopper.controller.kitchen.distributed.DataManagerServiceInstanceFactory"/> </service-plan> .. </service-plans>

8. Controller Configuration (2) <service-plan customer="demo"> <service-instance name="fas:live1" installation="fas-assembly-7.2.0" load-balancer="rightscale“ factory="com.fredhopper.controller.fas.MasterSlaveServiceInstanceFactory"> <property name=“control.dataManagerServiceInstance">dm:dm</property> <property name="ms.masterHasLive">true</property> </service-instance> <service-instance name="suggest:live1" installation="suggest-distribution-2.0" load-balancer="rightscale" factory="com.fredhopper.controller.suggest.SuggestServiceInstanceFactory"> <property name=“suggest.fasServiceInstance">fas:live1</property> </service-instance> </service-plan>

9. Demo

11. Deployment Agent - Results & Learnings • Identification of core concepts is key • Removing concepts is hard • Avoid complexity • Versioning and Fail-Fast Behaviors • Detect problems, and report them immediately and clearly • System Identification and “Support for Support” • If something in the higher layers breaks the agent is the last resort for gathering valuable information • Auditing/Logging • Infrastructure components are hard to upgrade • Cannot get enough testing in synthetic and production scenarios • Stable API to ensure compatibility with future versions • Plugins and alternative implementations of core components • UI is important • People want to see that everything is good, ‘no news is good news’ does not work • Complexity in high-level language, not in scripts • Well-known language and environment • Easily testable • Adaptable for new products: installations deliver the glue code, coded against available API

12. Controller - Results • Also infrastructure glue, Deployment Agent results apply • Concepts, Integration, Extensibility, Testing • Testing is hard: cannot duplicate production environment easily • Software updates are common • New services • Improved deployment models • Must provide real benefit for adoption • Upgrades of service software • Scaling models to reduce costs • Centralized model enables access to the big picture • Support/Operations can solve routine tasks quickly • I/O scaling is needed, CPU is irrelevant: partitioning seems inevitable

13. Controller - Structure

14. Trigger Execution Example: FAS Full Data Load

15. Situation – On-Premise Shoppers Integrators Frontend Monitoring Load-Balancing Integrators FAS Business Users Custom Scripts Integrators Hardware SysAdmins

16. Situation – Cloud Environment Shoppers Integrators Integrators Business Users Frontend Monitoring Service API Load-Balancing Monitoring Controller Fredhopper FH Operations Deployment Agent Hardware FH Operations