A customer started with an 8MB Tomcat runtime for web apps , but by the time the dev teams added in their "stuff" it turned into 60 MB "kitchen sink" type app server.. It includes may jars which one might expect to use to develop modern web apps which is fine because we expect customers to bundle those with the app. BUT it also contains a fairly complete set of jars that comprise a middleware server (web services, jms, ...)
Why should I choose WebSphere Application Server Liberty over my homegrown tomcat solution
Following is a comparison of Liberty
vs a homegrown Tomcat "kitchen sink" type server.
- Liberty, by design, allows you to include only the features you need for your applications .
- Liberty "minify" will subset the runtime for you, based on the configuration of the server
- produces a deployable binary server
- Homegrown is monolithic, will require significant manual effort and testing to figure out how to get back to "right-sized" server environment
-Or customer will need to always deploy the 60MB homegrown server
- Liberty - configuration changes are dynamic - don't require server restart (i.e. jms, jdbc, vips)
- Homegrown - configuration changes will probably require restart
- Liberty - all the configuration goes in server.xml (or xml files included by server.xml) at customer's choice
-unique properties can be managed external to the server.xml, which allows customization per environment (Dev, FVT, Prod, ...)
- Homegrown - all the packages added to Tomcat will have their own config method/files
- Liberty log / trace files are consolidated
- Trace setting are consistent across components
- Homegrown will have logs/traces in multiple locations
- Homegrown components will NOT have trace setting suitable for production debug
- Liberty runtime can be extended by adding features in an architectural fashion, consistent with IBM developed features
- Can create wrapper for 3rd party libraries which allows configuration of the new "feature" consistent with IBM developed features
- Homegrown only allows ad-hoc integrations of 3rd party jars
- Liberty - config changes are dynamic - don't require server restart (i.e. jms, jdbc, vip settings)
- Homegrown, - config changes will probably require restart
Liberty is fully supported by IBM
Homegrown? middleware support team + App teams + OSS communities
OSS communities (or public individuals) don't provide formal support. Its based on best effort and interest as determined by the particular community / individual
Liberty - In the service stream Liberty has strict backward compatibility requirements
- no regressions on service releases
- new behaviors in service must be intentionally enabled by customer
Homegrown - Open Source communities don't adhere to strict backward compatibility.
Liberty APIs are primarily based on open standards, allowing flexibility and a wider range of applications to work.
Homegrown - some APIs are based on standards but many are not. (i.e. "stax-2" is not a standard)
- Liberty - IBM vet's all the OSS that we deliver and the code we develop.
- Homegrown - due diligence is customers responsibility
- Liberty supports hashing/encryption of passwords in config, can be kept in separate property file
- Supports seamless integration with Tivoli and other authentication and authorizaton products.
- Homegrown security is likely to be a hodge podge of custom integration with different vendors.
- Liberty allows automatic "drop in" of new app versions. No server restart required.
- Homegrown - Tomcat allows "drop in" deployment, but most likely the extensions do not
Central server management
Liberty collective will allow customer to build large administrative clusters
- i.e. start, stop, update config sent to LibertyController which updates all servers in the collective
Homegrown - customer would need to develop management framework
Liberty is significantly better than Tomcat