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
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
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, ...
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
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