Watson, Eat Your Heart Out: Here Comes x.ai
In 2011, when IBM’s Watson beat Ken Jennings and Brad Rutter at Jeopardy, the geek in me was giddy. Here was years of research on artificial intelligence and machine learning put into practice on live television, for all to see. And it won. The feat was impressive, but I wasn’t holding my breath for a Watson of my own anytime soon. With 100 IBM Power 750 servers (and a massive cooling system to match), Watson was so big and beastly that it couldn’t stand alongside its human competitors. Watson is powerful and may be potentially useful to many individuals and organizations in the future. But for now, I have other, more mundane problems. Like sifting through email, finding a rental car, and managing my calendar. It’s my understanding that Watson can’t do that yet, or at least isn’t available for such lowly tasks. A Personal Assistant for the Rest of Us Enter x.ai , an NYC-based startup that has created an AI-powered personal assistant that schedules meetings for you. Here’s how the product works. You connect your calendar to x.ai. When you begin the usual song and dance over email to schedule a meeting, rather than look at your calendar for a time, you delegate to Amy (or twin Andrew) Ingram by cc’ing email@example.com (or firstname.lastname@example.org). Once you copy her in, she takes over the thread, finds a mutually agreeable time and place, and sets up the meeting for you. I recently sat down with one of the x.ai founders, Alex Poon, to discuss what they’re up to and how they’re building the product. How x.ai Works I arrived early for our meeting at x.ai’s Wall Street office, and spotted Alex playing Ping Pong with a coworker. I waited for him to finish the game (I believe he won), and we sat down in the nearby lounge. Clad in a casual, startup-chic hoodie, Alex begins to tell me about the technology that makes up the platform and the way information flows through it. “We first ingest the email, and very quickly break it apart into the pieces we want,” explains Alex, “then we store that information in MongoDB immediately.” x.ai runs entirely on MongoDB and AWS. Natural language processing is a major component of x.ai’s stack. The information passes through a number of natural language processing modules built in Scala to extract the information it needs – names, dates, times, locations and so on. To facilitate this workflow, x.ai uses Amazon’s Simple Queue Service (SQS). Ultimately, the information enters what Alex and his team internally call Idris – the brain of x.ai, a supervised learning engine that can understand the context of the meeting and relevant emails. (Idris is a name borrowed from Doctor Who: “a humanoid woman who was used as a host for the matrix, or consciousness, of the Doctor's TARDIS.”) Idris maintains the context of each meeting. It knows what was written throughout the conversation, and it tracks the progress of scheduling the event. Based on the progress, it drives the conversation toward obtaining all the necessary information to confirm the event. Idris can enrich the metadata of the meeting and the participants to ensure that x.ai schedules a meeting according to the appropriate parameters, like a participant's calendar availability and meeting preferences. The data is once again stored in MongoDB before it is shipped off to the next module. Once x.ai knows what times to suggest for the meeting, it passes the object along to a module that figures out what to write back. Using a set of dynamic email responses stored in MongoDB, Amy crafts the follow-up. And that’s the basic lifecycle of a meeting in x.ai. x.ai uses Mongoose and Node.js for the front end. (This front end is for its team of developers only, as there is no front end visible to the end user.) It has also built an app to monitor Idris, which allows the engineering team to see all scheduling in flight. x.ai has a data set for training Idris offline, as well as a production model upon which Idris relies to schedule meetings in real-time. Both of these are stored in MongoDB. Alex mentioned that the team is interested in exploring some of MongoDB’s text and geospatial analytics capabilities, but it hasn’t yet begun to use those for its production system. x.ai uses replica sets for HA, and to ensure the data is always there in case of data corruption or an outage at AWS, it relies on backups from MongoDB Management Service (MMS) . x.ai <--> MongoDB I asked Alex to tell me a bit about why he chose MongoDB for x.ai. Sitting back at a small table in the lounge, he said rather casually, “It’s just so easy to explore your model – your business model, your data model.” In fact, this is the second company that Alex and his cofounder have built that runs entirely on MongoDB. (The other company, Visual Revenue, is a real-time predictive analytics platform that helps editors make better decisions about content creation and placement. It has since been acquired by Outbrain.) x.ai’s product is sufficiently far along that Alex says his team now only makes significant changes to the data model once every couple months. What about at the beginning, I asked. “Oh, well at the beginning it was more like weekly. I mean, all you have to do is add a field, and boom you’re done. We were iterating a lot then.” I was curious how often x.ai ships releases. Many of the customers I talk to at Fortune 500 companies are looking to move from 12-18 month cycles to shorter cycles in the realm of 6 months. “Ummm, we don’t really do releases. We’re on weekly sprints...continuous integration,” remarks Alex, as though he couldn’t tolerate anything more slow. To him, it’s a given that they’ll iterate every week. I love it. (By the way, Alex is hiring data scientists, data engineers, web application engineers and backend engineers.) My final question to Alex as we wrapped up: “So, I’d love to try x.ai...how long is your waiting list?” He glanced away for a moment as he stretched, and then he smiled. “Very, very long.” Want to learn more about how x.ai's data science modules interacts with MongoDB? Watch their presentation at MongoDB World 2015. x.ai MongoDB World 2015 presentation About the Author - Graham Graham is on the Product Marketing team at MongoDB. He works closely with customers, partners and the open-source community to articulate why MongoDB is becoming the world's most popular database. Prior to joining MongoDB, Graham was a Senior Business Analyst at CSMG, a boutique management consulting firm specializing in the high tech and telecom industries.
MongoDB Innovation Award Winners
What Do I Use This For? 270,000 Apps
“Would you rather run 10 different databases, or run one database in 10 different ways?” - Charity Majors, Parse/Facebook. When introduced to a new technology, would-be users often want to know, ‘So, what should I use this for?’ At MongoDB, we like to say, ‘MongoDB is a general purpose database good for a wide variety of applications.’ While this may be true, it of course doesn’t help the would-be user with her original question: ‘So, what do I use this for?’ Fair enough. In the evening keynote at MongoDB World, Charity Majors offered a response better than any MongoDB employee could have conjured up. Charity is the Production Engineer at Parse (now part of Facebook), a mobile backend-as-a-service that “allows you to build fully featured mobile apps without having to sully your pure mind with things like data models and indexes.” And it runs on MongoDB. Parse runs and scales more apps than even the most sprawling enterprises. 270,000 apps. The number of developers using Parse is growing at 250% per year; the number of API requests is growing at 500% annually. They serve every kind of workload under the sun. “We don’t know what any app’s workload is going to look like, and neither do the developers,” says Charity. And as Parse goes, so goes MongoDB. The diversity of workloads that Parse runs on MongoDB is testament to the canonical ‘general purpose’ argument. With 270,000 different apps running on MongoDB, it should be clear that you can use it for, at the very least, a lot of different use cases. But Charity’s rousing speech offered an implicit response to the use case question cited above. ‘What do I use this for?’ begs a different but arguably more important question that Charity suggests users ask themselves: ‘What can I not use this for?’ That is, when choosing a technology -- especially a database -- users should be looking for the most reusable solution. “Would you rather run 10 different databases, or run one database in 10 different ways?” Charity asked the audience. “There is no other database on the planet that can run this number of workloads.” While most companies don’t need a database that works for 270,000 applications at once, every developer, sysadmin, DBA, startup, and Fortune 500 enterprise faces the same questions as Parse but on its own scale. Given a limited amount of time and money, how many databases do you want to learn how to use? How many databases do you want in production? How many vendor relationships do you want to manage? How many integration points do you want to build? Assuming one database works for most if not all use cases, what is that worth to you? These are all flavors of what we’ll now call ‘The Parse’ question. To those in search of a solution, we suggest you take a look at MongoDB. And if you’re still unsure, we can try to put you in touch with Charity. But no promises -- she’s a bit of a celebrity these days. ======== Some other delectable quotes from Charity’s keynote because...we just couldn’t resist: “Holy #%& there are so many people here.” “I’ve been coming to MongoDB conferences for almost 2 years now, and they just keep getting better.” “Speaking as a highly seasoned operations professional...I hate software for a living, and I’m pretty good at it.” “Reliability, Flexibility, Automation.” (The 3 things she loves about MongoDB.) “When I talk about reliability, I’m talking about reliability through resiliency...you should never have to care about the health of any individual nodes, you should only have to care about the health of the service.” “Scalability is about more than just handling lots of requests really fast. It’s about building systems that don’t scale linearly in terms of the incremental cost to maintain them.” “The story of operations is the story of dealing with failures. And this is why MongoDB is great, because it protects you from failures. And when your database lets you sleep through the night, how bad can it be?” “May your nights be boring; may your pagers never ring.” To see all MongoDB World presentations, visit the [MongoDB World Presentations](https://www.mongodb.com/mongodb-world/presentations) page.
Dear CIO: Here's What Your Budget Isn't Telling You
The CIO is asked to do a lot: keep the network humming; secure the business from the Syrian Electronic Army; wrangle with gnarly vendors. But one demand stands above them all: cut costs. Most CIOs look in the obvious places -- replacing mainframes with commodity hardware; finding workloads they can migrate to the cloud; virtualizing and consolidating. Many CIOs evaluate where they can replace commercial software with open-source alternatives. We applaud them. While these efforts help trim the IT spend fat, they have little if any impact on one of the largest line items of all: staff. Said differently, CIOs should continue to pursue these initiatives, but might consider prioritizing efforts that make their staff more productive, since those efforts should move the needle more. This wasn’t always the case. In 1985, a gigabyte of storage cost $100,000. Today, it costs $0.05. In other words, it used to make sense to spend a lot of time optimizing for your hardware. By contrast, developer salaries averaged $28,000 per year in 1985. Today, developers are the new kingmakers, and they’re paid accordingly -- to the tune of $90,000 per year. Read: today it makes sense to optimize for developer productivity. Consider how this affects project costs. Take a sample project in 1985. Let’s assume in 1985 we need 5 GB of storage and we have 2 full-time developers devoted to the project. In 2013, we assume a generous 5 TB of storage and the same 2 FTEs working on the project. We take a 3-year view of cost. This is what the balance of cost looks like between storage hardware and developer salaries in 1985 and 2013. In 1985, it made sense to optimize for storage costs. Today, the cost of storage is a throwaway compared to the cost of development. In fact, the inventors of the relational database performed this calculation, too. Given the high cost of storage in their time, they made a tradeoff. They optimized the database for storage. Developer productivity, ease of use, agility -- these were deprioritized, and rightly so. Today, developers are at a premium. They comprise the lion’s share of cost relative to storage. When we built MongoDB, we optimized for developer productivity. And we’re not the only ones out to improve developer productivity. There are code collaboration tools, like GitHub. Platforms-as-a-Service, like OpenShift and Cloud Foundry. And better approaches to building apps, like agile methodologies. What your budget isn’t telling you is that old technologies are driving up your cost of development. When you budget for 2014, what are you optimizing for?
How to Stay Relevant by Listening to Your Users: A Lesson from ADP
ADP is quietly adapting its business to meet the demands of the modern consumer. With over $10B in revenues and 600,000 clients, ADP is one of the largest business outsourcing solution providers in the world. While a slew of technology startups are disrupting established industries – from payments to taxis to healthcare – ADP focuses on innovation to maintain leadership. This strategy is driven from the top, but depends upon the bedrock of flexible data infrastructure like MongoDB to make it work. IT As Innovator For CIO Mike Capone, IT must be a source of innovation, and to that end he expects his team to be an integral part of product development. To facilitate this, Capone created an IT innovation lab and also holds an annual conference in which top ADP executives showcase new ideas. To ensure his team doesn’t operate in a vacuum, Capone requires members of his leadership team to spend a day and a half with customers each month. Not surprisingly, as part of these activities ADP learned that its customers (and their end-users) wanted a better mobile experience. ADP validated this need, finding in its own survey that employee smartphone use now exceeds 50% for large and midsize companies, which mobile interest is even greater for some other demographics. Millennials, for example, may only check email occasionally on a laptop, but some have an 80% open rate on their smartphones (ADP). So ADP began to build mobile apps. One such app, ADP Mobile Solutions, provides employees a view of all HR services – payroll, T&E, benefits and others – within a single, elegant design. The goal was to give employees the ability to view the services they care about on the device of their choice. If an employee wants to check her copay while at the doctor’s office, that should be simple, intuitive and accessible on a smartphone. The results are staggering. Since launching over two years ago, the app has amassed over one million users across 41,000 clients. It is available in 17 countries and 23 languages, and remains one of the top 15 iOS free business apps. Systems uptime has increased and more projects are closer to timeline and budget, precipitating a rise in top and bottom lines. All of which is great, but how has Capone’s work influenced sales? According to Capone, sales productivity has risen by 20% due to better products. Those “better products,” in turn, derive from far better data: Capone tracks everything from the number of appointments it takes to close a deal on a new product to how often the new product is sold in a given launch period. Building Its Mobile Future On MongoDB When designing the mobile app and the associated infrastructure, the ADP team evaluated a number of technologies and chose MongoDB for the database. According to Jigesh Saheba, chief architect at ADP Innovation Labs, they chose it for several reasons. To ensure a pleasant user experience, the database had to be fast. It also needed to scale to support a massive user base. To live up to modern consumer standards, it had to be reliable and redundant across multiple data centers. Perhaps most importantly, the database had to be flexible and adaptable in order to support ADP’s mission for constant innovation. But it also needed to retain some of the features of relational databases – like rich querying and secondary indexing – in order to enable the feature set that the team wanted to implement. MongoDB met all these requirements, empowering ADP to bring a mobile app to market quickly, and then iterate on it continuously. Saheba’s team is a model for startup-grade innovation in a large enterprise, combining product development and operations into a single cadre known as devops. Not only has the team provided 100% uptime, but since launching the app, it has unearthed clever ways to listen to users and cater to their needs. For instance, by observing usage patterns in the app, the team found that when users look at a pay stub, a common next step is to compare it to the last. So they added a button to compare pay stubs in a single step. Similarly, ADP uses predictive caching to push relevant content to users – like a 401K statement – when that content is updated. <img src="http://s3.amazonaws.com/info-mongodb-com/_com_assets/media/ADP_Slide_15.png" style="width:90%";/> Having reaped the benefits of MongoDB to deliver a personalized mobile app, ADP is now looking to implement the database across the organization. Options include a MongoDB-as-a-Service internal offering to ADP developers and a Big Data platform. Enabling Innovation One App At A Time To the enterprise looking to stay relevant and to prevent upstart technology companies from disrupting their businesses, consider: What are you doing to listen to your users? And how does your database infrastructure support the innovation required to respond to them? See below for Jigesh Saheba’s interview with Silicon Angle’s The Cube.