We got a lot of good feedback from customers when we announced the 3.0 builds and platform changes. As a result, we've added back support for the MySQL and SQLServer databases. I'd like to take a minute to address some of the feedback and explain some of the background for this move.
As background, we've changed the way we package and ship our software. I just published an in-depth look at the benefits of this move - a good read if you're looking to understand more.
The package we've built is available on Linux and Solaris and runs on the following databases: MySQL, Postgres, Oracle, and MS SQLServer. The application itself is available as an installable package and bundles an application server, Java runtime, the app itself, and a set of optimized preconfigurations (example: tuned JVM settings).
Why make this move? A number of reasons. We talk to customers often and the consistent number one priorities are performance, scalability, stability, and the support experience. We get a lot of great feature and improvement ideas but those top priorities are the air customers breathe. Based on that, we try to move the needle in these areas significantly for each release. For example, for the 2.5 release we managed a 40% performance improvement overall. In 3.0 the numbers aren't quite as dramatic but we've added new features and performance has not suffered. As we looked up and down our architecture it became clear that some new thinking was needed.
The application has evolved past the point where it can be distributed as a standalone WAR file (however, to be clear - a WAR does still exist in the bundle). The context in which it runs is vitally important, especially for things like performance but also for features. We need the ability to depend on the environment we run in and there is a lot of variance in server-side Java deployments.
On the support side, we've seen too many misconfigurations in the environment. For example, sometimes we see issues where a customer is unable to change the parameters of the VM either to allocate more heap memory or to change the GC settings - these kinds of things are vitally important to the Jive app. Another big challenge is just access to the right log/debug files - none of this is consistent among appservers. Also, oftentimes the best information is a Java heap dump and we've seen the ability to get that information be a real challenge. In the new package, we've distributed a script that grabs every relevant log file and heap dump and zips it up in a way that can easily be sent to our support team. We feel this will dramatically improve the time-to-resolve issues.
What doesn't change? It's important to note that development, customizations, plugins, themes, etc don't change in at all. For example, how you deploy a plugin is exactly the same. Clustering also works in the same way. This is not an appliance, nor is it a black box. (Note, an appliance is something we'd consider as an option for future deployments - let us know if you have feedback on this approach).
We believe there are a lot of benefits to this approach. Ultimately, this foundation will allow us to develop some very unique features while delivering continued huge performance and scalability gains. We definitely recognize some customers will have problems migrating to this platform and we're more than willing to make it work for you - just let us know.
(One final note: within a week we will announce when the extra database support will be available.)
If you have questions, comment on this post or feel free to drop me a line at bill@jivesoftware.com.
.
Nice, Very Nice, so you start Supporting mysql and MSsql back?,
but I dont udnerstand if you support msSQL should not you also support win OS?
this is totally wrong.
Java heap dump and we've seen the ability to get that information be a real challenge....
do you really beleive that IT departments do not know how to adjust heap size? I am 100% sure, companies that use Clearspace have smart anought IT to be able to change JVM parameters(common man, what kind of statistics are you basing this from? ). or where to locate log files? especialy if jive (besides server logs) managers its own additinal layer of logs and logfiles.