WordPress Shortcode

Link

Webinar: The OpEx Business Plan for NoSQL

The era of Big Data is an era of opportunity. Companies are innovating and delivering massive value to customers, employees, and shareholders across a wide variety of industries. However, as with any
…

The era of Big Data is an era of opportunity. Companies are innovating and delivering massive value to customers, employees, and shareholders across a wide variety of industries. However, as with any great innovation, the path to success is not always a straight line, and companies struggle to plan and budget for success that doesn't always come on the first try. Traditional cost models push much of the planning and costs to the beginning of a project, limiting the kinds of efforts and risks organizations are willing to shoulder. In this webinar we compare alternative cost models and explain how NoSQL systems lower the costs and risks of delivering successful projects.

But opportunity involves risk, and we don’t always know the way forward. So, we make a plan and do our best to innovate.

But when we make a plan, we tend to assume that the path is straight and that success is clearly in front of us, just over the hill.

Most of the time at the end, however, we look back and see all the bends in the road and the turns we took to get to where we are.And how well we did is a lot more dependent on how well we turned, sped up, slowed down – how well we adapted to change.

Here are some popular examples. For each there were many turns in the road before arriving at the destination. WD-40 is named because it was the 40th attempt at the formula for the product. There were 39 turns in the road.Dyson is famous for trial and error. He proudly claims 5,161 failed designs before arriving at his bag-less vacuum cleaner.And Angry Birds, one of the most popular games of all time, is the 52 iteration of the game. (Don’t know if there were other angry animals that preceeded the birds, or other bird emotions, or something else).

Edison is famous for saying that he has not failed 10,000 times, he found 10,000 ways that will not work.Edison did not invent the light bulb. He found a practical material for the filament that made them low enough in cost that they could be popular. Ultimately Edison made a lot more money on the generation of electricity than the light bulb. (This is similar to how 10gen makes money – our light bulb – MongoDB -- is free, we sell subscriptions, tools, training, and consulting to help you make the most of our lightbulb)##### Optional StoryIn 1914 Thomas Edison&apos;s factory in West Orange, New Jersey, was virtually destroyed by fire. Although the damage exceeded $2 million, the buildings were insured for only $238,000 because they were made of concrete and were thought to be fireproof. Much of Edison&apos;s life work went up in smoke and flames that December night. At the height of the fire, Edison&apos;s 24-year-old son, Charles, searched frantically for his father. He finally found him, calmly watching the fire, his face glowing in the reflection, his white hair blowing in the wind. &quot;My heart ached for him,&quot; said Charles. &quot;He was 67 — no longer a young man — and everything was going up in flames. When he saw me, he shouted, &quot;Charles, where&apos;s your mother?&quot; When I told him I didn&apos;t know, he said, &apos;Find her. Bring her here. She will never see anything like this as long as she lives.&apos;&quot; The next morning, Edison looked at the ruins and said, &quot;There is great value in disaster. All our mistakes are burned up. Thank God we can start anew.&quot; Three weeks after the fire, Edison managed to deliver the first phonograph.

When you set out to innovate in your business, there are three key areas of investment for building an application.All three of these areas are positively impacted by MongoDB, as we shall see.

We used to develop software with a waterfall approach.Features would be described by the business, their requirements documented, and then the software team would work through analysis, design, build, and test of their code.At the end the business would be asked: is this what you asked for.The problem of course is that the time elapsed between describing the requirements and reviewing the application is typically measured in months or years. Think back to the curvy road and all the turns we need to take. Chances are those turns happen more quickly than the months or years it takes to follow this process. So what tends to happen at the acceptance step is that the business reports back to the development team that the requirements have changed, and so the process begins again.

Today software development tends to follow a more iterative approach. Teams may take one feature at a time, or a subset of a feature, and work through analysis, design, build and test in a time-boxed cycle that usually lasts 2 – 4 weeks.At the end of this cycle a new build of the application is produced. It isn’t fully functional, but it provides incremental capabilities and provides an opportunity for the business to ensure the project is on track. If there’s a turn in the road, the team can take the turn together, every few weeks if necessary.There are a number of methodologies that share these traits. Examples include agile and SCRUM.MongoDB helps teams be more agile because its flexible data model makes these turns easier to take. We will talk more about this later.

