You are here

WEBINAR: Choosing the Best Database for Your Cloud Application

Guest speaker, Forrester Principal Analyst Noel Yuhanna, discusses how to determine which type of database is most suitable for your cloud application. 

Slides available here

Video transcript: 

Lorita Ba:  Hello, everyone, and welcome to our webinar, “Choosing the Best database for Your Cloud Application.” My name is Lorita Ba. I’m from NuoDB, and I will be the moderator for today’s webinar. You’ll notice that there is a quick poll that is now on your screen. For those of you that’ve been on for a few minutes, this is a second question. So if you can just take a few minutes to go ahead and answer that while I introduce our speakers for today’s webinar.

I’m joined by Noel Yuhanna, Principal Analyst at Forrester. Noel, thanks for joining us. And Ariff Kassam, VP of Products at NuoDB. Hi, Ariff.

Today, we’re talking about how to select the right database for your cloud application. First, we’ll turn to Noel, who will give us an industry view of the database landscape, the database requirements cloud applications need to consider, and recommendations for choosing the right database for your application.

From there, Ariff will dive into some of the technical requirements to help narrow your selection, the tradeoffs people have had to make with existing systems, and introduce NuoDB’s elastic SQL database. At the end, we’ll open it up for some Q&A.

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, and attendees will be muted during the call. There is a questions panel in the GoToWebinar control panel. So, we please encourage you to go ahead and submit your questions there throughout the presentation, and we’ll address them at the end.

And so, with that, I’m going to go ahead and close the poll, and we’ll go ahead and begin. Noel, I’ll turn it over to you.

Noel Yuhanna:  All right. Thanks a lot. Thanks a lot for having me on this webinar, “Choosing the Best Database for Your Cloud Applications.” It’s a very, very interesting topic, actually. As a Forrester analyst, I get to speak to many customers. These are midsize companies, these are large companies, from the banks and insurance companies, retailers, healthcare, manufacturing, ecommerce, you name it, across the globe. And, you know, people are building these new generation of applications today. That requires different mindset when it comes to data storage, data processing. Even databases, right? That’s what this talk is all about. How do you build a strategy for the next several years so that it can be successful in these new generation of applications you’re building?

So I’m going to share you some of the things we have learned as a result of these conversations we’ve been having with customers. And where do you see this trend going, you know? Right? I mean, because we have so many different types of databases today, actually. It could be very confusing, right? I mean, I’ve been doing databases for more than 25 years, and it’s interesting how things evolved over the last few years alone, let alone, right? I mean, we’ve got more choices than ever before today. And because so many different products, whether it’s on premise, whether it’s in the Cloud, and what-have-you. Okay, next slide.

So, what’s interesting is, from the trend perspective, we definitely see the database market to be about 27 billion dollars, which includes software support and consulting services. And this is growing about 12 percent annually. Now, what’s interesting is cloud databases is already 25 percent adoption across enterprises, you know, 25 percent. And this is going to be doubling in 2020, within the next three years.

Now, what’s interesting is there’s a huge growth around Cloud databases, just because it makes it a lot appealing to create these new databases from on-the-fly, it’s got all this good scale, performance, lower cost. So, I think, you know, we’re going to see, in fact, more than double in the next three years. So, that means there’s a lot of potential out there. And I think we get almost a few inquiries on these cloud databases already every week.

And, as I mentioned, the number of inquiries have been growing as well. Organizations are looking for scalable, high-available databases for next generation as we know it. Automation is a big thing, you know, right? I mean, everyone wants automation. You know, there was interesting conversation to have with this company. We’ve got 65,000 databases. These are not small databases, but these are enterprise-class relational databases. And, you know, the bigger problem is that, how do you manage those 65,000 databases, especially if you want to actually grow by 10,000 in the next, you know, five years?

It’s a challenge. And so, I think the automation is going to be crucial. You want to minimize tuning. Remember 10 years ago, we spent 60 percent of our time tuning our databases? And many people still spend a lot of time tuning, doing upgrades, doing scale requirements. Capacity planning. I mean, remember five, 10 years ago, we used to build an application with capacity planning requirements, okay. This is going to require 16 CPUs, or cores, and maybe eight gigabytes memory.

Today, you don’t have a clue, because these applications can scale very well, quickly. The application could really explode into millions of users overnight, right? So, you need, actually, a platform which is more scalable from a high-end perspective. You don’t know what the scale requirement would be, actually. That’s interesting, you know.

Organization of building dozen of new applications every month. Remember, again, we used to build ER, eCRM applications once a year. Now we’re building a dozen of these applications every month. You need, actually, a platform that is not only scalable, it’s agile, but also it’s highly automated, simplified, as well, right? So, the time to value becomes very, very critical.

So, the requirements, I guess, you know, have changed a lot over the last five years alone. And I’m sure you are seeing this in your organization, as well. Next slide.

