ike so many startups, Yozons was founded when my partners and I came up with an idea that we believed would be a huge success. We felt our unique process for incorporating public key cryptography in a way that could easily be used by any businessperson was sure to revolutionize the document-driven economy—a "killer app" for electronic signatures and the last mile for the paperless office.
The only trouble is we didn't have sufficient capital to build the business. If you've lived through the founding of a company before, you what a serious problem that was. Money talks—you know what walks.
Undeterred, we immediately documented our special process and filed a provisional patent, giving us a critical year to raise money, develop the technology, raise more money, and then get the final patent application submitted. A year may seem like a long time, but time flies when you're busy designing, developing, fundraising, marketing, hiring, dealing with legal issues, configuring networks, and forging strategic partnerships.
After the dream of billions in revenue and a monster market cap in five years gave way to the reality of a bursting stock market bubble that was going to make raising capital brutal, we decided that we'd have to figure out how to bootstrap the company. Our calculations showed that we needed at least $200,000 to build the software on a shoestring budget. Among other things, this meant we'd have to use open source software to avoid the license fees, but of course keeping our source completely separate from the open-source code, and using highly portable coding techniques so we could deploy on "real" gear later. (See the sidebar, "Some Startup Lessons We Learned")
Prayers Answered
How do you find money when most investors were losing all of their tech bets? Family, friends and a prayer, of course. All three answered. First a friend came through, then came family and a few angel investors who chipped in until we exceeded our goal, letting us get started six months after the idea was hatched.
In order to build a viable Web services business, we needed to use tools that would let us scale from a single server on up to potentially thousands of servers to handle the projected loads. But if you've recently priced Solaris or NT, an Oracle database, BEA Weblogic, iPlanet, or RSA Security's crypto toolkits, you know that deep pockets are a must. And spending too much on base software would negatively impact our ability to sell a reasonably priced Web service as well as dramatically increase the licensing costs for our customers. It's a lot harder to make money on technology when the stack it rides on costs $200,000 for a moderately sized system. Open source can be the savior for enabling the building of sophisticated applications at a price point that allows a reasonable return on investment.
Because of my significant experience with Java technologies, I decided to build this system using Java. It is highly portable and new systems can be built rapidly.
Fortunately, Java is a free download for Windows, Linux, and Solaris. I decided to use Sun's JDK 1.3 and VA Linux's Intel-based servers running their version of RedHat Linux. Sadly, I'm now stuck with hardware that works fine but is unsupported because VA Linux recently announced they've abandoned their roots to become a software-only company.
The Web server seemed pretty obvious. I picked Apache because it is stable, robust, secure, and well known. What's nice is that our service requires high levels of security, with SSL a must, and the folks at OpenSSL have a fine implementation that plugs into Apache using ModSSL. The build was straightforward, and there was no cost other than the hardware and Thawte digital certificates for the production servers.
Apache Comes to the Rescue
But Web services require dynamic Web pages, so the next choice was for an application server. Fortunately, the Apache project came to the rescue on several Java fronts. First, it offers the Jakarta project, which includes Tomcat for our Java ServerPages and servlet environment. And it has an XML parser and a SOAP implementation that we needed for our remote APIs. With these in place, we could serve up secure, dynamic Web pages.
Next came the database. I'd read much about MySQL, and it did seem to be a super fast database. They'd just added transaction support, but it was a new combination and I fretted that it might not yet be ready for prime time.
So we turned to PostgreSQL. It's a seriously good database with a workable, though not entirely compliant, JDBC interface. Its support for transactions—even performance across queries and updates—good locking rules, online backups, and support for large binary objects was critical.
We did have a couple of minor snafus with PostgreSQL, though. First, binary objects are not well supported via JDBC, and it's important to run a "contributed" utility to clean up orphaned objects. Second, having to run "vacuum" periodically is a pain, though I understand it's being addressed soon. Third, the JDBC library doesn't support small binary objects, but we got around that by base-64 encoding them and storing them in a text field. We have a lot of small objects in our application for encryption keys, secure hash results for things like passwords and encrypted credit card numbers. Finally, timestamps in many programming environments have a resolution of milliseconds, but we couldn't get JDBC to accurately store anything higher than centiseconds. Normally, that's unlikely to be a problem, but if you use timestamps as part of a digital signature or secure hash, missing bits are a real problem. At this point, we had a free set of software that worked extremely well and allowed us to build a sophisticated Web application. Unfortunately, we needed more to support Yozons' highly distributed architecture.
In order for our application to be able to run on multiple, distributed servers, we needed a way to reliably transfer messages among them all. For that, we needed a transactional messaging platform with guaranteed delivery, preferably one that implemented the Java Messaging Service APIs. What I found was not open source, but at least it was free (as a startup, "free beer" may be more important than "free speech"). SwiftMQ's federated router architecture provided a highly scalable message routing platform that is fast and reliable. With the ability to connect remote routers over SSL, secure messaging is possible even over the Internet. Even though it's not open source, it has a community of users that can help with configuration issues—and bug fixes and new features have been coming out periodically.
At this point, we had everything for a scalable, distributed Web services platform—at no cost to the startup, and with no added licensing costs for our customers.
Introduction
Key Encryption Implementation
More Resources
