In this on-demand webinar, Jeff Kaplan of THINKstrategies and NuoDB CTO Seth Proctor discuss the shift toward SaaS models and the impact that shift has from a database perspective.
(Lorita Ba): Hello, everyone. Welcome to our webinar, “Executing a Saas Strategy: the Role of the Database.” My name is Lorita Ba. I’m from NuoDB, and I’ll be the moderator for today’s webinar. I’m joined by Jeff Kaplan, founder and managing director of THINKstrategies. Jeff, thanks for joining us.
(Jeff Kaplan): Hey, it’s a pleasure to be with you.
(Lorita Ba): And Seth Proctor, CTO of NuoDB. Hi, Seth.
(Seth Proctor): Hey. It’s great to be here.
(Lorita Ba): Today we’re talking about the role the database plays in executing a SaaS strategy. First, Jeff -- if you can turn the slide, please -- first we’ll turn to Jeff, who will spend some time exploring the underlying drivers for this move toward software as a service, and how customer expectations have changed as a result. He’ll also briefly touch upon the data opportunities and challenges that result from such a migration. From there Seth will outline how these changing expectations warrant a reevaluation of database requirements. This will lead into a short discussion of how NuoDB meets those needs and how it differs from other database options. Finally, we’ll hear customer examples of this migration to SaaS and what it has meant at a database level. At the end we’ll open it up to Q&A. Next slide, please.
But before we begin today’s presentation I’d like to review a few logistics. Our webinar will last just under an hour. The webinar will be recorded and made available for replay. Attendees will be muted during the call; however, you may submit questions at any time during the presentation using the questions box in the go to webinar control panel. We’ll answer as many questions as time allows at the end of the presentation. So with that I’ll go ahead and turn it over to Jeff. Jeff.
(Jeff Kaplan): Hey, well, thank you very much. It’s a pleasure to be with everybody today, and we’re very excited to be a part of this webinar, because as we see it, the SaaS marketplace is maturing quite rapidly, and data is at the center of the SaaS movement, and therefore the database is becoming a much more pivotal part of SaaS vendors’ success strategies. So what we want to do today is talk about some of the trends that are driving the growth of SaaS and some of the challenges that are associated with that growth. Now I have to apologize a little bit, because I’m suffering from a bit of a cold, so I may have to go for my water occasionally during this presentation.
But what I wanted to do to start is put everything into context with the famous line, the best of times and the worst of times, and we can all look around us at the broader marketplace and recognize that from a good news standpoint there’s never been a better time to be in this industry. The market opportunities are growing, the models for success are expanding. There really are very exciting times that we are living in. But on the other hand, we also face escalating challenges: greater competition as the barriers to entry are falling all around us; and higher customer expectations as the number of apps that are available expand, and the expectations of customers in terms of the performance of those apps are also rising.
So with that as the context, let’s dig a little more deeply into what’s really driving this market. As we all know, the world is changing. We’ve got everything from globalization to the advent of the mobile workforce, and the more dispersed workplace, which is leading more and more employees to take things into their own hands when it comes to the comsumerization effect, and it’s having its own effects when it comes to software applications. And in particular we’re seeing this with the new generation, if you will, the cloud generation of millennials and others who have grown up taking advantage of mobile apps and expecting a certain level of performance and user experience associated with that, which is leading them to make choices that are unlike any that we’ve seen in the past. They have greater control over the decision-making process, and are more finicky about the apps that they use, and when and where they take advantage of those apps.
So with those kinds of trends influencing the way in which user or consumer behavior is evolving, we’re also seeing, of course, that explosion of mobile-based applications, and the phenomena of the bring-your-own-device has morphed into the bring-your-own-apps world. The good news, again, is that we have more buyers interested in taking advantage of our applications. The bad news is that the barriers to entry have fallen, and the assortment of on-demand apps is expanding rapidly. So what we’re seeing is an evolution in the way in which SaaS is taking a hold within the organization, and this is true in both the small and mid-[sizers?] and B level, as well as the enterprise level of organizations.
The first thing that we see is that the horizontal apps are taking hold first in the front office with sales automation, and marketing automation type apps, and collaboration apps. Many of those [are?] acquired or procured in a clandestine fashion by disgruntled employees who have gotten fed up with the traditional applications around them, and they want to find something that’s more responsive to their needs. As those horizontal applications take hold in the front office, we’re seeing that they’re also beginning to gain penetration in the back office and even being used for inter-enterprise application requirements. So everything from ERP systems, to financial management systems, to supply chain, and e-commerce are all now being SaaS-ified.
At the same time, we’re seeing a new generation of industry-specific apps aimed at particular vertical markets. So these are applications that are trying to solve age-old business processes within specific industries, and again, trying to provide an easier-to-use, on-demand alternative to the on-premise applications of the past.
Now in the past, we saw IT try to fight off this SaaS phenomenon, because of its concern about a loss of control, the possible security ramifications of using these on-demand applications, and the concern that they had about being able to monitor and measure their effectiveness. But as these SaaS apps have matured and the use of them has expanded across the organization, IT organizations are finding that not only do these applications work for business purposes, but in fact they serve as a model for success that the IT organization itself is envious of, and as a result we’re seeing a number of IT organizations move towards using SaaS-based, cloud-based applications to manage their own operations. So with their acceptance and adoption of SaaS apps for their own IT management purposes, we’re seeing them also support greater adoption of SaaS applications across the organization. So as a result, what we’re seeing is SaaS being adopted quickly and serving as a lead in for organizations to take advantage of infrastructure-as-a-service and platform-as-a-service alternatives as well. So every aspect of cloud-based services is gaining not only attention but acceptance and adoption across the industry and across the marketplace.
As many of you probably know, Marc Andreessen made a prediction a few years back -- I believe it was back in 2011 -- that software was eating everything, and I have a feeling that even he’s surprised at the extent at which his prediction has come true, because in fact there is software everywhere you look nowadays. Whether it’s in the connected car, or the connected home, or even connected health, cloud-based alternatives, and they are all software-driven alternatives, are changing the way in which almost every product and service is being delivered today. And the good news is again that software opportunities are everywhere. The bad news is that the expectations again are being driven not only by competition but by growing expectation among consumers in terms of the response rates and the performance that they expect. And what we’re seeing is that the software penetration of every industry is transforming those industries and disrupting those industries. Of course, we’ve seen a tremendous disruption in the entertainment industry with the subscription services that have taken hold there, and we don’t have to look far to know about what’s going on in the sharing economy with Airbnb and Uber as well. Now, again, these are cloud-based business models driven by software, and software as a service is really at the heart of all this.
So SaaS means that we have a new opportunity to better serve customers. And although this guy may look a lot like me, and in fact I am a cyclist, I don’t usually go riding around with my head down looking at my cell phone, because here in the Boston area I could have a short trip. And I don’t usually wear a suit and tie while I’m going through that ride, as well. But the more important point is that SaaS gives us a new opportunity to better understand my needs and the needs of consumers like me. It also helps to better understand what I prefer, how I behave, and when I may be at risk not only of being hit by a car, if I’m in that position on my bike, but more importantly, when I’m at risk of maybe leaving that application and that service provider for another alternative because I’m not using that application as I might have in the past. So what it means is that a SaaS provider, if they architect their application properly, has a pretty good idea about what my needs are and what I might do next. And in fact in the cycling community there is an app for that, and that is Strava, and it’s the app that tracks our movements and allows us to record our rides and analyze our behavior. More and more, whether I’m a consumer and a cyclist, or I’m a business executive, or an end user, I want that data at my disposal. So what we’re seeing is SaaS apps becoming much more data centric and data driven.
Then, of course, for not only the SaaS provider, but the users of those SaaS applications, it’s all about being able to better target our solutions and our strategies to meet our business objectives. So the folks over at Gartner have suggested that we are now at the slope of enlightenment on the hype cycle when it comes to SaaS and the broader cloud services. And what we believe at THINKstrategies is in line with what IDC has been saying over the past couple of months or so. It sees a movement toward SaaS as well and suggests that by 2018 most SaaS vendors will have fully shifted to a SaaS and PaaS code base. They believe that this means that many enterprise software customers, as they reach their next major software update or upgrade decision, will be offered SaaS as the preferred option. Now, as it relates to this topic about data, IDC goes on to say, “Put together, new solutions born on the cloud and traditional solutions migrating to the cloud will steadily pull more customers and their data to the cloud.” And it is all about that data.
As we see the patterns of adoption shift from the clandestine end-user or SBU adoption that at one point avoided the IT organization and decided to adopt the SaaS application unilaterally, we’re now seeing enterprises make company-wide decisions to move to the cloud and to SaaS, and that’s raising the bar in terms of the expectations of the customer and the performance expectations for the data. So the good news is that there has been a proliferation of players from a user point of view. That means that what we’re seeing is a buyers’ market, and we see over 2,600 companies that are listed across 90 different categories on THINKstrategies cloud-computing showplace. But the bad news is that it’s tough for the decision makers within those organizations to determine which SaaS apps are best for them, and they’re going to make those decisions based upon a higher standard of performance.
So as we look at this marketplace, there’s no question that there’s an intersection of cloud-based services and the big data phenomena. Now for anyone who’s been in the database business, we all know that the challenge of big data has been out there for a long, long time. But what’s happening is, of course, that the new forms of data, whether it’s social data or other forms of data, is compounding that challenge, and in fact the folks over at Gartner suggested that only about 15% of Fortune 500 companies are going to figure out how to use that data effectively to gain a competitive advantage. Said another way, 85% of those Fortune 500 companies are not going to figure it out. So that means that as the data grows, the challenges grow as well, and with the advent of the internet of things and the digitization of almost every business, we’re seeing more data being produced every day. So as the marketplace moves to the cloud to capture that data and to utilize that data to power their businesses, there’s got to be a change in the way in which the data is architected, the database is architected, to support those requirements.
Now for us at THINKstrategies, we think there are a number of keys to success when building a SaaS database architecture. It starts, first of all, with the ease of deployment, because it’s all about ease of use in the SaaS marketplace. But then it’s also about accessibility, because that data is of little value if you can’t get to it at the right time and the right place. Added to that is, of course, the concerns about security and about scalability. But along the way what we’re also trying to do is maintain a level of performance that meets the expectations and the rising expectations of customers [that places?] on demand marketplace. Portability is also important, and of course manageability goes along with that. When the day is done, of course, what a lot of organizations are trying to do is achieve cost savings by moving to a SaaS orientation and taking advantage of the cloud.
So what we’re seeing is a number of market trends that are driving a wider array of organizations to move to SaaS. But what we also see is SaaS companies being challenged to meet the expectations and the growing demand that that places on their organizations as well. So what we’re going to do here is I’m going to pass the baton on to Seth so he can dig deeper into some of these trends and their implications for SaaS companies and talk about what that means in terms of the database requirements for SaaS organizations that have NuoDB [is?] responding to those trends. So, Seth, the platform is yours.
(Seth Proctor): The platform is mine, the data platform. Thank you, Jeff. That was an awesome introduction. So it’s just that what I’m going to do is I’m going to kind of follow onto [what?] he was just describing, kind of the overall requirements around SaaS, what does the infrastructure look like, what are some of the driving requirements, and talk a little bit more deeply about what we’re seeing in terms of requirements specifically at the data level, and then talk a little bit about how we’re addressing those at NuoDB. In particular, in that last slide, what you heard Jeff talking about really were some core requirements that increasingly, as you’re building SaaS architectures, you want from your data platform. Those are around things like elasticity and high availability, making sure that you’re working in a cloud-native model. We’ll talk a little bit about what that really means. There are issues of being cost-effective and secure, and of course [there’s?] issues of simplicity, or kind of driving down complexity. In other words, kind of what people increasingly are demanding is that their data service, their platform, kind of look like the application platform that they’re trying to provide, not something that’s chopped apart into lots of different pieces that have complexity but that make it simple to deliver the next application and the next application.
What do some of these things really mean when you’re looking at a data platform? I think, first of all, people really care about elasticity. Really what that means, you know, for all of us who work in a cloud world, is that we’re used to being able to get capacity as needed. We all know that this is about lowering costs, it’s about driving simplicity, it’s about getting from your data model the same thing that you’re trying to provide from your application model, and it’s a way increasingly, as your SaaS applications are not just serving one individual user, but are trying to be multitenant, you want really to think carefully about how those resources are being used and how to apply them best to each tenant to be as cost-effective and application-effective as possible.
Fundamentally, as Jeff said, this move towards big data, this move towards SaaS applications, this move towards the data-driven society, means that if your data is unavailable your application is unavailable. So fundamentally your data platform, when you’re building a SaaS architecture, it needs to be resilient. It needs to be resilient not just to those unexpected failures, but to all the normal day-to-day activity you’re going to run -- upgrade, migration, if you’re in a public cloud, all of the changes that happen in the infrastructure around networking and storage, and kind of all of the management of your architecture as a whole. You can’t lose data, even the subset of your data, for any amount of time -- [it’s?] your platform -- if your service is going to continue running.
It’s also increasingly critical that people are looking at this and saying, well, how do I get something that’s cloud-native? Not just how do I take my last generation data management platform and try to sneak it into this next generation SaaS thing I’m building, but really how do I build on components that are fundamentally native to the environment where you’re running? This is less about are you running on a public cloud, or are you running on-premise, are you running in some kind of hybrid, this is more that the cloud is really all about distributed computing. It’s all about this movement -- just as we moved once from the mainframe to a client-server model, we’ve now moved from that client-server model to a distributed computing model. There are all of these wonderful benefits that come with it. There are also a few challenges that come along the way. So that’s really what we’re talking about is software that is built with this new model in mind.
Part of that means that we’re talking increasingly about running in virtualized or in containerized environments. You want not just your application to be running there, but you really want data services that can take advantage of that model, can take advantage of the fact that your OSes are virtualized, the disk, the network. That means you’ve got a whole host of new monitoring tools, you’ve got a whole host of new management tools, and you need those tools, because cloud is largely about virtualization. It’s about being able to lower your costs through use of commodity infrastructure, and commodity is inexpensive for a reason. Virtualization is a wonderful tool for developers, for productivity, for cost effectiveness, but it also introduces more likelihood of failure. So building with data models in mind that increase redundancy, that provide horizontal scale, that give you the ability to tolerate failure, these are core requirements if you want your data platform to continue to run in the case of failures, to continue to support your SaaS, your service that you’re providing to your users.
Finally, I think it’s really important increasingly in both developers’ and operators’ mind to drive toward simplicity. We’re building increasingly complicated infrastructure, widely distributed systems, a lot of moving pieces, a lot of great, rich functionality for our users, and as you continue to build within that direction you need to simplify what your core infrastructure looks like so you can actually understand it, you can manage it, you can maintain it. Part of that’s about the programming experience. Part of that’s really about making sure that your developers have APIs, have languages, and tools that they’re used to working with. They know how to do testing, they know how to do deployment, they know how to actually do analysis and make sure that before they go into production they can stage things and understand what they’ve built.
To support that in a cloud model we’re often talking about on-demand provisioning. We’re talking about self-service dev tests, we’re talking about making it easy for your developers, your testing group, your operators to get services provisioned on demand to build the next layer of services on top of them. It’s also about that ease of ability to automate things like backup and recovery, upgrade, migration. You know, when you’re talking about scaling out a caching tier, or you’re talking about an application tier, often those are transient, often those are fairly easy to provision and get running. When you’re talking about the data management tier, these are fundamental things that really matter. You’re talking about [stateful?] services, you’re talking about durable services, you’re talking about maintaining often large amounts of information across a cluster of systems. So you need something that makes it easy to manage that as you scale, so that you don’t discover at some point down the road that you can figure out how to scale your application, and it’s going great, and everyone wants to buy your application, your SaaS offering, but the bottleneck is you don’t know how to scale, say, your backup model. That’s a real challenge increasingly in enterprise and web applications.
I think one way you get that simplicity is by providing a single, local view of your service. Just as end users find SaaS offerings really valuable, because it just is a single application, it doesn’t matter what device you use, it doesn't matter where you’re logging in from wherever in the world, you just have a view into your application or your data, likewise it’s far easier if you’re building your higher-level application onto a structure that provides that same logical view.
In summary, I think what both Jeff and I have been talking about is that for SaaS offerings you really want data services that are on-demand, elastic. You want them to always be available, make it easy to exploit the advantages of cloud. You want that single, logical service view, a drive toward simplicity, a drive toward easier scale, and growth, and ability to not just develop [against the?] system but operate the system. And in many cases you care both about the ability to migrate existing applications and also build new applications while operating against a common model.
So what have we done at NuoDB to address some of these requirements? Well, for those of you who are unfamiliar, NuoDB is a SQL database that has been architected for the cloud. By that I mean it’s a fully ANSI-standard SQL database, does standard ACID transactions. All of the drivers and tools that you’re used to using in terms of JDBC or ODBC, full support for notions of DVL, Schema, the ability to do arbitrary end-way JOINs, have full indexes, views, stored procedures, all the things that you’re used to having in a SQL database, real isolation levels, standard driver, standard languages, no limits on what can run in a transaction (inaudible) the underpinnings to let you migrate your existing applications, use your familiar tools and get them into [an?] environment. But that design for cloud really means that we’ve stepped back, and we spent the last several years fundamentally rethinking what the architecture for a relational database should look like, for what a SQL database should look like, when you’re trying to address these kinds of SaaS requirements. So this is not a bolt-on storage engine. It’s not a caching tier or a layering tier on top of an existing database. It’s really a fundamentally new system from the ground up, built on a peer-to-peer model that’s designed to do the things I’m talking about, that’s designed to scale well on virtualized infrastructure, that is designed to be distributed across a large number of systems with no single owner, no single point of failure, no single actor for any given piece of data. And it’s designed to be memory-centric, really in-memory database, to support both performance and also flexibility and storage.
And what does that really mean? What it really means is as we thought about how to build a database at scale, we thought about two kind of traditionally tightly-coupled components as separate concerns. So we think about the service layer, kind of where we do the transactional processing and where clients connect to the database, as a separate tier essentially from where we think about storage. So that service layer is a transient layer. It’s a peer-to-peer system, it’s caching, so it’s running in-memory. But because it’s a transient tier, it kind of scales in a familiar fashion like we were talking about earlier. The ability to scale on demand is something that’s just built into the system, in part because there’s no explicit sharding, no explicit partitioning. The database appears like a single logical unit to developers, because this caching tier is taking responsibility for bringing data into memory where it’s needed, coordinating amongst the peers to share information as it’s needed. Because there’s no single place where data is owned, scaling this tier just involves starting new machines and scaling back the tier just as shutting off machines or processes. So this really works the way many people are familiar with scaling -- transient services, caching tiers, application servers, things that really are memory-centric, and it’s responsive in that same sense and gives you that flexibility while the developer still programs to a single database -- I mean operators still operates a single logical database.
With that front tier, the storage now is something that we think more about redundancy than a place where we enforce all of the requirements of ACID consistency or kind of the traditional performance that drives people to think about I-OPS in the database. The database in NuoDB is something that’s automatically replicated, so you can have multiple points of storage and more maintaining automatic replication of that data. So that helps you with the redundancy that helps you with the failover. It makes it simpler to think about doings like backup and recovery. And this model, of course, gives you the ability to allocate the right kinds of resources for the right tasks. So depending on the kind of processing you’re doing, depending on how you’re thinking about your working set sizes, depending on the amount of data you’re storing, you can allocate different instance types, for example, if you’re thinking about an AWS model. Or you can allocate on-premise, high-end storage servers on the back end, and very lightweight, scale-out virtualized servers on the front end. This really gives you a great deal of that kind of cost-effectiveness that Jeff was talking about earlier. And because both of these tiers are redundant, they’re designed to survive failures, they’re designed to support upgrade, they’re designed to be a system that you could continue to mutate and grow even as the service as a whole remains running.
That’s really the important part, is providing that service, and part of how we do that is we have built into the product another tier that’s really focused on orchestration. It’s the thing that provides to anyone who’s interacting with the database that single, logical view. It takes care of things like load balancing and discovery for SQL clients. It supplies resource monitoring and management for the administrators of the system that care more about resource than they care about SQL. It gives you visibility into what failures are happening, it gives you a platform for automation, either responding to failures, or allocating new resources on demand where you’re under provisioned. That provisioning step is designed to be very simple. Again, this is about being cloud-native, it’s about providing simplicity for both the developers and the operators, and provisioning is really just a matter of starting some new instance or container or [VM?] somewhere in the system with the NuoDB software on it, telling that software where to find one existing peer in this network, and providing at the entry credentials, because these communications are always secured. Then as soon as that initial connection is made you’ve allocated new resources that are available either to expand some database you’re running, to run some new database and treat this as kind of a generic pool for a number of multitenant databases, or simply have preallocated resources available so that as your database or databases are starting to become taxed you have a place to expand.
As an example of a couple of our customers who are particularly interested in this, in the SaaS space, we have a few customers who are very much traditional ISVs, very large companies in different vertical -- thinking about different customers, thinking about different specific applications that they’re providing, but they have a common theme between them. The common theme is that traditionally as ISVs they think about operating in the customer data center. Typically what that means is the customer will go out and have licenses for some RDBMS. Typically that’s a traditional client-server relational database. There may be other things in their infrastructure. Then that customer will buy the ISV software to run either on their metal, or maybe in a virtual machine, but run on-premise and kind of manage themselves. That’s great, but it doesn’t give these customers of ours insight into how the customer is using their software. It can make it hard to make sure things are configured and running correctly. You certainly don’t get the ability to orchestrate resources between that application tier and that database the way you might want in the SaaS environment.
And more importantly, both of these ISVs are following a trend that I’m sure many of you on the call are interested in, which is this movement towards taking things that were traditionally on-premise or on client applications that you downloaded in RAM locally and actually turning around and offering them as services. Interested in taking their traditional on-premise applications and actually offering these as services to their customers through the cloud. The first step of that is ensuring that they have the platform to build on, that they have that data model that we’ve been talking about, that is elastic, that is cloud-native, that is simple to provision, that can be monitored, that can be backed up, that can tie into all their existing tools. That lets that application tier that they’re building then scale easily, knowing that that data service is also there to scale along with it, that transforms something that was very tightly coupled and on-premise to something that is much more cloud-native. With that in mind they’re then able to go back to their customers and say they can now offer something on-premise that is exactly what they do in their cloud service offering, but now it’s that same service model, and it’s offered not as just a piece of software that ties to a piece of software that a customer has, but really as an elegant solution that looks like a cloud offering in terms of orchestration, in terms of managed resources, in terms of components that really work together and that give the customer a better experience, but also give our customers, these ISVs, the ability to have better insight into how their customers are using the software, to better optimize systems, to better manage systems for their clients. So this is a really powerful model of software evolution and I think very much the trend we’re seeing in terms of how SaaS companies are really thinking about transformation from on-premise to cloud, to expanding that cloud, to being back on-premise but in a managed fashion.
Bottom line, I think what both Jeff and I have been talking about is SaaS is all about being able to offer scalable solutions to your clients, to your customers, so that they can solve the problems they want. They don’t want a provision infrastructure; they don’t want to manage systems. They just want their application, and they want their application to have access to their data. To make those customers successful, to make your business successful, if you want to be able to scale your service, and data is increasingly the core of your services. For all of the different players around that data, you want a database that is the platform, which is kind of the traditional contract we’ve had for so long in the enterprise world and the ISV world. When the database is the core that you can guarantee provides transactionality, provides scale-out, provides operational insight, provides simplicity for application development, provides models for backup and recovery, provides simple provisioning models for doing testing and profiling and getting back to [no good states?] in the case of strange failures, when you have that as your platform it simplifies your application development, it empowers you to be able to build richer applications that work well with your operations model, that work well with your backup and recovery models, and fundamentally simplifies what you’re doing and lets you get to better scale-out models faster.
So I think that’s what we wanted to say about both what’s happening in the SaaS world, what’s happening specifically for our customers who are trying to understand the requirements for data at scale for their SaaS applications, and a little bit about NuoDB. With that, Lorita, I think we have a little bit of time, so we’ll open to some questions.
(Lorita Ba): Absolutely. So I’d like to remind everybody that you can ask questions through the questions panel in the go-to-webinar control panel. It should be on the right of your screen. We’ve had a few that have already come in. The first is -- logistically -- people who have asked for a copy of the presentation. We’re happy to send that copy to folks after the webinar.
The first question actually is for Jeff. Jeff, can you help explain what kind of tolerance do SaaS users have for outages and latency? Do you have any statistics around that?
(Jeff Kaplan): Well, I wish I had specific statistics to answer the question, but you know it all depends on the nature of the application. But there’s no question that in today’s world, with more and more organizations becoming dependent on those softwares and service applications, they’re not particularly happy with any outage or any latency. So what we’ve seen is that companies like Salesforce.com, for instance, who had some issues years ago, have had to put in place their trust site to provide information about the status of their services and to continuously strengthen the delivery of those services, and others have had to keep pace with that. So, again, the competitive landscape is such, and the customer expectations are such that the tolerance for outages and latency continues to go down, and the expectations continue to go up.
(Lorita Ba): Great. Thank you. Seth, the next one is for you. Why wouldn’t I just take my existing Oracle database and migrate it into something like Amazon’s EC2 to address some of the cloud issues?
(Seth Proctor): You certainly could, Lorita, and Amazon obviously has a relational database service offering, and it offers support for databases, Oracle being one of them, other traditional databases. Again, I think it comes back to the transformation that we’re seeing so often from customers, is that when you’re already migrating to a cloud environment you really want your entire staff to embody that cloud-native model, and you really want, at all layers of your stack, that operational simplicity, the elasticity, the cost effectiveness. But also kind of to what Jeff was just saying, you don’t want that client-server model, because you don’t want to be thinking about single points of failure and then getting into the game of, well, how do I do replication? How do I know that my replicated copy is up to date? How does that affect latencies? You really want something -- I think fundamentally when you’re designing your stacks you want everything up and down your stack designed for that distributed, scale-out, resilient, redundant model. So I think that customers in some cases start by moving with those databases. I think they very quickly discover that when that database platform itself embodies everything they want, and they can build on it, it just makes everything up above it work so much more smoothly.
(Lorita Ba): Great, thank you. Another question here is as you scale the database out, is all the data replicated across the system by a sharding, or do you have the ability to have complete copies of a single database instance? For example, I want to export historical data to a different machine.
(Seth Proctor): Sure. So at NuoDB specifically, that’s something we’ve designed to give you an option around. The kind of -- the simple model is that all the data is replicated to all your locations at the storage layer. Then as you are interacting with different subsets of your data, it’s brought into cache as you need it. So if you have a mixed workload where you’re looking at the historical data, you might run your system purposely optimized to save operational transactions running that are real time for the current data, and then somewhere else you have data sitting in cache, because that’s where you’re driving your transactions that are looking at history. You might also set up a system to use partitioning, kind of traditional, table-level partitioning that we’ve mapped to something operational that lets you make the decision to store different data or age different data in different fashions. It’s designed to provide support for the different use cases depending on which kind of models you’re most interested in.
(Lorita Ba): Sort of similar to that, someone’s asking specifically about how NuoDB compares to something like Oracle RAC and GoldenGate?
(Seth Proctor): Sure. That’s a great question, and a really natural thing. For those other folks who aren’t familiar, Oracle is based on a traditional client-server architecture. RAC is a clustering architecture essentially that lets you scale out where you’re actually doing processing on the system. GoldenGate is a technology that takes it about a step further and lets you do replication, both kind of synchronous and asynchronous, and resolve any conflict that’s happened as you are replicating between different instances. In terms of comparison, I think what we’ve tried to design at NuoDB is something that doesn’t kind of make the distinction between those models. A database is a database, whether we’re responding with one machine or five machines or across a couple of data centers. It just looks like a single logical database. It’s designed to be resilient, so it’s designed to do some similar things to what RAC does in terms of failure, in terms of being able to scale out, the places where clients connect, and where you can do transactional (inaudible; distortion). It’s not designed with any assumptions about the hardware. It’s not designed to require specific disks or specific networks, or make assumptions about kind of low latency type connections. So it’s much more kind of designed for that cloud model, as opposed to kind of the traditional rack architecture, R-A-C-K architecture. Certainly in terms of GoldenGate our design was not to think about active-active replication that has to be reconciled, but about globally transactionally consistent data models, so again kind of a different -- I think a different set of assumptions as people build cloud-scale architectures, and they’re looking for something that’s a little bit simpler to work with and a little bit more natural to what their models are.
(Lorita Ba): Next question is how does IMDB and the use of SSDs impact the architecture of the database?
(Seth Proctor): Well, that’s a good question. I mean, we have designed a database, as I said earlier, that’s more focused on being memory-centric than being disk-centric. I think that’s how most people who are building modern cloud architectures are thinking, is always with a cache or always with some memory model. Again, this is not a database where all the data has to be in memory, that it’s the working step, not that that working step is in memory, and you’re working very efficiently. That said, obviously any database cares about making data durable. That is the D in ACID. So employing something like an SSD certainly will help just in terms of latency, in terms of the number of transactions you can run through the system. NuoDB is what’s called a multi-version concurrency control-based system, or MVCC, which at a high level means that -- you kind of think about NuoDB as an append-only database. We’re never changing things in place, we’re just keeping track of the changes in versions as they happen. So from that point of view using an SSD to handle kind of what in our system is analogous to the traditional log is something where you get great performance benefits. But obviously in any database applying something like an SSD is certainly beneficial, and as we look at what’s happening with 3D XPoint, you know, some of the new kind of hybrid technologies that are coming down the line, I think it’s a very interesting time for databases in general. This is an architecture that we can exploit many of those changes that are happening.
(Lorita Ba): How are you addressing the hybrid issue where clients have critical data in both the cloud and on-prem locations?
(Seth Proctor): Yeah. That’s definitely increasingly important. Both for people who are kind of testing the waters and starting to look at migration, for customers who are running a service and want kind of additional capacity on the cloud, more often for people who have a data model where they’re willing to take some of their data and put it into the cloud, but they’re not yet ready to take all of their data out of their on-premise model. We also talk with customers who are going to run across multiple clouds because they’re just running in different physical locations, and one cloud provider is the (inaudible) in one, and the different cloud provider in another. So, yeah, definitely important.
The short version is, again, that NuoDB is not really focused on a particular hardware. It’s not even a requirement that you run with the same kinds of instances in hardware supporting it, as I said earlier. So it’s kind of designed with that heterogeneous model in mind. It’s very much designed for users who are thinking about hybrid models, even in their own data center, in terms of different kinds of services, different networks, different disks, different servers, and then also those users who are thinking about expanding and running in different places with different requirements.
(Lorita Ba): How -- one question here is trying to understand the competitive comparison against NoSQL players like Couchbase or Mongo, or other vendors like MemSQL?
(Seth Proctor): Sure. The comparison against NoSQL, you know, part of it’s in the name. Without sounding flip, I mean, this is -- NuoDB is a fully SQL database, real ACID transactions, real schema, real ANSI compatibility, and so that’s obviously one substantial difference. We are designed to scale out the way NoSQL systems do. Internally we run tests like YCSB, and we’ve done public benchmark demonstrations of that just to show that we’re able to do the kinds of things that you want in terms of scale and on-demand capacity that something like a Couch or a Mongo or some other kind of NoSQL system would provide. But I think looking at the world from wanting all of that in terms of scale and in terms of flexibility, but wanting transaction integrity. In terms of systems like MemSQL, I think there are many databases out there that have decided to solve a subset of application use cases that require a subset of SQL. Those are highly valuable database solutions. They’re highly useful. You certainly see companies like MemSQL doing very well, because they’re solving useful challenges out there. One of the important differences is that MemSQL is not trying to provide a fully compatible ACID solution. So if you’re talking to an enterprise, if you’re talking to a traditional player that has existing applications, that has heavy lifting, one of those ISD customers I mentioned is today running applications that are doing 14-way joins, that are running transactions that take minutes to complete against the traditional RDBMSs of the world. So these are significant, heavy-lifting transactions, and those are something that we’ve designed, our systems do, that other databases typically are not designing (inaudible; distortion). [00:46:35]
(Lorita Ba): Another question from one of our viewers is there are many cloud-based products that are bought directly by the business. How can the database architecture for each of these products be unified so IT has a better hold from a database management perspective?
(Seth Proctor): Maybe I’ll ask Jeff to give some of his thoughts up at the high level, and then I can add a little bit more color.
(Jeff Kaplan): Well, yeah. It is true that we’re seeing organizations search out the best-of-breed solutions across a variety of vendors and across a variety of types of service providers. But what we’re also seeing, as that process continues to evolve, is that they want to center around strategic suppliers, and therefore they try to find an anchor account, so to speak, an anchor supplier who has a series of relationships with third parties that complement their core capabilities. I know what you guys have been doing is building up a pretty good ecosystem of relationships to ensure that you’re getting it all to support your customers both directly and indirectly, so to speak.
(Seth Proctor): Yeah, for sure, and I think just certainly again for -- the previous question about differentiation. I mean, one of the reasons that we’re so passionate about the standard SQL piece, and about not just what that means for application developers but also operators, is that for a very long time that’s been part of the way that there’s unification. The database and using schema as a definition of the database has been a unifier. It’s allowed developers to develop against some newer model. It’s allowed the operators to come in and look for things that are running slowly, understand something about disk utilization, resource utilization. It’s been what we use to do backup and recovery. It’s been the backbone of building things that unify applications and services in the IT environment. I think there are a lot of great tools that we’re building today that don’t require that model, but I happen to be a big fan of having that kind of unification, and I think this is one good way to do it.
(Lorita Ba): Thanks, Seth. The next question is how did the demands for data multitenancy, such as having a tenant ID in the row, how are those addressed in NuoDB?
(Seth Proctor): Sure. This is a standard SQL database. Obviously if that is a model that you’re interested in, that’s something we support. So the question really is about if you want to do multitenancy, can you take a traditional approach of saying essentially you use an identifier in one column, say, whoever has that identifier is one tenant, and a different identifier is another tenant. We also support a model of multitenancy that is a little bit more flexible where from the same management interface you can instantiate multiple distinct databases. By multiple distinct databases I actually mean physically separate processes that are running with physically separate security credentials that are writing to physically separate locations, are talking over disjoint secure channels. So if you really want a kind of a secure multitenant view of the world where you have your tenants physically isolated and where you can apply resource optimization differently to those different tenants, so maybe some of those tenants use very small amounts of resources, others are always using massive amounts, and some in between are kind of constantly going back and forth and very spiky, this gives you the ability not just to think about separation of the data, but also really do resource optimization in different ways. That’s kind of a different model that we support, but I think it’s much more native to the way people think about building cloud applications in general.
(Lorita Ba): The next question, Jeff, it’s for you. Are there particular industries or apps that are migrating to Saas at a faster rate?
(Jeff Kaplan): Well, you know, it’s interesting. What we’ve seen is that those industries that are more customer-facing, where the customers themselves have greater demands for on-demand types of applications are obviously going to be the ones where we see greater adoption of SaaS and cloud-based alternatives. Here in the past that might have been retail or consumer-products-oriented companies. But nowadays almost every industry is moving towards the cloud in general and SaaS in particular, as they try to accommodate those forces that I tried to outline in my presentation and the kinds of dynamics that Seth has been talking about. So everything from agriculture to manufacturing, and even conservative industries like financial services and the public sector who have had historically concerns about security have found that SaaS is now a viable alternative from a security standpoint, and they’re increasingly taking advantage of SaaS because of the database architecture alternatives that we’ve been talking about today that they think are going to be more important for their business going forward.
(Lorita Ba): Thanks, Jeff. The next question, Seth. We’re a global application, and we deal with a lot of personally-identifiable information. We’re finding a lot of new regulations popping up in different countries about keeping that in-country. Is there a way for us to do that without sharding the database? (laughter)
(Jeff Kaplan): Well, yeah, that’s something that a lot of people are asking about right now, whether you’re keying into the word residence, whether you’re talking about governance. There are lots of different words people are using, but, yes, it’s definitely increasingly a concern about privacy, about sovereign data, about data that’s not allowed to leave jurisdictions, or data that needs to be treated very sensitively in different locations, sometimes data that’s not allowed to enter certain regions. The traditional models are either around sharding, as you said, Lorita, or as the person who asked the question asked. They’re either around kind of sharding systems and having complete separation, or they’re around kind of encryption or what’s called data masking, which still involves strong separation of data and involves bringing in more services that also have to be online to be able to unlock data, to be able to relate data. These systems obviously introduce their own complexity. They introduce their own questions about high availability, the security model, what you have to audit. The model that we’re choosing to pursue here at NuoDB is one where you really want to take that single logical database view of the world and scale it to multiple sites, and then use that partitioning scheme I was talking about earlier to dictate where data is allowed to live, where data may live or may not live, both on disk and in memory, and then build up essentially policies to know something about where your data is allowed to reside, where it has resided, kind of how you govern that data. This is work that we’ve been exploring now for quite some time. It’s something that we’re starting to fold into our products, and certainly if there are people listening to this call who are interested in this particular set of use cases, I’d love the opportunity both to show you what we’ve done, and also get some feedback and understand how we can really help address your challenges at scale.
(Lorita Ba): This question -- I think we could probably answer, Jeff, in a general fashion, and then maybe, Seth, you can answer it specific to NuoDB’s experience. But to what extent are the application vendors who are moving to a SaaS environment doing so in a public cloud versus a private cloud versus a hybrid model? Jeff, maybe you should start.
(Jeff Kaplan): Yeah, yeah. Most of them get started on the public cloud. Many of them begin with AWS. Increasingly Azure has become attractive to those companies who are aligned with what Microsoft has to offer. But what happens, and I think Seth has expressed this very, very well, as the company matures, as its customer base grows and as that base itself becomes more diverse, obviously that puts greater pressure on the database requirements. The SaaS company, as a result, has to think about some mix of cloud resources and database architectures to respond to those needs. That’s where things get more complicated. That’s really what Seth has been talking about, the considerations that go into trying to keep pace with those demands in a highly dynamic market. Seth, I’ll let you add to that.
(Seth Proctor): Yeah, I think you said it very well, Jeff. It is complicated. It’s about -- from some people’s perspective it’s about CAPEX versus OPEX, for some people it’s this kind of security and governance question, for some people it’s about where their customers are located and how to best support them. Certainly here at NuoDB we see a mix. We see some people who are really starting out right off the bat, and they’re running in public clouds, and I agree with Jeff, it’s often Amazon. It’s the public cloud, although not always. Some customers we’re seeing really focused on running in their own data centers, either because historically they have their own data centers, or because they think their customers are more conservative and would be put off a little bit by the immediate rush to a public environment. I’m not sure there’s a lot of technical reason for that point of view, but certainly there’s a lot of perception in there. What we don’t see a lot of are people running to a SaaS model that is hybridized. I think by and large I do see -- I agree with Jeff -- I do see people who are running a collection of services and applications, some of which are in public cloud and some of which are on-premise. What I’m not seeing a lot of are single SaaS offerings that span both right now. I think that’s -- it’s a little bit easier for people to think about the class of [the problem?] and the class of data and really focus on one or the other.
(Lorita Ba): I’m afraid we’ve run out of time, and I know that there are a few questions that we still haven’t gotten to, so we will plan to respond to those via email after the event. We will be sending out the recording as well as the slides, and finally the white paper that Jeff Kaplan has written on this topic as well in the next couple of days. In the meantime I’d like to extend a special thanks to Jeff for joining us, and Seth for joining us as well, And to you, our audience, for attending the session. I really hope that you found today’s conversations informative and useful, and if you have any questions, please don’t hesitate to contact us. Thanks again for attending, and this concludes today’s webinar.