Now, now, if you look at the Forrester Database market landscape, you know, this obviously includes relational databases, NoSQL environments. You got data warehouses. Now, what’s interesting is, in the green boxes, you will see where most of the adoption has been growing more recently. We’ll have in-memory databases have been growing significantly.

Definitely, there’s more demand for moving into memory, because memory’s faster, right? It’s like, no, 10 times to 1000 times faster than traditional disk drive. And also, it can scale very well for these larger requirements to applications. You can also run some of these databases completely in memory, which is really good to have.

Now, what we believe is going to happen is we’re going to be heading into petabytes memory deployments in the coming years. Your iPhone, your Android phone, is going to have a terabyte, soon. Think about it, right? So, we’re going to petabyte scale in memory computing in the coming years. So, it’s definitely in-memory database is going to be a big thing in the coming years. You should definitely be putting plans together for in-memory databases.

Scale-out relational is something new area of venture, where we are starting to see -- traditionally, we’ve only had relational databases on a single server, but what could if we run across multiple nodes in a cluster, in a scale-out configuration yet also maintaining asset compliance, right? Data integrity, performance and scale, and availability along with that. So, this is an area which we’re going to see a lot more growth happening in the coming years.

Obviously, NoSQL document databases have seen growth over the last few years. But document databases have been generating a lot of adoption, especially in insurance companies and some of the healthcare insurance companies as well. So, this is going to be a big thing going forward, as well.

Cloud and hybrid databases are going to be, again, the future. While we are seeing 25 percent adoption, as I mention, cloud is obviously a big thing. But yet hybrid is also important, right? People are going to be running on-premise and cloud, not just cloud alone. But you got to have a combination of hybrid environments, as well. Next slide.

So, how do you see, for operational databases more specifically, there are three types of operational databases we see today in the industry, right? I mean, we got relational databases, which have been doing operational for many years. And we got NoSQL category, which can also do operational requirements. And then, we got this whole mix of open-source databases, which could also support relational open-source and also NoSQL open-source platforms. Well, because some of them are commercial, some of them are open-source. Yet I think there are more open-source NoSQL databases versus relational being open-source, yet we do see a mix of these, you know. So, there are three types of these operational databases, which has got the most adoption right now. Next slide.

We got a poll. In fact, this is the poll which you guys actually responded to earlier on. And the question came up was, have you deployed a cloud database, right? And if you see the results, 47 percent said no, but we plan in the next 12 months. Whoa, 47 percent. And very, very interesting, I guess, you know.

And then we got the 29 percent had no, we don’t have immediate plans, I’m sure we’re going to have that plans change over the course of this year due to competitive pressure. And then this 18 percent said yes, we have both managed cell services databases, and I think 6 percent said yes, databases, we manage them as well. So, that’s really a combination of results, there, but the good thing is that lot of people are focusing onto cloud databases for deployments, which I think should be part of your strategy. Okay, next slide.

So, what are the pros and cons of the operational databases which we are talking about, those three things, the relational, NoSQL, and open-source databases? Well, if you look at it, relationals have very good, strong ACID compliance, transactional capabilities, SQL support. SQL support is still a very strong element for application development and data access, as you can tell. Adoption has been strong with relational. The tooling is very strong with the relational. Yet it lacks scale-out architecture. Right? I mean, unless you are the new generation of relational databases, traditional databases don’t really have a scale-up architecture. They’re always contained in a single server. You can always scale up to adding more CPU power, but their CPU power becomes more expensive. Scale-out becomes more or less expensive in most modern computing era.

High-end performance scale is obviously a challenge, unless you don’t go scale-out. Which is why NoSQL actually became important for customers to venture out to. Expensive. Most of these relational databases are commercial databases, not really open-source.

Now, if you look at open-source databases, which are a few of those like MySQL, all right, which is a common relational databases -- they are, obviously, lower-cost. They got an ecosystem around this. You got a community behind that. But again, they have some issues around high-end scale and performance. Not cloud-enabled. I mean, these are not really built for the cloud, right? I mean, they have a challenge itself. Slow in new features. You know? I mean, you don’t see them rolling out these new features, advanced features, or driving, really, the bigger innovation across the board. This is obviously a bigger struggle, because the timeline is good, the community is great, but guess what, it is a bit slower in adopting these newer generational things that people need.

NoSQL, on the other hand, has got a scalable-sharded kind of model, which can have documents, it can have graph. It is also have different sharding availability requirements and deliverables. But downside is, you know, not all of these NoSQL databases deliver ACID compliance. In fact, they can only -- like documents --  only deliver ACID compliance for a document, not across documents. So they have some issues. It can scale out, though, right? But yet, it doesn’t have a compliance of ACID compliance across documents and transactional support.

