|
« August 2005 |
Zimbra Blog
| October 2005 »
As some of you have noticed our hosted demo was down over the last 18 hours or so. We had a planned upgrade last night to install ZCS Milestone 1 and add a 2nd server. We took the demo off-line and no more than 10 minutes later a Slashdot story posted.
Slashdot | Zimbra Collaboration Suite Launched
CPU wise the servers were 90%+ idle. At times pages were loading very slow; the demo was also sluggish so we decided to keep it down. We continued to troubleshoot and monitor the servers overnight. This morning we discovered that the firewall at our ISP only had a 10Mbit connection. This artificially capped our bandwidth, and was the root cause for the slowness.
We've now had this resolved and the demo is back up. Enjoy! Continue reading...
Posted by Kevin on September 28, 2005 at 03:59 PM
• Comments (0)
One question I'm answering a lot these days is "Why Email?"
In my prior life (CTO of WebLogic/BEA Systems) I was chained to my email for a minimum of 3-4 hours per day. Even while traveling to Asia or Europe, my admin. had to carve out an additional 2.5 hours of time from every meeting day for email. No doubt much of this overhead was due to sheer volumes (hundred+ inbound per day, not counting spam and mailing lists). But I also became convinced that I was wasting perhaps 1/3 of that time on tasks that my email software should have been doing for me:
(1) Sorting/moving email across north of 600 nested folders so I could hopefully find communications again (my self-defined sorting system probably worked 75% of the time; other times I would give up before finding the thread I was looking for);
(2) Managing external/internal conversations between customers and tech. leaders---At least ten times a day, a sales/customer question was sent to me. As CTO, I often (probably most often) didn't know the answer, but I did know who did, and so I had to play intermediary in forwarding and editing responses;
(3) Managing the workflow of communications to make sure none of the balls got dropped (To accomplish this, I had "hot", "hotter", "hottest", "on hold", and so on "staging" folders);
(4) Switching context from email to my contacts, email to my calendar, email to other web applications, etc. and then having to hand cut and paste content from one to the other; and
(5) Waiting for my email client while it sync'ed with my email server (consuming most of my client CPU and bandwidth in the process).
Like many other power users I have commiserated with, email became the most frustrating application I had to deal with, and it was the one that I was spending the most time on by at least an order of magnitude. How can it be that Yahoo! and Google are offering innovative, Web 2.0 email solutions with a gigabyte+ of storage for free, while my corporate messaging is still stuck in the mid 90's?
What I decided I was seeking was more of a "Web 2.0" solution:
(1) Rich search that covered every syntactic aspect of email and the associated attachments, so that I could always lay my fingers on what I was looking for without that a prior foldering overhead;
(2) Conversation management that spanned folders, so when new communications came in, they would be automatically correlated to relevant content in my archives;
(3) Content that was automatically linked to Web and enterprise applications: When a customer case number was included in email, why did I have to cut and paste it by hand into our product support system? When a travel itinerary showed up, why did I have to cut and paste it into my calendar, to print tickets, or to check for on-time status? What I really wanted as an AJAX-style "mash up" of email and the relevant application right there in my email client! That, by the way, is the real power of AJAX for email---not just the zero install/zero-management client: If the browser is the defacto pull interface, then email is the defacto push interface, and an AJAX messaging client allows the user to mix-and-match both paradigms without switching UIs.
What was surprising to me after my first six months as a Zimbrian is how similarly frustrated the system administrators are with the day-to-day care and feeding of enterprise messaging deployments. Laments I hear include:
(1) Why don't I have out of the box compatibility with my existing messaging PC and wireless clients?: Outlook---on-line and off-line, Apple Mail & iCal, Evolution, Thunderbird/Sunbird, Eudora, Blackberry, Good, Treo, Nokia, and so on;
(2) Why are messaging servers "black boxes" that prevent me from understanding what's on the disk, making my own back-ups, and reasoning about scalability?;
(4) Why do I have to restore an entire storage group to recover an individual user's mailbox at a particular point in time?
(5) Why do I have to buy enough SAN or NAS storage to redundantly store email attachments once per user (some systems) or once per storage group (other systems)?
(6) Why do I have to bolt on and then manage complex, unintegrated solutions for retention & archiving, replication & disaster recovery, HSM, and discovery/cross mailbox search when all of these services could be provided in a more integrated fashion?
(7) Why do I have to install and configure VPN and client software on every machine required to support email (including my employee's home systems) when the web security model and AJAX provide such a rich, zero administration client experience?
(8) Why can't I prevent potentially dangerous attachments from being downloaded to less protected clients by instead opening them on secured (Unix) servers with the latest anti-virus software, and providing an HTML rendering of relevant documents to those clients?
Hopefully, you agree---email today is well short of what email could and should be. So that's why email was the best choice for me---the opportunity work with a great team to strive to deliver a compelling better user and administrative experience was simply too much fun to pass up.
Posted by Scott on September 27, 2005 at 09:08 AM
• Comments (3)
Just a quick poll to gather the community thoughts.
Posted by Kevin on September 21, 2005 at 11:14 AM
• Comments (18)
We are frequently asked whether or not you should choose a hosted deployment for Zimbra. Since we have strategic partners offering Zimbra as a hosted service (or at least we will with our generally-available release), we do endeavor to be unbiased in advising you on the hosted versus on-premises decision.
Dean Jacobs (one of the former WebLogic architects, and now at Salesforce) eloquently makes the case for hosted software over on-premises software http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=320. Rather than echo many of his arguments, we suggest that in reality there is a spectrum of deployment options available to you:
• Hosting via hosted- and application-service providers (HSPs & ASPs), generally via generic (a.k.a. shared) hardware and software;
• Off-premises outsourcing –- Hardware and software is dedicated to your business, accessed over the WAN/VPN and administered externally;
• On-premises outsourcing -- Your LAN as well as dedicated hardware and software, but outsourced administration;
• Appliances –- On-premises, dedicated hardware, albeit with reduced administration overhead (which can itself be outsourced); and
• On-premises software
Given the broad range of software required by a small and medium-sized business (SMB), by a small and medium-sized enterprise (SME), and by a large enterprise, one size simply does not fit all---even within a company, let alone between companies. Thus far (at least for email/messaging), SMBs have been the mosted interested in pure hosting, while SMEs and enterprises have been more interested in on- and off-premises outsourcing as well as traditional on-premises software. Appliances, interestingly enough, seem to have appeal from larger SMBs all the way up to enterprises.
In order to find the sweet spot for a particular application, here are some of the trade-offs to weigh:
1. Integration with internal applications –- HSPs and ASPs do often provide integration points for other (generally on-premises) applications to securely access (consume) services and data (such as the web service bindings available for Salesforce). However, choosing to host applications that must consume services and data from other enterprise applications can be more challenging (see customization). The latter is often more of an issue for solutions like Zimbra, that support easy linking to your enterprise applications (ERP, CRM, and so on). While this can be done securely for applications that export web services, integration of applications deployed across multiple sights inherently entails additional overhead (e.g., in configuration, security, and performance).
2. Customization of applications –- Hosting’s (as well as an appliance’s) sweet spot is when you can use the application “as is”---that is, without any customization of the business logic to your specific workflows and without integration with other in-house applications. While some HSPs and ASPs are attempting to support the hosting of custom applications, the reality is that this business is inherently more one of an outsourced service offering rather than generic hosting. This is because your provider must understand your customizations in order to manage them, as well as to figure out how to merge them into future releases. Customization for horizontal platform offerings like Zimbra is often less of an issue than for more vertical business applications.
3. Performance -- Hosted and application service providers amortize hardware and network investments across multiple companies (indeed, this is one of their selling points). Such sharing can allow faster hardware to be shared across users, but it can equally lead to contention for those shared resources. Moreover, hosted services are located across the WAN, and hence inherently face additional latency.
4. Protection from WAN outages – Hosted- and application-service providers can often do an even better job of providing uptime for their application or service, since it is their core expertise. At the same time, however, such deployments are inherently more vulnerable to WAN connectivity problems. For on-premises email, temporary WAN problems are often masked from the end-user (since they are using the WAN asynchronously).
5. Security –- Like performance, security cuts both ways. VPNs/SSL and careful hardening can ensure greater data privacy even for hosted deployments. On the other hand, with an HSP/ASP your companies data is being hosted outside of your firewall and outside of your direct control.
6. Archiving and compliance –- With the emergence of retention policies and new regulations like Sarbanes Oxley, there are inherent questions about whether external providers are prepared to honor your precise policy requirements. On the other hand, if your policies are close to industry norms, an external provider may well be able to do it more efficiently than you can do in-house.
Any that we missed?
From our perspective at Zimbra, the key is to strive to architect Zimbra in a sufficiently balanced way that it supports this spectrum of deployment models---meaning that we need to get multi-tenancy, delegated administration, intra-server security, etc. right for hosting, as well as the easy install and compatibility with existing infrastructure for on-premises deployments. The good news is the vast majority of the Zimbra Community's work (and hence the Zimbra codebase) is focused on improving both the enduser's and system administrator's experience, and hence relevant to all Zimbra users.
Posted by Scott on September 20, 2005 at 04:40 PM
• Comments (3)
Founder Ross Dargahi wrote up a nice example of how the AjaxTk can be used to
mix html and tookit UI components.
Posted by Kevin on September 15, 2005 at 10:06 PM
For those of you that want to see the SOAP/XML in action... Try the demo or your local install with this debugging tip. It'll let you see the guts of our AJAX communication.
Posted by Kevin on September 14, 2005 at 06:52 PM
• Comments (0)
We have been quite happy with the response thus far to the name Zimbra. Hopefully, Zimbra is growing on you the same way it’s been growing on us.
The name Zimbra comes to us from Talking Heads’ (our choice for best band of the 80s) tune "I Zimbra", which can be found on Fear of Music (which ought, by the way, to be in your collection). Zimbra alone, of the thousands of names that we considered, came out of a desperate late night search through the CD collection to head off alternative names like HobNob, AquaFront, and Oompa Zing. (We’re use failed company names for our conference rooms, and there’s no possibility of our ever running out.)
Zimbra came to the Heads via Dadaism, which Wikipedia defines in part as a “protest against an oppressive intellectual rigidity in both art and everyday society.” Hugo Ball, a Dadaistic poet, wrote a nonsensical poem---Gadji beri bimba---just for the sound of it, and then Talking Heads made poem into song.
Zimbra apparently also means “Juniper” in Portuguese, but the term doesn’t seem to be in very common use. (At least, my Brazilian friends hadn’t heard of it.)
But we figured all that stuff out after the fact. The reality is that we just like the sound of Zimbra, and admittedly several of us still love the Heads.
I think to date naming may have been the single hardest thing the company formerly known as Liquid Systems has had to get done. Naming is hard, because
• It’s one thing nearly every employee and perspective community member cares passionately about;
• You have to endeavor to avoid collisions with many thousands of commercial software products (since every man or woman and his/her dog can have a commercial software product);
• You also have to endeavor to avoid collisions with 100,000+ open source projects;
• You need something that anyone can easily spell once they’ve heard it (I learned this lesson the hard way---“Tengah” was at one time the name for the WebLogic Server); and
• Of course, you need to be able to get the URL and trademark (both of which would have been challenging if we’d tried to keep the name Liquid).
Looking forward, however, there’s one part of naming that we still haven’t sorted: What do we call the members of the greater Zimbra community?
• Zimbrainians
• Zimbracans
• Zimbradors
• Zimbrashers
Your vote or additional contributions would be most welcome on this blog thread.
Posted by Scott on September 12, 2005 at 02:02 PM
• Comments (9)
Put together a few screen shots of some mash ups we've done. The Skype mash up can be seen on our hosted demo already. Google Maps and Alexa can be seen in a upcoming milestone release. Continue reading...
Posted by Kevin on September 09, 2005 at 08:10 AM
• Comments (1)
Some folks have already found it but we added an End User forum today. Great place to give feedback about using Zimbra and/or features you'd like to see in the future.
This is in addition to our Admin, Developer, and Announcements forums.
Posted by Kevin on September 09, 2005 at 12:32 AM
• Comments (0)
Posted by Kevin on September 08, 2005 at 11:29 PM
|
