Are you running Tomcat on the Cloud? What can you do to make Tomcat really take advantage of the cloud? In this session we will discuss how to make Tomcat a native cloud runtime - one that is optimized to run "in" the cloud rather than just "on top" of the cloud. First we will look at what is important for any runtime that wants to truly be cloud native: multi-tenancy, self-service, elasticity, metering and billing, dynamic discovery and side-by-side versioning. Then we will explore how to make Tomcat work in this way. Based on experiences making Tomcat run in a cloud environment as part of Stratos, an Open Source project based on Tomcat and OSGi, we will look at the real issues, solutions, as well as exploring future work in this area.
Making Apache Tomcat Multi-tenant, Elastic and Metered
1. Making Tomcat Multi-tenant, Elastic, Billed
and Metered
Paul Fremantle
CTO and Co-Founder, WSO2
VP, Apache Synapse
ASF Member
@pzfreo
http://pzf.fremantle.org
Afhkam Azeez
Lead Architect, Stratos
Axis2, Synapse PMC
ASF Member
And also big thanks to Shankar, Amila, Srinath, Isuru,
Senaka and the whole team
2. Paul Fremantle
• Working in Apache
since 2002
• Apache Member
• CTO and Co-Founder of
WSO2
• VP, Apache Synapse
• I play the Tin Whistle
(in case you hadn’t
noticed yet)
@tedleung
3. Ok I lied a bit
• This is about “Using Tomcat to run multi-
tenanted, metered, elastic webapps”
• We didn’t embed this into Tomcat code
• If you want to leave now, I won’t be
offended!
4. “Cloud Native”
• Self-service
• Distributed and Elastic
• Multi-tenant
• Metered and Billed
• Dynamically wired
• Versionable, incrementally deployable and
testable
7. Can I run Tomcat on the Cloud?
• Yes of course
• There is at least one company selling
supported AMI images of Tomcat
• What does that get me?
– Saves me creating an AMI
• Can we do better? Yes!
8. Cloud computing in one page
The Big Picture
• Infrastructure as a Service
– Servers, storage & networking
– For infrastructure specialists
• Platform as a Service
– Middleware and Core Services
– For developers, integrators, architects
• Software as a Service
– Applications
– For end-users
19. Challenges of Multi-tenancy
• Security and Data Isolation
• Allocation of resources
• Configuration, Management
• Programming Model
20. Multi-tenanting Tomcat
• http://appserver.cloud.wso2.com/t/fremantle.org
/webapps/sample/
• Uses a valve to direct the request to the right tenant
• WAR files already have separate classloaders
– And session isolation
• Each tenant can only load code from their tenants deployed
WARs
• For services we also restrict classloading using Java Security
• We apply security policies to stop webapps opening ports,
modifying local files, calling OSGi Services
– We intend to enhance this to support limited access to services
23. Identity
• Every domain/tenant has its own single-sign
on and identity manager
• Based on LDAP – which is inherently multi-
tenant
– Each tenant has their own LDAP partition
• Supporting SAML2, OpenId, OAuth, XACML,
Infocard, WS-Trust
24. Simply enabling security
<security-constraint>
<display-name>Example Security Constraint</display-name>
<web-resource-collection>
<!– some stuff deleted for simplicity-->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>admin</role-name>
</security-role>
25. Single sign-on
• We already support SAML2 based single-sign on for
Administration
– So if you want, you can use a SAML2 Relying Party in
your webapp, that works
– We can recommend one too
• OpenSAML2
• https://spaces.internet2.edu/display/OpenSAML/Home/
• Not yet automatically supported for webapps
– We plan to add this
26. Elasticity
• Elastic Load Balancer
– Apache Synapse
• Always done load balancing
• Now has full transparent HTTP support
• Has “Autoscale” mediators
– Based on Azeez’s Master’s thesis
• Priority Execution support and throttling (Business
Class)
– Underlying Cloud API
• We have based on Amazon/Eucalyptus/Ubuntu API
• Adding support for vmWare underneath
29. Distributed
• Our distribution/clustering model is based
on Apache Tribes
• Adjusted Tribes to support WKA model
• In a large cloud (e.g. Amazon) you cannot
rely on subnet communications between
nodes
• Nominate two Well Known Addresses
– Tribes contacts the WKA and uses that the
bootstrap the fabric
33. Billing and Metering
• A generic multi-tenanted metering and
billing module
• Written as OSGi
• Uses Drools to implement service levels
– E.g. 10 users, 100Mb transfer/month, 15
deployed services for free level of subscription
• Can be used to meter real business events
– How many sales transactions / month
34. Programming Model
• Sub-tenant programming model
– “Normal”
– Suited to fit within a tenant
• Super-tenant model
– How to write one app for all tenants
– i.e. how to write multi-tenant apps
– Different but similar
• Neither is complete yet
35. Data
• Is a pain
• Most webapps use JDBC-based data sources
– Very hard to “multi-tenant”
• We are looking at two options:
– Multi-tenanted JBDC driver
– Multi-tenant NoSQL (e.g. Cassandra)
• In Amazon environment you can start up
RDS
– But you pay for time not usage
36. Cache
• Uses JSR107
• cache =
CarbonContext.getCurrentContext().getCache();
• cache.put(key, value);
• value = cache.get(key);
• CarbonContext is our general model for building a
sub-tenant multi-tenant programming model
– A set of standard stuff that works in an MT environment
– Isolation and security
37. What else do you need?
• Multi-tenant enabled:
– Log
– Cache (done)
– Billing
– Identity
– Authorization
– JMS/Queue/Topics
– Registry/Repository/Config access
– Managed Service Requester (HTTP, SOAP)
• JAXWS/JAXRS/Commons HTTPClient
38. Summary
• Cloud Native attributes distinguish code that
just floats on top of the cloud from
applications that live in the cloud
• Stratos is an example of a making Tomcat
Cloud Native
• Not complete…. But that would be boring
anyway!
Hinweis der Redaktion
Data center provisioned for peak capacity
Utilization is 5-10% or up to 50% with virt
Tight coupling between applications and hardware allocation
Bought app silos (e.g. SAP)
Provisioned for peak capacity
Build apps using enterprise middleware
Provisioned for peak capacity
Hardware & app provisioning takes months
Has a private IaaS
Overflows to one or more public IaaS
Uses a bunch of public SaaS
Has a bunch of private SaaS, both build & buy
Internally built SaaS is HUGE
Because that is the competitive differentiator for every business
Private SaaS running on PaaS using private hybrid IaaS
PaaS also could be private or public
Has unified identity, security, audit, etc. across all of these
Has federated identity management across public / private infra (SaaS/IaaS)