It’s got some basic SQL support. Even though they were NoSQL, they have now support for SQL. Which I think is good, because SQL definitely is an important element for customers for access information. And easy to learn, right, as well. Lacks broader-use cases. You know, they have, obviously, graph databases. You got key value store, and you got document databases, and in these are very specific needs. And they are specialized databases for specific needs, which is good and bad. Good is if you have the requirement for specialized databases, these are good, but then, if you don’t, then, well, sometimes these databases don’t serve the purpose for the other use cases that you’re trying to address. Next slide.

So, what are the new applications demanding, right? I mean, you got these social networking applications, like LinkedIn and Facebook’s have, right, and Twitter, and all these applications. And they have to scale. They have to provide a very good platform to scale, because you may have recommendation engines going on behind the scenes. You may be recommending friends and additional events and other things going on. So, definitely, you need actually a very connected database, I guess, you know, which can scale. And you should be able to scale, even horizontally, even better. Right? And not necessarily just a scale-up model. A scale-up model, in fact, may not even work, actually. Because just adding horsepower alone may not be able to serve that need. A scale-up architecture actually helps you drive a better strategy.

Mobile applications, obviously, is gaining a lot of ground. We see, obviously, iOS and Android applications driving many, many different types of new requirements. As I mentioned, people are building a dozen new applications every month in the enterprise. And that’s changing, because of these mobile devices are quicker to deploy, as well.

SaaS applications, right, building from vendors who are rolling out these new types of cloud applications. They want to have a database platform that is more agile but also highly automated, can deal with unstructured data, can deal with faster, real-time access of information, as well.

Then you got other categories of applications. High-performance application, that real-time data mashup, departmental collaborations, and on and on and on. So, I mean, you see this new requirements of these applications, and these are changing the way the data is going to be stored and processed all the time.

So, when we speak to banks, insurance companies, who are building these new applications, or retailers, I mean, they’re demanding a database that can not only deliver an agile platform, but also scale. Ideally, scale up horizontally, deliver more value right away. Just keep on adding additional nodes in the cluster, right? That’s what they want to do. And these clusters are, obviously, low-cost cluster of servers you’re trying to put in the cluster, yet have a lot of value out there as well, right? Can deliver a high availability and disaster recovery and all that good stuff. So, all of these requirements are obviously new things, which companies are looking for. Next slide.

Okay, we got the second poll results. “What is your top requirement for a cloud database?” So, when do you a cloud database, what is your top requirement? Forty-four percent said elastic scale out and in. So, definitely, elastic scale is a very, a very important element, right? I think people want database that can scale, actually, without the needed man or resources from the people, but also on-demand based on the application. It may be able to scale up, scale down, right, depending on what the requirement would be. There could be an application that needs a million users to be supported because it’s a holiday shopping season, right? And your application should be able to scale automatically, right? That’s the whole idea behind these cloud databases.

Obviously, 31 percent said highly continuous availability, active, active. You know, availability is a very, very important scenario. You know, the fact that everyone wants the five-nine environment. So, definitely is a critical component. We hear that all the time. We can’t afford to go down -- in fact, based on certain research we have done, no, a one-minute downtime could actually cost $10,000 dollars for a company. In fact, in certain large organizations, would be even $100,000 or more for a minute. Forget about the 5 to 10 hours. So, definitely, it can cost a lot, you know?

And also, customer loyalty an issue, right? And customer may think, “Well, if the system goes down all the time, we are probably going to move on to another environment, or another company or a vendor.”

Okay, and then we’re at a 90-percent hybrid cloud deployments, is another one that you see as a requirement, which is, I think, it’s important. Not just a cloud alone. You want to have a hybrid model, which I think is very important. You want to have the balance of the two. Some people want the hybrid because of security reasons. They don’t want to move data all completely in the cloud, because they’re not going to be -- they feel not really as secure that the data is not going to be as much secure as on-premise. We got all credit-card data, we got all this PII, PHI data, which we can’t really move. Yeah, so you want to have a hybrid model so that we can use the hybrid resources, the cloud resources, on-demand to scale these applications as well, right? All right, next slide.

So, cloud databases are viable as we know it, right, I mean, for different types of things going on, whether there’s elastic scale as we know it. Elastic scale, actually, is the big one, I guess, based on the poll, which is why people actually use cloud databases. Definitely the need for scale-up, scale-down, as much is automatically being done, being able to provision, lower-cost, better availability, backup recovery. Even security could be good, maybe, obviously you got to be cautious about it. You know, you don’t have to just dump data into the cloud and be happy with it. Oh, no, you want to, obviously, protect the data. You want to make sure you got encryption enabled on the network. You got encryption at the destination, at rest, as well. So, you want to make sure that, if you’re going to put data in the cloud, make sure you got security, encryption, auditing, monitoring, available as well.

And you get updates right away. In fact, all of these database vendors are trying to move toward the cloud-first model. Now, by the way, cloud databases are not exactly the same as databases in service environments. Right? If cloud databases are different, (inaudible) that maybe optimized for the cloud environments, right, it could be -- certainly managed cloud. You can have, you know, self-managed or even private clouds, public cloud environments.

