dsi-javaee-in-the-cloud-andreadis

Red Hat
Java EE in the cloud

Dimitris Andreadis

DSI 2011, Portorož, Slovenija

1 DSI 2011, Portorož, Slovenija

Agenda

● Why PaaS is important
● Existing Java PaaS offerings
● Java EE and the Cloud
● JBoss/RedHat and the Cloud
● Conclusion


Agenda

● Conclusion


The most Powerful Shift in Enterprise
Computing in the last Decade

Provide new services despite
The Cloud budget limits

Increase enterprise agility

Improve service levels

Reduce capital requirements

Increase operational efficiency


Gartner proclaims 2011 to be
“The Year of the PaaS”
● By 2013, all leading software vendors will aggressively
compete for leadership in the cloud platform market
● By 2014, most mainstream IT organizations will have
a positive experience using a PaaS service and will be
increasing its use.
● By 2015, cloud platform experience will be a listed or
demanded skill in most hiring decisions by IT software
projects.


PaaS Provides Abstraction & Automation

A Cloud provides PaaS Cloud: API & Service
abstraction layers to abstraction,
manage scale and 3rd Abstraction maps app
Developers APIs and services to
complexity
cloud resources
• Self service
IaaS Cloud: Resource abstraction,
• Abstracted, elastic 2nd Abstraction maps
resources cloud to virtual
IT/Cloud Admins resources
• Location-independent
storage & services Virtualization: Hardware abstraction,
• Users, Groups 1st Abstraction maps
Virt Admins virtual to physical
• Accounting resources

• API's, Drivers, Tools Bare metal: Full access,
No Abstraction
• Federation System Admins


What “True” PaaS Buys You


Current PaaS vs. True PaaS

● Current PaaS is more like a Glorified IaaS
● Pre-installed, pre-configured middleware
● With some nice UI and scripting glue
Deploy App:
 Provision Provision DB Deploy schema
cluster

Still many IT tasks to perform
Deploy App to (not a transparent update process)
● Provision cluster:
each node
provision Configure LB
nodes
Setup BC for QA cluster

Setting up IaaS components
cluster
● Configure DNS
Provision DB:
 Provision

Complexity is still there
node
Setup BC for DB
●
Provision node:
Configure AS

Manage environment (recurring)
Analyse sec. Analyse QA Analyse AS/OS
bulletins bulletins logs
maintain OS maintain JVM maintain AS

maintain DB maintain FW Validate/QA
Metering/Scaling (recurring) stack
Measure App Provision node
performance
Update Cluster Update LB Update Security


Agenda

● Conclusion


Google App Engine (GAE)

● A Jetty based web container that
scales the Google Way!
● Adapt your application design to the Google paradigm
● Let the engine assume full control of resources and I/O
● Remove the database bottleneck with NoSQL BigTable
● Use misc facilities, mail, memcache, schedulers, SSO

● Enjoy zero administration and maintenance
● Provisioning, monitoring, fail-over, sharding
● Secure, reliable and cost efficient

Google App Engine (GAE) – cont.

● Restricted Java APIs (JRE Class White List)
● Restricted I/O, no Threads, DB operations
● No full EE (e.g. EJB, JMS, JCA, etc.)
● Questionable framework support (e.g. Hibernate, Seam,
RichFaces, etc.) with many workarounds

● Various limits & timeouts
● Outbound connections, 5-10secs
● Request must return within 30secs
● Queries may return up to 1000 results


Google App Engine (GAE) – cont.

● Great for new applications with scalability potential
● Pay nothing or as-you-go

● Too many constraints and portability concerns
● Often a show stopper

● Enhanced App Engine for Business on the way
● Hosted SQL support, etc.


Amazon Elastic Beanstalk (beta)

● Managed Apache Tomcat container on EC2
● Use any compatible Java frameworks
● No limitation on threading, file or network I/O
● Limited only by the capacity of the underlying VM

● Many database options
● Amazon RDS (MySQL and soon Oracle 11g) on
dedicated/managed hosts
● Amazon SimpleDB (NoSQL)
● Roll out your own with Relational AMIs over EBS
volumes.


● Control scaling options
● Fire up new instances based on predefined rules
● But you need to setup session replication yourself

● Access to other Amazon Simple * Services
● Queue (SQS), Storage (S3), Email (SES)
● Payments APIs, etc.



● Natural PaaS evolution step for AWS IaaS
● Still offering full control over underlying IaaS

● Proven option for Enterprise Applications
● Cost is an issue for small websites/applications


CloudBees

● RUN@Cloud infrastructure acquired from Stax
Networks
● Support for Tomcat (and soon JBoss AS)
● Utilizes EC2 (with plans for other IaaS providers)

● More IaaS sharing options for lower costs
● Multiple appServer instances on the same virtual server
● Inactive instances are swapped out of memory
● DB servers can also share virtual host


CloudBees – cont.

