Five Questions For… Seong Park at MongoDB

MongoDB came onto the scene alongside a number of data management technologies, all of which emerged on the basis of: “You don’t need to use a relational database for that.” Back in the day, SQL-based approaches became the only game in town first due to the way they handled storage challenges, and then a bunch of open source developers came along and wrecked everything. So we are told.

Having firmly established itself in the market and proved that it can deliver scale (Fortnite is a flagship customer), the company is nonetheless needing to move with the times. Having spoken to Seong Park, VP of Product Marketing & Developer Advocacy, several times over the past 6 weeks, I thought it was worth capturing the essence of our conversations.

 

Q1: How do you engage with developers that is the same, or different to data-oriented engineers? Traditionally these have been two separate groups to be treated separately, is this how you see things?

MongoDB began as the solution to a problem that was increasingly slowing down both developers and engineers: the old relational database simply wasn’t cutting the mustard anymore. And that’s hardly surprising, since the design is more than 40 years old.

MongoDB’s entire approach is about driving developer productivity, and we take an object-focused approach to databases. You don’t think of data stored across tables, you think of storing info that’s associated, and you keep it together. That’s how our database works.

We want to make sure that developers can build applications. That’s why we focus on offering uncompromising user experiences. Our solution should be as easy, seamless, simple, effective and productive as possible. We are all about enabling developers to spend time on the things they care about: developing, coding and working with data in a fast, natural way.

When it comes to DevOps, a core tenet of the model is to create multi-disciplinary teams that can collectively work in small squads, to develop and iterate quickly on apps and microservices. Increasingly, data engineers are a part of that team, along with developers, operations staff, security, product managers, and business owners.

We have built capabilities and tools to address all of those groups. For data engineers, we have in-database features such as the aggregation pipeline that can transform data before processing. We also have connectors that integrate MongoDB with other parts of the data estate – for example, from BI to advanced analytics and machine learning.

 

Q2: Database structures such as MongoDB are an enabler of DevOps practices; at the same time, data governance can be a hindrance to speed and agility. How do you ensure you help speed things up, and not slow them down?

Unlike other non-relational databases, MongoDB gives you a completely tunable schema – the skeleton representing the structure of the entire database. The benefit here is that the development phase is supported by a flexible and dynamic data model, and when the app goes into production, you can enforce schema governance to lock things down.

The governance itself is also completely tunable, so you can set up your database to support your needs, rather than being constrained by structure. This is an important differentiator for MongoDB.

Another major factor which reduces speed and agility is scale. Over the last two to three years, we have been building mature tooling that enterprises and operators alike will care about, because they make it easy to manage and operate MongoDB, and because they make it easy to apply upgrades, patches and security fixes, even when you’re talking about hundreds of thousands of clusters.

One of the key reasons why we have seen such acceleration in the adoption of MongoDB, not only in the enterprise but also by startups and smaller businesses, is that we make it so easy to get started with MongoDB. We want to make it easy to get to market very quickly, while we’re also focusing on driving down cost and boosting productivity. Our approach is to remove as much friction in the system as possible, and that’s why we align so well with DevOps practices.

In terms of legacy modernization, we are running a major initiative enabling customers to apply the latest innovations in development methodologies, architectural patterns, and technologies to refresh their portfolio of legacy applications. This is much more than just “lift and shift”. Moving existing apps and databases to faster hardware, or on to the cloud might get you slightly higher performance and marginally reduced cost, but you will fail to realize the transformational business agility, scale, or deployment freedom that true legacy modernization brings.

In our experience, by modernizing with MongoDB organizations can build new business functionality 3-5x faster, scale to millions of users wherever they are on the planet, and cut costs by 70 percent and more, all by unshackling from legacy systems.

 

Q3: Traditionally you’re either a developer or a database person … does this do away with database engineers? Do we need database engineers or can developers do everything?

Developers are now the kingmakers; they are the hardest group of talent to retain. The biggest challenge most enterprises see is about finding and keeping developer talent.

If you are looking for the best experience in working with data, MongoDB is the answer in our opinion! It is not just about the persistence and the database …MongoDB Stitch is a serverless platform, drives integration with third-party cloud services, and enables event-based programming through Stitch triggers.

Ultimately, it comes down to a data platform that any number of roles can use, in their “swim lanes”. With the advent of cloud, it’s so easy for customers not to have to worry about things they did before, since they consume a pay-as-you-go service. Maybe you don’t need a DBA for a project any more: it’s important to allow our users to consume MongoDB in the easiest way possible.

But the bottom line is that we’re not doing away with database engineers, but shifting their role to focus on making a higher-value impact. For engineers we have capabilities and features like the aggregation pipeline, allowing us to transform data before processing.

 

Q4: IoT-related question … in retail, you want to put AI into the supermarket environment, it could be video surveillance or inventory management. It’s not about distributing across crowd but into the Edge and “fog” computing…

At our recent MongoDB Europe event in London, we announced the general availability of MongoDB Mobile as well as the beta for Stitch Mobile Sync. Since we already have a lot of customers on the network edge (you’ll find MongoDB on oil rigs, across the IoT, used by airlines, and for the management of fleets of cars and trucks), a lot of these elements are already there.

The advantage is how easy we make it to work with that edge data. We’re thinking about the experience we provide in terms of working with data – and giving people access to what they care about – tooling, integration, and to look at what MongoDB can provide natively on a data platform.

 

Q5: I’m interested to know what proportion of your customer base, and/or data/transaction base, are ‘cloud native’ versus more traditional enterprises. Indeed, is this how you segment your customers, and how do you engage with different groups that you do target?

We’d argue that every business should become cloud native – and many traditional enterprises are on that journey.

Around 70 percent of all MongoDB deployments are on a private or public cloud platform, and from a product portfolio perspective, we work to cover the complete market – from startup programs to self-service cloud services, to corporate and enterprise sales teams. As a result, we can meet customers wherever they are, and whatever their size.

 

My take: better ways exist, but how to preach to the non-converted?

Much that we see around us in technology is shaped as a result of the constraints of its time. Relational databases enabled a step up from the monolithic data structures of the 1970s (though of course, some of the latter are still running, quite successfully), in no small part by enabling more flexible data structures to exist. MongoDB took the same idea one step further, doing away with the schema completely.

Is the MongoDB model the right answer for everything? No, and that would never be the point – nor are relational models, nor any other data management structures (including the newer capabilities in MongoDB’s stable). Given that data management vendors will continue to innovate, more important is choosing the right tool for the job, or indeed, being able to move from one model to another if need be.

This is more about mindset, therefore. Traditional views of IT have been to use the same technologies and techniques, because they always worked before. Not only does this risk trying to put square pegs in round holes, but also it can mean missed opportunities if the definition of what is possible is constrained by what is understood.

I would love to think none of this needs to be said, but in my experience large organisations still look backward more than they look forward, to their loss. We often talk about skills in data science, the shortage of developers and so on, but perhaps the greater gap is in senior executives that get the need for an engineering-first mindset. If we are all software companies now, we need to start acting accordingly.

from Gigaom https://gigaom.com/2018/12/12/five-questions-for-seong-park-at-mongodb/