But database services is more like multitenancy, where you want to slice the database and give it to an application, to a user or consumer as well. So, that’s how you look at it from a cloud adoption. But the good thing is that all of the new features of the databases can get deployed very, very quickly. You don’t have to have a CD being burnt every six months or a year, coming down your doorstep, trying to install it. Well, the cloud is already enabled, right there, which gives you an update of these features in minutes, right? And they’re rolling out every month new features, which is really cool to have, I guess, as well. Okay, next slide.

So, cloud offers many use cases. So, based on customers, you know, what do we see out there -- having mobile applications, as I mentioned, ecommerce applications, which are completely in the public cloud using cloud databases, and analytics and predictive analytics in the cloud, social media, data services, departmental line of businesses. I mean, you know, it’s got a lot of variation of different types of application you can build and use-cases.

Customer churn, 360-degree view of the customer, are critical components of these offering, as well. You can build these new types of applications right away. Certainly, definitely, a lot of potential out there from a deployment perspective.

But we definitely see, you know, all kinds of applications being moved. You can also move existing applications to the cloud, because a lot of these cloud databases are SQL-enabled, which is a very critical component of movement, because they help you migrate these databases onto an elastic platform in a very effective sense. You don’t have to reengineer your database -- or the application from scratch. Yet you can help it do the migration a lot simpler. So, definitely, the cloud databases offer many choices.

And I think the good thing is the potential is huge, right? I mean, especially when you have these tier-one applications that demands a lot of horsepower and storage requirements. Imagine you’re building those 50-, 100-terabyte transactional, operational systems. You’d need those -- not only storage, for backup and recovery, and disaster recovery, and test and dev environments. But yet, you also want to make it more scalable. Which is why cloud offers you a lot of these potential as well. Next slide.

So, what to look for in the cloud? You know, if you are -- and I know we saw that -- like 30 to 40 percent people are looking at the cloud in the next 12 months. So what are you going to be looking for in a cloud database, right? Well, you need to have a scalable and a distributed platform in the cloud. What it means, it should be not just cloud that, “Hey, I got cloud databases, and we’re good with that.” You got to look at how scalable are these databases in the cloud? Right? Are they scale-up, scale-out? How quickly can they scale out, as well, right? Because you may be scaling from 10 terabytes to 1000 terabytes, or what you do call -- petabytes. And then we have 10 users to a million users, as well, coming, based on these applications. How quickly can the scale to deliver more value?

What about asset compliance and data consistency as well, right? Some of these databases may not have ACID compliance, which is an important element, especially in these critical applications, like in banks, insurance companies, retailers. The fact is, it may apply to every industry where you want consistent data. You want not only trusted data, consistent data, but also data that actually can be able to meet all of these new use cases you are delivering, whether there’s customer insurance, customer 360 fraud detection applications and all the good stuff. Support operational transactional requirements together. I mean, we are seeing a big trend where the separation of these two, which have been there for decades, isn’t being there in the future because they’re going to be converging, the operational and transactional requirements. Because applications should be able to support both, technically.

Highly automated, with minimal zero time; full access to SQL; comprehensive security built in; subscription model; geodistributed backup and discovery -- I mean disaster recovery scenarios; so, I mean, all of these requirements are very, very critical. So, I definitely encourage you guys to look into those things as you start to build a cloud database requirements. Okay, next slide.

So, one of the recommendations, I guess, we have is to look beyond traditional databases for cloud. I mean, you could use traditional databases for the cloud, but the problem, I think, would be, would they be able to scale, right, to your demands? If you have very small applications, well, it may work fine. But if you have a very complex, large environments, which needs to be more on-demand, right, because you don’t know the requirements, definitely look for databases that can do high-end scale and definitely deliver more value right away. Consistency, integrity, is also important for supporting the trusted data, right? I mean, you want to be able to have trusted data.

Some other scale-out architectures may not deliver -- what do you call, eventually consistent model may not have trusted data. Because if that query goes to one single node, and another query goes to another node, guess what? The data may not be consistent across these nodes, right? So, depending on the applications, it may be fine, right? But obviously the modern applications demand differently. They want trusted data, right? So, look at those things for your applications when you are making a decision. Look for databases that are highly automated. I think this is very important, from a tuning, optimization, backup-and-recovery, all of these should be automated as much as possible. You want to minimize your DBA effort into these environments as much as possible, right?

Ensure that sensitive data is well protected, right? Encryption, all the thing is enabled, especially even in moving into the cloud. You want to make sure this is done, because, you know, all databases don’t really have complete control of these datasets you’re driving. You want to make sure that the data is protections.

