Don't think 'lift and shift' when it comes to cloud migration; it needs to be 'lift and transform', says MongoDB CEO Dev Ittycheria

Profile picture for user slauchlan By Stuart Lauchlan March 10, 2021 Audio version
Summary:
Organizations that rushed into cloud migration may have been burned; there's a need to avoid several problems in order to reap the benefits of a modernized IT stack.

worker

I believe we will look back at 2020 as the year that put an exclamation point on the need for businesses to re-invent themselves using software and data.

So says Dev Ittycheria, CEO of MongoDB, but organizations need to realise that there’s more to this re-invention than simply declaring that it’s full speed ahead in a shift to the cloud. That attitude has led to many fingers being burned, he warns:

Moving to the cloud held out the promise of reduced complexity and improved productivity. What many early cloud adopters have learned the hard way is that moving to the cloud often exacerbates the poor state of their data infrastructure.

Based on past experiences, there are three pain points to watch out for, explains Ittycheria:

First, companies decided to lift and shift their existing on-prem relational workloads to the cloud, replicating their on-premise problems in the cloud. As a senior IT executive and one of the world’s largest asset management firms recently told us, he doesn’t know of a single one of his peers who didn’t come to regret the lift and shift strategy.

Second, given the known limitations of relational databases, cloud providers promoted a number of other single purpose databases to address more diverse requirements, which in turn create a larger number of data stores for customers to learn, manage and integrate. This dramatically increased complexity of their data architecture.

Third, cloud providers encourage customers to go all in with their proprietary offerings across the IT stack. The overwhelming number of proprietary point solutions not only slows developers down, but also deepens cloud vendor lock-in.

The end result of this is that while there is still a significant shift to the cloud underway, there’s also a recognition that ‘lift and shift’ is not the mindset to adopt when tackling this. Ittycheria advises:

I would more frame it as ‘lift and transform. That's where MongoDB comes in. People recognize the benefits of our flexible data model through the document model. They recognize the benefits of running and using multiple use cases because of the versatility of the document model. They also appreciate the scalability and performance of our distributed architecture and even more pronounced because Atlas basically automates all that.

What we're also seeing a new trend is the increasing importance of multi-cloud and customers are more and more interested in multi-cloud and being able to deliver a multi-cloud solution for either resiliency or other reasons. And so we see customers building new apps on Atlas [MongoDB’s cloud database-as-a-service offering] and re-platforming existing apps on Atlas. So we've seen trends across the board making Atlas a very attractive definition for app development.

New approach

MongoDB’s latest quarterly numbers make for encouraging reading when it comes to Atlas with revenue from it making up nearly half (49%) of the total $171.0 million for Q4, up 66% on the same period last year. (Full year revenue of $590.4 million was up 40% year-on-year, with a new loss of $266.9 million.)

This reflects changed awareness of the need for a new approach, suggests Ittycheria, leaning towards build, not buy:

As the world increasingly becomes digital first, there’s no off-the-shelf software that organizations can buy to differentiate themselves against their competition. To be blunt, you cannot buy a competitive advantage; you have to build it yourself. And to build your differentiated future using software and data, you have to maximize the productivity of your developers.

Managing data is a developer’s most challenging problem and the biggest drain on their productivity. Legacy platforms are not designed for how developers think and code, nor they designed for performance and scale. This problem only gets worse at the data intensity and performance requirements of modern applications increase. Consequently, developers spend an enormous amount of time working around the limitations of existing solutions versus spending time building better applications and user experiences that drive a competitive advantage.

At the same time, companies are aware they need to modernize their IT stacks and it’s this need that MongoDB attempts to address, although getting to the point of being an enterprise standard remains a long journey in most cases, admits Ittycheria:

While each customer story has its unique elements, we have observed that they tend to follow a similar path on the way to declaring MongoDB as standard. We usually land an account by identifying a specific pain point that cannot be addressed by existing technologies. In a Fortune 50 financial institution that is now a seven-figure customer, our early use cases leveraged the strength of the document model to efficiently capture a complex loan application with hundreds of entries. In the case of a global gaming leader developers first started using MongoDB for micro-services that leveraged the rapid scalability of our technology. After establishing a presence with the customer, we leveraged the success of the initial workloads to expand across divisional and geographic boundaries within the account.

Once MongoDB’s offerings do become widely deployed, the next step is to leverage internal proof points to convince more people and to pursue becoming a standard for future app development, he adds:

We emphasize the versatility of the document model to address a wide variety of use cases, meaningfully simplifying their data architecture. Second, we illustrate the performance, security and scalability of our platform ensuring that MongoDB can be trusted for the most demanding requirements. And third, apps built on MongoDB can run on-premise on any cloud or across different cloud providers, which offers real platform independence, benefits no other alternative can provide.

A CTO from a Fortune 100 business almost fell off his chair when we demonstrated how easily a customer can deploy a workload across two different cloud providers. He remarked, he was planning to have a 50 person team work on this and now one person can do this in a few hours. Platform independence is something the C-suite in particular cares a lot about.

This strategy is working, insists Ittycheria, pointing to a total of nearly 1000 customers spending over a $100,000 a year on the MongoDB platform and close to 100 customers spending an excess of $1 million a year. Among major customer wins, he cites:

  • Customer intelligence firm Acxiom, part of the Interpublic Group of Companies, which is using MongoDB Atlas, Data Lake, Realm and now Charts in its cloud architecture to reduce time-to-deploy its solution for new customers from two months to less than 20 minutes.
  • 1199 Funds, one of the largest labor management funds in the US, accelerated a massive cloud transformation initiative in response to COVID, migrating from SQL Server to MongoDB Atlas on Google Cloud in order to modernize its enterprise data warehouse and leverage MongoDB Realm to deliver a COVID-19 health screening app in just three weeks.
  • The UK Department for Work and Pensions chose MongoDB to underpin a secure platform and scale services across a distributed micro-services architecture to support the huge increase in demand for its Universal Credit welfare benefit during the pandemic.

But for now, even among the largest customers, MongoDB typically represents a small fraction of total database spend, but that leaves opportunity for growth, says Ittycheria:

Most of our large customers start as small customers. They could be 500 or 600 customers, and then they evolve into seven-figure customers. On the rare occasion, we might have a customer that quickly becomes a seven-figure customer and that’s typically because they have one use case or one workload that grows very, very fast. But in most situations it’s basically customers adding more workloads to the MongoDB platform and so obviously it takes some time.

MongoDB is not a product that you just buy and then start using. You have to actually build an application on top of it. So there is a certain rate and pace of app development, whether you're building new applications or re-platforming existing applications. But what we've seen is, once we get into an account, we find it reasonably easy to expand into adjacent opportunities and the adjacent opportunities tend to be bigger than the initial deal.

Don’t expect this model to change in the near future, he adds, even as the post-pandemic world opens up and organizations look to overhaul and build apps faster:

As we grow, as people get more and more comfortable using MongoDB, as we have more and more proof points now with nearly 25,000 customers - we have proof points almost across every potential use case, every industry, every geography - it gives customers a lot of confidence [and] becomes largely that much easier to win the next incremental workload. But it does take some time. It’s not like magically, you can re-platform 1000 apps to  MongoDB overnight.

My take

A pragmatic worldview. As diginomica always espouses, the best proof points are customer exemplars and MongoDB is adding those nicely. Setting realistic expectations around adoption rates and models is also a sound move. As the Vaccine Economy opens up, there will be fresh opportunity ahead among organizations looking to re-start their business thinking for a post-pandemic world, but this needs to be tempered with caution. MongoDB’s ‘land and expand’ approach is appropriate to the emerging climate.