The second area of investment is the software license model.Traditionally software was licensed on a perpetual basis – you would buy it up front, then pay an annual maintenance fee, typically between 20% and 25%.That’s a very capital intensive model!Today many companies offer subscription models. You pay for what you use when you use it. This is beneficial because it shifts the costs out to a time that is closer to when the business experiences value rather than well in advance. The perpetual model shifts all the risk to the buyer.These newer products also tend to have lower total cost of ownership. We will touch more on this in a few minutes.

The third area of investment for innovation is hardware.We used to buy mainframes then large, monolithic servers. There were three big issues: 1) the incremental cost of additional processing power continues to increase, so as you get bigger it gets more and more expensive to increase capacity, 2) upgrades are very expensive, so you tend to over provision resources so upgrades don’t happen very often, which means you pay for more than you need, and 3) there is a limit to how much you can increase. At a certain point you can’t get any bigger.Now we want to buy cheap, commodity servers – each is not so powerful, but together many of them are more powerful than the largest single servers. More importantly the costs are predictable and linear. Finally, you can increase capacity when you need it, rather than buying up front.

So across these three areas of investment what we see is a consistent trend: moving from a pay up front to a pay as you go model.Or, moving from what we think of as a capex model to an opex model.

MongoDB positively impacts all three areas: development, software and hardware. We will discuss why.But first it is good to stop and think about why the alternatives are slowing you down and keeping your innovation from what it could be.

Here’s a relational model for an application. It has hundreds of table.If you are the new developer who just joined the team, congratulations!!Here’s a map of the database, now go figure out how to add your new feature (or fix a bug).Good luck!

This approach is like an imaginary parking garage. When you drive up, you hand the attendant your keys, and he disassembles your car into all its constituent parts. He then organizes all the parts into bins. It is incredibly space efficient. However, when you come back to pick up your car he has to assemble your car into its original form (hopefully he gets it right).This is how a relational database works.

And so the developer who is trying to build an application that has something to do with cars, he has to understand all those bins and how to put the car back together.Because in his application it is a car that he works with.And this process is so complex than a whole other layer of software evolved called Object Relational Mapping. The developer needs to understand this too. It is not uncommon for the XML config for the ORM to be thousands of lines long.This is pretty complex.

Now, let’s imagine there’s a new feature, or even just a small change. Let’s say now I need to track the age of the people in my application.I have to go to my schema, add some tables maybe, add some rows. And some of these operations may require my application to go offline for a while.Its no wonder that it is hard for me to deal with the curvy row. I keep having to take the car apart and put it back together!!

MongoDB is a new way.It makes development faster, it makes it easy to scale, and it has a lower TCO.

One of the main reasons is the data model.Documents are just easier.If my app tracks car collections, I don’t need to know dozens of tables – all the data for an individual and their collection is in one document. (Walk through this example)

So that complex set up that I used to deal with and needing to understand all three layers: the application, the ORM layer, and the relational database. . . . .

. . . . That just goes away. It turns out the way I describe the data in documents is just like the way I work with it in the application, so I only need to know one way to think about the data.

And with MongoDB . . .

I can instead focus on new features for my users.Let’s talk about a few examples from users of MongoDB.

Illustrative. Meant to show how the economics of MongoDB and Oracle stack up against each otherCosts Vary by Use Case. Topologies and costs vary from use case to use case. Cost disparities could be smaller or greater depending on many factors, like number and complexity of appsStarting Point. Use framework as a starting point for conducting analysis for yourself. Give you some tools/ammunition if you want to go back to your organization.Technology-Agnostic. Framework can be used for MongoDB, or any other database

152 partners, growing ~20% monthlyCertification: Cloud, BI/ETL, Analytics, Auditing/SecurityOther partners in BI (e.g., Pentaho, Jaspersoft) with many more comingIBM: Standardizing on BSON, MongoDB query language, and MongoDB wire protocol; integration with Guardium security product; integration with WebSphereRed Hat: Collaborating on a secure architecture for MongoDBInformatica: Integration with ETLAmazon: Easily deploy MongoDB on Amazon EC2; we have worked together to develop reference architectures and to use MongoDB with Amazon’s latest technologies, such as SSD instances and Provisioned IOPS (PIOPS)Rackspace: Rackspace offers a purpose-build database-as-a-service offering for MongoDB (through acquisition of ObjectRocket)Microsoft Azure: We have collaborated on tools to make it easy to deploy MongoDB on Microsoft AzureIntel, EMC, NetApp: We’re certified to work with their hardware. More to come.