Ensure solutions that can scale and deliver performance, as I mentioned earlier on, and look for solutions that are lower-cost, as well. Because sometimes there are hidden costs, as well, you know? In the cloud databases, you’ve seen that. So, you want to make sure that they are lower-cost and you’re able to save money when you go to the cloud, as well, like public cloud, right? Ideally. I mean, you should be able to save 20 percent or more from moving from on-premise to the cloud. And I think a good thing is that you have a lot of flexibility with these cloud databases, which I think is really phenomenal, you know? Next slide.

And with that, I would like to thank you and hand it over to Ariff.

Ariff Kassam:  Thank you, Noel, that was very insightful. So, the next section of this webinar, I’m going to talk through some of the ways to think about narrowing the landscape of your choices. Noel did a great job outlining a lot of things that you should be looking for as part of cloud databases. We’ll touch on some of those again, in a little more detail, and talk through, sort of, your choices that you have out there when you’re thinking about cloud databases.

So, obviously, this is a very obvious slide. The biggest thing you need to do is understand your requirements. And they can be broadly divided into, sort of, business requirements and technical requirements. We’re not going to go through the business requirements, but you’re going to have to take a look at the total cost of ownership as well as your growth projections, how fast you want to do releases, all that you need from a business perspective.

We’re going to focus on the technical areas and understanding your requirements from a technical perspective. And, broadly, they can be thought of in four different areas: the workload type, your sort of architectural requirements, your transactional requirements, and whether or not this is an existing app that requires SQL support or whether you want to build something that has SQL support or you’re willing to change your access models to an API or NoSQL model.

So, the first consideration is, what is your application trying to do? And Noel, again, touched on this earlier in his talk. You have analytical databases out there that are looking at data, trying to predict trends, trying to understand how to optimize businesses, how to run businesses. You also have your traditional, general-purpose OLTP relational databases that really perform operational or transactional workloads.

Noel also alluded to a newer type of databases that are currently being seen out there that can support both analytical and operational-transactional workloads. In this case, the analytical workloads aren’t your complex data warehousing queries that range across terabytes of data. They’re more operational, analytical in nature, where they’re real-time queried that could potentially change the scope of a transaction. Fraud detection is a classic example in these use cases, where you need to make a decision, based on the behavior of the transaction, whether to allow that transaction to complete or not.

And then you’ve also got specialized requirements. These could be time-series database, from sort of an IoT perspective, or even graph databases for different modeling. Stream processing, again, another IoT use case, where being able to stream data to a platform, potentially do some analytics on that data, as well. And then you’ve got very specialized scientific platforms that exist out there. So, a lot of your choice in your database landscape is going to be driven primarily by the type of workload you believe your application is going to be performing.

The next critical piece is, sort of, the architectural requirements. And we’ve sort of highlighted three major pieces. What is your availability requirements and disaster-recovery requirements? That will dictate your strategies on the type of databases that you’ll deploy within a cloud environment, across cloud environments, or across multiple cloud providers, either public or private, and whether they’re different cloud providers. Again, I’m sure everybody’s aware of outages that have been seen by some of the cloud providers. If all your services are locked into one cloud provider, that outage will affect you significantly. And you may want to consider spreading your services across multiple cloud providers to prevent issues within specific environments.

Also touched on by Noel was this idea of hybrid. Is this a new application that you’re deploying? And, if it’s a new application, do you have any restrictions on whether or not the application can be fully cloud-based or has to span an on-premises and cloud environments? If it’s an existing application that you’re migrating to the cloud, there may be a transition period where you need to have a hybrid model, where you’ve got data in applications on-premises, as well as some database and data capability in a cloud.

And so, we typically see customers doing sort of a cloud on-ramp kind of strategy, where they’re migrating an app -- an existing application from an on-premises to a cloud environment, and build out this hybrid model, where they deploy a few nodes in the cloud and migrate over time, as they get more comfortable. And they build out capabilities in their application to support that model and then fully move to a cloud or maybe maintain a hybrid strategy, depending on the use case.

And then, finally, another big component in the architectural requirements is this idea of scale-out and scaling requirements. Again, if this is an existing application, you may have a very good idea as to what you’re workload and your scale requirements are. You’ve been running this application for a year or two and have a very good idea of what either the nature of the workload, or the number of users that you may have. If this is a new application or a new service that you’re providing in the cloud, it’s very hard to predict what that workload and scale is going to look like.

As Noel, again, mentioned earlier, five, 10 years ago, everybody had to go through the exercise of sizing the database based on projections of how the load that they believe the workload’s going to do. And 99 percent of the time, everybody was wrong. Whether that was sized it too small, and you need to upgrade immediately after production, or you wait three years to get to the scale that you think you were going to get day one, at which point in time you’ve overprovisioned your environment and are underutilizing your systems.

So, the question when you start thinking about your database requirements is, do you have an understanding of what the workload’s going to look like, the type of scale requirements you’re going to have, and what timeframe you’re going to do? Obviously, to reduce costs, you’d love to be able to scale out on-demand and scale in on-demand so that you’re utilizing the systems as highly as possible rather than, sort of, being overprovisioned and waiting for the point in time where you’ve got the right load on your systems.

