There comes a time in the evolution of building a technology platform that you have to pause and look back where you’ve come from, before continuing on with the journey. As I think back to the formation of the Cisco Eos platform, it was a time of hard work and rapid growth.
The Cisco Media Solutions Group went from being a business unit with an idea, to truly taking form in 2007 when Cisco made three software acquisitions—Five Across, the assets of Tribe.net and the assets of Click.tv. From that day forward, we were charged with developing an innovative platform that could get media companies online in a simple, manageable way. That long journey started with the single though difficult step of uniting three independent companies and countless independent perspectives into a single team executing against a single vision.
As with any consolidation effort, tough decisions had to be made. One of the most important we faced was what development platform we were going to leverage. Our three teams had experience in just as many languages: Ruby on Rails, PHP, and Java – not to mention Adobe Flex and even a bit of C. After much debate, we chose to use Java for the back end, which includes the core Cisco Eos data and content components like blogs, discussions, and member profiles. And we chose PHP for the front end, the dynamic page-rendering environment that our users can customize for presentation to end consumers. Read More »
Tags: API, architecture, cisco eos, data, platform, social entertainment, technology
Working with our customers, we see media companies in all stages of the social entertainment development process. Many have taken the first step and have begun integrating social features into branded web sites, leveraging Cisco Eos to build out the social experience. However, it is when media companies stop here that they immediately leave fans longing for more.
You may be thinking, “But my competitors haven’t gone any further than this, so we must be in line with what users want, right?” To address this, I ask you this question, “How do you personally interact with content?”
Unless you have been living under a rock, you have a smartphone that gives you the ability to use targeted interactive apps or surf the internet. You may have taken it a step further and bought an iPad to get this same mobile experience on a larger screen. If you fit into either of these scenarios, ask yourself why your consumers aren’t also looking to take advantage of these platforms to engage with your content. As with any product or service, individual users have individual preferences. To fully reach your target audience, you need to provide access to content from all of the devices they use. If you don’t, you run the risk of leaving a large percentage unsatisfied, or turning them off from repeat visits.
If last month’s SXSW Interactive Conference brought anything to the forefront, it is that people are increasingly interested in using mobile web and mobile apps to view content anywhere, anytime. If you are in charge of developing social entertainment experiences across your content portfolios, it is time to start reaching beyond the desktop computer to mobile devices. If you fail to extend your social entertainment experiences to all screens, you are missing the ability to capitalize on a very important, very large audience growth opportunity. Read More »
Tags: API, cisco eos, html5, mobile, osmf, smartphone, social, social entertainment
Arguably, one of the biggest weaknesses of MPI is its lack of resilience — most (if not all) MPI implementations will kill an entire MPI job if any individual process dies. This is in contrast to the reliability of TCP sockets, for example: if a process on one side of a socket suddenly goes away, the peer just gets a stale socket.
This lack of resilience is not entirely the fault of MPI implementations; the MPI standard itself lacks some critical definitions about behavior when one or more processes die.
I talked to Joshua Hursey, Postdoctoral Research Associate at Oak Ridge National Laboratory and a leading member of the MPI Forum’s Fault Tolerance Working Group to find out what is being done to make MPI more resilient.
Read More »
Tags: API, HPC, IPC, mpi, resilience
Many in the HPC research community are starting to work on “exascale” these days — the ability to do 10^18 floating point operations per second. Exascale is such a difficult problem that it will require new technologies in many different areas before it can become a reality. Case in point is this entry at Inside HPC today entitled, “InfiniBand Charts Course to Exascale“.
It cites The Exascale Report and a blog entry by Lloyd Dickman at the IBTA about their course going forward. It’s a good read — Lloyd’s a smart, thoughtful guy.
That being said, there’s a key piece missing from the discussion: the (networking) software. More specifically: the current OpenFabrics Verbs API abstractions are (probably) unsuitable for exascale, a fact that Fab Tillier (Microsoft) and I presented at the OpenFabrics workshop in Sonoma last year (1up, 2up).
Read More »
Tags: API, HPC, mpi, networking, software, verbs