Developing and operating an enterprise commerce ecosystem, with its complex integrations, can often be a significant challenge. Are you wondering if a migration to the cloud would be best for your business, or if it is even possible for your specific applications? In this webinar we will discuss some of the advantages and disadvantages of working in a Platform-as-a-Service (PaaS) environment, such as dealing with restricted classes, leveraging automatic scalability, and migrating the persistence layer. Learn from our experiences, as we reveal what worked best as we moved our own multi-server enterprise application from traditional collocated hardware into the Google App Engine cloud environment.

1. Moving Complex Enterprise
Ecommerce Systems to the Cloud
Eddie Chan
Ronald Chen
Elastic Path™

3. Elastic Path Software
• We help the worldʼs biggest brands sell digital goods
and services
• We provide a flexible Java ecommerce platform and
expertise in ecommerce strategy and implementation
• #1 ecommerce blog: www.getelastic.com
• For more on-demand ecommerce resources:
www.elasticpath.com/resources

4. The Elastic Path Platform
Elastic Path Architecture Components
Eclipse RCP
SWT / JFace
Financials ERP CMS Payment Legacy Custom /
Web Browser Mobile Browser Commerce Manager Client System System Gateway Systems LOB Apps
Store Front Server Commerce Manager Web Services Server XML Import/Export
Spring Security Spring Security Spring Security
Core Engine
Apache Velocity Spring Remoting JAX-WS
Spring MVC Quartz Scheduling Core Engine Data Sync Tool
Drools Core Engine Core Engine
Core Engine
ETL Tools
Search Server
SOLR Search Server Quartz Scheduling Core Engine
J2EE Application Server Database Server
Ecommerce is complex.
Enterprise ecommerce is complex-er.

5. Case Study
• Since 2008, Elastic Path has been the ecommerce
backbone of a few of Googleʼs online stores
• For these stores, many customizations have been made
to the Elastic Path platform.
• One of the largest customizations thatʼs been made
to the Elastic Path platform is migrating it to run on
Google App Engine.

6. Migration to Google App Engine
Before: After:
• EP running in the Colo • EP running on App Engine
• Fixed Cluster • Dynamic instances

7. Google App Engine
• Same system that powers many of Googleʼs own apps
• GAE is a Platform as a Service (PaaS)
• More restrictive than Infrastructure as a Service (IaaS)
offerings (but for good reasons)
• Supports Python, Go, and Java (& other JVM
languages)
• Free to get started; pay as you go pricing

8. Advantages of Google App Engine
• Automatic Scalability
• Well defined development environment
• Secure
• Easier deployments and operations
• Reduced Cost
• Built-in monitoring tools
• Useful services

9. Topics
• Challenges with Restricted Classes
• How App Engine Automatically Scales
• Performance, Performance, Performance
• Migrating the Persistence Layer

10. Topics
• Challenges with Restricted Classes
• How App Engine Automatically Scales
• Performance, Performance, Performance
• Migrating the Persistence Layer

11. Challenges with Restricted Classes
• App Engineʼs JRE Class White List:
These JRE Classes
work on App Engine.
All other JRE Classes
do not.
The full list of white list classes can be found at:
http://code.google.com/appengine/docs/java/jrewhitelist.html

12. File Restrictions
• Not allowed:
• Reading/writing to the filesystem
(this should not be done anyway)
• Writing to files inside the WAR
• Allowed:
• Reading from files inside the WAR

13. Example: File Restrictions
• Problem: we were reading/writing to the filesystem
• Solution: we moved the read-only files into the WAR
and moved the read/write data to the Datastore
Before: After:

14. Socket Restrictions
• App Engine does not allow the use of raw sockets
• Reason: security considerations
• Workarounds may exist depending on the nature of
the communication
• e.g. HTTP sockets & App Engine URL Fetch Service

15. Example: Socket Restrictions
• Problem: We used HttpClient, which uses sockets, for
Spring HTTP Remoting
• Solution: There is a custom connection manager for
HttpClient 4 that uses App Engine URL Fetch Service
instead of sockets
Before: After:

16. Thread Restrictions
• App Engine does not allow spawning of threads
• Use Task Queues instead of threads for background
jobs
• Task Queues:
• Like a Java Executor
• Highly configurable
• Accepts URLs instead of Runnables
• Code that would have been in Runnable is bound to
a URL
• Fetching the URL is like running the task on another
thread

17. Example: Thread Restrictions
• Problem: Generating a file on a background thread
• Solution: Migrate Runnable to Spring Controller and
schedule with App Engine Task Queues instead of
Executor
Before: After:

18. Topics
• Challenges with Restricted Classes
• How App Engine Automatically Scales
• Performance, Performance, Performance
• Migrating the Persistence Layer

19. How App Engine Automatically Scales
“App Engine apps are powered by any number of
dynamic instances at any given time, depending on
the volume of requests received by your application. As
requests for your application increase, so do the number
of dynamic instances powering it.”
http://code.google.com/appengine/docs/adminconsole/instances.html
Requests Instances Requests Instances

20. How App Engine Automatically Scales
• A single instance handling requests
• This instance, like all instances, has a request queue to
hold incoming requests

21. How App Engine Automatically Scales
• A new request comes in
• Instance-1ʼs request queue is getting overloaded, so...

22. How App Engine Automatically Scales
• App Engine spawns a new instance to handle request-5
• request-5 is a loading request; request-5 must wait for
instance-2 to fully initialize before being processed

23. How App Engine Automatically Scales
• instance-2 finally finishes initializing and can now handle
requests alongside instance-1

