Sun's new Download System -- So what's going on?
By Gary Zellerbach on Oct 05, 2007
I first mentioned we're building a new download system back in March (wow, was it really that long ago already?), and frankly, we had hoped to have it out the door by now. Alas, it's been a very complex project, and when you're dealing with the kinds of download volumes we are, we simply needed more time to ensure the highest quality system.
One of the complexities (and benefits) of the project has been our decision to use much more of a service oriented architecture (SOA). When we built the first system starting way back in 1997, the term SOA wasn't even coined, and we built all the functionality ourselves. Since then, we have worked hard to standardize web services and systems that all of Sun's web properties can share via SOA. We call this set of systems the "Common Web Platform," and it includes ID management, My Sun Connection Portal, eCommerce, downloads, and more.
Here are some of Sun's common services that our new download system (internally, we call it "CDS" -- Common Download Service) will use and their benefits (similar functions were built-in to the old system, making it even harder to manage):
- ID Management: By using common Sun Online Accounts, users don't have to create nor remember multiple credentials on different Sun properties and can move between them seamlessly using single sign-on and session transfer. CDS doesn't have to build its own customer registration system nor store the data for millions of downloaders.
- Portal: When users download many of our most popular products, we'll automatically signal the My Sun Connection Portal about the transaction. Customers can then login there, go to their "My Products" tab, and it'll list their recent downloads. Using this info, the Portal presents really useful content. For instance, if you download the Solaris Operating System, you'll find informative links to articles, blogs, training, support resources, and forum postings. If you've never visited our portal, I think you'll find it very worthwhile -- check it out!
- Outbound Email: Some products are set up to send instructive emails to customers after they download. By using Sun's common email service, we gain efficiency while better respecting customers' Sun-wide privacy preferences. (Trying to track opt-in/opt-out data separately on our many web sites just doesn't work!)
So what's this have to do with the project schedule? With all the benefits of SOA, we're learning about the added complexity as well and some new pitfalls:
- Number 1, and probably obvious, but we don't control 100% of our fate anymore. Our team has to work with each service's business and engineering teams. Sometimes their priorities are different than ours, and a delay in any external system we rely on affects our entire schedule. (One of the systems lost a key engineer in the middle of our project, for example, and that hurt.)
- Environmental complexities: We can't build and test everything in our shared production environment, so we work in development and test environments. But the non-production versions of the different systems aren't necessarily in the same place, and so your testing can come to a dead halt just because someone hadn't opened the right firewall ports for the systems to interconnect.
- Debugging can be more difficult, and quite honestly it introduces a whole new world of "finger pointing" (as in, "My service works perfectly, so it's obviously something wrong on your end!")
These complexities are not the only reason the project has taken longer than expected, but they certainly contributed. It's a good learning experience, and when we plan our next SOA integrations, we'll know to add some extra time and be better prepared for this new world of interconnectedness.