Voices in DevOps – Episode 2: A Conversation With Seong Park of MongoDB

Guest

Seong Park is the Vice President Strategy at MongoDB. MongoDB is the leading modern, general purpose database platform, designed to unleash the power of software and data for developers and the applications they build. Headquartered in New York, MongoDB has more than 4,900 customers in over 90 countries, including more than half of the global Fortune 100. The MongoDB database platform has been downloaded over 30 million times and there have been more than 700,000 MongoDB University registrations.

Transcript

Jon Collins: Hello and welcome to this episode of the Voices in DevOps podcast where I'm here to speak to Seong Park, who is Vice President of Product Marketing and Developer Advocacy for MongoDB. As everyone knows MongoDB is an information company, it's grown to where it is today based on offering that alternative to old traditional style databases. But equally, it's the kind of tool that people are using in organizations that are adopting these agile best practices like DevOps and so on and so forth.

So I was very interested to get your view in terms of how your offering aligns with what people are trying to do with DevOps, and what challenges you seeing from your observer standpoint, -- because you're not directly in that toolchain in the pipeline, but you're part of the platform. So maybe if we start from the point of view of how did you get to here, how did you get to end up being VP of PM and DA at MDB?

Seong Park: Sure. Hey Jon, it's great to speak to you again and I think to answer that question it was obviously just a confluence of events, but ultimately sheer luck in terms of landing in this role. What I mean by that is if you look at my background, obviously I've been with MongoDB now for just coming up on four years. This is actually my second role here at the company, where prior to working with the customers from the standpoint of obviously strategy and product marketing and interfacing and engaging with our developer community, I ran basically what we call our ‘solutions architecture’ team which is a technical team aligned to working with our customers in terms of ultimately driving success, driving outcomes.

So I think it's something that as you pointed out.., I've had the fortune and the opportunity to see a lot of customers both in the enterprise space as well as more in kind of the smaller startup space, and everything in between, in terms of what journey they're undertaking, what problems they're solving and ultimately I think what type of value that they are trying to deliver in terms of their customers.

We have a list of questions which I'm now going to completely ignore, and ask you a question that you haven't had yet, just to mess with your head. But I'm interested to know in terms of the organizations that you're working with, -- if we were to do a pie chart of them, I mean are they all DevOps shops or how would you draw that pie chart?

Yeah I think everyone is definitely moving towards a model and leveraging methodologies that drive very specific outcomes. What I mean by that Jon, is you'll see that even in the enterprise segment, there are a lot of customers and companies that are all about delivering ultimately value, and that value I think is derived in two ways. Because you want to be able to acquire companies in today's day and age. You want to be able to deliver value to customers ultimately in terms of that whole disruptor/be disrupted model.

And I think the key drivers for any company ultimately don't change.
Because I think what I've observed is that companies no matter how big or small they are are all about trying to drive and build competitive advantage as well as getting to market quickly, time to market, time to value. I mean all those drivers I don't think have changed over the course of the last few decades.

But to answer your question directly, I think MongoDB has a unique opportunity because as a data platform, we can address any company's data requirements no matter how big or small they are. So we have a really good cross-section of startup companies, SMB as well as large enterprises. And I think as far as how they're trying to ultimately employ or embrace DevOps in the sense of driving that customer value, it's something that I think has become very

So if I were to maybe draw a pie chart, I would say that there are obviously in the smaller company size segment, I want to say almost the majority of them are leveraging some type of DevOps practice or DevOps methodology. And then you'll see in a lot of these larger enterprises (and I think you've written about this too), it comes down to getting small wins and not necessarily doing a wholesale kind of change in organization or mindset or leveraging or embracing DevOps, but it comes down to I think smaller teams or even lines of business that are embracing DevOps in a way that again drives those outcomes.