24. How App Engine Automatically Scales
Loading requests make users wait!
Introducing warm-up requests:
• Introduced in Google App Engine v1.4.0
• Initialize instances ahead of time so that live requests
do not initiate new instances
• On by default
• Not always called for every new instance (e.g. the very
1st instance)

25. How App Engine Automatically Scales
Letʼs replay the previous scenario with warm-up requests.
• A single instance handling requests
• App Engine sees that instance-1ʼs request queue is
getting overloaded, so...

26. How App Engine Automatically Scales
• Before any more requests arrive, App Engine sends a
warm-up request to initialize a new instance

27. How App Engine Automatically Scales
• instance-2 finishes initializing and is ready to handle
requests alongside instance-1

28. How App Engine Automatically Scales
• A new requests comes in
• instance-2 is ready to handle request-5 right away
• request-5 is not a loading request this time

29. How App Engine Automatically Scales
Fast-forward a few seconds. request-1, 2, and 5 have
been processed.
• instance-2 is idle and instance-1ʼs queue is not full, so...

30. How App Engine Automatically Scales
• App Engine scales down and drops instance-2 because
it is no longer needed

31. How App Engine Automatically Scales
Introducing Always-On Instances:
• Always-On instances remain running even with no traffic
• Minimizes impact of loading requests
• A premium feature (i.e. costs a bit more)

32. Topics
• Challenges with Restricted Classes
• How App Engine Automatically Scales
• Performance, Performance, Performance
• Migrating the Persistence Layer

33. Performance Tools - AppStats
• AppStats
• A servlet filter that measures the performance of each
request

34. Performance - Loading Deadline
• Recall that any request has the potential to be a
loading request

35. Performance - Request Deadline
• Still need to handle actual request in the remaining time
after loading application
• After 60 seconds, a runtime exception will be thrown
and the requests will be dropped

36. Performance - Optimizing
• Loading Request time = Start-Up time + Request time
• To thrive on App Engine, request performance and start-
up performance must be optimized together
Optimize
Requests
Optimize
Start-Up

37. Performance - Optimizing Start-Up
How do you optimize start-up times?

38. Performance - Optimizing Start-Up
How do you optimize start-up times?
Do Less

39. Performance - Optimizing Start-Up
Do less at start-up:
• In our application half the start up time was being
consumed with classloading
• Amount of classloading is application/framework specific
• We were loading more classes than expected
• Use -verbose:class
• Classpath scanning is slow
• Use static configuration instead of classpath scanning
• Generate configuration at build

40. Performance - Optimizing Page Loads
• Serve resources from the WAR statically
Before: After:

41. Performance - Optimizing Page Loads
• App Engine provides memcache service
• Cache is shared across instances
• Best effort cache
• In our application we gained performance by caching
Spring Remote calls

42. Topics
• Challenges with Restricted Classes
• How App Engine Automatically Scales
• Performance, Performance, Performance
• Migrating the Persistence Layer

43. Migrating the Persistence Layer
• Google App Engineʼs persistence layer is Datastore
• Datastore is a non-relational database
• Most enterprise applications use a relational database
• Non-relational databases donʼt have tables
SQL Table: Datastore (abstract):

44. Migrating the Persistence Layer
• Transaction boundary in Datastore is very different
• Can only perform transaction around entity groups
• Each entity has a parent entity
• An entity group is a tree of entities

45. Migrating the Persistence Layer
• Existing domain model unlikely to work in Datastore
• Different storage structure
• Different transaction model
• Different tools/framework
What do we do?

46. Migrating the Persistence Layer
• Existing domain model unlikely to work in Datastore
• Different storage structure
• Different transaction model
• Different tools/framework
What do we do?
Run Away?

47. Migrating the Persistence Layer
• Datastore is designed to scale with the App Engine
cloud
• Entities are far easier to cache
• Fetches are small and focused
• No more fetch group hell
• The data and transaction model force cleaner domain
models
• More flexible than tables
• Can have different properties on the same “type” of
entities
• Focus on smaller transactions
• Alternatively, use Google Cloud SQL

48. Letʼs Recap
• Elastic Path is a flexible Java ecommerce platform
• Google App Engine is a true cloud platform that
supports Java web applications
• App Engineʼs constraints can be liberating
• JRE Class restrictions forced one to implement
workarounds with App Engine services
• Automatic scalability is achieved with dynamic
instances
• App Engine imposes strict performance requirements
on your apps
• The Datastore is a non-relational DB that forces one to
untangle the domain model

49. Was the Migration Worth It?

50. Was the Migration Worth It?
For us, yes!

51. Was the Migration Worth It? - Yes!
• Automatic scalability
• App Engineʼs restrictions forced us to rethink and
improve our applicationʼs design
• Deployments to App Engine are flexible and easy
• Production environments are easy to replicate for
testing
• No more server configuration management
• Reduced costs
• Frequent Google App Engine releases continue to
introduce cool, useful features

52. Thank you.
Any Questions?
For more information visit:
Web www.elasticpath.com
Blog www.getelastic.com
Twitter @elasticpath

53. Additional Resources
• Google App Engine homepage: http://code.google.com/appengine/
• Maven plugin for Google App Engine: http://code.google.com/p/maven-gae-plugin/
• Will It Play In App Engine - lists the level of compatibility of various Java technologies and
App Engine: http://code.google.com/p/googleappengine/wiki/WillItPlayInJava
• ESXX - Custom HttpClient 4 URLFetch connection manager: http://esxx.blogspot.com/
2009/06/using-apaches-httpclient-on-google-app.html