Friday, April 28, 2006

fresher than most

With Magnolia 3.0 around the corner, and a new positioning of our products coming with it, we have decided to open-source Magnolia For Documents, our JSR-170 / magnolia-based document management system. The code will probably be checked in later today.

One reason behind this decision is that we strongly believe that Magnolia 3.0 will be so compelling, that our market share will rise significantly anyways, and be further boosted by the open source DMS. Magnolia immediately is the best open-source WCM and DMS available, so this is going to be a fun ride.

We also decided to scrap the planned (commercially licensed) web edition. Instead the community edition will be free, too, and offer functionality that is way beyond anything out there in the open-source area today.

In short, there will be:
  • open source (no binary)
  • community edition - free (binary with mostly open source)
  • enterprise edition - commercial with enterprise features like LDAP and JSR-168 support
  • business process edition - commercial
More soon through our official channels of communication.

to Matt: magnolia eats its own dog food

In a recent post, Matt was under the impression that is not running on Magnolia.

Well, he is under the wrong impression. Magnolia is using its own CMS for its homepage, and has been doing so ever since before we released the first version (November 15th 2003), exactly since July 16th 2003.

We have built some pretty amazing things with Magnolia, including magnoliaQT (edit videos in your browser, anyone?), Magnolia for Business Processes (draw and document business processes directly in your browser), and Magnolia for Documents.

Magnolia 3.0 will see its beta in the next week, including workflow and versioning, JSR-168 support, JAAS/LDAP, meta-templates including RSS feed generation (and consumtion) and podcast-generation, asset-management, scheduling and an even better new GUI.

As far as kick-ass sites go, thats a very personal perception, - here is one I like, using a quote from Brandon Root (Portent Interactive, who built the site):

"Thanks, you guys made my day Magnolia! We just finished up the Amgen Tour of California,, and everyone loved it!

We were very impressed with how Magnolia handled under the load, even before I got caching working. We averaged about 580 hits a second, although that was an overall average and we probably had about 4 times that during lunchtime. This was all running on a single server per magnolia instance, an intel xeon 3.0 ghz processor with 2 Gb of ram."

I think that kicks ass pretty badly, handling up to 8 million hits per hour. Maybe it needs two minutes for installation instead of one, but boy, that one minute sure buys you a lot ;-)

Friday, April 14, 2006

Magnolia Marketing Marathon

Pascal and I spent two days in Ticino with the intention to take a break from our hectic office and prepare the marketing of Magnolia 3.0

Ticino is a fantastic place - the exact opposite of our office - nice view, amazingly quiet, a place were you can reset your brain and start to be yourself again, and be creative.

Unless you are constantly online, using skype to coordinate projects around the world, mobile phones while taking a stroll to the plaza in Locarno and generally do business as usual, which is of course what we ended up doing instead.

Nevertheless, it was great being there, and yes, the pictures really show 40 gramms of red hot chili peppers and a handful of garlic to go into a brilliant fish curry we prepared for dinner on the first evening.

We still have managed to structure our new website and come up with a couple of great ideas.

And the magnolias where in full blossom (just that I did not take a single snapshot). What a beautiful view.

Magnolia's Multi-Server Advantage

Magnolia has built-in clustering capabilities. These come in the form of a pluggable publish-subscribe mechanism that allows to have any number of subscribers for a publisher.

Magnolia by default runs on a multi-instance setup - one authoring and one public instance - where the public instance is subscribed to the authoring instance.

This architecture has a lot of advantages. Two instances provide flexibility, performance and security. It separates concerns, scales well and allows creative solutions for interesting problems. Most of all, it allows to run Magnolia on two (or more) separate servers serving different purposes, namely to author content in a secured environment and to publicly serve the content to site visitors.

Stability of the public instance. Authors have the liberty to do whatever they need to without affecting the public instance. If something they do is so severe that the server needs to be restarted, this is not a problem. This even extends to developers that need to add new templates and other configuration changes that require a restart. All of this can be implemented and tested on the authoring instance without affecting the public instance which is visible by the user community.

The authoring instance needs system resources to facilitate editing content, locating and managing data, and constantly checking permissions. Often, you also output more log information, which costs additional resources.

The public instance is only concerned with generating cached pages and then serving those pages when requested. With this separation, content editors are free to tax this system as much as they like, developers can put in hot fixes required by content editors, and none of this impacts the performance or availability of the public instance.

Commonly, you want the authoring instance to be behind a firewall, and the public instance accessible from the internet. There are mainly two reasons why this setup makes sense - one is to make sure that no one can publish content by directly manipulating the public server, and the second one is to make sure that information is only then available to the public when it should be. A typical example is the publishing of a press release or financial information. Authors can edit the information behind the firewall and only once the publishing date has come, this information is pushed to the public server. So even if - for whatever reason - your public server is compromised, only public information is found on the system. At the same time, since no authors need to access the system directly, you can secure the public server tightly.

Due to this architecture, you can easily run the two instances on two different servers (or more instances on more servers). For instance, one of our customers has the need to publish information to 70 standalone servers for security reasons. Each of these machines needs to be accessible "from within" if their location is cut of from the outside world. In that scenario, one author instance is used to drive 70 public instances - on 70 different servers.

Another example is having 20 different authoring servers publishing to a single public server to present the content -- this is a typical university setup, where each department wants control over its own server, but the university wants a single public access point, preferably using a unified look and feel.