This brings us to an interesting question which again you haven't seen yet, is there's actually two pie charts. There's the DevOps Pie Chart, so thank you. But then there's also the ‘Not Managing Data in a Traditional Way’ pie chart. So not leveraging the data platform in the traditional way, not using a central database etc... and that both areas that you might see as going from those initiatives to then growing it out and then deciding ‘well why would he use anything other than the new way of doing things?’ So is there an alignment between (I hate this term) ‘DevOps maturity’ and use of tools, no sequel type tools like MongoDB?

Yeah absolutely, because if you think about... development organizations or teams and you think about operations teams. I think historically they've always been diametrically opposed in terms of their goals because if you think about development teams, it's all about build. It's all about releasing new features quickly ultimately to drive that competitive advantage, and also to respond rapidly to changes in the market, changes in the business etc...

And then if you think about Ops teams, I think they've always been chartered specifically around stability. They want to make sure their environments and their production systems are secure and that they're reliable. So in a way you want to reduce the number of changes that are introduced in any type of production environment in order to not ultimately affect uptime and reliability and stability. So I think historically that's always been kind of a natural tension.

And you know for us, if you think about then data becoming much more prominent and you've heard obviously the three Vs of data, right? There's the volume, the variety, the velocity in which data is being generated today. And I think data really comes down to what company can actually unlock the inherent value in data in order to drive, again, those outcomes that lead to more customer value but ultimately to drive that competitive advantage. So I think that's where MongoDB fits in. Because if you think about the company: we were born out of wanting to drive developer productivity, which I think the key benefit there is driving to company or business outcomes. You want to get to market faster time to value faster, be agile in that sense, drive more innovation. And I think that's been the natural hook for us,. if I can use that word for companies that are looking to again move quickly and move fast.

So I think that's been the natural integration point for us where customers then are now looking to modernize their application stacks and ultimately not use a tabular database that's been around for... I want to say, the better part of four decades, that ultimately inhibit the ability for a lot of customers to move quickly and to iterate on their applications and ultimately drive those outcomes as a business.

Now it's interesting, I noticed by the way that the whole world should know that you used to work for BMC more on the ISA side. And you've piqued my interest, and I'm going to go off base a little bit around what you're saying around this balance between Dev wants change and Ops wants stability.

You talked about the disruptors versus the ‘be disrupted’ companies and that would map onto the smaller and the larger organizations. Just thinking about the larger organizations, the 'be disrupteds'. Are Ops people kind of bought into DevOps from what you're saying? And if the answer is ‘not as fully as they could be,’ are there valid reasons for not wanting to just kind of go “hey we'll just change all the time, we'll be fine?”

I think it's working backwards from this, Jon, I mean but we do find again with our larger enterprise customers that absolutely you have Ops teams that are very much aligned to wanting to drive more releases to iterate on applications and to get to a point where they can release changes to code much faster. And I think as far as balancing that with what I said earlier around stability and reliability and security, that that's never going to change or go away.

So I think it's really finding that that nice balance point, if you will. Because over the past maybe two decades, you've seen the pendulum swing in a few ways, -- where it went from kind of monolithic, slow waterfall, slow development cycles where you release changes to applications maybe once a quarter, sometimes even once a year, and then now that's kind of swung the other way in the last decade or so, where you have kind of this mentality and mindset around driving hundreds, sometimes thousands of changes in a day if not a week or a month.

And I think it's finding that right kind of equilibrium to be able to drive and be fast in terms of driving innovation, to drive changes in the business ultimately supported by applications, but also never lose sight of making sure that your production environments are stable and reliable and secure, again because I think for a lot of companies, the face to their end customer is ultimately through an application or a piece of software. And I think that's the thing where you find enterprises now finally embracing that and getting with it.

But what what I don't see necessarily are enterprises embracing ‘DevOps methodologies’ wholesale. And I think you'll find lines of business or sub teams inside of large enterprises that operate that way and embrace that.

