Cisco & MongoDB: E-commerce Transformation
Migrating a Major Revenue Generation Platform to Improve Customer Experience
The recent Launchpad event in San Francisco was the venue for our announcement of
MongoDB 3.4
. This new release offers a major evolution in capabilities for users seeking to address the emerging opportunities presented by digital transformation. Even before MongoDB 3.4, many of the world’s most progressive and innovative companies have been using MongoDB as a cornerstone of their transformation initiatives.
To illustrate this point, at the launch event Dharmesh Panchmatia, Director of e-commerce at Cisco Systems, discussed how his company is using MongoDB to modernize its e-commerce platform. This is a mission-critical application in every sense of the word – it handles the online configuration, pricing and purchasing of all Cisco products and services globally. Through the transformation, Cisco is aiming to do two things:
Replatform for the cloud.
Now the company’s e-commerce solution can tap into the business agility enabled by cloud computing.
Improve customer experience.
8x faster response times, while delivering continuous availability to ensure users are being served 24x7.
You can get all of the detail by
watching a recording of Dharmesh discussing the Cisco e-commerce transformation project
in a fireside chat with Seong Park, VP of Solutions Architecture at MongoDB. I had the chance to catch up with Dharmesh after his chat to get a summary of the lessons learned from using MongoDB to transform a mission-critical application.
Can you start by telling us about your role at Cisco?
I manage a team of 45 Cisco engineers and architects, in addition to the external resources we use for development and testing. We are distributed across multiple engineering sites in the US and India.
What is your team responsible for?
We are responsible for the e-commerce platform – a suite of 35 different services that power product configuration, pricing, quoting, export compliance, credit checks, and order booking across all Cisco product lines. It’s managing both B2B and B2C transactions, serving 170,000 unique users across Cisco's sales team, Cisco partner, and direct customer users across the globe. We are handling an average of 3.6 million hits per day, rising to 6 million at quarter end, and we’re experiencing continual growth. The average financial value of each transaction is extremely high, so it is truly critical to our business.
What challenges were you seeking to address in the transformation project?
We’re driven by improving customer experience and business agility. By modernizing the underlying database layer, we wanted to make the e-commerce platform cloud-ready. What does that look like for the business?:
Ensuring resilience of the core platform by providing fault tolerance against any outage.
Enabling continuous delivery of new code deployments and upgrades with zero downtime.
Improving response times to users by a minimum of 5x. Our previous SLAs required 98% of all page loads be completed in less than 3 seconds, and 99% within 5 seconds. In order to provide a seamless user experience, we needed to make page rendering on the client a sub-second operation
What led you to MongoDB?
We looked across the entire non-relational database landscape. MongoDB came out as the top candidate for three reasons:
Strong consistency with partition tolerance.
As a distributed transactional platform, we can’t afford the risk of acting on stale data. Eventual consistency wasn’t an option. MongoDB was ahead of all other databases in providing the consistency guarantees demanded by the business.
Secondary Indexes.
We don’t have control over the types of questions business users want to ask of the data, so we needed the ability to efficiently query against any attribute. MongoDB’s secondary indexes gave us this flexibility in ways other databases simply couldn’t match.
Ease of development.
Time to market is critical, so we needed a database that was easy to develop against. MongoDB’s flexible document model allows us to store objects in the same structure as our applications, without requiring transformations or mappings between the code and persistence layers. This makes it much simpler for our engineers to interact with the database. Our UI is written in AngularJS and JavaScript, while the application layer is developed in Java. MongoDB’s JSON documents fit perfectly into this environment.
How did you prove MongoDB as the right solution for you?
We needed to ensure MongoDB delivered both the scalability and availability demanded by the e-commerce platform. So we embarked on a rigorous PoC (Proof of Concept) to test MongoDB’s behavior under a variety of conditions:
We started by validating MongoDB’s performance against required peak load. We then increased that load by 5x. MongoDB scaled seamlessly, delivering the same low latency and high throughput. This gave us the headroom to accommodate projected business growth.
We then went on to explore MongoDB’s availability guarantees by inducing a range of failure conditions. We randomly killed primary replica set members, then measured recovery times. We were extremely impressed by how quickly MongoDB self-healed – typically in 2 seconds – without administrators having to step in to restore operations.
Finally, we tested resilience to outages in the underlying network and storage infrastructure. MongoDB’s distributed architecture was able to withstand these failures without interruption to the application or its users.
With the testing complete, we had the confidence we needed to move forward with MongoDB.
At what stage are you now with the project?
We started development in February 2015, and went live in December of that year. We have focused first on the most mission-critical part of the app – capturing orders from partners and customers. Any issue in that part of the application would have materially affected Cisco’s financial results. We had to ensure there was no system impact as we migrated the database layer to MongoDB, so testing has been exhaustive.
It’s not just the database we’ve changed. As part of the migration, we have delivered 26 additional business capabilities that involved the development of 600,000 lines of new application-side code and 120,000 lines of rewritten code.
Our e-commerce platform is such a critical application, and naturally the business is averse to introducing any risk. As a result, we went through a lot of regression testing, and ran database operations in parallel for a while where we wrote transactions to both the existing database and to MongoDB. While this approach involved more work for my team, it was essential to giving the business owners the confidence they needed to move forward with the project.
With this part of the project successfully delivered, we are now actively moving the remaining parts of the application across to MongoDB, and expect to be done in around 12 months. We are also spending more time with other application owners in Cisco who have learned about our achievements with MongoDB, and are now seeking to replicate it in their own domains.
What does your MongoDB deployment look like?
Currently we are running MongoDB Enterprise Advanced on a 5-node replica set across three data centers located across the US. This architecture gives us the performance, scale, and fault tolerance demanded by the business. We use MongoDB Ops Manager extensively to monitor node health and query performance – generating alerts so that my team can proactively address any issues before impact to our users.
What have the results of the migration to MongoDB been?
The results have been excellent – we’ve encountered no issues since launch. We’ve just closed our first full quarter on the new platform, with perfect performance. The maximum query latency in MongoDB is close to 10x less than the latency we specified at the start of the project. Pages render in 600 – 700ms at the 99th percentile, compared to 5 seconds in the old system.
We've also completed a MongoDB upgrade since launch. In my experience with other databases, upgrading can be an arduous operation. Plus, for such a critical revenue-generating application, we were not able to schedule a downtime window. Using Ops Manager, we were able to upgrade from MongoDB 3.0 to 3.2 in less than 5 minutes, and without any service interruption.
You’ve taken a look at MongoDB 3.4. What is most interesting to you in the new release?
There are a couple of new features that really stand out:
Faceted navigation
. This allows us to deliver an enriched search experience to our users while streamlining our environment.
MongoDB Compass
. This is an essential tool for my DBAs. It enables them to fully control the database schema – from enforcing data governance to optimizing query performance and user experience.
What guidance would you give to other teams planning transformation initiatives with MongoDB?
There are four best practices I’d recommend:
Make sure you identify the key business metrics that will define success, and get buy-in from stakeholders.
Work with the MongoDB solution architecture and
consulting teams
. They provide unparalleled expertise in key areas such as schema design, system sizing, and performance best practices. You will be accelerating your path to success by leveraging these teams.
Invest in regression testing and in backwards compatibility.
Don’t build your project in isolation. Instead, fully think through impacts to other applications and develop APIs where necessary to reduce tight coupling between systems.
Dharmesh, thank you for sharing your experiences with the MongoDB community.
Want to get a head-start on your digital transformation initiative?
Download our Relational Database to MongoDB Migration Guide
About the Author - Mat Keep
Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.
November 30, 2016