Traditionally, if you've deployed databases and you look to do some of scale-out capability, traditionally there's basically two models of scale-out. One is a clustered shared disk architecture; this could be as simple as MySQP clusters where it's more an availability story, not a scale-out story, but if you've got something like Oracle RAC or IBM pureScale where they've got shared memory clustering, as well as shared disk clustering, then you can get some scale-out in those models. Though, the more traditional method of scale-out is a sharded approach, or a "shared-nothing" approach. Obviously, this has been the basis on which a lot NoSQL databases achieve their scale-out by partitioning across multiple nodes, but you can also do this with a traditional database. You can shard your traditional database and do scale-out in that manner.

The disadvantages of these types of traditional scale-out architectures is that they're very complex. Oracle RAC and IBM pureScale are very complicated systems that require significant investment in sort of SAN technologies for the disk. Partitioning and sharding is also very complex; it requires a lot of knowledge upfront on your application workload on how to best partition and shard your application across databases as such that you don't have any hotspots. And if you do have hotspots, then you have to figure out how to repartition and reshard the database to alleviate those hotspots. It's difficult to manage; these could be -- again, in a sharded environment, you're dealing with hundreds of partitions probably, or shards, and basically, each instance is its own database that needs to be managed independently. And again, sometimes it may require changes to the application to support scale-our architecture.

The next sort of architectural and technical requirements is transactional guarantees. Again, depending on your application requirements, if this is an existing application, it may already be built on specific transactional semantics, and may require ACID or partly ACID guarantees, if it's doing business-critical data, application management or financial transactions, or any sort of database of record system.

Some of the newer web applications don't need ACID or transactional guarantees. Some of the social applications, or social mobile apps also don't need transactional ACID guarantees. Those are obviously very well-suited, and a lot of the internet companies out there, like Facebook and et cetera, have built large data management solutions based on these eventual consistent NoSQL partitioned scale-out, highly scaled-out systems. And again, it depends on the application, and it also depends on the amount of complexity you want to build into the application to be able to manage the database semantics and how data is represented and replicated, and made consistent across the nodes. So a lot of times the NoSQL applications have to take into account that there could be different views of the data, and there could be inconsistent views of the data, and there could be inconsistent views of the data, and the applications just need to build that into its knowledge. It's not easy; but it is a way to handle scale-out depending on your needs.

And then finally, the last piece that we sort of talked to is your SQL support. Again, is this an existing application, that -- or has already built a lot of tooling around the availability of SQL. Does, in the cloud database, if you're migrating an existing database that's built on SQL migrating to a cloud, obviously you start with a cloud database that supports SQL semantics. SQL, as Noel pointed out, has a large ecosystem and toolset out there that a lot of people are comfortable with and have built a lot of operational procedures around. And SQL databases again abstract the knowledge of how data is managed from the application, so a lot of the data management tasks are pushed down to the SQL database versus moved into the application. Again, there's no right answer here; it depends on your application and the complexity of your application, if you can handle and want to handle data management tasks and maintain versions or schemas or access patterns, and optimizing access patterns within the application, then SQL support may be something that you don't really need. If on the other hand, if you've got an application or are building an application and you want to simplify the application code in terms of optimizations, performance, schema management, those are traditionally what a SQL relational database, or SQP databases have done in the past. And so you may need those things in your cloud database as you sort of look for the next solution.

So as a SQL database, the customers that we've been talking to, the customers that we've been engaged with, traditionally come to us because they are looking for a SQL database that elastically scales out, specifically in cloud or across hybrid environments. So customers are saying, we want elasticity. We want the benefits of a NoSQL database that provides scale-out, scale-in, availability, the ability to deploy on virtual systems, cloud systems, on-premises, but I also want to keep my SQL capabilities, and SQL being transactional ACID semantics, the SQL language abstraction and management capabilities that I traditionally have with my existing SQL database. And so, we've defined this idea of an elastic SQL database that combines the scale-out simplicity, elasticity, and continuous availability that cloud applications require without losing the transactional consistency and durability that applications require from a database of record.

So briefly, what is NuoDB and how does it achieve these elastic SQL capabilities? So NuoDB is a modern database architecture that has effectively taken your traditional legacy relational SQL database that is a monolithic process that controls both transaction management, transaction processing and storage management into a multi-process distributed system, right? We have fundamentally split the traditional database into two different types of services; one is a transaction processing service and one is a storage service. The transaction processing service represented by the dark green circles at top are full in-memory, only in-memory processing engines that parse SQL and execute the SQL against in-memory data that is available in that network.

We also have a durable storage layer, so for databases of record that have to have durability, we maintain multiple processes to store and make multiple copies of the data available. It's fully ANSI-SQL compliant, and we can deploy within a data center, or across data centers in different clouds, in containers, so we've got flexibility, the architecture has the flexibility to have a lot of different deployment models.