It's interesting. And there were lots of thoughts popping into my head, one of which is... and feel free not to answer this, but whether the the ops people that you're speaking to now from from MongoDB's perspective are the same ones that you used to speak to when you were working working with BMC, and another thought I had... I mean you're absolutely right from an Ops perspective. I used to work in IT as well and from an Ops perspective, no Ops person gets up in the morning thinking ‘I want to make everything stop happening.’

The whole job is to is to help people do what they're trying to do et cetera.. But there is this kind of golden rule in Ops which is ‘Don't break my stuff.’ You can do what you like as long as whatever's running at the moment doesn't break, you carry on. But if you're going to start breaking my stuff, then I'm not going to be happy with that.

You know it's a great point you make because I think my time at BMC (I actually landed there through an acquisition of a company called Bladelogic which was the data center automation company). So if you think about even leveraging and embracing DevOps, one of the key tenets is ultimately driving towards automation, driving towards standardization of ultimately how you make your code changes but also how you make changes into your production environment. So absolutely, I mean even 10-15 years ago, enterprises were concerned about driving automation to remove the ‘fat finger’ user-induced error so that it ultimately removes the risk, doesn't take down a production system.

But more importantly: have the ability to roll back quickly so that it doesn't impact uptime and SLAs. So I think we're seeing a lot of that in terms of enterprises that again want to have the maturity as you said before by standardizing, but ultimately leveraging automation to do that. And I think tying back to where MongoDB fits into that bigger picture, we want to ultimately make data very simple to work with and something that again either developers or Ops people don't have to necessarily think about in terms of how they get access to it, how they interact with data, how they build their apps, but more importantly than how they operate and manage that data itself. Because we want to make that experience as seamless and as easy as possible so that they can focus on the higher value, the higher order important things. like building those apps and ultimately introducing that type of value back to the customer, being able to get to market faster, increase the value etc.

So I think for us it comes down to making data just super easy to work with. I think that's something that we embrace, that we also want to help empower our customers. Again, no matter how large or small they are, to be able to work with data in a way that's natural and intuitive and ultimately supports their ability to embrace DevOps methodologies and to embrace things that allow them to move faster, but ensure some degree of governance and standardization and security and reliability and all the things that are going to be important for customers.

So I'm going to both go more technical at the same time as showing my absolute technical ignorance. So bear with me on this. Essentially here's a thought process: DevOps is great, everyone likes it, everyone wants to kind of just be able to develop stuff and break down the wall of confusion, so you're no longer throwing stuff over the wall, you’re just kind of throwing it at target systems and it just runs and you've got your next iteration of your mobile app or your IoT app, or website or whatever it is, and it just runs and everything's fantastic.

When that goes wrong, is that there's just too much complexity in that process and as soon as you start bringing in test management, different infrastructure configurations et cetera everything slows down. To which people say “well we've got an answer to that” and it'll be infrastructure as code or it'll be test management as code, so you can actually define your test environment as code and actually put that into Jenkins at the same time in parallel. So you've gotten everything that you need all in one place and you can regenerate. That's the way that all of that stuff's gone.

Now, here's where I show my ignorance, on the data side of things my understanding is MongoDB doesn't need you to define schemas in advance of actually storing data because everything's done as... (you've got the technical terms for this), but you essentially say “Here's the shape of the data I want to store. Just store it for me and then I'll go to work out the best what best way of managing that.”

So does that kind of ‘data structure as code’ issue go away, or am I completely off the plot? Is it just a case of you don't need to worry about that sort of thing [because] we're not going to slow down DevOps anyway. Or is this stuff we do need to do?

Yeah I think it's more of the latter. I mean you absolutely need to worry about it because I think like anything else, applying some type of best practice, applying some type of governance is key. I think the one thing that this label around no sequel this new generation of databases, modern databases that has labeled us in some way starting from just over a decade ago, Jon, is this schema-free, dynamic schema, kind of label.