● DEV@Cloud a.k.a. Hudson/Jenkins as a Service
● A Continuous Integration environment that scales
● Private Maven Repositories
● Git/Svn Repositories (soon)

● Going for DEV@Cloud to RUN@Cloud


Agenda

● Conclusion


Why the JVM is good for the Cloud

● The Java Virtual Machine is already
a managed environment
● Portability across O/S & JVM implementations
● Remote debugging/profiling/monitoring hooks
● Security Policies

● Base runtime for different JVM languages
● Ceylon, Groovy, Java, JPython, JRuby, Scala, etc.


Why Java EE is GOOD for the Cloud

● Java EE is essentially a managed
container architecture
● Packaging is standardized
● Resources are managed
● Services are injected
● Applications are isolated
● Security is part of the model
● Basic monitoring is provided
● Clustering is supported
● Portability between Java EE Containers
is reasonably good

Why Java EE is BAD for the Cloud

● Most EE servers still heavyweight
● Applications often assume exclusive runtime usage
● Modularity of applications and services an afterthought
● Setting up of standard services not standardized
● Configuring clustering facilities even less standardized
● Traditional RDBMS stores present scalability problems


The PaaS reality

● All of your Java EE are belong to us!
● You do not control the Platform
● You may have to share the Platform
● You need a portable way to configure the Platform

● For existing Java PaaS solutions
● Either adapt to what is offered, or
● Tweak the underlying infrastructure


Java EE 7 Goals

● Multitenancy support
● Different apps sharing a runtime
● Potentially 100's of them

● Service Metadata
● Configuration and QoS for provided services
●
Clustering, 2nd level Caching (e.g. cloud.xml)
● New Cloud “Deployer” Role


Java EE 7 Goals – cont.

● Modularity (compatible with SE 8)
● Versioning of apps, Dependencies
● Versioning of APIs/Impls, BOMs

● New APIs
● Web Sockets, HTML 5, JSON
● JCache, NoSQL?

● Updates to existing APIs
● JMS, JPA, EJB, CDI, BV, Servlet, JAX-RS, JSF, ...

Java EE 7 Goals – cont.

● Target Timeframe – end of 2012
● Timeboxed Release Design by Committe®

● The “Enterprise Cloud” - WARNING!
● Let best practices emerge, then standardize


Agenda

● Conclusion


Achieve Flexibility and Avoid Lock-in With
Portability in the Cloud


Red Hat Cloud Foundations PaaS


Makara Accelerates
Red Hat Cloud Foundations PaaS

● Provision and secure Cloud resources
● Support for JBoss and PHP applications
● Application auto-scaling
● Performance monitoring for the entire stack
● Dynamic log management built in


Red Hat Public Cloud PaaS Service

●
1st Release of Red Hat's PaaS offering will be as an
online service
● Hosted public cloud service by Red Hat
● Will offer choice of public IaaS clouds for back-end
providers
● Ideal for developers wanting to develop new applications
rapidly as well as enterprises wanting to provide self-
service development, test, and production environments

Developers can currently try out an online preview of Red Hat's PaaS at
http://makara.com


Introducing JBoss AS 7.0

● Motivation
● Improve Elasticity Qualities
● Improve Manageability
● Simplify Configuration

● Clean things up!
● Remove abstraction layers
● Remove legacy stuff
● Modularize


JBoss AS 7.0 – Elasticity

● Faster (Parallel) Start-up
● 3 secs (AS 6.0 ~19s)

● Smaller Memory Footprint
● 16M (AS 6.0 ~180M)

● Smaller Distribution
● 60M independent to the number of profiles


JBoss AS 7.0 – Manageability

● Multi-node Centralized Configuration
● Or Standalone

● Multiple management APIs
● CLI, Java, HTTP, Console

● Simplified Configuration
● No intermixing with internal wiring


JBoss AS 7.0 – Modularity

● Based on JBoss Modules
● In anticipation of Java SE 8
● With Support for OSGi Bundles

● Modular
● Do not expose implementation details
● Better Classloader Isolation


JBoss AS 7.0 – Roadmap

● AS 7.0 currently in Beta3*
● 7.0 Final (EE6 Web Profile)
● 7.1 Final (EE6 Full Profile)

● JBoss AS 7.0 will be the base for JBoss
Enterprise Application Platform 6 (EAP)

*Check out JBoss JIRA for an up-to-date schedule


Agenda

● Conclusion


PaaS is all about balance

Managed Flexibility &
Scalability Control


Beware of Vendor Lock-In!


Evaluating PaaS providers

● Ask the right questions
● Ease-of-use, Management, QoS, Cost

● Ability to
● use arbitrary technologies & frameworks
● move code & data between different clouds
● abstract and choose application services
● access the underlying infrastructure


dimitris@redhat.com
41 http://dandreadis.blogspot.com
DSI 2011, Portorož, Slovenija

dsi-javaee-in-the-cloud-andreadis

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Recently uploaded

Recently uploaded (20)

dsi-javaee-in-the-cloud-andreadis