This is a bit of an eye chart, and it may be a little bit hard to read on your screen, but the top three diagrams represent how you can sort of scale out the NuoDB environment, and then the bottom three diagrams show how NuoDB provides continuous availability across the application. So, in the top diagram, it shows two TEs; these are the transaction engines that are fully in-memory, and two storage managers that are the durable points for our database, right? And the applications are connected up the transaction engines, and working, executing their workload across two different processes that are fully active and fully available processing the requests from the applications.

In the second picture, you can easily see the applications scaling out by adding either a low-bounce or adding another node, another web server, however the application is scaled out. And then on the third image, we can simply add a transaction engine on the fly without any outages, without any downtime, dynamically add a new transaction engine so that can start serving that application that was just recently added to provide that scale-out capability.

And then the bottom three talk about availability. So in this case, that one new transaction engine that we just added fails for whatever reason; the server went away, or whatever happened to that server in the cloud, the application will see that failure, will get a reconnect; you'll do a standard connection pool that will then go to the next available transaction engine, so the applications connect up to any of the transaction engines, and continue its work. So from the applications point of view, it's just a reconnect; there's no loss of data; there's no loss of availability to the application.

So I wanted to talk through a customer use case. So Alfa Systems is a UK-based software provided that provides software for managing financial assets to companies. For example, a lot of the car manufacturers use Alfa Systems' software to manage leases. So customers lease their cars, and the Alfa Systems software is used to manage those leases. Alfa Systems just a couple weeks ago issued an IPO on the London Stock Exchange, and it was the large UK IPO since 2015.

The challenge that Alfa Systems had is that they've had an on-premises solution, and they were losing business, or were not growing as fast as they wanted to without a cloud or SaaS offering, and so they needed to migrate their application to provide a SaaS solution in the cloud. They tried MySQL in the cloud environment, but they're having problems with MySQL scaling, MySQL, and the Oracle licensing in AWS was too expensive for them.

So they chose NuoDB because of our elastic scale-out capabilities, as well as our continuous availability in providing active-active across multiple cloud environments, while maintaining transactional SQL consistency.

The benefits that Alfa found is obviously a huge ROI for Alfa and their clients. We were able to reduce their costs by 90 percent over their Oracle costs, and we've increased their performance as well as availability and response time capabilities.

Just a brief slide on NuoDB; who are we? We were founded in 2010. We are a management team made up of database pioneers. You can see some of our customer logos onto the right. We have patented this elastic SQL database for the last several years. It has been built from the ground up for cloud technologies; it's not your traditional legacy SQL database.

Lorita Ba:  Great, thanks, Ariff. So, I'd like to take this time to remind people that you can go ahead and questions in the GoToWebinar control panel. We're going to take a couple that have come in throughout the time here. The first I think is directed to Noel. Noel, could you give us an idea of which use cases, and what kind of workloads and applications are moving to the cloud sooner than others?

Noel Yuhanna:  I guess, it's all kind of use cases I guess are moving to the cloud, as I mentioned. You know, especially the ones which need scale, right? I mean, if you look at it, the way they build applications, I mean, we obviously start with a smaller build up the application and grow, and that's the traditional approach of building an application, right? I mean, you start small and grown, and you actually fix the applications down the way. But today, with the competitive pressure, today with the digital business initiative that's going on, you know, you don't really have time to actually build an application with a building block kind of model that hey, we're going to start with a thousand user, then we must a ten-thousand user next month, then we'll start to grow this. You know, because obviously application has to scale linearly, but also budget is an issue. (laughter) People don't have handfuls of money and resources available for these applications, so you got a cost equation on one side, on the second side of SQL to scale, and the availability of these applications that demands differently than what you've done in the past, which is driving the need for this cloud.

Now obviously, as I mentioned, what are the best use cases, you know, whether you're building social applications, mobile, SaaS applications, real-time applications, fraud detection, customer churn, customer intelligence applications, you know, all of these very, very suitable for the cloud, I guess you know, and that's what you've seen, whether you're a bank, insurance companies, retailers, healthcare, you know, oil, gas, I mean all these companies do need these agile, so-to-speak, platform which deliver scale, performance at a lower cost, you know, which is why in a cloud, there's obviously, you're gaining a lot of ground, you know.

Lorita Ba:  Great, thanks. And you made a comment during your presentation about eventual consistency, and paying attention to kind of importance of transactions. Are there use cases that you would recommend more for sort of that eventual consistency, or NoSQL model versus the ones that are better-suited for relational databases?