What I think a lot of people don't realize is that we've introduced controls and functionality and capability etymology that allows you to have actual schema. So we support JSON schema first and foremost. We have things like document validation and the things that allow you to have that control over the schema, I think is something that we provide for users, number one. I think number two, you hit on a great point: it's about how do you find and strike that balance between moving quickly to drive the fast iteration especially early on.

I was recently talking to a customer that was actually kind of walking me through their whole journey using MongoDB, and it's actually a pretty big customer of ours. They've spoken publicly about us and mentioned how they use MongoDB,-- a company called Coinbase, and they made the bet on MongoDB several years ago. To your point, the document model allows them to move very quickly to be able to build things in a way that allows them to experiment also and iterate, but more importantly one of the critical things that happened was the document model and ultimately using MongoDB allowed Coinbase to even do, I wanna say security integrations, with a third party security application or technology, -- I should say, at a time where this whole crypto mania thing was coming to a head. And obviously security was paramount to Coinbase in terms of... again I think we're seeing a lot more hackers  going after their systems.

If it wasn't initially, it would very quickly become...

Exactly, and it allowed them to ultimately strike that balance of early on being able to get an idea into a working MVP and then ultimately getting an app that was working but then also as they matured with their application, the document model. Ultimately MongoDB allowed them to have these integrations with other technologies done very easily.

In their own estimation, it took them days and weeks versus what they were anticipating could have been months of integrate the security app right into their stack. So I think it's striking that balance and I think this is where you see this kind of confidence that customers are ultimately,I like to say ‘betting the farm’ on MongoDB, because it allows them to again move quickly when they need to, but then we also provide all the controls and the governance and ultimately the capabilities that allow them to have that balance with stability, reliability and security.

Another big customer of yours is Fortnite, which is boldly going where a lot of organizations would never even dream about in terms of having to scale. This is a leading question, so I'll make it a point. You've been working very closely with them in order to solve some of the issues that they've come up against in terms of managing massively growing at the same time as people accessing real time data sources.

