Matt Aslett of 451 Research outlines the key database criteria for cloud applications, specifically a combination of standard functionality such as ANSI SQL, and new cloud capabilities, such as elastic scalability and continuous availability.
(Ariff Kassam): Hello and thank you, everyone, for attending today’s webinar called “Key Database Criteria for Cloud Applications.” My name is Ariff Kassam, and I am the VP of Product at NuoDB. I will be hosting this webinar along with Matt Aslett from the 451 who is the research director for the data platform and analytics channel.
A couple of housekeeping items before we get started: after the presentations, we will have a brief Q&A period. To submit a question, please click on the question button in the webinar interface. We will try to get to as many questions as possible, but if we run out of time, someone will get back to you with an answer after the webinar.
In addition, a copy of the presentation will be made available to all attendees and registrants. We also ask that you provide us with any feedback that you may have from today’s presentations.
With that, let’s get started. Matt, please take it away.
(Matt Aslett): Thanks, Ariff. Thank you everybody for joining today’s webinar. So as we’ve said, my name’s Matt Aslett. I’m the Research Director for Data Platforms and Analytics for 451 Research. Just briefly, before we get started in the presentation itself, to give you an introduction to 451, if you’ve not come across the organization before, so we are a leading IT research and advisory company. We were founded in 2000. We have a few hundred employees, including over 120 analysts, and over 2,000 clients which includes technology and service providers, corporate advisory finance, professional services, and of course, IT decision makers, and the last number I’ll read off here is the most important one, perhaps the next one on the chart, is 50,000 plus. That is the number of IT professionals, business users, and consumers in our research community. So those are not obviously necessarily direct clients of 451 research, although many of them work for companies that are, but you know, they’re practitioners; they’re end users out there, you know, using technology, either – mostly at work, also at home, and they help shape our view in the world by taking part in surveys and interviews, an increasingly important part of the 451 Research business.
In terms of research itself, so we deliver both written research and data across 15 channels. We talk about, you know, from the data center core to the mobile edge, and as you can see, almost slap bang in the middle there, data platforms and analytics. That’s the channel that I am responsible for, and been with 451 and covering data platforms and analytics for the last nine years.
So onto the content itself. When we’re talking today obviously about databases as they relate to cloud and cloud applications, so just, primarily here just to sort of set the scene, you know, in terms of our perspective on the cloud, and how to relates to databases, I mean, you know, we obviously see the cloud is, you know, a significant trend, and it definitely has an important role to play in driving down the cost of storing and processing data, and we’ve got numerous research reports that point to that, and evidence from talking to customers and clients. We also see some additional benefits as well, in terms of things like developer and business agility, faster time to adoption for emerging technologies, high availability, and reduced infrastructure configuration and management overheads.
In relation specifically to cloud applications, obviously we’ll go into a lot more detail on this in the next couple of slides, but what we see is that cloud applications require a database that’s able to deliver the combination of the flexibility and scalability advantages of the cloud, plus, you know, maintaining the sort of resiliency and functionality expected over, you know a traditional enterprise database.
So if we talk about databases and the cloud, it’s important, I think, just to level set what we mean that, because there are multiple choices, and some people, you know, start talking about different parts of that, and you know, it’s important just to be very clear. So if we think about this, I think, you know, a lot of the conversations initially we had with people around databases in the cloud, and clients around databases in the cloud, with databases on the cloud. So, you know, going back to 2008, the operational database vendors all made their – pretty much all of them. They all have now, of course, made their products available on infrastructure-as-a-service (IaaS), predominantly, of course, first Amazon Web Services, but then other service providers as well.
And then the analytic database providers quickly, you know, followed suit in 2009. And, you know, so this has provided customers with additional choice. They can run those database products on the IaaS offering of their choice, but what we’re talking about here is really existing relational database products, and then obviously subsequently nonrelational and NoSQL database products as well, but existing products just configured to run on their IaaS environment. So you gain the benefits obviously of running IaaS, but you know, in terms of the database itself, you’re just running the database pretty much the same way you would on-premises.
Also, you know, another thing a lot of people think of when you talk about database in the cloud is database-as-a-service. So, you know, there we’re talking about on-demand delivery of database management software, consumed by the user as a service. Predominantly, of course, you know, again, we would think about public cloud, but that, although it’s not necessarily the case, I mean we do see other organizations delivering private database-as-a-service internally, either from their own on-premises infrastructure or perhaps a hosting provider. Either way, you know, we see that database-as-a-service[DBaaS] is in the very early stages of adoption, and most data-related workloads are deployed on-premise and delivered in the traditional manner.
And, you can get a sense of some of trajectory we see here, from this chart, which, it’s from our 451 Research Market Monitor service. So we provide revenue estimates and market sizing estimates for all of the products and technologies that we cover within the data platforms and analytics channel. This chart in particular relates to operational databases, and as you can see here, so in blue, is the revenue for operational DBaaS and databases on cloud infrastructure. And as you can see, once it’s growing rapidly, it’s a very small proportion of the overall database revenue. And so, you know, we anticipate that for operational databases especially, the majority of the revenue for the foreseeable future is going to come from, you know, traditional on-premises products, primarily because that’s where the incumbent adoption has been.
But going back to you know, the previous chart, there is a third option here, and that is databases for the cloud, or databases for cloud applications as we’ve described it here. So essentially what we’re talking about is a database that’s designed to take advantage of, and enable that kind of elastic distributed architecture that supports software-as-a-service[SaaS] applications. But that, the applications will be delivered in a SaaS manner and consumed by end users as a service. The actual database software that underpins them may or may not be running in a cloud architecture.
And, you know, if we think about the phases of adoption that we see from on-premises to all in cloud, that third option becomes, you know, increasingly attractive, because whilst we see that organizations are working towards, you know, increased amount of cloud adoption, they’re doing so in phases, through discovery and evaluation, running trials and pilot projects, application test and development, initial implementation and broad implementation. And you know, all of those phases in between could be described in some way or another as kind of a hybrid level of adoption. So one of the phrases we’ve been using recently is, hybrid is not a trend; it’s reality. You know, for most organizations that haven’t get gone all in cloud, which is the vast majority of organizations, hybrid is, for the foreseeable future, going to be a reality. And the reality is that even as they increasingly are delivering applications to be consumed as a service, you know the database that’s running that requires some of the capabilities to deliver that, things like elasticity. You know, it may actually be running on-premises in a more traditional architecture. So you know, one of the key factors here in terms of choosing a database for your future application requirements is to have that flexibility, and the capability to move through these phases of adoption.
In addition to that, you know, if we think about the requirement drivers for databases for cloud applications, obviously the application itself is critical, and some of the capabilities in relation to the application, but we also talk about the developer requirements and the architecture. So to go through each of those in turn, if we think about from an application perspective, you know, I’m not going to go through each of these things individually, but clearly there’s a trend in general towards global, local, mobile, social applications, essentially an increased level of interactivity which places additional demands on the application that, you know, haven’t been the case for more traditional applications delivered, more of a kind of client server architecture.
Additionally, depending on the application, a lot of if not most of the adoption and access is going to be through mobile devices. Again, that just places different demands on the application and the database that is required to support it.
Turning to, you know, developer requirements, again, there’s multiple aspects (inaudible). Clearly, you know, we talked about the requirement for additional flexibility. Clearly agile development is a significant trend that we see; it’s shaping organizations. Choice, particularly in terms of their databases and their data platforms. You know a lot of access is driven now by APIs and REST, and then, you know, depending on the nature of the application itself, you know, Schemaless could be important. You know, clearly we do see an increase in NoSQL database usage, but you know, in addition to that, you know, SQL is not going anywhere; it hasn’t gone anywhere. It’s, in fact, increasingly important in terms of, you know, means of accessing data, and a means of querying data; in fact, we even see that, obviously some of the NoSQL database vendors adding support for SQL, because, you know, organizations want to retain their existing tools or existing skills. And so SQL support continuing to be important.
Then, you know, from an architecture standpoint as well, you know, we already talked about the importance of, you know, distributed architecture, elasticity, scalability. Obviously, you know, in recent years, there’s been a big shift towards virtual environments, and then a more recent trend, you know, towards containerization. So those architecture changes, plus, you know, the developer requirements, plus the application requirements, you know, you put those all together and you start to really have to think seriously about the limitations of traditional relational databases.
You know, as we said, enterprise architectures have shifted from a scale-up to a scale-out approach to make use of distributed hardware. There’s greater scalability demands on the database layer than there’s ever been before. And, you know, there’s issues in terms of delivering predictable performance, as you scale.
You know, we look at traditional relational databases. They simply were never designed to cope with some of the modern application requirements, things like geographic distribution, proliferation of cloud, the support for multiple data types. And you know, all-in-all, what we see is that modern application requirements essentially require a rethink of the relational database model.
Which isn’t to say, you know, you’re actually requiring to think beyond relational and throw away the investment in relational, but it’s about thinking differently about the database products that are available, and whether they can deliver you the combination of the benefits of the relational model plus support for some of these new applications and architecture requirements.
So if we think about, you know, the key database criteria for cloud applications, there are actually many, and multiple. So we’ve actually got them in two chunks here. So we start with scalability, dynamic, resilient, and simplicity. You know, scalability, the ability to scale-out across low-cost distributed commodity architecture, we’ve already talked about that. Dynamic: the ability to provision rapidly, and scale up and down in response to changing requirements. Resilient: you know, always available. And not just available, but available in an active form in multiple locations and multiple regions in order to deliver that global availability that we talked about earlier from an application perspective. And simplicity, you know despite all this additional functionality that you want, obviously what database administrators still want is simplicity rather than complexity, for that database to be easily monitored and managed and integrated with existing applications and services.
Beyond that, you know, we see hybrid, performant, secure, and predictable as also key database criteria. Hybrid, you know, we’ve already talked about hybrid cloud, but also hybrid in the sense of, you know, we see an increasing demand from organization to analyze data in the operational database, not as a replacement for an analytic specialist, analytic database, or a data warehouse, but you know, as a quicker way of getting at value from that data, as it is produced by the application. So we – you know, people talk about HTAP and those various (inaudible). We talk about combined operational and analytic processing.
From a performance perspective, you know whatever your database requirements, performance never goes away, the ability to support high performance workloads as required. Obviously, some applications require greater levels of performance than others, but performance is always going to be a key consideration for any organization when selecting a database.
So too security, clearly never goes away, and obviously in relation to cloud applications, you know, arguably, actually, more so top of mind, and we certainly see that amongst organizations when looking at cloud providers and architecture, security is always one of the top two or three things they have in mind, the ability to support existing security and access technologies and standards is absolutely paramount.
And then obviously, the last one is predictable. Again, this covers a couple of things, so we talked already about, you know, the ability to support existing skills and tools for organizations to bring their existing people and their skills to those databases, so for example, support for SQL. And then, in terms of predictability as well, you know, consistency is clearly a significant issue. I haven’t talked specifically here about ACID properties of databases, but clearly, consistency is an overall requirement. That might be tunable, you know, in some cases, depending on the application, that consistency might be eventual. But you know, there is an absolutely requirement for the database to deliver a level of consistency.
So just to sum up then, in terms of core conclusions, and you know, the landscape as we see it, as we said, the growing adoption of databases on the cloud, and DBaaS is something we do see, but you know, hybrid is not a trend; it’s a reality, and as we’ve said, in terms of thinking about databases to support SaaS applications, it isn’t simply a matter of, you know, choosing a database on the cloud, or DBaaS. There are other options in terms of an on-premises database with the architectural capabilities to support SaaS delivery.
As we’ve said, we’ve talked about some of the key requirements and the conclusion that we’re seeing, you know, a lot of our clients reach the traditional relational databases are not fit for purpose in terms of supporting a lot of their SaaS application requirements, because they simply, you know, weren’t designed to cope with those modern application needs.
As was said, you know, SaaS and cloud applications require a database that’s able to take advantage of, and also enable that elastic distributed architecture. And I think, you know, that’s a key issue here. We’re not just talking about the ability to run in a cloud environment. We’re talking about the ability to deliver the kind of elasticity and distributed nature that organizations require for the SaaS applications.
But of course, as we said, you know, things never go away, (inaudible) they also need to deliver the performance, resiliency, security, and some of the core functionality that’s been expected of traditional, particularly relational databases, you know, over the past 30, 40 years.
So, with that, thank you for your time. I’ve got my contact details here if you wish to contact us to find out more about 451 Research. Obviously, would also encourage any questions, to submit those, and we’ll get to those a little bit later on, but for now, I’ll hand you back to Ariff.
(Ariff Kassam): Thank you, Matt. So, Matt went through some of the core capabilities that he was talking about and seeing through his research. I’m going to just summarize a little bit from what we’re seeing at NuoDB when talking to customers. As Matt mentioned, customers are asking for the ability to do database cloud applications, have a database for the cloud, and customers are saying, they want elasticity. When we hear elasticity, it’s sort of conflated with a bunch of specific features, which is, be able to run on commodity hardware across virtual or nonvirtual environments across a distributed platform; the ability to scale in and scale out on demand. The ability to have the system fully available all the time through upgrades, through outages, single-server outages, etc., data center outages, so continuous availability.
And for applications, specifically, that are sort of suited towards the SQL side, they don’t want to lose SQL. They don’t want to lose the ACID consistency model that they’re used to. They want to have the ability to leverage the existing code, and leverage the existing tools that have been built up around their application, and not have to retrain their people, or retrain, or rewrite the code. And then also, the ability to have a database system that manages their data as expected, rather than putting a lot of that data management logic into the application, which makes the application a lot more complicated. So customers are asking this basically, that they want to be able to scale their SQL database to the cloud.
And some of the benefits that customers are finding by going to the cloud to an elastic SQL database, sort of grouped into four topics. One is like, customer satisfaction, again, the ability to make sure that the DBaaS and the application that it’s serving is also up; there’s no downtime. Again, consistent performance, when they need it, on demand. And again the automation of making it simple to use, including automated disaster recovery failover.
Customers are also looking to time-to-market. They have existing applications that they’ve been either running on-premises at customer sites and they want to provide a SaaS solution, so they want to reuse as much of the application that exists today using the SQL layer that exists, and trusting the data management layer to do the management that it was built to do. So making it faster for people to migrate off of on-premises to a SaaS model.
The agility is critical, right? People go to the cloud specifically for agility, the ability to dynamically add and remove servers on demand, deploy across a hybrid environment, or fully on-premises on a private cloud or in a public cloud, or across both. And again, being able to have a SQL layer that allows them to have faster modifications to applications.
And then finally, customers are looking for total cost of ownership, the ability to reduce their licensing costs, increase their server utilization to match their demand, reuse existing skills and toolsets that already live in the enterprise, and then be able to provision on-demand without having to sort of certify large systems upfront.
And so, with that, obviously NuoDB provides a single server database scale-out option for managing the databases. We were founded in 2010. The management team are database pioneers. There’s a lot of database expertise within NuoDB. We have several patents around elastic SQL database and leading SaaS providers are running their solutions either in public clouds or private clouds on NuoDB. We’re headquartered here in Cambridge, Massachusetts. And here’s a few customers that are leveraging our application.
So, what makes NuoDB different? As Matt pointed out earlier, you need a database that was built for the cloud. And when you build a database for the cloud, you need to be distributed by design. You don’t start with an existing client-server database application, put it into a cloud environment and try to add scale or add distribution to it through either sharding or through replication, or through potentially a shared-disk type of model like some database companies provide. So you don’t start with an existing database and host it and put it on the cloud and then try to make it scalable. You start with a database that was built for distributed systems. That is a peer-to-peer environment that scales across nodes, across different types of servers, across locations. But it is still a single logical database that can scale elastically.
The second key idea is a separation of duty, right? We’re finding this more and more in the computing space where you have the separation of processing and storage. And so with NuoDB, we’ve got two layers, two different types of processing that we provide that can be scaled independently. We have our transaction engines, which basically is supporting transactions in memory with an existing working data set. There’s no explicit sharding; there’s no explicit partitioning, automatically by the workload that they sent to the TEs, dynamically partition the data into the working data set that they use, so it stays in memory.
The scale and throughput is dynamic by adding additional TEs, allows customers and clients to scale their application workload. All this, all these features from an application perspective in transparent, right? The application is unaware of the number of TEs or the vocality of the TEs that they are talking to.
The second part of the architecture is the storage. Right, obviously a database needs to be durable, right, and so we can allow the processing of durability separate from the actual processing of the transactions, and you can have a tunable consistency model here by either making it synchronous or asynchronous in terms of how the data is stored, and it can be specified by region. You can have synchronous locally and asynchronous remotely.
So what this does provide is a single logical database that allows multiple processes to be used in different combinations and permutations depending on your workload. For read and transaction-heavy workloads, you can scale out the transaction engines. For write-intensive workloads, you can scale out the storage managers. Any one process, failure of any processes has no effect on the application. They survived both failures, and you can also allocate different server types based on the type of processing you need. You can have memory-heavy transaction engines, or disk-heavy storage managers. You can mix-and-match; we don’t really care the type of servers that you use, and leverage commodity or specialized hardware.
So in practice, this – it’s a little busy diagram, I apologize, but in practice, this is sort of showing you applications may connect up to the various systems. The green dotted dash box represents the TEs and SMs that are in a peer-to-peer network; they’re talking together. The applications are either connected to one or more TEs, and in this case, if the TE fails or goes away, whether that was in a transient virtual container that went away, the application simply redirects its queries to a surviving TE and continues on with its transactions. And the plus signs of the right of the Xs are indications that you can dynamically add additional nodes, whether that’s the TEs or storage managers, and the applications can dynamically scale in any manner as well. So we support fully-redundant, elastically-scalable, continuously available and active/active across single data centers, or multiple data centers, multiple availability zones.
So here’s some typical deployment scenarios that we see with customers. Customers typically start out with what we call a fully-redundant single data center environment where they’ve got a 2x2, two TEs and two SMs for full redundancy and processing. We also have the ability to add additional SMs; in this case, the middle image is with the snapshot manager to account for logical errors, so be able to take snapshots and reverse snapshots automatically for logical errors or fat-finger errors. And then obviously scale-out. So customers then, once they’re comfortable with the deployment that they have, and the application is meeting their SLAs, and as the application SLAs, or application workload grows, you can scale out the different engines, whether those are TEs or SMs, dynamically as needed.
From a multi-data center approach, we also support obviously disaster recovery, so the disaster recovery could be a hot standby, depending on your usage. So there’s a primary site where all the applications are being driven, and then you have a disaster recovery that’s what we call “hot standby,” ready for processing as soon as the applications switch over. So there’s no recovery time; there’s no outages, once the application switches over to the DR site.
We also do support active-active, so the ability to run applications across multiple locations, in this case, across multiple availability zones, or low-latency, or limited latency regions that are in close proximity, and we are scaling out to multiple regions, so to two or more regions that are separated out with longer latency links for larger regional distribution of data centers.
So, in general, how we position NuoDB across the landscape of your options for cloud deployments, you have the SQL layer, so the consistency, the durability, recoverability, obviously the traditional databases score very highly on that axis, and then as you move out to the cloud, and NewSQL, or NoSQL, the SQL capabilities decrease as you move across there. And then, on the elasticity side, which includes simplicity, continuous availability, and scalability, the traditional databases score low on that, obviously because they weren’t built for them, as you move out to the right, the new types of databases scale much better from an elastic perspective.
We position ourselves high both in the SQL category as well as high in the elastic category. Obviously, we’re fully ACID; we support all the SQL semantics, and provide full elastic capabilities across multiple distributed compute environments, locally or remotely.
Shown here is also a quote from one of our customers, Kodiak Networks. In this case, they selected NuoDB because of the choice of supporting scale for their transactional application that they had, and that they needed.
So in summary, NuoDB provides an elastic SQL database; it is, in our belief, the only database that allows scaling out to the cloud for your SQL applications. You don’t lose the benefits of a SQL or relational database by moving to the cloud. It also provides continuous availability with disaster recovery, allows you to concentrate on your business, reduce your costs, improve your customer experience, and get faster to market by moving to the cloud as quick as possible.
That is the presentation, so both presentations, we’ve got 15 minutes or as much time as we want for questions and answers, so you have questions, please go to the “questions” box in the webinar and add any questions that you may have to that, and we will answer them as we see them.
So, Matt, I think there’s a question for you here. When should customers consider using NoSQL versus a database built for – a distributed RDMS database for the cloud, also known as sort of the New SQL systems?
(Matt Aslett): Sure. I mean, obviously, there’s multiple kind of reasons for going NoSQL, or New SQL. Sometimes it may come down to the data format, obviously depends on what you’re trying to achieve in terms of, you know a particular requirement may take you towards, say for example, a graph database, or very simplistic requirement of a key value store. Ultimately though, I think what we see organizations looking at is, you know, unless they’ve got a very specific requirement that takes them in a specific direction, or a higher level, it’s really about, you know, the consistency requirements. I mean, you know, I’ve touched on consistency. You talked specifically about, you know, ACID requirements. Clearly, if the requirement is ACID, then you’re looking at a relational database; obviously if you’re looking at the distributed, you’re looking towards what we would call a New SQL database. Yeah, so I mean they run multiple drivers. Actually, we’re just in the midst of publishing a report about this, kind of the way you should think about the choices that you have for different database application requirements, and we’re looking at least seven in terms of that. But I think consistency and ACID consistency is one of the primary ones, in terms of that choice.
(Ariff Kassam): Excellent. Thanks, Matt. So, here’s another question here: does NuoDB support distributed transactions? So, just to be sort of clear, NuoDB is a single logical database. So, even though it is a distributed engine by nature, from an application perspective, it’s a single logical entity, so the application doesn’t really need to worry about distribution transactions across the different nodes. We have within our environment the ability to understand the data cache, and the existing state of the database, the consistent state of the database. It is an MBCC database, so we have multi-version concurrency control. So, there isn’t really a huge – there isn’t a need to support distribution transactions because it’s a consistent model across all the engines. I hope that answers the question.
I’m just looking through this here, the rest of the questions here. Is there a possibility to use NuoDB as a managed service? Are there any providers like AWS? So that’s a great question. Today, there isn’t any managed service providers providing NuoDB as a service. You can run NuoDB in AWS; some of our customers are running it in AWS, but there is no – currently, there is no -as-a-service option.
So there’s another question here. How many active geographical regions can you have where the inter-region connections are slow? So, because we’re a consistent database, a fully-logical consistent database, and we can’t break the speed of light barriers, having low-bandwidth, or long-latency links between your regions will impact how fast the consistency information is shared across the environment. And if your durability requirements in strict in that the data needs to be durable across multiple regions, then by nature, you will pay the penalty that the applications will pay the latency penalty. So what we provide with NuoDB is a tradeoff. You have to decide what your tradeoff is, whether that’s durability across multiple regions for the data, or performance in terms of latency for those transactions.
Just looking through the rest of the questions. Does NuoDB have encryption as part of its engine? Yes we do, so all the data is encrypted at the network layer. We do not encrypt on disk, but that can be solved by third-party encryption engines as the disk layer.
So lots of questions, just trying to make sure I get to some of these. So another security question. What’s the security on NuoDB? Again, it’s standard database, so we’ve got access controls on users, the data, the network data is encrypted, but as I mentioned, we don’t encrypt on-disk.
There’s a question about the recording. We will provide information about the recorded webinar to all registered participants.
There’s a question here about how hard is it to migrate SQL applications from SQL Server Oracle to NuoDB. So as we are building out our SQL layer compatibility, so we support NewSQL today. Obviously, each database vendor has its own proprietary extensions. We are actively migrating a number of SQL server instances to NuoDB, and it’s becoming easier and easier over time with those migrations as we sort of fill out our compatibility feature set across those different databases.
Going through here. Matt, here’s a question for you: are customers looking to use cloud as an augmentation to on-premises resources, or for existing applications, or for new applications:
(Matt Aslett): Yeah, I mean primarily, we see it’s driven by new applications. I mean, you can and will find obviously examples of customers that are migrating existing applications across to different databases running the cloud. You know, what we see is just traditionally, people don’t change their database, unless they’ve got a really, really good reason to do so. What they do is they select a new database, new applications, and they develop those applications and they then, at some point retire the old applications and the database that goes with it. So that’s what we see predominantly going on, absolutely.
(Ariff Kassam): And I think this question also could be answered by you, and maybe it’s a combination here, right. Do we feel that rolling back software upgrades is easier in the cloud now? So I don’t know if you have a view on that, Matt?
(Matt Aslett): Yeah, well, I think theoretically, I think, you know, the devil’s in the details, isn’t it? But yes, I mean, theoretically there could be some advantages to that. I think it depends on precisely what software you’re using, and the functionality that’s available. But certainly, in some products such as we’ve seen, there is that advantage.
(Ariff Kassam): Yeah, and from a NuoDB perspective, rolling upgrades and rolling downgrades are critical to us. So we support the ability to take a particular node offline, upgrade it to the next version, bring it online, and do that across the different topology, and obviously, the rollback is the same model, right? You can roll back different parts of the environment over time so you’re not stuck having to take an outage.
There’s a question here about pricing. Is NuoDB for free? We have a community edition that is available for free for download off our website. The non-community edition, the enterprise edition, is a licensed model.
There’s a question about interfaces. So does NuoDB provide a programmatic database interface? What languages does it support? So obviously, we have a standard JDBC ODBC interface. We have had – so we do have other interfaces that are sort of community-led, Python, and others. There is a GitHub page that has some of those drivers available for use.
There’s a question here, I’m not trying to interpret it, but the question is, where is the data stored? Is it in the US data centers? So we provide a solution that customers deploy, whether they deploy it on their own data centers located in the US or internationally, or they deploy it against a cloud provider, whether that’s AWS, or somewhere else. So NuoDB is not hosting the DBaaS. We are providing a software solution to enable a DBaaS, or to enable SaaS for your applications.
Lots of questions. If you have anymore, please, again, just submit them to the questions and answer box. I’m just going through making sure we’ve covered most of them, or all of them. So here’s another one, sort of similar to the cloud question here. What cloud environments does NuoDB support? So today, we have support for AWS, as well as private cloud environments. We are looking to support Azure and Google cloud environments in the future.
Here’s another question here: does NuoDB support hybrid deployments that span both on-premise and cloud environments? Yeah, so again, because NuoDB can span multiple availability zones or data centers, you can have NuoDB running on-premises, with any cloud provider that’s fairly close by in proximity that has some of your nodes so you can have outages either in your data center or the cloud and still survive that from your application perspective. So that’s sort of what we call, it’s a different type of hybrid model, which spans multiple data centers or multiple environments, and we do support that.
I think that’s most of the questions. If you have any other questions, please feel free to ask that in the Q&A box. There’s a question here, does this make us more trigger-happy with upgrades? Again, I think this depends on your application and your upgrade cycles for the application. Obviously, for SaaS, one of the biggest benefits of SaaS is the ability to do the upgrade in place, and the customers don’t know that the upgrade is actually happening, or really care that the application is happening. So again, depending on your application level deployment models, and how you schedule those, I think you’re moving toward sort of the whole dev ops model where with every build, you’re pushing to production, right? So we know people who are doing that every two weeks. Obviously, Amazon does that very regularly as well. So again, I think it depends on your application, how it’s been built, and how you’re deploying your application.
So I think we’ll take one more question here. Is cross-region supported today on the road map? So a cross-region, as I sort of showed in my slides, is something that we’re working to, and we’ll have, our plan is to have something shortly. I can’t commit to it right now, but cross-region, or long-latency, and in other words, long-latency distributed data centers is something that we are actively working towards.
So, I think that’s all the time we have for questions today. On behalf of myself and Matt, I’d like to thank you for attending today’s webinar, and hope to see you on another webinar soon. Thank you, and have a great day.