Noel Yuhanna:  Yeah. I mean, I think every application is different, right, I mean the fact that if you look at it, you know, you maybe, eventual consistent model, like some of the travel sites, when you go to a travel site, and you're booking travel, they want to actually have a platform that can scale very, very quickly, right; yet the data may not be consistent in that kind of scenario, right? You're booking a travel, and all of a sudden it says, "By the way, the prices have increased actually," all of a sudden. (laughter) Why? Because the data wasn't consistent, I guess, you know, right? So, I mean, it depends on the uses cases we're seeing, typically, for documents, like if you're doing, say, social networking, eventually consistent may be fine, right? I mean, if someone posted something, and you don't get it for like three seconds, does it really matter? No, not really, right? I mean you're not doing a banking application, right, not doing a transactional application, right? So, I guess, you know, eventually consistent kind of models are very good for those kind of social media, social networking applications, or when you're dealing with, maybe an IoT data I guess, you know, which may not be needing consistency data as well as much.

So, there are certain demands for certain things, but I think, you know, if you look for traditional applications like enterprises are building those customer-facing applications, you want to have a consistent model for that. Consistency is very critical; you know, ACID compliance is very critical, because you want to get a single version of the code for the customer, and in real-time, like if a customer calls in complaining about something, you should know about this customer in-and-out until that second. Now, it doesn't matter, you know, how you get to the data, right? Bu that's an important model altogether in having, versing being inconsistent, I guess, for that reason, right? So I guess all applications vary you know, so yeah.

Lorita Ba:  Great, thank you. Ariff, I think the next question's for you. Is it possible to write to the same data from multiple nodes in NuoDB?

Ariff Kassam:  So, all our processes are fully active, so you can have the application connected up to all the nodes in the database, so you can be able to do full reads and writes across the entire database, and that is both within a single environment and across multiple environments, so again, if you've got a hybrid model, you can have an application processes doing both reads and writes to the database that spans on-premise as well as in a cloud environment.

Lorita Ba:  Great. And then the next question is, with respect to continuous availability, you mentioned the loss of an existing TE, or transaction engine, that it will auto-redirect request to another TE. This person's curious about what the transaction engine stores locally, and whether the storage manager is where the data physically resides, and whether one can scale-out the storage manager.

Ariff Kassam:  So those are all good questions. The transaction engines are in-memory systems that cache data based on application workload that is directed to that transaction engine. So in the case of that failure scenario where the application was doing a workload against transaction engine 3 for example, and transaction engine 3 went away, when the application connects up to transaction engine 2, and reconnects -- so let's assume the transaction was rolled back because of the connection failure, and reconnects and tries to replay that transaction, it will make the same requests, and if the data does not exist on transaction engine 2 at that point in time, it requests it from the storage manager, which can have the full copy of the database. The transaction engine 2 may already have the data already in its memory; if it does, then it doesn't need to go back to the transaction engine to get that data.

The second part of the question was whether or not these storage engines can be scaled out. So there's two modes for the storage managers; they can either have a full copy of the data, so if you've got two storage managers running, then you've got two copies of the data. If you want sort of a K-factor of 3, then you could have three storage managers running for redundancy. We also support the idea of partitioning the data across storage managers. This is a concept called "storage groups" within NuoDB, and in that case, you could have a third of the data across three different storage managers, at which you can then scale out that data across multiple servers.

Lorita Ba:  Great, thank you. Noel, I think the next question is a follow-on to the previous answer. Do scale-out relational databases sacrifice transactional consistency for the ability to scale out?

Noel Yuhanna:  No, the new generation of applications which are new types of databases that are doing consistency, I guess, the relational and the scale-out architecture, right? But traditionally, they haven't been doing that, I guess, right? So that's a big challenge. But if you do consistent model with the relational, and the scalar architecture, it can be very, very complex to do that, I guess, you know, yeah. But yeah, I mean, it's a totally different requirement altogether, yeah.

Lorita Ba:  Ariff, does NuoDB sacrifice transactional consistency for the ability to scale-out?

Ariff Kassam:  No. So we are a full-ACID, fully transactional-consistent database. We have standard isolation levels for accessing data within a transaction. We are also an MVCC database, multiversion concurrency control, which also allows us to scale reads and writes without locking.

Lorita Ba:  And then a follow-on to the continuous availability question we had earlier, would you still be able to maintain the request level SLAs when we're transitioning a request from the sale TE to the active TE?

Ariff Kassam:  So, again it really depends on the SLA. Obviously, there is a little bit of a hiccup when we are moving from a sale TE to an active TE because of that reconnect to the second active TE. Again, depending on your SLA, if you're right up against your SLAs, then maybe not. But generally, your SLAs have enough room that that particular network reconnect is minimal and doesn't affect your SLA.

Lorita Ba:  Great. And we're unfortunately at the end of our time here, so if you'd asked a question and we didn't have a chance to get to it, we'll follow up with you at the end of this webinar. We have recorded the webinar and we'll send it out to anybody for your future review, and in the meantime, I want to extend a special thanks to Noel and Ariff for leading our discussion on selecting a database for your cloud application. And thank you to our audience for joining us today; hopefully you found the session today interesting and informative. And we'll see you the next time. Thanks so much, bye-bye.