Yes, we absolutely have. And I think it was again always born out of the fact that... (I've joked with you even about just the cool dad status with with my two older sons who are apparently experts in their own claims). But for Epic Games, which is the company behind Fortnite, if they hadn't picked something like MongoDB, it would have not allowed them to iterate very quickly. It would have prevented them from being able to operate at scale because they are probably the most popular and one of the largest online gaming communities, -- I want to say hundreds of millions of players or gamers.

And I think to the point around DevOps and what we're observing here is that Epic Games embraces a micro services architecture, so that design pattern is something that allows them to work very quickly, iterate very quickly and I think MongoDB is perfectly positioned to allow them to do that in a way that speeds up their development cycles and speeds up their time to market to release because if you are a gamer, you know that they're constantly releasing new updates, new changes to the game itself. And I think it's something that you know MongoDB is perfectly suited for.

But then to my other point, I've been working quite a bit with their SRE team, their Site Reliability Engineering team, and what do they care about? They want to make sure that they can introduce changes into their production environment very quickly, make those changes to the game, but more importantly not affect downtime, not affect anything in terms of taking the game offline due to some change that they introduce; or even more importantly, constructing and making sure that topology is in a way that allows them to scale to handle spikes and to handle the large volume of gamers at any given point.

So I think it's something that we see and maybe to give you a different angle, so we're also working with... (I was recently talking to a company here based in New York that's actually kind of an upstart I want to see in the real estate market). And for them it's actually around MongoDB being something that allows them to move very quickly to adapt to the needs of the business and ultimately move and encroach on I think some of the other (I want to say companies that have been around for a while), so they're looking to drive that competitive advantage in that market. And it's something that they are embracing and leveraging MongoDB to drive a wholesale. They're only DevOps but it was interesting.

I was actually talking to their head of DevOps and he said it's quite interesting the point you made because he talked about hey we were able to move very quickly and to build things in a way that got us to market very fast, but what we didn't really think about was some of the design choices that we made that ultimately prevent us from scaling and prevent us from maybe growing beyond where they are today. MongoDB allows them to iterate very quickly so that they can deploy those changes, account for those changes in the application and ultimately in their production environment. And it's something that... I think the cool quote from him was, “Specialization is the hallmark of any civilization.” And he was actually talking about at some point and maybe the not too distant future: is his DevOps team going away?

The responsibilities around security around their infrastructure, around security from a networking standpoint, the things that they have to do to drive productivity of their developer teams ultimately being a shared burden, which I think speaks very strongly to something you wrote about Jon, which is embracing devops and doing devops at scale also requires kind of a wholesale organizational and ultimately a mindset change.

And I think they have a shared goal within the company that they need to be able to move very quickly, respond to changes and ultimately drive that kind of high velocity and high pace of innovation. And it's something that they're leveraging and embracing MongoDB for, because it allows them to move very quickly and not have to worry about their data because that data will grow with them and will be easily managed by ultimately what we afford them with things like MongoDB Compass, which allows customers to basically spin up and fully manage a MongoDB cluster in the cloud for them on any cloud platform, and kind of take away the headache and take away the extra cognitive load of having to worry about what that production environment can ultimately look like.

So it doesn't just work or it doesn't have to just work as you're saying, but it does enable people to change this MongoDB thing. I'm going to come back to something that you're saying about SRE. I've never been a site reliability engineer. It's a long time since they allowed me to do anything like that, but my take on it (and I've seen this written in various places) is it's kind of the master class of DevOps. But I'm also thinking it's kind of apps that's driven from the operational perspective.

So it's when the architects and the security people and the operations people say “yeah sure we want to be able to deliver these scalable applications that change quickly. So here's all the things that we need to make sure that we're in place first” as opposed to DevOps being ‘hey we've got to build things more and more quickly and all we need to do is communicate better.’ So it's kind of taking it to the next level.

Yeah. And I think the way I've always thought about it and understood it Jon, was it takes I think some of the core tenets and some of the great things about how developers have been doing software engineering, especially over the last two decades I want to say, and then applying them to something you said: infrastructure and operations, infrastructure as code. How do we automate? How do we make this so that we can apply the ability to move very quickly and to iterate on changes very quickly and respond to changes.

And I think the way you do that is through automation and through standardization. But I think it's kind of the mindset shift. Operations folks I think historically especially when I was at BMC were always about ‘hey let's keep the lights on, let's make sure everything kind of stays running and everything is stable and we don't have to worry about it.’ They were actually very prone to not introducing any type of change, versus now I think with SREs, they're probably in one of the hardest jobs, because they need to be able to introduce massive amounts of change into production environments, but really ensure the uptime and ensure that they are up and running safely and reliably.

And I think it's that mindset shift around leveraging some of those core tenets of how companies and users are embracing that speed in which they can deploy changes and iterate on apps and applying that to ultimately the OPs realm.

Maybe all DevOps shops ultimately become SRE shops...

It's definitely a role right that I think we're seeing a lot of. And it's something that I think companies small and large are definitely embracing because I think it's the one common thread around making sure that those production environments and their apps are stable and running and secure. And it's I think that SRE's charter in order to maintain that while at the same time introducing a lot of that.

Absolutely. Change is good, but we all hate it.

And it's constant. Right?

I used to work in a methodology group and I was great at telling other people how things should be and I hated anyone telling me how it should be. So the big irony. From the point of view of the organizations you work with, I know it's a bit of a cliche, but where would you say that the most common challenges are that you still come up against in making DevOps a success?

I think you see the most challenges in larger enterprise companies because it speaks to that maturity model especially around wholesale organizational and mindset changes that need to happen. Anytime you want to implement some type of process change as well, I think it's it's easier to go at it as ‘hey where's the low hanging fruit?’ Ultimately how do we drive towards specific outcomes that deliver some type of value?

If you have that mindset going in, then I think it becomes much easier versus with startups and smaller companies, they've already embraced that. So I typically don't observe that in terms of embracing that DevOps mentality and mindset. But ultimately it comes down to even Ops teams where (you know the simple example, right?) an insurance company here in the States, -- they take on the order of anywhere from two to six months to provision out hardware so that they can actually install software onto their production systems, versus you have companies that are embracing the cloud.

I mean it takes minutes to set up an Atlas cluster for us, and it's kind of that dichotomy  still like they're happy to operate in kind of the timescale of weeks and months versus minutes and hours. That's where I see the biggest challenge: is how much empowerment they have, but also how much risk are they willing to tolerate, and then ultimately it's always easy especially in larger organizations where, well hey you know of course we could spin up a cluster in minutes and kind of leverage the cloud and do those type of types of things. But if the organization doesn't support it, if the company doesn't support that willingness to move quickly and to experiment and to embrace these things,  it just becomes the adage of like ‘hey nothing's broken so we're not going to fix it’ mindset, so we don't change. Does that makes sense?

I've sat in those procurement meetings where it's just, ‘okay, so when can we have it?’ ‘Okay, we can have it in that period. Okay that's really going to help us in six months time. Great. Fantastic.’ And you just go away and think, oh well. It is very frustrating... because we can go down a whole set of rabbit holes here, but I’ll mention the terms and then we'll move on: the additional transformation and so on.

And culture change is one thing. The phrase culture change seems to imply that it's going to change over time but actually I think what you're hinting at is more of a cultural epiphany. It's “Are we going to work in the quick way or are we going to  carry on working in a slow way?’ And if you're not forced to work in the’ quick way or if you're not sort of suddenly magicked into a state of mind where the quick way appeals, then you will just carry on working the slow way.

Yes that's absolutely correct. And to your point around ‘digital transformation’ like that, I mean that's been a term that's been thrown around for the last 20 years. Companies are still embracing that because ultimately they all know they need to leverage software. They are becoming software companies if they are not already, but ultimately being great software companies. And I think the underpinning to all that is how they leverage and utilize and ultimately about market power in their data whether it's through operational transactional workloads like e-commerce system, systems of record that ultimately drive revenue, but also being able to afford insight and being able to derive insight that ultimately drives business decisions that allow them to adapt to changes in the market, -- changes in even a company dynamic itself.

I think it's among MongoDB's unique value propositions there that we can support obviously the most mission critical operational and transactional workloads like gaming systems, large e-commerce systems for like Sysco for example, and at the same time allow companies and users to gain real time insight in their data by leveraging our analytics capabilities and servicing all that in a very easy way (because I'm sure given your history, you know it's always been about kind of this separation of OLTP or operational and transactional workloads versus analytical workloads). And I think that's historically always been kind of the brainwashing, if you will: ‘Hey I have to wait hours if not days in order to get this data moved out of my operational database into this data warehouse’ or this advent of data leaks: it was all around trying to gain insight much more quickly.

With MongoDB we allow customers to ultimately get that insight by leveraging real time analytics on that operational data. That's another big trend that's happening where you're seeing kind of emerging operational and analytical workloads into a single data platform, and that's ultimately part of our charter and mission as a company, which is to make data super easy to work with, but do it in a way that allows users to embrace any type of requirement, -- whether it's supporting those transactional workloads as well as being able to gain instant insight based on all the data that they have.

Now that does remind me of one of my favorites and I use a three letter acronyms TLAs is ETL, which back in the day when I thought ETL that sounds like a really complex system. Wow, what do you mean extract, transform and load? You're literally just taking data out, mucking around with it and then pushing it back into the system. It’s just like how how we can make the most primitive things sound clever and zany? That's the IT industry in a nutshell.

And I guess as we start to wrap up and you're starting to hint at some of the things that you're saying are going to come, with the old phrase in mind about (I didn't see a hockey game my first ever hockey game at the weekend and that was fascinating. I've no idea what happened but it was very exciting but I did see the puck move an awful lot.) And the old adage about going to where the puck is going to be.

The question is: from an enterprise perspective, how should they prepare for where the puck's going to be in terms of both data and data management and then also DevOps and SRE and so on? What would you advise organizations that are just saying “Look we're trying to set ourselves up for the next couple of years, and where should we start?”

Yeah it's a great question Jon, so I think there are probably a few facets to it. And if you maybe take a ‘top down’ look at why companies even undergo digital transformation initiatives in the form of modernizing their application stacks, legacy modernization, it takes a few or it has a few labels to it. Again it's all driven around driving towards business outcomes and ultimately providing some type of value and mapping that value back to I think the end customer.

So I think the embracing of new technology, especially technologies that allow you to work faster, to embrace things like DevOps methodologies that can get you to, again reduce that time to market increase ultimately the value that you deliver is is critical to any business. And I think when MongoDB was born out of that whole mindset over 11 years ago, -- which was all around driving developer productivity, making data super easy, ridiculously easy to work with and driving it in a way that you can't deliver value if you're distracted trying to manage a stack. So we want to also basically supply an easy to consume service in the cloud via Atlas that allows clusters to get spun up in minutes so that organizations can focus on the high value work, -- which is building apps that really drive the business and drive revenue streams going forward.

I think data as a whole, -- it's something that has a ton of inherent value and every customer I speak to struggles with unlocking its real potential, unlocking its real value. So I think the faster they can move towards not even just some of these DevOps mindset and methodologies, but also how they look at managing and running their data real estate. It actually behooves them to move away from legacy stacks that have been built at a time and place where it was a whole different set of requirements, -- 40 years ago -- and embracing things that really allow them to build a truly modern application.

I think I'll maybe end on this note, like the way we think about modern applications at MongoDB is kind of three fold. We want to drive ultimately developer productivity and what that means is allow developers to work on the high value work which is building their app and coding and not having to jump through hoops to manage and interact with data. That's number one.

I think the second thing is looking at how we can provide that whole concept of infrastructure as code, but ultimately for their database or their data platform which is around ‘Hey if I want to consume a database that's a service like MongoDB Atlas I should be able to just go and spin it up in a few minutes and just start working.’ And then also not have to worry about kind of the management aspects: the reliability, the security, the stability of the system.

So we want to ensure that we can also drive kind of that unique proposition of moving data as close to the user as possible. So ultimately underpin the third thing, which is for us, delivering that uncompromising user experience and that comes in the form of data that is going to be highly performing from the standpoint of: I don't have to sit there and wait for my app or my browser to go and query the database and get data and it comes back seconds later; we want to have and provide this ubiquitous ‘global data layer,’ I like to call it Jon, which allows data to be as close to the user as possible to provide that that uncompromising user experience. And I think those were the key tenets for us as far as how customers are thinking about modern applications.

And obviously know Devops, agile methodologies, how companies go to market and what things they embrace all underpin that because it's all about speed; it's all about innovation; it's all about agility; it's all about getting massive amounts of iterations out very quickly, but also balancing it with the stability, the reliability, the security that I think every business needs and requires today.

Also ultimately then it's it's about putting the business into the driving seat. So as you say, stop thinking about the stock, start thinking about how can you set the time to value. You said time to market that. I'm extending that because you want to talk about value, so getting that.

So that whatever the business is trying to do right now, we've got a solution for that. And we want to make the developers as productive as possible to deliver that solution as quickly as possible so that the business can get on working with customers. Jobs are good and fabulous.

Well thanks. Thank you. Thank you, Seong. It’s always fascinating and fantastic to talk to you and and learn your views about what is going on. And I very much look forward speaking to you again.