1. Trends in Enterprise Applications Architecture
An overview of upcoming changes
1/6/2011 Michaël Figuière

2. Buzzwords are around...
Elasticity
NoSQL
Cloud
Distributed
Scalability
Virtualization

3. Enterprise applications, nowadays

4. Enterprise applications architecture
• Huge, monolithic architectures are no longer the trends
Service Oriented Architecture is ubiquitous
• SOA is now mature, not dead
After extremism, pragmatism is now the trend
• Web applications are everywhere, REST is around
Frontier between Web and Services is now blurred

5. Service Oriented Architecture

6. Service Oriented Architecture
How to make it scale
exactly to our needs ?

7. The Cloud

8. Cloud Computing principles
• Abstraction
SaaS, PaaS, IaaS, ... actually « (.*) as a Service »
• Automation
Reduces manual tasks as much as possible
• Elasticity
Scale up or down depending on the current needs

9. Cloud’s basic abstractions
Owned by the Cloud Provider
Owned by the enterprise Provides a
middleware
SaaS
Application
Client / User PaaS
Web
Application
Middleware IaaS
Web
Provides an
empty server

10. Cloud and automation
• Resources provided by the Cloud are exposed as services
Makes it possible to allocate a new server, create a new
database, or change network security with a service call
• Maintenance and deployment tasks can be easily scripted
Reduce manual talks necessary for infrastructure changes
• The Cloud provider handles the maintenance tasks
The customer keep focused on the application development

11. Cloud and elasticity
• Automation ability makes it possible to easily start and stop instances
And subscribe / unsubscribe from load-balancer
• Elasticity makes it possible to make allocated resources stick to current load
Pay only what you use
• Elasticity makes it possible to handle very high peak of load
• Simplifies capacity planning

12. Elasticity in action
Service
Instance 1
Storage
Instance 1
Web Service
Instance 1 Instance 2
Storage
Instance 2
Web Service
Instance 2 Instance 3
Storage
Instance 3
Service
Instance 4

13. Public Cloud players

14. Public Cloud vs. Private Cloud
Typical server load
during a whole day

15. Public Cloud vs. Private Cloud
Public Cloud
Private Cloud

16. Example at guardian.co.uk

17. But the Cloud magic comes at a price

18. Elasticity requires symmetric instances
Service
Instance 1
Storage
Instance 1
Web Service
Instance 1 Instance 2
Storage
Instance 2
Web Service
Instance 2 Instance 3
Storage
Instance 3
Service
Instance 4

19. Elasticity requires symmetric instances
Service
Instance 1
Storage
Instance 1
Web Service
Instance 1 Instance 2
Storage
Instance 2
Web Service
Instance 2 Instance 3
Storage
Instance 3
Service
Instance 4

20. Some solutions
• Leader election can be used to avoid symmetric issue
Zookeeper is a cluster management framework
• Other tools can be used to make the set of instances more collaborative
Zookeeper provides distributed locks, queues, states...
• Cloud providers solutions can be used
Amazon RDS, SimpleDB, Google BigTable, ...

21. Configuration and logging

22. Application’ inputs and outputs
Input Output
Application / Service
Logs /
Configuration
Monitoring

23. Application’ inputs and outputs
Input Output
Application / Service
Logs /
Configuration
Monitoring

24. Application’ inputs and outputs
Input ok Output
Application / Service
Logs /
?
Configuration
Monitoring

25. Typical Configuration
• .properties or .xml files are typically used for configuration
Large enterprises applications may have 100+ conf files...
• Puppet, CfEngine and Chef can help
... but isn’t it just a hack ?
• Finally, most settings aren’t used
... and developers may not know their meaning

26. Configuration options are a hope that your users, with
less knowledge of how the system works, will find the
right solution where you didn't.
Jonathan Ellis
Project Leader Apache Cassandra

27. Another way to configure
• Uses zookeeper to maintain the current application configuration
Highly available and consistent distributed storage
• Uses your Cloud provider storage and tools
S3 buckets, Elastic Block Store
• Reduce configuration options to minimum
There is probably too much options...
• Uses Convention over Configuration

28. Typical Logs
• Append-only text files, stored locally or sent to Syslog
Can be large for especially with stacktraces, ...
• Queried with Grep, Sed, Awk, ...
Simple but doesn’t fit for complex queries
• A Regex implicitly defines the schema of the log
The customer keep focused on the application development

29. Typical Logs
Regex acts as a non
negotiated schema

30. Logs as a dataset
• Logs made of serialized plain entities
Log Schema updates are easier
• Centralized and combined for easy query through MapReduce
Any query can be executed
• Some command-line tools can be provided for simple queries

31. Logging as a Service
Applications send their logs
to Loggly which provides
some added value features
Compared to a vendor
solution, Loggly benefits
from a shorter and
richer feedback loops

32. Traditional Design vs. Design for failures

33. Traditional Design
• Technical errors typically redirect the user to an error page
SQLException, IOException, unavailable backend...
• Some single points of failure, or bottlenecks
Highly available stateful services may be expensive
• Timeouts and slow backends, are typically not handled
One backend gets slow and the whole application slows
down

34. Design for failures
• Failures will happen
Let’s embrace them rather than avoid them
• Handle slow backends and timeout with circuit breakers
The application may use graceful degradation
• Cloud and NoSQL brings some highly available storage
The most critical data can then be made highly available

35. Summary of interests for enterprises
• Elasticity helps to reduce costs and to handle high load
and simplifies capacity planning
• Cloud is high availability provided by experts
Avoid expensive, custom and/or brittle solutions
• Cloud middleware can be expected to gain quality quickly
Thanks to reduced and richer feedback loop
• But .... JEE 7 won’t come before 2013 / 2014

36. Questions / Answers
?
blog.xebia.fr
@mfiguiere