I ask you to bear with us. Because I'm certain every single one is an interesting talk. We're hearing about the way organizations are adopting MongoDB. We've heard them starting from inception. We'll hear a couple of those this afternoon. We've heard years of stories. And as we continue, we've got a great story here from Forbes. Forbes, which is a publishing company, that's gone out and created a project called Falcon where they've introduced the ability to be a publishing software capability, both on-premise and as a service.
And we have the opportunity to hear, today, from the former vice president of software engineering, Steve Bond, who is a self-proclaimed technology nutritionist. I've asked him to explain that because I don't know exactly what it is. But his whole purpose in life is to disrupt and cause chaos where you have a focus on discipline, calculated risk, and one more thing, what was it?
I don't remember.
Anyway, we're really pleased to have him. Just before we get started, please make sure your mobile phones are on silent. Remember there is a survey for each of the presentations. You can find it on the MongoDB World app. Please fill it out. If you do, you'll be placed in an automatic drawing for an Xbox each and every time that you do that. So thank you very much. Steve, thank you for joining us. We look forward to your story.
Thank you. Hi, I'm Steve. I'm going to go through introductions. Number one, I have no sense of humor. But like everybody who has no sense of humor, I think that I'm very funny. So I'll start cracking jokes. Please laugh. Because I have somebody here who always tells me I'm not funny. All right. So anyhow, how are ya'll doing? Because I just moved from Austin, Texas on Saturday. But I forgot my cowboy boots at home. So that was a joke. All right. Fine.
So what a technology nutritionist is. So I don't work for Forbes. I joined Forbes in 2010, with the sole mission to rebuild their content management system. And it's been a fun ride with them for three years. And I'm being totally biased and unbiased. I'm going to tell you what we've done at Forbes. And I was the original architect of the platform. And how it's really changed the company that is a 97-year-old start up in media space. And it became, in like a couple years, a start up in technology space.
So with this said, it would be cool if you can have something like this. Right? You buy stuff. You look at it. And you say, OK. It's good for me. I'm going to take this strawberry cheesecake and eat it. And it's going to do me a lot of good. And I'm going to go run in Central Park. It would be cool if in technology you can do the same. But it doesn't happen this way. And every time you're faced with building a platform, it's almost like a soccer game. But instead of 11 people on the field, you are on the field alone. But there is 11 people on the sideline judging every move you make.
So it's pretty cool. And the ball is the size of the goal. And the goal the size of the ball. So try to figure it out. And I'll tell you how we tried to figure it out with Forbes. So it started with pretty simple things, the agenda. So I've done introductions. I'm not going to shake hands and kiss babies. OK. I'm going to stop making jokes. Hi. How are you? So introductions are over.
I want to make it very interactive. Just throw a paper ball at me. I would love it. And I'll answer any questions as I go, as opposed to the end. What keeps you awake at night, general challenges in publishing? I'm going to keep this agenda on. I don't have too many slides. But for me to understand you, like, how many of you are engineers, just engineers? Man, the world needs more of us. It's a business of technology. How many are just of pure business? Great. And everybody like me in transition, right? Business and technology. OK.
So anyhow, how we started at Forbes. So I came in summer of 2010. And the goal was for me to look at the content management system that Forbes had and help them to understand where they want to go. The content management system that they had could be called anything, but actually, was a lot of components. Bought, built, customized, they were all working somehow very hard to make them work, very hard to make it open to the world. And the idea was how to make the publishing world open source. Like, Forbes wanted to connect people who are going to write for them from anywhere in the world. A new newsroom, brilliant idea.
But how are you going to use a content management system that you buy off the shelf and let everybody connect and write their wonderful content without VPN or jumping through the hoops, or what have you? It was hard. And the goal that we had to make open-source business solution for Forbes, as they envisioned, and started looking at commercial software. And I'm not going to name what packages we looked at. But none of them actually worked. They were all closed-source. You can't modify a lot of things. You can write a lot of code around it. But that's about it.
And then we decided to figure out what does content management mean in this world. And I like to say that content management world is over. And now we live in the post content management world. What it means, it's just like, you know, speakers. Forget about whoever owns data does it best. Let me get the API. Let me figure it out. Let me concentrate on applications. And that's the approach we took. We said, OK. Content management is a great thing. But what is it?
It's ability to create content. It's ability to store content, search it, and render it to users. When we looked at it, none of the commercial packages actually worked. So we broke it into components. Let's find a tool that will allow writers create articles. Great, one. Second, let's find a database that we don't have to think too much how to modify and have flexible schema. Two, let's find search index. Three, let's find out how you're going to protect infrastructure from high traffic. How are you going to make sure, we're going to scale. Four, and a lot of other things.
So when we broke it down to the components of the system, it was much easier to find a solution. A solution for content creation was driven by network of bloggers or writers. Everybody was extremely familiar with WordPress. They love Wordpress. We could have replicated the HTML editor, or got Drupal, or whatever. But they love it. OK. Fine. Have it.
Would I put a medium to high load site on WordPress on MySQL database-- I have nothing against MySQL, I've done years on MySQL-- but I wouldn't. So we started looking at databases that allow us to do two things-- A, scale, B, don't hire new skill set of people. Forbes, at this time, outsourced DBAs to some other companies that I don't remember. But, so you have people, because you cannot bring them. DBAs are expensive, what have you. And every time you have to change schema, for those of us who code, and you have to change something in MySQL. You just create this hookup table, and whatever. You create. But you change your stored procs. You do stuff.
And it's going to parallel development where you talk to web developer. If you're going to give database to web developer and he's going to do something very fast. And it might not scale. So I was told, please do something that doesn't require to buy more talent, to get more people into the company. Great. We looked at left schema relational databases and it kept us awake at night for a very long time. Then that was a Eureka moment, a little bit more from my MapQuest experience. As some of you remember, there was a company called MapQuest doing maps before Google was doing Maps.
And the way we solved maps, at MapQuest on a technology level, we just schlepped MySQL database and web server. So they're sitting there on the edge and data is available. And this schema was very flat. So we used MySQL database, but stored data just like you would store in NoSQL database. But we were not using anything from MySQL. But it was cool. It was the only solution was. And we thought we were geniuses because we flattened it all out. But we didn't need the engine.
So then we started looking at solutions such as Cassandra, Couch's, and Mongo's, and other fruit. And it became-- it's interesting, like, when you look into the NoSQL databases, and please Mongo people don't throw anything at me. It's like it's a religious thing, right? This is better. This is better. Key value. Blah, blah, blah. Document. schmocument. I don't know-- cool, right? But then when you have the second thing, how can I put it into production tomorrow or yesterday? And I don't need to open reqs and hire people. And it's a challenge in itself if you work for a corporation.
Then it became clear that my argument over years with my friend who was CTO of Financial Times, what is different in structured and unstructured data was a -- I don't care which data-- but how are you going to store it? But this thing answers the question, the MongoDB. And when Java developers got into it, they're like, oh crap. It's easy. I'll do it, whatever. I don't want anybody. The only thing that we have to do, if you're interested in how to manage this with people, is we created a very tiny group of platform engineers. And they're goal was just to do the best possible job with protecting database from application developers and creative API layers.
So this went very well. And we were able to launch the first MongoDB implementation in like a couple months. Nobody knew anything about MongoDB. Nobody knew anything about our search index, that we picked Solr, another open source, a great package. In two months, engineers that never touched MongoDB were able to make a product that just scaled out of the box.
Woo hoo.
Great story.
That was a joke? It's a great story. Yes. It's a great story.
And then over time, looking at how we developed with MongoDB at Forbes and other companies, it is really intuitive and easy tool. And another thing that, not to go into religion, if you're thinking about Mongo, no Mongo, Schmongo, to me, it's three things, right? It's ease. A Java engineer can do it. And what else? What else that I didn't like when I called CouchDB, a great solution? Nobody picks up the freaking phone. And if you go down and bounce, it's not cool, right? Especially, if you want to get the next paycheck. That was a joke.
So the third thing with MongoDB, that my hat off to them, is when you pick up the phone there's like three people trying to help. I had an instance with MongoDB when I told one of the people, who is in this audience, like, I don't need you on the phone. There's too many of you. This is great. I love that you're trying to help. But they're trying to help. So these were the three big things that made it for us with Mongo. OK. But how we turned this into a technology company. And this goes to a nutrition label, working with this open-source technology starts inspiring you. And B, there were two moments which made sense for us. In 2011, the business didn't believe that we should concentrate any amount of dollars on mobile. Everybody said mobile is important, 2011.
But nobody wanted to say, let's take four engineers, put them in this room, and tell them to do the mobile site. Because the mobile site was at 5% only of traffic. And the reason behind it, because it sucked so much. Right? But nobody wanted to put four engineers. And that's where we decided to go a little bit rogue. And we said, can we have two weeks of lab time. Just lab.
One person. One person, can we take the engineer who is very tired from the last project, give him two weeks of relaxation, and do something with mobile. And actually, I lied. It ended up being one and a half person. And ended up three to four weeks, we launched the whole Forbes mobile site on freaking doing two weeks of development.
Why? Because whatever we needed to do with MongoDB, we just extended the schema, right? It's easy. You don't have to create the hookup tables. Even if they're all old values and sometimes we don't clean up, fine. But you can add what you need straight through Java. And you don't have to do a lot of stuff, right? So back in Java developer, we'll just do it. And in two weeks we'll launch mobile site, the full site, definitely not every possible page. And the traffic went from 5% to, I believe, 15%. Now, it's at over 50%, as far as I know. But it went from 5 to 15 overnight because the site looked good. And it loaded faster than going through the night or buying a coffee at Starbucks across the street.
So this is one thing. We said, wow. This is kind of interesting, what we built around MongoDB, what MongoDB gave us. And it works. The second thing was we, in 2011, summer, the same year, a great year, we launched some of the lists that Forbes is, I don't know, what colleges, or some list, some wonderful list that tells you where to live, what to do. And we have networking issue. And we just go down, like hard, very hard. And this wonderful list that everybody writes about, it was just for some reason, like, 4 0 4, how are you doing.
And the first reaction from all the executives was like, oh crap. Do something. Take a snapshot of every page. We used to do this, and whatever. It's going to take you a couple of minutes, hours. And put the list back up. So we're given two hours, right? And it was the big aha moment with MongoDB and the code that we wrote. So two hours and I said, fine. I probably can find a better job. But it's kind of cool. Let's try. We schlepped every piece from the technology stuck in one box. Right? I'm serious. Like, in 2011, you could get a job, I guess.
But we put it in one box, one server, Mongo, Solr, MuleSoft who uses ESB, the WordPress thingy, the Varnish cache, what have you, in one box. Operations folks took an hour and a half to two hours. We freaking put it up. And we served traffic for a day in high peak. And everybody is like, how the heck did you do it? I think we wrote brilliant code. But how the heck we did it, because we were in components and Mongo was a big piece of it. It was easy to flip the data over. It was easy to update it as manual jobs. Because not everything was flying well. But it just worked.
And high traffic, one box, the technology that was picked right just worked for us. And at this moment, in 2011, was kind of great. Let's see if we can be like MongoDB and develop the technology by ourselves. And heck, yeah. We did. And in 2013, I saw the first signature on the first contract, the technology that we developed called Falcon. Please buy it. It's great.
It was sold to Publisher. The phone started ringing off the hook. People said, can we look at it? Can we buy it? So we have commercial licenses. We have a group of people that does professional services. And we sell freaking software. So the company that was 97 years the world famous brand in media became almost, I hope, a world famous brand in technology. Partly because of what we learned from our friends at Mongo and what technologies like MongoDB gave us.
So if I would go and do I have any time for jokes? So because this was a decision making, if you're in business or in product-- and they wore three hats. It was in tech side, on business side, and product side. Because they went through maybe too many startups. So some CMS solutions, or whatever, they cost you like a Ferrari, but you need a bicycle. The infrastructure, this is my favorite thing. I don't know. I see a lot of companies that just, how is my infrastructure doing? It's great. Let's add something like this guy eating pizza. This is silly. But it's true. You see it. And I've seen it too. And you see it every day.
And business folks, saying like, we need to make more money. And actually, everybody is saying, we just bought this technology 10 years ago. It's great. It's like, he needs a new horse. But this is the decision making that you'll go through. But the way we build it, in the last four minutes, is-- and this is, basically, everything that's in our technology. So it's very simple. Every piece does one thing. But we think it does it right. At least it works for us. The HTML content editor from WordPress Writers love it. It does this job, does it great. We have this layer of databases. MongoDB, not too many. We don't shard. We don't need it. We have a lot of content.
We have another open-source solution for search, which is Solr. And we have these little stacks. They do one thing, do it right. And we protect them too. I don't believe that Mongo totally scales. I'm not going to expose it to the front end. I'm like, don't do it if you have very high traffic. We put Varnish. It helps. You want to sleep at night.
But with this architecture on one box, I can scale to 5 million pages an hour easy, like seriously, scary. So Mongo does this job very well. We did put a nice cushion for them, for MongoDB. Varnish works even better. Operation folks love it. And then we said that everything else is application. And when I talk to clients, and in the past, what Falcon gives you, what our implementation of MongoDB gives you is the ability to concentrate on your business, create the applications. Everything else is taken care of.
And that's what we call, of course, CMS world where you pick pieces of technology. They do one thing. They do it right. And nobody has a solution how to create your mobile or web app. Only you do. If you're on business side, you know where this market is taking you. You know where the money is. We don't want to do it. But we put the technology that's going to kick ass for sure. OK?
Can I ask a question?
Yes, of course.
How was the content rendered?
Will you repeat the question, please?
How was the content rendered? So this thing over here that I didn't write. So there's two things. We use Mongo, by the way, just to make it clear. We developed our own proprietary analytics engine that kicks armature ass. I'm serious about it. The company ran an API. So you have an API layer in front of your database assertion [INAUDIBLE]. It produces all the data you need. You need to extend it? API is going to be extended. The application request API? Template render data. On the template side, we use FreeMarker. Did I answer your question?
Did you use MuleSoft for the integration?
Yes we do. It's a huge overkill. MuleSoft is a great company. I wish they had great documentation. They developed it with a target of financial services. I use 5% of it. But it's the same as writing HTML editor that Wordpress has. It was the same. We started using MuleSoft when they were very start up. They work for us, so we continue the relationship. But again, we utilize only a little portion of their capabilities. [INAUDIBLE].
Basically, the way it works is we use MuleSoft for carrying data, just workload, from one system to another. In this case, we take data from MySQL that sits under the MySQL, the WordPress HTML editor. And we don't do anything else. We just use Mule or some little data feeds. We send it through Mule to Mongo.
Hi. Thanks for the presentation. Can you please elaborate on the slide number six. You mentioned there's five million searches on this particular architecture. Can you please put more light on the slide number six?
You were able to get five million pages per hour.
Yes. Five million pages in an hour. OK. So the application side, we're talking about five million pages on application side. Data is cached in Varnish. And data comes through the API from MongoDB. Does that answer your question?
Are you using caching technique?
Yes.
So you're using Solr or some other tool?
For caching we use Varnish.
Thank you.
I have a question. First of all, thank you for that. That's a great story and a journey. The way that you told it really makes it understandable. You had a problem. You decided to create a custom solution, whether you chose to do that up front or not. You analyzed each of the steps of the process to bring together. And you created sort of microservices. Is that right?
Yes.
OK. And it really became test worthy when you actually had the 404 incident. Something went down and you went, oh my god. We've got to get this back up. Is that right?
Yes.
So in two months, two to three months, you created this solution, shared nothing kind of object architecture services. And then you created a mobile app in two weeks.
In a couple weeks, yeah.
Somebody was bored and brain dead. So you said, just go create a mobile app.
Probably, a tech wanted to prove that we can do it, even if you don't give us time.
And you went from 5% usage to 15% usage.
To 50% now.
That's pretty amazing. I don't know anyone else-- I'm impressed. That sounds great. What a great story.
Thank you.
Invention in MongoDB. Hello.
Thank you.
They've just heard so many great stories, they go, OK. Just another great story. I go, wow. That's really great. And it's funny that when you had the biggest problem that's when you actually built the resilience, right? 404 came up. And then you said, now, we're going to make this bullet proof. Right?
Yes.
Right. Amazing story. Hooray. Thank you for sharing that. And now it's a money maker for Forbes.
It makes money, yes.
An old publishing house reinvents itself, becomes a software engine where it actually build it's solution set. That's an amazing story. Thank you. No other questions? I don't know why anyone-- that's great. Woo hoo. Let's hear it.
Thank you.
Steve, that's really great. I really appreciate it. So everyone, thanks for your time. We've got three more sessions coming up. Please don't forget to fill in your surveys. You get a drawing into the Xbox today. Coming next, we have Pearson Education. We're going to hear how Pearson, one of the largest education companies in the world, has put mobile first. They're going to share their story of how they decided to reinvent with MongoDB. After that we've got Medtronics. And last, today, we've got a great story about how a brand new company, a social messaging company in India, created, overnight, 15 million people using their solution platform. So thanks very much. See you soon.