Xebia Knowledge Exchange (jan 2011) - Trends in Enterprise Applications Architecture

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

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

Enterprise applications, nowadays

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

Service Oriented Architecture

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

The Cloud

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

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

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

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 • Simpliﬁes capacity planning

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

Public Cloud players

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

Public Cloud vs. Private Cloud Public Cloud Private Cloud

Example at guardian.co.uk

But the Cloud magic comes at a price

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

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

Conﬁguration and logging

Application’ inputs and outputs Input Output Application / Service Logs / Conﬁguration Monitoring

Application’ inputs and outputs Input ok Output Application / Service Logs / ? Conﬁguration Monitoring

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

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

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

Typical Logs • Append-only text ﬁles, 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 deﬁnes the schema of the log The customer keep focused on the application development

Typical Logs Regex acts as a non negotiated schema

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

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

Traditional Design vs. Design for failures

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

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

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

Questions / Answers ? blog.xebia.fr @mﬁguiere

Xebia Knowledge Exchange (jan 2011) - Trends in Enterprise Applications Architecture

by Michaël Figuière on Jan 07, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

Xebia Knowledge Exchange (jan 2011) - Trends in Enterprise Applications Architecture — Presentation Transcript