What this means for you:

• The new pricing is in effect as of September 1st, 2011
• Xeround Customers: Your account has been updated automatically and you do not need to do anything to take advantage of the new pricing.
• Data Size is calculated on an hourly basis. During the periods that your database’s size is less than 1GB, Data Transfer is free of charge and you will be charged only for Data Size.
• The new pricing is reflected in the Cost Preview page in your Database Manager Online Console
• You are still eligible for the 20% discount off your total monthly costs (for both Data Size and Data Transfer) until the end of the year.

This feature allows you to easily restore your Xeround database from a backup file to a new DB Instance. The new instance can be created either in the same data center, in a different data center, or in a different cloud provider.

With this functionality you could, for example:

• Effortlessly build a database for testing purposes by using a current backup of your Xeround database in production.
• Quickly copy your Xeround database to a new data center or even to a new cloud provider.

  This is useful either when you’re migrating your application; or when your current cloud provider is experiencing some availability issues (such as in the case of a lengthy outage) and you wish to temporarily restore service from a different data center.

  With Xeround, there’s no vendor lock-in, as your database instance can virtually skip between two different clouds with a click of your mouse.

Restore to New is the first in a long line of new features and enhancements to our high-availability offering being released in the coming months.

Using the new “Restore to New” feature is as straightforward as possible:

1. Login to Xeround database manager console
2. Click to select the database instance you wish to restore
3. Navigate to the instance’s “Backup” tab and select the backup set to restore from.
   Xeround offers automatic scheduled backups as well as on-demand user-initiated backups. You can choose either of the saved backup files to use for restoring your DB.
4. Click the “Restore” button to have the “Restore backup” dialog displayed
5. Select the “Restore to a new DB instance” option, choose the data center for the new database instance and hit the “Restore” button

Within minutes your newly restored database should be up and running!

We’ve been getting some questions regarding the different ways for connecting Heroku apps to Xeround, and the different plans Xeround offers for Heroku users.

So here it goes:

What does Xeround provide?

Xeround Cloud Database is the only horizontally scalable and highly available database available for MySQL applications created on the Heroku platform.

Xeround provides unlimited scalability (out/in), built-in replicas and automatic failover for high availability — all in a plug-&-play, simple database service (DBaaS).

How to use Xeround with your MySQL-Heroku application?

Heroku users can use Xeround Cloud Database transparently instead of either the PostgreSQL DB that’s provided with their Heroku instance, or a manually installed MySQL DB.

There are two ways you can create your Xeround Cloud Database instance to use with Heroku:

1. Xeround’s add-on for Heroku allows you to create your Xeround DB instance with a single click from within your Heroku environment. This requires no registration to Xeround’s service and the entire process is carried out via Heroku.
2. Alternatively, you can sign up to Xeround to create your free cloud database, and then connect your Heroku application to it, just as you would connect your app to any external MySQL database.

How to connect your heroku MySQL app to Xeround:

Depending on how you chose to create your Xeround DB instance, follow these step-by-step instructions to connect your Heroku application to it.

At the last MySQL C&E we got a chance to catch up with MySQL users and to hear what they had to say about the challenges they face with their MySQL database in the cloud, and their expectations from an elastic database system.

We spoke with Bob Burgess from Radian6 about the tedious (and neverending) work that goes into maintaining scalability of your MySQL database.

• How much time of your daily work is spent on slicing and dicing and sharding and partitioning and replicating and god-knows-what…?
• What would get you to consider a cloud database?
• What do you expect from a database-as-a-service solution?

See what Burgess had to say.

Marc Sherwood from SkySQL discusses the complexity of scaling MySQL and how your database service can help you simplify the scaling process.

• How should you scale up?
• How should you scale down?
• How should you pay for those resources?

See what Sherwood had to say.

Mark Lehmann, a senior DBA for Morningstar, has been running MySQL in the cloud for quite sometime.

Lehmann shares his experience of what to expect when running MySQL on Amazon EC2 – everything from server crashes, machines that freeze, RDS performance issues, I/O limitations, and the operational challenges of managing numerous instances of MySQL in the cloud.

But it’s not all problems: see what Lehmann particularly likes about running your DB in the cloud, and what he expects from a cloud database – such as automatic backups, restore, replication and more.

Check out more videos on our YouTube channel.

Short update regarding the status of Xeround’s service on our EC2 datacenter in Europe, as Amazon are working to restore service in EU:

• The creation of New DB Instances on Xeround’s datacenter in Europe is now available.
• Existing Trial instances that were created in EU are being restored- look for an email from our Support Team by the end of the day with your new connection IPs.

Amazon EC2 datacenter in Europe suffered a major outage yesterday, caused by a lightning strike that hit EC2′s datacenter in Dublin.

The whole Amazon EU site was not available for several hours yesterday. Since the crash, Amazon has been working to restore service to both EC2 and RDS instances running in EU. The instances are being recovered gradually, in a process that is estimated to take up to 48 hours.

How Does the EC2 EU Outage Affect Xeround Users?

Xeround Customers:

So that your DB does not suffer any additional downtime, we have automatically restored your DB instance to our EC2 datacenter in the US.

While you may experience some latency, this enables you to continue to use your DB instance for the time being, while AWS resumes their service in Europe.

If you wish to use your DB running from the US, be sure to check your email for the notification from our Support team with your new connection IPs.

Xeround Trial Users:

Working with Existing Instances:

You can either wait it out for EC2 to resume full service in Europe, or alternatively contact us if you wish us to restore your DB instance to run off our US datacenter. Restoring to a new datacenter will be done based on your latest backup file.

Creating New Instances:

Until EC2 in Europe is fully operational you will not be able to create a new DB instance on our EU datacenter. We anticipate resolution within 24-48 hours, after which time creation of new instances in Europe will be available once again.

What’s Next?

In the cloud, you need to take into account that availability issues go with the territory (literally). We are always expanding on our built-in capabilities to ensure availability of your database, and are planning to release major improvements and exclusive features in this space as early as this month.

In the next couple of weeks we will be releasing a new feature allowing you to restore your DB instance into a different datacenter. This is a manual solution to address downtime caused by a complete meltdown of a datacenter (such as in yesterday’s case). You can choose to restore your instance from any of the backup files you have saved. This feature will later on be augmented by our full DRP solution — allowing you to automatically resume service from a different region, datacenter, or even a different cloud provider.

I gave it some thought, trying to encapsulate what’s the main takeaway from the conference. And it came to me – and surely enough, it was even printed on a T-shirt I got from the event organizers (so i didn’t have to search for very long :)): DATA MATTERS.

Seriously, it was interesting and refreshing to see the wealth of discussion around data.

(One excellent session I particularly liked was “Designing and Implementing Asynchronous Distributed Systems: Challenges, Strategies, and a Million Things That Go Wrong” by Scott Andreas).

The developers and open source community are all talking data: solutions, concepts, paradigms, architectures, and so on and so on. There is a real hunger out there for a solution that could streamline it all for you — for your exact specific needs — in one-click. For the more complex stuff, one-click is perhaps premature- so we’ll also take two or three clicks to get us up and running.

And this is what we strive for here at Xeround — aim high, so DB management in the cloud is as simple and as low-maintenance as possible.

Always a work in progress :)

Cheers,
Avi.

Check out this short interview with Razi Sharir, Xeround’s CEO, taken at GigaOM Structure Conference last month.

You may also want to watch the video recording from the Structure Conference of the “Cloud Databases” panel discussion in which Razi participated in.

Virtualization-centric solutions versus Service-centric solutions.

1. Virtualization-centric solutions – in this approach, the main function of the cloud is to provide different provisioning and management services around servers virtualization.  Server images which are deployed on virtual servers are key components in this approach as the atomic deployment and management unit for the cloud. Application provisioning is usually a set of images deployed on a number of servers. The virtualization infrastructure provides many of the enterprise level features such as high availability, replication of data, storage allocation and management, and even in some cases scalability for the application. The virtualization-centric approach  evolves from the bottoms up, starting by trying to solve  infrastructure inefficiency issues, server utilization, resource management and more.
2. Service-centric approach – in this approach, the cloud aggregates several high level services – such as data services, platform services, management services etc. –  for customers to choose from when developing and deploying applications. This direction is demonstrated by different cloud vendors who offer a comprehensive framework which includes everything needed for the application to run- with all the services often  wrapped in a friendly user interface, “shielding” the customer from the underlying infrastructure. In this approach the user is spared the virtualized infrastructure layer: want more storage – move this slider, want more scalability for the application – slide the cluster size control higher, etc., Great examples for this approach are the Heroku  and PHPFog platforms.

Look for Avi – mainly in the OSCON Data and Cloud Computing tracks - for a quick chat about relational databases in the cloud, MySQL, or just to compare the latest crop of T-shirts :)

We’re always looking to hear from the LAMP community — so if you see Avi at the conference- come say hi!

There are several ways to scale a database. When evaluating a database solution, ask yourself how it scales and see if it scales in a way that would be optimal for the needs of your application.

Before we can choose the most suitable scaling solution, there are a couple of things to consider:

What is it that we want to scale in a database?

1. Capacity – The most natural scaling scenario, where data has grown and the disk/memory/attached storage is too small.
2. Throughput – Application usage has grown, resulting in a decline in performance. Throughput is influenced by latency & concurrency, which means you can either improve the response time for every task (latency) , do a lot of tasks in parallel (concurrency), or use a combination of both (remember that one influences the other, and as concurrency increases, it affects latency as well.)

   Scaling throughput can be accomplished either for a specific type of transaction – such as scaling for read operations only – or for all types of transactions and operations: reads, writes and everything in between.

What we are willing to undergo during the scale event?

The Scale can be:

1. Offline – This scale event requires stopping the applications running against the database until we bring back the newly scaled (up or down) database. This scale event can take anywhere from minutes to hours. In some cases, it may also require a re-portioning event or something of the sort.

   To maintain service during the time that we need to take the database offline, we often back up the data and restore it elsewhere to maintain service from a temporary location. Also, once the scaled instance is once again operational, you’ll need to sync all your data with the data in your backup.

2. Online – The database continues to serve the application during this scale event. At most, the application might suffer some performance degradation during the scaling time, but overall service is maintained.

   Since your database records could change during the scale event, any solution that offers online scalability needs to be able to ensure data consistency.

So what types of scales are there?

Scaling Up and Down

Scaling up and down are the most common and ‘brute’ ways to scale:

Need more capacity or need better performance? Then buy a bigger, faster, meaner machine. The cloud infrastructure makes this approach very easy from the operational standpoint: you simply spawn the next available VM class and voila!

This approach can be achieved through a Do-It-Yourself operation of purchasing and installing additional virtual resources, or by subscribing to a database service that provides the ability to allocate additional instances on demand.

Advantages of scaling up or down:

• It’s simple – This type of scale is usually fairly simple to deploy, and is supported by most of the databases used today (so that once more processors and cores are identified, the database software is able to take advantage of the additional resources.)
• No code changes to the application – it is still runs against a single (larger) machine.
• Scales both throughput and capacity

Disadvantages of scaling up or down:

• Cost – High-end hardware is usually costly when deploying physical servers as well as when provisioning virtualized resources on the cloud. Moreover, if considering non-standard equipment (ultra-fast networks, PCI SSD storage etc.), the cost for such an infrastructure will be so expensive, making it unfeasible for most organizations. In addition, most of the cloud infrastructure uses commodity hardware, so the more high-end configurations and hardware are usually not available at all.
• Limited scalability – At the end of the day, you can’t outgrow the capabilities of a single machine. In the cloud infrastructure, those capabilities are also restricted to the hardware offers by your chosen cloud provider.
• Scaling up or down is usually done offline – This is the case because the hardware needs to be changed. To avoid service downtime, some kind of master/slave architecture needs to be established and upgraded one by one.

Scaling Out and In

This approach is more complex to achieve because it requires the database to be designed to support scale-out capabilities. There are various ways to scale-out; each solution carries its own advantages, disadvantages, tradeoffs, and architectural implications. We’ll address two popular architectures: read replicas and sharding.

Distributed read replicas:

This is the most common way to scale out. In this configuration, you have a single master server where all writes are performed and then distributed to all the read replicas. Read operations can be done against the master or the read replicas. The distribution of write operations can be synchronous, where the write operation will be blocking until it reaches all the read replicas (ensuring data consistency), or it can be asynchronous, where the write operation is unaffected, resulting in data inconsistency since you may not be reading the most up-to-date data.

Advantages of scaling out and in using read replicas:

• Simple – relatively easy to implement compared to other distribution approaches
• Scales beyond the limitations of a single machine
• Usually is done online (but the client is not automatically updated on the added/removed replicas)

Disadvantages of scaling out and in using read replicas:

• Scaling is only for throughput and  read operation (sometimes at the expense of write operations).
• Application changes are usually required to perform the reads and writes in the right place and to add or remove nodes.

The read replicas approach is used by MySQL replication, Amazon RDS, Zimory, and more. It is usually suitable for 1^st generation web applications where the application is mostly read (90/10, 80/20 – scalability is needed mostly for read operations). For next-generation web apps that are user and content-driven, this approach is less suitable.

With the expansion of social applications and social/sharing features, today’s applications are characterized with a much higher ratio of write operations. Some applications even demonstrate a ratio of 70/30 for write operations.

Sharding:

Sharding is another way to achieve scalability. It usually means splitting up the data by some logic derived from the application. This can be done by selecting a key in the data and splitting the data by hashing that key and having some distribution logic. It can also be done by identifying the application needs and setting different tables or different data sets in different databases (splitting the North-America sales data from the EMEA sales data, etc.)

This approach is simple from the database standpoint, but is very complex from the application standpoint since the application needs to be modified to deal with the data being scattered into the different shards. Moreover, combining data from different shards can be very complex and involves development in the application (you can’t just run a simple JOIN.)

Advantages of scaling out and in using sharding:

• Scales beyond the limitations of a single machine
• Scales both read and write operations (but makes some operations impossible to achieve in the database)
• Scales both throughput and capacity

Disadvantages of scaling out and in using sharding:

• Complex and requires application changes
• Scaling is usually offline and requires a re-partitioning event – and may require application changes.

Today, there are some solutions that introduce auto-sharding (Scalebase, Dbshards). This approach makes sharding more similar to shared-nothing partitioning, thus taking the sting out of some sharding complexities. However, it still requires application awareness and could prove to be a limiting factor if you needed to update your app or migrate to a different database solution.

What goes on in Xeround’s backend to enable scaling?

Xeround’s distributed architecture enables scaling by partitioning the data across virtual partitions, which are then replicated in a shared-nothing architecture. This means that all nodes are active, and each node holds part of the data. The approach is similar to a Master-Master distribution in the sense that all resources are active and are sharing the load.

The solution is based on a front-end layer that analyzes the request and distributes both writes and reads to the backend layer, which processes the requests.

The solution is scalable – all types of components can be added and removed from the system. If scaling throughput is required, we scale-out, adding (or removing) frontend nodes. When scaling capacity, we add (or remove) backend nodes. As we add more nodes, more processing will be done in parallel, increasing throughput.

Advantages:

• This approach scales both throughput and capacity.
• This solution scales both reads and writes.
• Scaling is done online with no downtime/partitioning event. New resources are added/removed automatically on the fly in a way that’s transparent to the application.
• Scales beyond the limitations of any single machine/node
• No application change needed

Disadvantages:

• This solution is much more complicated to implement (but that is our problem :) ).
• There are backend and frontend components, so every request involves some network hoops, meaning that the basic latency is bounded by network (which is faster than disk-seeks but slower than operations that could be resolved in a single machine memory).

How is Xeround’s MySQL scaling delivered to our users?

In one word: Automatically.

Xeround’s industry-first auto-scaling capabilities allow you to automatically scale out when your database requires more throughput or capacity, and scale in when it requires fewer resources. Xeround delivers seamless MySQL scalability – with no service interruptions, code changes or architectural changes required to your application.

Your database scales linearly in a way that is extremely granular and can accommodate any peak or demand from the application. That way, you can rest assured that your DB will always run optimally in the cloud, with no need for any of the extensive management or configuration overhead on your part to ensure that it is scaling the right way.

You can learn more on Xeround’s auto-scaling feature and on our scalable infrastructure.

And since this post has turned out kinda long… let’s close with a couple of short videos about how scaling MySQL in the cloud should work — and as you can see great minds think alike :)

Needless to say, we believe Xeround is the best cloud database solution available, but we are also confident it is the most cost-effective.

To convince you that’s the case, we’ll explain:

1. What use cases Xeround addresses
2. How the pricing works
3. How it compares to alternative solutions

Xeround is a fully-managed cloud database, also known as a database-as-a-service. It is a drop-in solution for existing MySQL databases. It currently runs on Amazon EC2, as a Heroku Add On and in beta on the Rackspace Cloud. In this post we will discuss pricing on AWS. In the future, we’ll address pricing on other cloud providers.

What type of databases is Xeround intended for?

Xeround was designed for mission-critical databases that are transactional in nature  (aka OLTP). From our experience with the more than 2,000 customers who participated in our beta program, in the vast majority of cases, these databases tend to be in the range of 0.5 to 50 GB in size, with a wide range of throughput requirements (some numbers provided below).

What type of databases is Xeround not intended for?

As of today, Xeround is not designed (nor priced) to address the needs of analytical apps (aka OLAP), “big data”, archiving, and generally very large databases.

What you get with Xeround?

To address its purpose as a mission-critical transactional cloud database we built some important features into Xeround, which address ease of setup and use, performance, scalability, elasticity, and perhaps most importantly: reliability.

We arrived at the features that address these requirements after literally hundreds of interactions with database users and improved on them during our very active beta phase.

Before we get into these features, it’s important to understand the basic way in which Xeround works: First, your database is kept in two synchronous in-memory replicas. In addition, the data is then asynchronously written to a persistent store (Amazon EBS). In other words, Xeround keeps three copies of the data.

With this you get:

• No setup. After you sign up with Xeround, you literally create your database with one click. Xeround takes care of high-availability, by automatically maintaining the three copies in the background.
  
  
• Performance. Because it manages data and transactions in memory, Xeround offers low-latency and high throughput. See this benchmark of Xeround vs. Amazon RDS.
  
  
• No Downtime SLA Guarantee. We are so confident about the reliability of our service that we are willing to put our money where our mouth is (BTW, read about how we handled the recent Amazon outage). And when we say “no downtime” it also applies to scaling up or down, scaling in or out and when making schema changes — all of these are handled automatically in a way that’s transparent to the application and does not result in a service interruption.
  
  
• Auto-Scaling. You can set CPU utilization, memory utilization and connection upper and lower thresholds and Xeround will automatically scale up or out — as well as shrink back down — to make sure your database always gets optimal resources to handle your application’s load needs. This also has a huge economic effect, as it ensures you only use what you need — and only pay for what you use.
  
  
• Scheduled Daily Backups. Xeround will back up your database once a day at a time of your choosing. You can also initiate additional on-demand backups.

In addition to all of this our pricing includes 24/7/365 email, web and phone support.

Xeround Pricing

So what do you have to pay to get all these features and support? Our pricing model takes a unique pay-per-use approach. You only use what you need and you only pay for what you use. Specifically, we charge $0.10 per GB/hour of data volume and $0.33 per GB of data transferred in and out of the database.

Cost Comparison

Now, let’s examine what this pricing model means when comparing — apples-to-apples — with Amazon RDS MySQL. We’ll look at a few typical scenarios that we’ve seen among our more than 2,000 beta customers.

Note that in all of these comparisons we are comparing to Amazon RDS’s Multi-Zone offering, as that is the comparable offering to Xeround in terms of High Availability (two replicas).

Case 1:

A micro-sized database of around 500MB, with relatively low throughput at an average of 35KB/second, with occasional peaks of 50KB/second.

Case 2:

A small-sized database of around 5GB, with volatile throughput at an average of 70KB/second, with occasional peaks of 100KB/second.

Case 3:

A medium-sized database of around 20GB, with relatively low throughput at an average of 400KB/second, with occasional peaks of 850KB/second.

As you can see, in all these typical cases, Xeround is the more cost-effective solution, with savings of 64%, 39% and 18% respectively. And as already stated above, our price includes 24/7 support, Zero-Downtime SLA guarantees, auto-scalability and a couple of other features we won’t get into here.

A Note on Throughput:

Xeround is especially cost-effective when you have fluctuating throughput. This is because we only charge you based on your ACTUAL data size, while on Amazon RDS, you will have to over-provision a machine that is large enough to handle your PEAK and pay for it throughout the entire month, in effect committing to a larger instance size, even though most of the time it goes underutilized.

Furthermore, Xeround automatically accommodates any throughput requirement you may have – as your cloud database automatically scales across multiple nodes when you need more throughput, and scales back in when it’s underutilized. This effectively eliminates the need for you to plan in advance how popular your application will be/what your future throughput will be like. You don’t need to predict your future requirements in order to ensure you do not get starved on I/Os, suffer service interruptions, or take a hit on performance when you have a sudden peak that a manual scale can’t handle fast enough.

To get a feel for the cost for other database sizes and data transfers use our Pricing Calculator.

Still not sure?

Try it out for yourself. We offer a 30-day free trial during which you can use our cost estimator to see how much Xeround is going to cost you once you start paying.

After you’ve created and loaded your database, log in to your Database Manager Online Console and choose “Cost Preview” from the “My Account” menu. This will give you an up-to-date report of your current Data Size and Data Transfer usage and associated costs — so you could see exactly how much you would have paid for your specific database.

The hardware that makes up the cloud infrastructure is being continuously improved and optimized, so that over time it will be standardized and commoditized (much like “dial tone” at the PSTN days, or airtime for Mobile carriers).

This means that the infrastructure being offered by different cloud service providers – as it pertains both to the bare irons, and also to a great degree to the overlying stacks – would gradually become more and more similar. Cloud providers would offer nearly identical hardware and stacks – which is more cost effective on their end in terms of maintenance and operational costs. This will also provide greater flexibility to the end user – who will be able to more easily migrate between clouds and expect the same set up and performance.

Once the Infrastructure-as-a-Service becomes pretty much the same between clouds, the question then becomes what are the differentiators between the cloud service providers that can also generate additional revenue and increase profitability. Not surprisingly, much like the differentiators between Telco companies today, the value comes from added services (VAS) that are running on top of this heavily populated and distributed cloud infrastructure.

The direction we’re seeing is a gradual move from Infrastructure-as-a-Service to cloud added services. Looking at the current landscape and the already decreasing prices for the mere simple Virtual Machine (VM); it is the homegrown as well as branded Platform-as-a-Service (PaaS) and Database-as-a-Service (DBaaS) that mark the differentiators between cloud providers. Offering premium features and a unique set and functions like high availability and distribution – certain add-on services will become the key differentiator for the infrastructure they run on.

When the roads and lanes are the same – the car you drive becomes the issue :)

Customer, vendors and providers will need to ask themselves: What’s in it for me? How can I best benefit? — and the answer should be straight forward: Which value added services that are offered across more than one Cloud Service Provider (CSP) will drive for competitive pricing, service level and flexibility.

Look out for those vendors offering cloud agnostic solutions that can be run natively on both public clouds as well as in your private cloud or hybrid solution to allow for optimal CAPEX and respective OPEX.

Razi Sharir – Xeround’s CEO – participated in a panel yesterday, discussing the challenges and the opportunities for a cloud database. Joined by Jim Starkey from NimbusDB, Mike Miller of Cloudant and Barry Zane of ParAccel – the four discussed each of their unique approaches to solving the way RDBMSs scale in the cloud environment; What are the common use cases and applications to benefit from each solution; How they address availability issues and hardware issues in the cloud, support multi-tenancy, and more.

Watch the video recording of the panel:

Also check out Razi Sharir’s interview at Structure and the panel coverage on GigaOm and on Computerworld.

If you’re attending, be sure to check out “The Next Frontier”: Cloud Databases” panel discussion - 10AM on Thursday, June 23rd.

Xeround’s CEO, Razi Sharir, is participating in the panel with other leaders of NewSQL solutions and modern data management in the cloud.

From the panel’s abstract:

One of the biggest challenges that remain is managing data in the cloud. While the need for database scalability, reliability and performance has always been an issue in computing, the cloud introduces new challenges such as elasticity, geographic distribution and multi-tenancy. It has become a breeding ground for a wave of new solutions, including database-as-a-service offerings. In this session, we will engage in a discussion with some of these cutting-edge companies. We’ll define what a “true” cloud database is and explore the unique challenges of managing data in a cloud environment.

Check out the conference schedule here.

Hope to see you there!

With Version 3.0., we made great efforts to further improve our database service, emphasizing performance, throughput and scalability.

As a distributed infrastructure, networking and protocols are key factors in achieving better performance. A key development for version 3.0 was optimizing Xeround’s Database networking by using protocol optimization to minimize traffic between servers, reduce networking overheads in payloads, as well as manage transaction and control events.

Another main area we invested in was memory management. Compacted data structures, new data structure organization, and better reuse of released memory space all give the new version of Xeround a significant performance boost.

The Xeround Cloud Database Benchmark

We’ve also just published our updated database benchmark, which compares the performance of our new commercial version to the performance of Amazon RDS. You can see the new benchmark here. Tests were conducted on the actual cloud environment to make sure there was no environment-specific bias.

Something worth noting: when testing the throughput of Xeround’s DB service (using standard DBT-2), we found that the most recent version of our cloud database was significantly faster than our beta version. This improvement in performance does not come at the expense of Xeround’s scalability – as we continue to deliver stable performance and latency under high load and with large numbers of concurrent users.

Like our previous benchmark results, throughput stabilizes around 30 concurrent users. However, while our beta version managed to reach about 3,000 NOTPM, this recent version reached 7,700 NOTPM in exactly the same test – a 2.5x improvement is indeed impressive!

Check out our complete updated benchmark comparing Xeround’s performance to Amazon RDS and register for a 30-days free trial to try out the latest version of our cloud database, now available commercially.

during our beta period, we’ve had over 2,000 users trying our service, with many already using Xeround in their live production environments. We sincerely thank all of our users for their time and effort in testing the beta service and helping us to improve our product. Now, the time has come to offer it to the public.

Xeround offers the market our ridiculously simple, easy to use cloud database solution, allowing users to focus on their applications without worrying about the tedious tasks and frustrations involved with maintaining scalability and availability in the cloud.

Xeround’s cloud database is now commercially available on our Amazon EC2 datacenters (in the United States and in Europe), the Heroku cloud platform, and will soon expand to Xeround’s Rackspace datacenter, with support for additional cloud providers planned in the near future.

Xeround’s Database Service Includes:

1. No downtime SLA guarantee: Xeround’s built-in replicas and automatic failover ensure high availability
2. Unlimited Auto-Scaling: for both the size and throughput of your database.
3. Scheduled daily backups
4. Support included: web, email and phone support 24/7/365.

Xeround’s Pay-per-use Pricing

Xeround charges based on two usage metrics:

1. Database Size: $0.10 per GB/hour on our Amazon EC2 datacenters
2. Data Transfer: $0.33 per GB on our Amazon EC2 datacenters

Xeround becomes the first true pay-per-use cloud database service available in the market where customers only pay for actual resources consumed and not by server/instance size.

Unlike other providers, such as Amazon RDS, that require customers to commit to a pre-set instance size that provides pre-set storage and processing capabilities, Xeround is able to automatically scale up or down to the exact needs of the application so that the database gets additional resources when it needs more size/throughput, and scales back down when it is underutilized. This effectively eliminates both over-provisioning and over-paying, meaning users truly only pay for what they use.

This simple and easy to manage pay-per-use model ensures that the costs of running your database are tightly linked to the scale of the application it supports in a truly dynamic and flexible way.

How much will Xeround cost for you?
No more estimating how much throughput/connections/ops/data you have today – and how much you’re going to have – to be able to estimate how much Xeround database service will cost for your particular database.

During the trial period as well as when you become a paying customer, you will be able to see an up-to-date report of your current Data Size and Data Transfer usage along with the associated costs.

That way, once you’ve started your trial, imported your data, and connected your application to your new cloud database, you can get an accurate status report of what your costs would be if you were a paying customer of Xeround.

To view your usage and costs report, log in to your Database Manager Online Console and choose ”Cost Preview” from the “My Account” menu item.

How to get started with your new cloud database?

• Register to create your new cloud database
  (No credit card information required)
• the first 30 days of using Xeround are free!
• Before your 30-day trial period is about to expire, you will be prompted to enter your credit card information to continue to use Xeround
• You can cancel your account at any time and export your data for use with other tools
• No subscription commitment or minimum charges are required

Check out the first round of short video interviews recorded at the event to find out what MySQL users themselves view as the most important features for their database in the cloud.

Here’s a fun game: What if you had to scale your database based on the weather?!

• How many servers would you need on a sunny day?
• How many would you need when there’s a Tornado alert?
• How fast would you be able to grow from 2 database servers to 2,000?
• Would your users notice?

We spoke with Mark Grennan of Weather Decision Technologies, the company behind the popular iMap iPhone application, to hear about the unique database scalability challenges of an application that’s at the mercy of unpredictable weather.

• How do you service hundreds of thousands of users while maintaining a cost-effective and scalable cloud infrastructure for your MySQL database?
• How do you make sure it’s manageable, and that it’s reacting quickly to the changing needs of the application?
• What if you could go from 1 DB server to 1,000 with no DBA intervention? What if it was that simple?

See what Grennan had to say.

We sat down with Andres Karlsson from Recorded Future to discuss the unique challenges your database faces in the cloud.

• What is the main thing that makes databases in a cloud environment so inherently different from traditional installs? (hint: “S _ _ _ _ _ _ L”)
• Do vendors REALLY understand how the cloud works and how to achieve high availability and scalability for your DB in the cloud?

See what Karlsson had to say.

What level of elasticity do you expect from your database in the cloud?

• What is your DB size today?
• How big do you think it’ll get?
• How many users do you have?
• How many users do you think you’ll have a year from now?
• A month from now?
• Tomorrow?

See what Karlsson thinks of these questions and what he perceives as REAL flexibility and elasticity of your DB in the cloud.

The Xeround cloud database originated from a deep understanding of the unique challenges that your database faces in the cloud, and was designed with an important key value in mind: simplicity.

We really listen to MySQL users – Our main features, such as auto-scaling and built-in replicas and automatic failover, are all aimed at taking the pain out of scaling and maintaining high availability of your DB in the dynamic environment of the cloud.

Check out the 2nd installment of videos taken at mysqlconf, or see more videos on our YouTube channel.

Popular Open-Source Databases

MySQL and PostgreSQL are both open-source databases developed for mass adoption that offer a relatively cheap option to developers for various use cases. These databases are very simple to install and operate on a single machine with local storage. Other configurations are possible, and different advanced options were developed along the years to enable using central storage or different clustering options. Having said that, most of MySQL/PostgreSQL databases installed use the simplest configuration, since for many people, installing these databases in the more advanced configuration isn’t quite as simple to deploy as one would hope.

Alongside the simplicity issues, many popular applications, such as WordPress, Drupal etc., include setting up a simple instance of the common open-source databases as part of their installation process, usually using default locations for local hard drives for data storage.

This kind of default installation is based on a static infrastructure approach. It assumes a server that’s attached to the network. It retrieves an IP address and once the database is installed and running, users can access the DB via different tools like MySQL workbench or a simple MySQL command-line tool.

Traditional Enterprise Databases

The more advanced and powerful databases are ones like Oracle or MS-SQL Server. Such databases are usually part of a more complicated and advanced IT infrastructure, in which there is a central storage, like Netapp or EMC, and the database is installed on more than one machine, with high-availability option and a powerful server that can deal with a large user base, such as SAP, Peoplesoft or other large-scale applications.

These databases have strong dependency on the storage solution, which provides the database with powerful I/O capacity, thanks to the large amount of drives that it holds and advanced storage features like snapshots, backup, caching etc., This configuration is also suited for static IT environments – meaning environments that are not virtualized or cloud-based.

Using Oracle, for example, in a similar setup as MySQL or PostgreSQL on a single server is possible – however it will have little advantage over the open-source free options.

Hybrid Databases Infrastructure

The next level in IT deployment is virtualized environments that use a virtualization infrastructure like VMware to decouple the applications and databases from the physical infrastructure they run on. Virtualization provides more flexibility and speed in setting up and deploying new applications. It is also easier to change configuration of existing deployments on such environments.

Because many large enterprises have legacy datacenters or traditionally installed servers, many times virtualized environments reside side by side, and can even be interlaced, with traditional IT infrastructure.  In hybrid environments, it’s possible to find central storage solutions and large oracle instances next to virtualized servers. Often, Hybrid environments are more convenient for the enterprise as they offer maximum flexibility while maintaining the existing investments in expensive infrastructures, as well as keeping most internal operational procedures and systems.

In these environments it’s easy to find application servers running on virtualized servers, using traditional Oracle instances, next to already-in-place applications running on dedicated servers.

Traditional databases like Oracle can be used on such environments, but more often than not it is MySQL that is deployed on virtualized environments.

Another observation I can make in this context is that mostly, the more important and critical applications are using Oracle / SQL-Server and not MySQL, therefore, most data remains out of the game when virtualization and flexibility are concerned.

A New Breed of Databases: Lives in the Cloud / Born for the Cloud

Cloud environments are actually more limiting than hybrid environments, as they usually employ commodity infrastructure and hardware more than the costly, sophisticated components, such as central storage or high-end servers.

Data in the cloud is one of the greatest challenges these days. The MySQL / PostgreSQL type of usage patterns – characterized as non-critical data, relatively low volume and small databases – have given rise to various solutions of open-source databases deployed in the cloud: such as installing PostgreSQL / MySQL on a cloud instances (MySQL on EC2 for example), or Amazon’s RDS-provisioned MySQL, with read-replica options, backups and fully managed service.

Newly announced Oracle on Amazon RDS provides enterprise-level database on the cloud environment. However, looking at the configuration of Oracle on RDS – it looks like Oracle on EC2 is not the same as Oracle in an enterprise datacenter. I believe Amazon did right by not bending its strict policies and by sticking to its standard configurations, but in this case an RDS Oracle instance – even a large one – will not truly be able  to service a  large high-volume application – since it  is a single commodity machine with limited I/O capacity and networking. Take away the central storage- and performance takes a hit.

Since Oracle RAC is currently not available on Amazon, I guess that the main goal achieved by having Oracle on the Amazon cloud is compatibility. Oracle-based applications would now be able to run on Amazon seamlessly. This type of databases can live in the cloud despite their none-cloudy roots.

Hardly any SQL database solutions are built from the ground-up for the cloud, thus removing any I/O or performance barriers.

Such solutions have to be fully distributed at ALL levels so that they no longer rely on a traditional set up of high-power central storage. And – as we can attest to first-hand here at Xeround – creating a truly distributed DB that’s cloud-native is no easy matter.

Such a database must have several access points, a scalable and distributed SQL engine, and a distributed data store. It also needs to be very tolerable/agnostic to changes in the underlying infrastructure, including the removal (intentional or because of a system failure) of entire parts of the infrastructure it runs on.

All this has to be wrapped in an “RDS” like management layer and provisioning interface. Only a native-cloud distributed database would be able to replace the enterprise-geared Oracle or MS-SQL, keeping critical applications’ data with high user volumes.

To this point, only one database today does all of that: Xeround Cloud Database.

Xeround cloud database was designed for the cloud. Its architecture is comprised of multiple independently scalable layers with dynamically-provisioned virtualized components. Xeround database is always available, its data store layer replicates the data multiple times across several hosts to ensure that data is not lost. Its distribution and ability to further distribute a single instance when needed allows it to utilize the networking and I/O capacity of multiple machines in the cloud, thus removing the single-server barriers for any usage pattern.

In our white paper we describe in detail how Xeround’s architecture is unique and different from traditional databases and how it maximizes the cloud infrastructure to provide customers with the level of performance and capacity that they need, and keep serving their needs as they grow.

Xeround database is the only fully featured database that was born natively for the cloud – dynamically provisioning cloud resource to seamlessly configure and optimally run your database in the cloud.

Itamar Haber – Xeround’s AVP Ops & Solutions – walked us through the stages in the application deployment life-cycle, and demonstrated how easy it is to use Xeround with your MySQL app.

Watch the webinar recording to learn how to:

1. Create your new fully-functional Cloud Database in seconds

    

2. Connect your application to it

    

3. Enable Auto-Scaling – You’ll see a live demo of how your database automatically scales across multiple nodes when more size or throughput are needed, and shrink back when it is underutilized.

   

   You’ll see how “plug-and-play” and seamless the scaling experience is: Scaling is done with no service downtime, and is completely transparent to the application: no code changes required to your application and no need for architectural or code scaling considerations (memcached, sharding etc.).

4. …AND FOR THE GRAND FINALE: See a live demo of how a server crashes and your database survives as if nothing had happened!

   

   Xeround’s unique replicated, self-healing architecture ensures high availability and full resiliency of your database in the event of failure or schema changes.

WATCH THE WEBINAR RECORDING »

Learn about Xeround’s key benefits of high-availability and automatic scaling, and how you can guarantee no downtime and optimal resource allocation for your database — all with a click of a button!.

This goal gives rise to endless dilemmas and design considerations that we face while trying to deliver the best user experience and the best service to our users.

One such “dilemma de jour” that I thought would be interesting to share: What’s the best way to serve customers our unique dish of high availability, with no single point of failure and with load balancing?

Unlimited scalability via automatic front-end additions

An inherent capability of our distributed storage engine is the existence of multiple front-end nodes, which connect to our backend (which is also distributed on multiple nodes.) This multiple front-ends allow us to grow in throughput and number of connections beyond the limit of any single machine. This growth is not only unlimited, but extremely granular- in the sense that we can add just the right amount of extra resources required by the database, with no need for over-provisioning or being limited to Instance sizes, such as in the case of Amazon RDS. The automatic scalability is done in a way that is transparent to the application and with no downtime.

The application can open connections against all front-ends for both load balancing and for high availability.

Neat capability, right? But now, let’s consider this: How do we best deliver this feature to our customers?

Delivering high availability while not compromising automatic scaling:

1. The easiest way from our perspective (but the hardest from the user’s perspective) is to just provide users with the multiple front-end addresses and ports and let them handle it on the application level. Users will have to manage connection failovers, load balancing, etc. Best case scenario? They would be able to take advantage of a MySQL driver that has some of this capability built-in (Java Driver, for example).

   The main disadvantage of this implementation (aside from the extra difficulty on the user side, which goes against our value of simplicity,) is that it limits the automatic handling of scale-in and scale-out events. One of the main advantages of Xeround is our granular, unlimited, and automatic elasticity – which also manifests itself in our ability to add and remove front-end nodes as needed. With the above implementation, we don’t have any control over the connections, and therefore we would not be able to handle scaling automatically. The best we could do in this situation is send an email informing the user of the addition of a new front-end (A subtraction of a front-end node is even more difficult.)

2. Another alternative, probably the easiest from the user’s perspective, is to embed high availability into the driver itself. In this scenario, the driver will be supplied with the initial front-end details and would be updated automatically with any additional front-ends. The driver will balance the connections between front-ends, handle failover automatically, and move connections seamlessly in scale-in and scale-out cases without closing the connection on the user side.

   The problem with this approach is the need to support a multitude of drivers (due to the variety of platforms, programming languages, frameworks, etc.) This would also require an intrusive change on the user side, which we try to avoid, as some users may be reluctant to embed new components into their application and prefer to use the wealth of well-known and community-backed drivers.

3. The third alternative – the one we currently employ – is a balancer component on our servers, which is installed with each database instance. This component takes care of balancing and availability between all the front-end nodes and seamlessly moves connections when we scale in or out (This is why we do not use a standard balancer or Amazon load balancer.)
   

   Today, we expose to our users three IP addresses for those balancers that are used to access the database. The application connects to any of the IP addresses, and the balancer routes the SQL requests to any of the database’s multiple front- ends.

   The three IPs are provided for high availability so that you can failover from one IP to another in case of failure in either one of them.  The failover mechanism can either be coded in the application or, in some cases, implemented by a driver or even a middleware.

   Xeround’s auto-healing mechanism employs a “stand-by” machine, which, in the case of failure, takes over the failed machine components and preserves the same IP as the failed machine. However, it could take a couple of minutes for the process to complete, in which time failed requests sent to the first IP would need to be re-sent to one of the other IPs. Although users do need to take care of (some) of the failover between the balancers themselves, they also get unlimited front-ends for automatic scaling and for load balancing between the nodes to improve performance.

   Another downside to the implementation of our balancers is that some MySQL features are lost because the client is not connected directly to the MySQL, like SSL connections and host-based security are. These are all features we are working to support in upcoming releases of our balancer component.

   In the future, we plan to support failover between the load balancers in a way that will not require tweaking your app; this would be supported with a DNS that routes to the active balancer.

Let us know your thoughts on high availability – and how would you like yours served! :)

First things first: During the Amazon outage, Xeround costumers did not suffer any disruption to their live DB instances! The recent outage was due to an Elastic Block Storage (EBS) service malfunction. Since Xeround’s database is in-memory and we only use EBS for checkpoints and redo logs, the recent outage did not interrupt running instances despite the fact that we were on the same availability zone.

With our users’ database service uninterrupted, let’s discuss what we did experience:

1. A handful of newly registered users encountered problems when trying to create a new DB instance on our EC2-US-East datacenter and were directed to our other datacenters on EC2-EU-West and on Rackspace. This happened because we could not connect using Amazon’s API to purchase additional machines, and the space on our pre-provisioned servers had been exhausted. (BTW – besides Xeround, it seems that the only ones that survived the Amazon outage were those that  massively over-provisioned – such as Netflix. However, for many of our users, the entire point of moving to a cloud database is to save cost, meaning they wouldn’t need to over-provision to ensure availability.)
2. The Instances’ backups were unavailable, as Amazon’s EBS was unavailable and we provision EBS units for our backups.

Hopefully we won’t experience another large-scale cloud outage anytime soon, but we all have to face the facts: in the dynamic environment of the cloud – server crashes, hardware malfunctions and other manners of blips in the “availability” skies – these are all part of the territory. The trick is to expect it and to be able to address it in a way that is:

1. Transparent – So that the application is unaware of it
2. Immediate – So it won’t affect the availability of the service
3. Painless – So you won’t lose sleep over availability issues or send your developer/DBA home with a headache every day trying to keep up with maintaining the service.

How does Xeround handle high availability?

Our native cloud service was designed with a deep understanding that maintaining high availability in the cloud is inherently different from maintaining high availability in your traditional on-premise datacenter. In the cloud, high availability isn’t just about hardware resiliency anymore. You can’t just plug in an extra power supply or network card, or swap hard drives, etc.

High availability in the cloud depends on:

1. The availability of ‘more of the same’ resources
2. The ability to dynamically provision them across any and all datacenters/configurations – be it within the same datacenter, across regions, across availability zones and even across cloud providers.

In the cloud, there isn’t much that can be done to lower the chances of a machine failing, but in case it does fail – or more accurately: WHEN it fails – you want to be able to seamlessly provision a new one on-the-go and maintain service.

You start the “resiliency-chain” by launching a new machine to replace the one that has failed on the same availability zone. If that fails, you’ll want to expand to another zone or region, and sometimes you’ll even want to have another cloud provider altogether to be on stand-by for failover purposes.

Another point worth mentioning is that high availability in the cloud is optimal for stateless applications, where the ability to spawn resources at will is very helpful and powerful. Thus, your architecture should be leaving the “statefull-ness” in one layer: the database. So, despite its “statefull” nature, the DB itself should be able to handle high availability.

What goes on in Xeround’s backend to enable high availability?

Xeround’s distributed architecture spreads the data across virtual partitions, with each single partition replicated across multiple servers. If a server fails, all the data is still available in the surviving replicas and the DB is operational. As the self-healing process kicks in, replacement servers are acquired on-the-fly and re-sync is executed from the remaining replicas.

Xeround’s backend is extremely flexible and supports various options for high availability. Our technology allows us to arbitrarily set the number of data replicas that we will manage as well as set the role each plays and the location each resides in.

Presently, our service is offered with two active-active replicas, both residing in the same data center (and availability zone) as means of protection against  a server’s failure.

Down the road, we plan to have a multitude of high availability options, most of which we have already deployed on our on-premise realm:

1. Geo-distribution for read-intensive applications (where write performance can endure latency) – we have successfully deployed setup on 3 remote DCs across the US, where writes are performed synchronously (thus the high latency) and reads are served from the local copies. In the cloud, this model is transposable to the availability zones of a single region with replicas managed at all zones offered within the region. Alternatively, the same can be applied to achieve high availability across regions.
2. Active/Passive or Active/Active with automatic DRP – using this model, we manage 5 replicas of the database: 3 are in the primary datacenter and 2 at secondary datacenter. This allows us to withstand both failures of single machines at each site as well as a failure of an entire datacenter. Under normal conditions, writes are replicated synchronously in the primary site and a-synchronously to the backup site. In cloud terms, the different sites can be at different regions/datacenters or even cloud providers.
3. Another, and perhaps simpler, approach we’re considering is having the automated backups we provide to our DB instances copied to other cloud providers, which would allow users to restore an instance on another cloud provider. Because Xeround is vendor-agnostic, we can run on any cloud provider, allowing you to seamlessly migrate between clouds with no need for code or architectural changes.

There are many options for deploying high availability DB architectures, and we believe the cloud provides many opportunities to deliver them. This allows the application layer to remain stateless and highly available on its own.

With Xeround’s self-healing mechanisms, failover is handled automatically, saving you the headache and configuration updates to ensure your DB is always on. I believe this is what the cloud is supposed to provide: freedom from tedious IT operations, which lets you focus on what really matters – the application itself (and your Spring break plans)!

It’s a great opportunity for me to catch up with fellow MySQL/cloud/open source developers and see what’s buzzing. (And like all truly great events- it kicks off with a party – which i do well :))

So here’s my mugshot- in case any of you are attending and want to come and say hi (a Hi with a beer in hand is even better!)

I’m very interested to know what our users and the SQL community has to say and how they view Xeround.

In a nutshell– i’m probably as hard-core developer as they come. So if you have any questions regarding our product; or any problematic queries; or you may feel that somehow things that are suppose to work one way are not exactly working; or you have any input and want to share your views with us – well, I’m the guy to talk to – either to answer your questions or to just blame for things :)

A little bit about myself:

I’m the team leader for Xeround frontend modules, which are responsible for SQL parsing and data fetching from the backend (the sweet spot where things can go wrong :)).

I’ve been with Xeround from 2006 and executed various roles in the company, mainly focusing on frontend development and customer deployment.

I’m a realist – so no BS. If you want to discuss the nitty-gritty – I invite you to either catch up with me at the un-conference this weekend, or shoot me an email to ilan.bronshtein@xeround.com

Hope to see you at OpenSQL Camp,

Have fun!

Ilan

This is great news for cloud users and a major milestone in the industry. Most cloud providers create their own (closed) IaaS, PaaS and other *aaS, but CloudFoundry brings a new and refreshing message to this industry.

Being an open source project and integrating quite a few other powerful open-source solutions, CloudFoundry can create a whole that’s larger than the sum of its parts – it supports multiple frameworks, cloud providers and application services, providing developers with maximum flexibility and freedom of choice (no vendor lock-in!).

CloudFoundry’s stack includes virtualization technology, application platforms for Java and Ruby, a few data storage solutions, and a cloud management framework. In my view, it offers a more comprehensive solution than other previous attempts at similar initiatives (such as OpenStack).

With CloudFoundry, VMware demonstrates  the value of their investment in SpringSource as an application platform and how well the application layer can bond with the infrastructure layer to build a more robust foundation for the cloud.

These days, VMware is demonstrating their stack on a live cloud, which will definitely boost evaluation by developers and enterprises that are  looking for a more streamlined and flexible cloud development-to-production on-boarding process. Hopefully, this will increase adoption of the CloudFoundry stack in both private and public clouds.

CloudFoundry also has another possible side effect on the growth and distribution of the cloud environment: Many infrastructure companies such as Telco’s, web hosting giants, and similar companies that keep crunching the numbers with license costs and operational costs, just can’t make it work. CloudFoundry may just be the solution to enable them to jump more quickly on to the cloud-providers cart, and offers cloud services on top of their existing infrastructure.

To quote from one of my favorite Seinfeld episodes – “The Bottle Deposit:”

NEWMAN: Wait a minute. You mean you get five cents here, and ten cents there. You could round up bottles here and run ‘em out to Michigan for the difference.

KRAMER: No, it doesn’t work.

NEWMAN: What d’you mean it doesn’t work? You get enough bottles together…

KRAMER: Yeah, you overload your inventory and you blow your margins on gasoline. Trust me, it doesn’t work.

JERRY: Hey, you’re not talking that Michigan deposit bottle scam again, are you?

It seems like VMware might just provide the right-sized truck with free gasoline to make it work…

Compared to Microsoft Azure, this is a completely different ball game. Azure is not open source and it is also very much bound to (and by) Microsoft technologies. Mobility and flexibility is not an option in such a setup, and customer lock-in is guaranteed. The same goes for Salesforce.com. With CloudFoundry, cloud users and infrastructure providers could take advantage of a flexible and growing ecosystem to facilitate their cloud endeavors.

As a player in the cloud database domain, Xeround is independent  from any specific cloud environment. Our technology is cloud-agnostic in the sense it can run on any cloud service provider. One of the most important values we bring to our customers is allowing them the flexibility to choose between various clouds or moving from one cloud to another with no need to change their application code or setup. CloudFoundry provides similar freedom of choice by allowing their users to migrate their CloudFoundry-based applications between cloud providers.

These days, we are working on integrating Xeround DBaaS with CloudFoundry to enable CloudFoundry customers to benefit from the most advanced database technology in the cloud. Since Xeround’s database is MySQL compatible, any MySQL-based application running on CloudFoundry can be easily migrated to a highly scalable, highly available and fully managed database service, with all the “comfy” features that can make “life in production” so much easier.

I think CloudFoundry is a great strategic move by VMware, which will surely position it as a top cloud player in the market. Look forward to Xeround on CloudFoundry soon!

According to the 451 Group, NewSQL refers to “various new scalable/high performance relational database products and services which are designed to bring the benefits of the relational model to distributed architectures or to improve the performance of relational databases…”

Aslett lists several categories of NewSQL vendors: MySQL storage engines (ScaleDB, Tokutek), hardware and software appliances (Clustrix, ScalArc, Schooner), transparent sharding technologies (ScaleBase, CodeFutures), new databases looking to replace MySQL (VoltDB, JustOne DB, NimbusDB) and “NewSQL-as-a-Service,” where Xeround’s cloud database is categorized. (Looking at the companies mentioned, I believe the positioning of both GenieDB and Akiban remains to be seen addressed).

NewSQL Solutions – Cloud Database Services vs. Hosted Solutions

In addition to the differentiators between the various NewSQL solutions that Aslett proposes, I’d like to add a couple more definitions into the mix to better describe the “NewSQL” database arena in order to distinguish between hosted/appliance solutions and native cloud Database-as-a-service (DBaaS) solutions.

1. What’s considered a cloud-enabled database?Aslett did not use the term “cloud database.” I would maintain that a cloud-database is one that’s built from the ground-up optimally for the cloud environment, providing “natural” and unlimited elasticity by using only cloud resources.Tools, applications and solutions used in a traditional on-premise and/or hosted environment simply don’t cut it anymore on the uniquely distributed environment of the cloud.  To be able to really take advantage of the benefits of the cloud, a cloud-enabled solution needs to be designed, built and deployed in a cloud fashion, so that the core technology relies on virtualized resources with the cloud as an abstract management layer on top.

   Simply running a traditional hosted database in a VM is not sufficient for providing a database service that’s optimal for the cloud.

2. What’s considered a Database-as-a-Service? In my view, a Database-as-a-service means the focus of the developer is on the application and not on the database backend. A Database-as-a-Service is supposed to provide the user with the peace of mind knowing that high availability, elastic scalability and distribution (across clouds/zones) are all taken care of in an on-demand plug-and-play fashion. And what’s more, the user would only pay for what he actually consumed (the cost reduction promise of the cloud) and not for the dedicated servers he reserves for future use (as with traditional on-premise datacenters).

With all the various NewSQL solutions listed by the 451 Group and looking at the two points raised above, Xeround is the only NewSQL solution to offer a native cloud Database-as-a-Service. The other solutions – all viable ones for what they’re designed for – range from various downloadable plug-ins, engines etc., to middleware-like tools to boost read scalability (not write) and hardware/software appliances. (As you can see from our feature comparison table, Amazon RDS offers a DBaaS solution, but it is simply an implementation of MySQL on EC2, not a cloud database.)

At Xeround, we combine the best of both worlds: NoSQL and SQL (Does NewSQL sound familiar? :-)).

Underneath the hood, we’re a fully virtualized cloud NoSQL database (DHT + distributed b-tree indexes and object store,) and on the forefront, we have a customized parser that enables us to offer various database flavors which currently expose MySQL via the storage engine API.

With the on-going addition of cloud service providers and automation capabilities to take the pain out of scaling your database in the cloud and maintaining always-on availability, Xeround DBaaS is the most optimal solution for your database in the cloud.

Check out Razi Sharir’s – Xeround’s CEO – video interview

Watch the full-length video (13 minutes):

or watch the Quick-View (3 minutes):

At the conference we announced availability on the Rackspace cloud and our industry-first auto-scaling cloud database. Both announcements generated overwhelming response and kept the Xeround team and myself extremely busy at the event (to be honest, ever since the conference our R&D and Ops teams are working hard to keep up and meet the demand from our users – but that’s always a good problem to have ;-))

During the conference I was primarily busy with three things: attending the tutorials and technical sessions, giving my talk on Running Your Database in the Cloud (download the presentation slides) and speaking to the various people that stopped by our booth to discuss their DB needs in the cloud.

In short: Geek Talk! Which I thoroughly enjoy.

MySQLconf Tutorials and Sessions

The tutorials and sessions were a pleasant surprise both in terms of the technical expertise and also in terms of the turnout.  With as many as eight sessions happening all at the same time – I found myself often required to make tough decisions regarding which session to go to next. With Xeround providing a cloud database I naturally selected those sessions that are more relevant to cloud deployments and database design.

Amongst the sessions I attended, I would mention Giuseppe Maxia’s Replication Techniques tutorial, Anders Karlsson’s talk about managing Large datasets on Amazon EC2, Sarah Novotny’s session about a complex, highly distributed MySQL deployment, and of course “Ridiculously Easy & Seriously Powerful Cloud Database” by our very own  Itamar Haber (which you can also find the slides for here).

It was interesting to see that many users face similar problems around the growth in data size and availability issues, driving various solutions using existing MySQL capabilities or new ones. At the same time, none of these seemed to provide a comprehensive, easy to implement solution.

Running Your Database in the Cloud

My talk – “Running Your Database in the Cloud” – addressed the various challenges users face when migrating their on-premise database to the cloud infrastructure. These challenges, namely Availability, Scalability, Manageability and Cost can be addressed in two approaches:

1. A DIY approach (purchasing machines, installing and configuring MySQL etc.)
2. Opting for a Database-as-a-Service (DBaaS) solution.

I discussed the different solutions offered in the market today for each of the challenges, hopefully providing useful information to the attendees that are about the face these challenges.

At the start of my talk, I tried getting a feeling for the number of users already running their database in the cloud. To my surprise, the percentage of attendees that attested to having any sort of cloud experience with their DB was fairly low – around 10%. However, I learned that while many still run their database in their on-premise datacenter- they are working on migrating it to the cloud- but were concerned by the overhead of maintaining scalability and availability for the sensitive database tier on such a dynamic environment– so let’s hope Xeround’s service would be relevant for them in streamlining their cloud database experience :)

If you attended the MySQL Conference & Expo held last week in Santa Clara, don’t miss out on your chance to win yourself a brand new iPad!

Register to create your cloud database with the promo code printed in the conference event guide- and enter our weekly iPad drawing – winners announced every Sunday until May 8th.

(and congratulations to William Brown from DC-Energy - our first iPad winner)

The company itself seemed like your average run-of-the-mill startup: serious-looking people quietly swearing at their screens (which to my horror, displayed Linux prompts), punctuated only by the occasional scream from the direction of the QA group.

I was assigned to the XDB team, which stands for Xeround Data Blade –  our distributed, scalable storage backend. The XDB is responsible for distributing and storing data on multiple backend servers, while maintaining high availability. It also has the ability to adapt its size (internally as well as externally – by throwing additional blades into the mix) to user requirements, so that at the end of the day, we don’t use more system resources than we actually need, and users are only billed for what they use.

How hard can it be? I asked myself. To be fair, they did let me read documents for a week or two, but then I was thrown head-first into an overwhelming mass of “under the hood” low level code and complex distribution algorithms.

Luckily, being an experienced startup veteran, I was equipped with all the necessary tools to cope with the steep learning curve ahead: caffeine, a sleeping bag and a shovel. Don’t ask me about the shovel.

Gradually I was sucked in, discovering never ending layers of depth and challenge in the code, from the very lowest levels of data compression and memory optimizations, to relatively high level concepts (remember, this is the backend; what is high level to us is, to most, an obscure implementation detail) such as data distribution, consistency and transactionality (is that even a real word?).

An even greater challenge for me is to make the connection between my day to day tasks and user level SQL queries. Since the user’s queries are highly compressed and optimized by our front end, what we end up getting in the backend sometimes reminds me of the Matrix movie- you’d have to be Neo to see the SQL through all those bits and bytes.

Keeping the user’s perspective in mind can be incredibly challenging when you’re writing code to reduce memory fragmentation or digging into a core file to find out what went wrong – but precisely here lies the greatest motivation – in the end, all those nights of debugging and days of coding, all that haggling with the product people and stealthy tiptoeing by the QA room, all those things translate into something that someone, somewhere, is using to store data that is actually important to them! And as you know, there is no greater satisfaction for a software engineer than to know that their code is being used in the real world. OK, maybe becoming ludicrously rich, but you know what I mean.. :)

First day was a success: Our demo received great feedback; we had great interest following our latest announcements and got to meet a lot of interesting people to discuss their database needs in the cloud.

We’ll be posting the video recording of our session soon – so look out for that! In the meantime, check out some photos from the conference:

View more photos from the event on our Facebook album.

If you’re attending the conference, be sure to stop by at our booth (#407) for some giveaways and your chance to win an Android Tablet, and come attend Eran Levin’s session @2pm today!

Xeround’s cloud database architecture is designed to be vendor-agnostic, meaning it can run on any cloud service provider. Our vision is to enable true (and simple) elasticity and high-availability for your database in the cloud, regardless of where you choose to run your application.

This latest addition of Rackspace to our database service is a major step forward for us in realizing our vision of “Xeround, now playing at a theatre Cloud near you”.

By offering our customers multiple cloud platforms to choose from, they can avoid vendor lock-in and run their database on any cloud provider they choose. On top of that, they have the flexibility of seamlessly migrating their DB between cloud providers without any code changes to their applications.

Xeround’s database-as-a-service is already available on Amazon EC2 in the United States and in Europe, and on the Heroku platform. These past months we’ve received a lot of requests from our current users that are already running on Rackspace to support their environment. We’re always trying to address the feedback we’re getting from our users –it’s great to be able to meet the demands we’re seeing in the market by expanding our service to support Rackspace.

When signing up for Xeround, our users can now choose to create their cloud database in Rackspace’s data center. Initially, we’ll offer a limited beta on Rackspace’s cloud in the US, then we will move on to support Rackspace in the UK within the next couple of months.

We’re hosting a joint webinar with Rackspace on May 3^rd @ 2PM CST – Register for a live demo of our cloud database service to see how easy it is to create your database instance, scale automatically as needed, and even survive a server crash.

Learn more about running MySQL on Rackspace.

Xeround is the first to offer robust elasticity with automatic rule-based scaling for MySQL databases in the cloud. Scaling up or down is done with no database downtime and is transparent to the application, meaning no code changes are required.

A little bit of background:

Having spent most of my career around databases and the applications that use them, I can attest from experience that scaling the database tier is a major problem in the dynamic environment of the cloud.

Scaling an application (by adding additional servers and load balancers) is pretty much a no-brainer, and many cloud providers offer that. Some, like Amazon EC2, even offer the automatic addition of servers to scale an application once CPU usage is high.

On the database tier, things are very different: scaling a database in general is no trivial task. In the cloud, it is WAY more difficult because the database is statefull - unlike the cloud’s stateless environment.

Scaling a database requires:

1. Additional server(s)
2. Configuration
3. Synchronizing all the data
4. Changing the application’s code to recognize the new architecture and to take advantage of the additional resources
5. Ensuring the data is always synchronized – which is difficult since most databases do not support a Master-Master configuration
6. And lastly, the icing on the cake: In “shared-nothing” architectures, adding nodes for scalability requires re-partitioning the data. This may call for additional application changes, and in any case it requires a “Partitioning-Event,” which means database downtime.

If you’ve ever tried it, then you know that scaling your database can be done, but it requires a lot of manual and seemingly never-ending work. Once you’ve gone through all this trouble (and risked loss of business due to downtime or any migration issues), you…

1. Either repeat it again every time you need the next level of scalability
2. Or get caught in this back-and-forth routine: Scale-up, then once the peak is over and you need to reserve resources –  you repeat the process to rollback to your previous install; then scale up again, then scale down again, and up, and down, and so on…

The “dance” of the DBA isn’t such a pretty one.

Scaling a database is tedious, painful and potentially risky in the sense that it can cause a temporary denial of service. Furthermore, you often need to commit to a larger machine (over-provisioning) for seasonal peaks. The rest of the time, those resources go underutilized.

Naturally, you want to ensure elasticity and availability of your database, but you don’t want to be bogged down by the manual configuration, optimization, management, development, or god-knows-what required to make sure your database is running smoothly.

Introducing Xeround’s Auto-Scaling capabilities:

Much of our focus at Xeround is on simplifying the way databases are managed in the cloud – supporting true scalability and high-availability in a way that’s as plug-and-play and as automated as possible.

In comes Auto-Scaling:

1. The system identifies when more resources are required – either in DB size or throughput – based on the threshold the user defines.
2. Your database automatically scales across multiple nodes when needed, and scales back down when it is underutilized – no over provisioning.
3. No database downtime – re-partitioning and resource allocation are done on the fly.
4. Scaling is transparent to the application – no code changes or any architectural considerations are needed to support scaling.
5. Unlimited linear scalability for both database throughput and size.

To enjoy auto-scaling, all users need to do is log in to their Xeround Database Manager console and define the threshold at which they want the database to automatically scale up. By the same token, when the database is underutilized, automatic scale-down shrinks database resources to save costs while ensuring that the system will continue to function without disruption.

Auto-scaling is offered in addition to our on-demand scaling capabilities, where users can scale their database instance up or down with a single click from within the Database Manager online console.

Auto-scaling and the dynamic allocation of resources are also key to Xeround’s ability to bill users based on actual usage, and not by a pre-set instance, which often results in over-provisioning. As Xeround’s auto-scaling feature develops, users will be able to configure advanced rules and policies for automatically assigning resources to their database as their application demands.

To summarize:  Scaling your DB in the cloud just got a hell of a lot easier!

Very exciting! :)
Give it a try »

(feel free to print this photo for future reference so you can spot us on the conference floor ;-))

In this photo:
Standing-up: Itamar Haber – AVP Ops & Solutions ; Avi Vigder – Chief Architect ; Eran Levin – VP R&D. Sitting: Avigail Ofer – Director of Marketing ; Hamutal Mazor – Director of Product  ; Razi Sharir – CEO.

If you’re attending the conference, come say hi!

Stop by our booth for some swag and your chance to win an iPad; Catch up with us for a chat about your database in the cloud (among other things), or just chill with us at the evening reception (we’ll buy you a drink :))

Be sure to also check out Xeround’s sessions at the conference:

A ridiculously Easy & Seriously Powerful Cloud Database – See it in Action!
Tuesday, 3:05pm, Ballroom H.
Presented by Itamar Haber – AVP Ops & Solutions

Running Your Database in the Cloud
Wedensday, 2:00pm, Ballroom G.
Presented by Eran Levin – VP R&D

Hope to see you there!

At this point, I find that the article begins to drift into a “No-No-Land” from my perspective. It goes on to describe how to make your own cache on the application side, and then proceeds to making concessions on the business side in order to better deal with the performance issue.

When you’re at the point where you’re thinking of building your own cache or throwing away important business functions, I think this is a good time to move to a more suitable solution for your database. You need a database that will provide efficient performance, stability and scalability; one that is “future ready” for your application’s anticipated growth.

As an application developer, I think it would be better to focus on your code and not have to  deal with database scaling and performance issues, even as your site grows more than you might have anticipated (which is good news!)

Given limited time and financial resources an out-of-the-box solution, such as MySQL, is rather limited – providing you with only “one degree of scalability”. The article outlines several ways to achieve that one degree of scalability. However, when the need arises for increased scalability,  and developers try to achieve the next level of scale, things get too complicated and too fragile. And that’s when you start trying to build your own cache… doing without some of the functionality you planned for… and basically fussing and worrying about IT and your database, instead of improving your application.

Xeround cloud database is a great solution in this case. It offers great scalability and worry-free service that provides high availability with zero maintenance. What I particularly like about Xeround’s solution is that in most cases, it can help developers avoid  even the initial obstacles of setting up their own database and making sure it suits both their initial needs and the needs of future expansion.

Xeround provides a great solution for small-scale applications that will grow into a larger scale application, starting free of charge and progressing to a  “pay per use” pricing model, which ensures your costs are highly correlated to your actual business activity.

Haven’t tried us out yet? It’s never too late! :)

1. Schema design – Since different databases have different ways to optimize the raw logical schemas, the schema is designed and optimized for a specific database.
2. Toolset – The different tools that are used for the configuration and management of the  database are also frequently tied to a specific database technology. For example, MySQL workbench or PHPMyAdmin are used to manage MySQL databases.
3. Cost – same as with cars: there are the high-end “Ferrari” like databases, and the more economical ones. Since many of us can’t start with a Ferrari right off the bat, the initial costs of running a database should also be considered.
4. Simplicity and manageability – When choosing an ‘exotic’ database solution (like an exotic car…) expect high maintenance costs. These could be, for example, either in the form of work hours or in costly change management procedures. Those high maintenance costs come in addition to the risk of service outage and having to dig in an endless number of files or logs to find out what went wrong and how to restore the service.
5. Feature set – The database has to satisfy both the functional and operational needs of the application. Things like online backup and full ANSI SQL, and so on.
6. Supported platforms – Preferably, the database should support as many platforms as possible, to allow maximum mobility and flexibility.
7. Performance – This is an important issue, and may be an app-killer to your killer-app… However, this needs to be put in the right perspective, and performance objectives for the database should be defined based on use-cases. Nonetheless, this is a tricky one; databases behave differently when dealing with more or less concurrent requests. An important database capacity is its ability to scale if needed, to meet the performance objective under higher load.

As understood from the title of this post, my mind is already made up on the right choice for your database in the cloud :)

Why MySQL? Well, the most important thing to me is that I do not want to be blocked by a specific solution or locked to one solution — on any one of the considerations listed above.

MySQL is, in fact, more than a database. It’s an open, well developed and broad ecosystem, with many options and flavors in place. This allows me to create my application based on MySQL and then, when it comes to deployment, I can choose between various options without changing anything in the way I work:

Plain MySQL is simple enough to install and operate for the skilled developer. Alternatively, I can use a free Xeround database instance, which will work seamlessly with my MySQL application. For Ruby and Heroku developers, Xeround Cloud Database is one of the DB add-ons.

When my application matures, and picks up more audience and load, I can move to a fully managed service like RDS, or upgrade to a full scale database with Xeround, which gives me peace of mind as for my database scalability and availability. Another option for the very skilled developers and system engineers is MySQL Cluster, which can help me grow my database and throughput gradually.

In most cases, choosing MySQL would be the right decision because of its rich and diversified ecosystem. Databases should not be showstoppers, and MySQL gives me great choices for the different phases in my application lifecycle.

Xeround’s MySQL façade implementation is a great addition to this ecosystem. It enriches it in the most suitable way for the cloud. It is not aiming only at the “big fish”, like MySQL Cluster does, but providing a managed database service that can suite the full lifecycle of the application – for both the “Average-Joe” developers and the bigger fish.

While there’s no arguing that proper planning and research are required in developing the right cloud strategy, I’m also a firm believer in experimenting and prototyping — and cloud resources, by their nature, lend themselves quite effectively to this task.

While brainstorming for your organization’s “master plan” for cloud domination, you should start putting your ideas to the test TODAY to quickly assess what the best approach is to taking advantage of the cloud to best suit your business’ needs.

Many teams in various organizations worldwide are taking the ‘light’ approach to familiarize themselves with the unique infrastructure of the cloud and to optimize it to their needs.

How to go about it: The Bottom-Up Approach

In every organization there are applications/systems that are less critical (in the sense that they do not constitute the core IP or value of the organization). Moving these applications to the cloud is quite low-risk to the business, yet it carries direct and immediate value both in terms of cost and operation efficiency. Such applications can be, for example, online support forums, blogs, downloadable technical materials such as white papers or user manuals, or even the product’s catalog.

This “trial-and-error” approach of experimenting with isolated projects and gradually moving your business’ operations to the cloud – starting with your less-critical ones – has immense value. This “bottom-up” tactic creates a knowledge base and experience that can continue to be built upon to promote a more reliable transition to the cloud. This has proven to be a great low-risk way for enterprises to continuously tune their cloud strategy, making sure it progresses in the right direction. Furthermore, the actual experience gained by various teams is also effective in disarming any resistance and concerns about moving to the cloud that may arise.

A Step-by-Step Guide: Moving Your Application to the Cloud

To be practical, here is a simple blue print for migrating simple applications to the cloud.

In this example, we’ll use an online business catalog that will be deployed in the cloud with relatively minimal effort and cost. We’ll also review some very cool extra benefits that can be obtained when taking this a step further.

Online Catalog example:

Before deploying your product catalog in the cloud, some decisions need to be made:

1. Which  Content Management System (CMS) should you use to publish your content?You could choose an off-the-shelf CMS framework such as Drupal, Joomla or the Ruby based Spree and customize it to suite your needs. Another option is to code your online catalog in Ruby, PHP, or another web language (sometimes this is the quicker approach for migrating legacy applications to the cloud; it maintains all existing features  and data models).
2. Which infrastructure should you choose – a managed or a non-managed platform?
   Amazon’s servers infrastructure requires IT resources on your end for setting-up, configuring, and managing the environment. On the other hand are managed hosting platforms, such as Heroku (which is for Ruby applications only). With Heroku and its add-ons, implementation time can be faster, and scaling and management of the application is provided as a service.
3. Which data service should you choose?
   On the data front, you also have two options: manual installation and configuration or a managed data service. For simple data storage and retrieval, Amazon S3is a great solution for media files such as images or videos. It is easily accessible from the web front-end nodes and provides high data availability.For more extensive data needs that require a database for robust querying – you could, again, choose between doing it yourself or selecting a managed Database-as-a-Service solutionto guarantee high-availability and proper scaling. There are a few examples for managed databases in the cloud, and naturally I recommend ours as the easiest to set up and start running :). Xeround offers auto-scaling, which simplifies dealing with additional throughput when needed and also guarantees availability, even in the case of failure. In the future, we plan to also provide a limited-size database for free.Regarding the migration of your database to the cloud – In many cases, I think the schema for the database can be similar to or a subset of the original database. This would make the population of the database by an ETL tool easier.

Although this may seem like a complicated project (hopefully not :)), the purpose  of experimenting in this case is to learn how cloud environments behave, and how the cloud, and the platforms running on it, can save you both time and money.

During the migration process of their chosen application, I believe developers will realize that the cloud infrastructure will empower them to focus on the coding and development of their application and can greatly simplify their deployment operations. That way, they can get more done from a small team or even a single developer – leaving cloud’s various services to take care of the IT hassles. With cloud resources and development/production stacks acquired and auto-managed with just a click of a button, a lot of time is saved for what really matters.

And for the finale: the cool extra benefits organizations can gain by moving to the cloud:

For large enterprises, business frequently comes from across the globe. Being able to serve customers from a closer geographical location provides a better user experience, consequently increasing conversion and revenue.

Once the cloud blueprint is implemented on a single data center, it can easily be replicated to additional geographical sites like the US, Europe or Asia (where Amazon EC2 or other cloud service providers operate their data centers).

Free tools, such as ipligence or ip2location, can be used to redirect users from various geographical locations to the closest deployment of the website. Database replication configuration can be used to sync all the sites (as opposed to using ETL), and S3 can be used as a source to Amazon CloudFront for distribution of media files.

These extra benefits may prove to developers and to enterprises how powerful cloud services are when dealing with global production environments, all while having to do less coding and being able to use more available tools to get things done quickly and at the right scale.

The cost of getting your application in the cloud:

Surprisingly, the cost of such a prototype is relatively low since many of the required services or technologies are either available completely free or charge, as a limited ‘freemium’ version, as a trial version, etc., In addition, less resources are needed during development, and smaller scale servers can be used, which in turn carry lower monthly costs. The most expensive resource for a developer would be their time – but it would be a worthy investment!

BTW- you may also wish to check out some free development resources in the cloud to help with your development efforts!

The survey was conducted among 677 IT directors in large enterprise organizations, and the report discusses the infrastructure and topology of cloud environments alongside the unique additional limitations of the cloud, starting from access networks, such as mobile networks, high latency, bandwidth, all the way to the application server and the database.

One of the major findings from the survey was that “the majority of organizations… are greatly aware that poor performance of cloud applications has a direct impact on revenue.”

Naturally, I would like to focus on the database side. The database, in most cases, is the last stop in the application-fulfillment chain and is also one of the most sensitive parts in it. It is the most difficult tier to scale, and, even when scaled, it comes with a price of additional networking and latency.

A database that does not scale, such as a standalone database (the simplest and most used configuration today on the cloud), may lead to very unstable performance distribution (as we have seen in our Amazon RDS benchmark). As the number of concurrent requests grows performance has declined rapidly in a non-linear manner, quickly reaching the point where it is considered to be too slow. Add that to all the other latencies in the chain until the information gets to the end point, and what we will likely experience is a service or application that is not usable and will most likely lead to customer abandonment and possible revenue loss.

Xeround Cloud Database is a great example of how a native cloud database is different from a traditional technology/solution that has been adopted to the cloud environment. The inherent limitations of the cloud are taken into consideration as an integral part of the architecture and engineering of Xeround’s solution, making sure customers get a highly predictable performance model that they can count on.

In the broader sense, I think clouds today are still, in many respects, in their infancy, and there is much improvement ahead of us, both in terms of the infrastructure, especially networking and fast I/O, and with more intelligent ways to manage resources on the cloud and making sure related resources are allocated in an optimal way. For example, the Application Server and the database should preferably be hooked on the same switch – for both improved performance as well as proper allocation: the cloud service provider will not need to allocate costly long path routing resources for the two elements.

We’ve already got some cool press mentions – check out SiliconAngle (“Xeround is on the path for growth, taking on horizontal scaling capabilities and seeking additional points of integration“), Diversity Blog – where you can read more on how we’re different from Salesforce’s database.com offering, and most recently GigaOm.

From our Press Release:

Xeround’s Heroku add-on provides simple one-click integration between MySQL apps on Heroku and Xeround’s Database-as-a-Service (DBaaS).

From the users’ perspective, all they need to do is add the add-on to their application from within the Heroku environment. This automatically creates a MySQL-compatible cloud database that easily connects to their application. Xeround’s cloud database enables Heroku users to take advantage of a highly available and elastic database that can grow in size and throughput as required by the application.

“Xeround is already running on Amazon EC2, and we’re very pleased to announce that our service is now available also to Heroku users as a simple add-on,” said Razi Sharir, CEO of Xeround. “This is just the first of many steps we’re taking to expand Xeround’s database for the cloud, enriching our feature set and enabling easy integration with popular platforms in the cloud ecosystem.”

“We’re excited to have the Xeround Cloud Database available as a Heroku add-on,” said Morten Bagai, Senior Director of Product Management at Heroku. “The cloud, and the Heroku Platform in particular, promises simplicity – both in the development stages and in production. A simple cloud database is therefore great fit for Heroku developers looking for an easy way to ensure a stable and cost-effective database in the cloud.”

Xeround’s database is currently the only horizontally scalable and highly available SQL database available for Heroku users. To try Xeround’s add-on for Heroku – currently in private beta – Heroku users should sign up for the Heroku beta program by sending an email to beta@heroku.com.

And this is me: Avi Vigder – Xeround’s Chief Architect.

Unlike The Brain, I have a cheerful disposition, but much like him, I’m also planning to take over the world :)

Also like The Brain, my diagrams (as you can see above) are all pretty self-explanatory and simple. With just one glance the great truths of life will suddenly become crystal clear to you!

OK, maybe not quite…

While my diagramming skills admittedly need some work – here at Xeround I am responsible for the design of all things “cloud database” – starting from the underlying architecture, technology, and up to the Database-as-a-Service admin tier.

I personally invite each of you to come to me with your questions, whether it’s on how Xeround’s cloud database is set up, how we work, our secret sauce, or how best to optimize your database instance for the cloud. I promise to do my best to answer CLEARLY and avoid diagram illustrations as much as possible.

Feel free to email me directly at avi.vigder@xeround.com. Also, if you’re attending MySQL Conference in Santa Clara – come by for a face-to-face chat!. Like several of my colleagues, I will also be by our booth there- looking forward to talking in-depth about technology.

Finally, a little bit about my background: I’ve been with Xeround since its early beginnings in 2005, when we were focusing our technology on the telco industry. I’ve been involved in the product development since its conception, focusing mainly on the backend.

I especially enjoy the unique challenges of Xeround –  on the one hand dealing with complex database development and on the other hand a highly distributed, fail-safe system that’s delivered to our users in the simplest possible way. Robust database functionality and simplicity are two areas that for long time did not mix (someone mentioned NoSQL J). It’s pretty amazing to see our vision of a software-based, highly scalable and fail-safe database hitting the masses and helping so many of our users deploy their database in the cloud environment.

So don’t be a stranger and I look forward to your questions!

Cheers,

Avi

Only a week to take advantage of savings up to $200!

If you’re planning to attend the event use code mys11fsd for a 25% discount.
Click here to register »

We’d love to see you there!

Internet, e-commerce and web 2.0 projects can benefit the most from using development resources that are in the cloud, such as development platforms (PaaS or Development-as-a-Service), free storage/hosting, a code repository and more.

There are a few reasons for development teams to start using development resources in the cloud:

1. Development Resources - Servers and networking are expensive. When developing in the cloud, most developers would just need a desktop or a laptop, and internet connectivity. For projects that require only a few months of development work, purchasing resources can be very inefficient due to the setup time and the fact that those resources are used for a relatively short time and then become less useful or even obsolete.
2. Collaboration – Shared online environments create a new communication channel between management, different teams or roles, and most importantly – the customer. The ability to try features or functionality as they are being developed, get feedback from all relevant parties, and  demonstrate the success of a development cycle (“Sprint”) in the online environment are all great advantages.
3. Time to market – When people don’t have to spend so much time on setup and synchronization they can deal with the application itself. Another advantage is having the option to test the application at a large scale or high throughput by acquiring large amount of resources (like servers) for very short periods (even only for a few hours), up to the scale at which the actual deployment is planned for.
4. Prototyping or small-scale projects – Frequently, great ideas start small. The cloud can provide a free or low cost environment to test ideas and experiment with them, in a live environment with no need to commit to long-term expenses.
5. Education – Many students need different kinds of resources such as web servers, databases, application servers, etc. for their various projects. Many people may also use such resources to educate and train themselves to become more professional and skilled for today’s workforce. Free cloud resources can make studying a lot easier (Personal thank-you to all the students already using our cloud database — hope you enjoy it J).

Finally, check out some relevant links to development resources below. Drop us a line if you have any recommendations for other resources we should add.

• Hosted code management for free
• Free Linux server on Amazon – 750 hours of shared server (Microsoft has a similar offering on Azure)
• Xeround – Free SQL Cloud Database
• Heroku - Ruby in the cloud
• CloudControl – PHP hosting

Freddy wins a brand new iPod Touch 32GB.

We thank everyone who participated for their time and effort with testing Xeround cloud database. We’ll see you on the next tournament!

Q: Will we have access to the MySQL logs? Slow queries identification would be top of our list.

A: We don’t provide access to the logs, we do however enable our users to monitor database activity and identify queries that cause full table scans. We also provide full support to the <explain> command to provide the execution plan for a query.

Q: Is there a more detailed user guide than what I see on the website? I’m looking for things such as manually backing up a DB (just before a new app deployment), cloning a DB, export-import data subsets between DBs.

A: This functionality is provided through the web user interface, see documentation for using it here. Regarding backup functionality, currently backup and restore can be done using any standard MySQL console. An upcoming feature in the web console will provide this functionality, including the ability to schedule backups, manage backup files, and restore data from those files.

Q:  Any web-based query editors available or is it SqlWorkbench over SSH?

A: Both work well, but we provide additional web-based query module, which can be launched from our Database Manager Console using PHPMyAdmin.

Q. What’s your production timeline and how do you plan to charge when this rolls out to production – By GB, network bandwidth, combo?

A: Currently in Beta, the service is free of charge. We plan to launch commercially by summer.

We are currently finalizing our pricing model – please see structure below:

With Amazon you commit to a preset instance size and pay in advanced for the storage and processing it allows. With Xeround, the pricing would comprise of 3 components:

1. Database size: price per MB of the actual data size (and not per machine 1.7GB, 7.5GB etc.)
2. Ops: either per TRN/SQL ops
3. Network Traffic cost (similar to Amazon)

This model ensures that you only pay for what you use with no need for over-provisioning. Elasticity is supported both for the database size and for the throughput. Our service key offerings of high-availability and elasticity (auto scaling up/down based on the requirement of the app) – which are not supported on Amazon – are naturally included in the price.

Q: How do you handle multi-tenancy and security – is each tenant’s DB a separate instance?

A: Each database is a separate instance and runs in separate processes.

That’s it for this round. You can check some other popular questions on our FAQ. As always, if you have any further questions – don’t hesitate to ask!

If you haven’t already- no time like the present to try out our service: be up and running with your free cloud database in under 5 minutes – it’s truly is that simple!

I figured this would be the perfect opportunity to introduce myself on our blog, and to invite all our followers and users to drop by and meet in-person at the conference.

A little bit about me:

I joined Xeround in 2010 as VP of R&D.

Following my degree in computer science, I started working as a programmer and gradually moved into managerial and product positions. Nevertheless, I have never lost my passion for programming or for the technological challenges of software development.

I joined Xeround because I saw a unique combination of technology, product and market demand – it’s very rare to come across a company that has all these ingredients that are so necessary for success, so well-aligned. At the same time, all three impose many challenges – that keep us driven in our daily work.

Cloud computing is fairly new, and addressing the specific challenges of databases in the cloud is even newer still. This is why I find it exciting – to be on the cutting edge, literally defining the future of cloud infrastructure. My work, together with the R&D team at Xeround, is basically finding ways to solve those day-to-day hurdles that developers, DBAs, and anyone who had their database freeze on him on the cloud face everyday. When we see the market has a clear need for a solution like ours- it’s exciting to rise to the challenge!

Clearly, the challenges on all fronts are huge:

Creating a distributed, highly available and elastic database is challenging on its own. The need for full SQL coverage and competitive performance just adds to the fun. Furthermore, Database-as-a-Service (DBaaS) itself is a relatively new concept (along with Infrastructure-as-a-Service). Hence we face new problems challenges – both on the technical side as well as meeting customer expectations. Finally, the cloud is such a dynamic and unexpected environment – with both its technology and its players still maturing – so there’s never a dull moment.

On a personal note (since life isn’t all about the database :)) – after a long day’s work, besides being with my family, I usually dedicate my evenings to sports. If I’m in an active mood and still got some energy, I play basketball, while on other evenings I settle for watching sports on TV. During the weekends I try to free some time to my two hobbies – hiking and photography, and combining the two if possible. If you’re interested in some scenes from the Israeli landscape – check out my photo album at https://picasaweb.google.com/eran.shvilisrael (note it’s in Hebrew, but the pictures speak for themselves).

Looking forward to shaking hands with some of you at the MySQL Conference – hope to see you there!

And if you ever have any feedback or suggestions about our service- feel free to email me at eran.levin@xeround.com

Get ready for the grand prize next Sunday- as we draw an iPod Touch between all of our beta testers that participated.

To enter next week’s drawing simply continue testing Xeround cloud database and reporting any bugs you may encounter to support@xeround.com

However, as I was assembling my new (high-end :)) desk-in-a-box, I could not stop cursing IKEA for putting the wrong type of screws in the box (too big for those tiny holes), only to find out that it was I who was attempting to put the screws in the wrong place.

The IKEA folks actually did not make a mistake after all and I had to disassemble the thing, re-read the manual and build it again – this time placing the screws in their rightful place.

While I enjoy assembling IKEA desks and cabinets (while I sort out the screws mix-ups), for some of the more “toolbox-challenged” people – the task may not be as entertaining.

Now – from my short-lived career as a carpenter (or really, an IKEA-assembler of sorts :)), to my experience with software development:

Databases for my various applications can be set up in different ways, and in the cloud there are now more choices than ever.

In general, there are two options for setting up your database:

1. The DIY option: choosing a database, like MySQL or Postgres, and installing it and configuring it on a cloud server.
2. Subscribe to a database service: for this option, you can choose a ready-made database service from one of the DBaaS providers on the cloud.

The differences between the two options are huge, and it’s not a case of “always the right decision.” Depending on the resources of a business, some organizations can manage setting up their cloud database themselves, but for others – correctly configuring a database to maintain scalability and high availability on the distributed and dynamic environment of the cloud – the task might prove too problematic and resource-heavy.

Databases especially are a sensitive part of the IT puzzle: they keep all the data, all the contacts, all the invoices etc. Data loss or an unresponsive database are big issues that could have serious consequences for today’s businesses.

While there are some friends for whom I would help construct IKEA purchases, I would not help even my best friend set up his database. Let’s face it – an IKEA chair is replaceable but if your DB breaks it can sink your entire business.

Most databases need care and attention, such as frequent backups, constant monitoring, configuration adjustments and more. In the DIY approach, attending to your database requires adding more capabilities and a management layer around the database itself – such as scripts, external monitoring and more. Not a simple task…

If someone offered you a sofa fully assemble, delivered to your door and at a similar price as IKEA – would you go for that, or would you prefer to run through the IKEA maze, carry the boxes yourself, kill your back lifting and trying to fit those large boxes into your compact car, drive all the way with the long wooden pieces in the back seat pushing you from behind, lift it home, and then… put it all together hoping you get it right :)

I know what my choice would be, even if I could do it all myself.

DIY is often more expensive and requires more time, attention and internal resources. It may also prove more expensive in terms of actual cost – for example, Xeround charges on a usage basis – unlike with Amazon RDS where you pay per instance, resulting in over-provisioning. In the future we’ll even offer a free limited version, making the DIY option unnecessary.

The key differences between the DIY approach and DBaaS:

If you’re debating whether DBaaS is for you, give it a try!

Xeround offers a free DBaaS for your MySQL applications over Amazon EC2 (US East and Europe).  All it takes is quick registration and you’re a few clicks away from running your free, elastic and highly available MySQL database in the cloud!

Heroku users who wish to try this new Add-on need to sign up for the Heroku Beta Group. Simply send an email to beta@heroku.com. Be sure to state your acceptance that info furnished through the Heroku beta program will be treated as confidential until otherwise indicated. Once you’re approved for the Beta Program you’d be able to add this Add-on from the Add-ons directory.

Two more weeks left on our Bug Hunt challenge!

One more $50 Amazon gift cards and the grand prize of an iPod Touch are still up for grabs! So get cracking with the beta testing :)

Hardware has immensely improved in the last few years. A key development in the field is more CPUs/cores per server, providing vast processing power to today’s standard servers. This is amplified with the latest Nehalem architecture from Intel, which enables a much higher level of parallelism due to its new cache memory re-architecture and more cores in a CPU. Standard I/O capabilities have also greatly improved, particularly with high bandwidth and fairly low cost solutions like SATA. In addition, hard drives have also grown significantly in capacity and can now provide terabytes of storage on a single drive. Lastly, energy efficiency has also improved considerably, with lower power consumption across the board.

These key improvements in hardware, which enable users to get even more from their infrastructure, have also found their way into the cloud – where they are used effectively to power this environment.

At the current state, cloud infrastructure has two main bottlenecks that significantly impair cloud services, especially distributed services:

1. Network Bandwidth:

A 1Gb network is commonly used in most interfaces today. Even if multiple network interface devices are used on a single server, their combined bandwidth is still far lower than desired. The relatively low bandwidth in and out of the server prevents the optimal utilization of the server’s capacity. After all, most applications are I/O intensive and not computation intensive.   For example, in a 4 cores Intel CPU the throughput can easily reach 40Gb/sec, yet this power cannot be demonstrated on top of 1Gb networks. (I highly recommend reading this paper from Intel, on a software-switch prototype demonstrating how fast CPUs are today.)

To unleash the power of the server, clouds must provide multiple 10Gb connectivity as a standard. Cloud applications by nature require extensive network use. Once the STANDARD shifts from 1Gb to 10Gb network interface, the cloud as a whole will enjoy better connectivity and will be better equipped to deliver on its major promises.

The following illustration shows how CPU and memory are utilized depending on network connectivity. To clarify, this assumes I/O is done through the network, such as when using Amazon’s EBS for example.

The illustration shows a 1Gb network connectivity fully utilized for networking and I/O, while CPU and memory bandwidth remain under-utilized. This results in unbalanced server utilization, where the CPU and memory are under-utilized and the networking and I/O are over-utilized.

A 10Gb network connectivity fully utilized for networking and I/O, brings CPU and memory bandwidth to 100% utilization – A well-balanced server can easily utilize the full potential of all of its components.

2. Storage

Another major pain in the cloud is large-scale persistent storage and the way it deals with random access patterns, or in short – hard drives…

Those old beasts are not suitable to serve one of the most common data use-cases – a database.

Despite the improvements in hardware, hard-drives for the most part still exhibit their inherent limitations of seek time and read/write serialization, resulting in poor support for random access. Hard drives have zero level of parallelism, and they are highly limited by their physical mechanical structure, which forces a delay of ~10ms on every move of their heads across the magnetic plates. It is less of a limitation when serving use cases like video streaming (as those make good use of hard drive high capacity and high throughput in sequential read patterns), but prove inefficient for heavy read/write operations that are often required by databases.

SSD is an evolving technology that resolves the random access pattern issues, while still providing large-scale storage capacity and long term data persistency. SSD is built on “electronics only”, with no mechanical parts that cause delays. SSD is a perfect solution for databases, despite the fact that today it is much more expensive than standard hard drives on a per GB price (price ratio today is about 1 to 5). However,  when considering the overall cost and value of this technology, and its effect on server utilization and performance, this price may not be as high. Another significant advantage is the fact that there is no need to make any changes in software to benefit from SSD technology, as it uses the same interfaces as standard hard drives, namely, SATA interface.

The effective throughput of SSD for random data access can reach 30-50MB/sec. Contrast that with a standard hard drive’s effective throughput of 100K/sec (when trying to read 1K records from random locations on the drive).  While SSD keeps improving, hard drives have made very little improvement in the last 20 years.

The following illustration shows how CPU and memory are utilized when standard hard drives are used, compared to SSD.

Ten hard drives at full throttle (random access) barely scratch the performance of a server.

Ten SSDs bring server utilization to a very reasonable area, leaving space for additional tasks such as web apps to run effectively on the same server.

When implementing these two great improvements, the cloud can then be truly exploited in an effective and efficient manner. Their impact on key critical components in the software funnel – such as distributed databases – is immense.

Bottom line – 10Gb network and SSDs are an absolute necessity in an advanced cloud environment, leading to improved resource utilization and further adoption of the cloud.

10Gb networks and SSDs are hopefully coming soon to a cloud service provider near you!

Two additional $50 Amazon gift cards and the grand prize of an iPod Touch are still up for grabs!

So get cracking with the beta testing-
Report a bug, get a reward. Fair, isn’t it? :)

In this benchmark we measure throughput and latency under increasing concurrent users to compare the performance of Xeround cloud DB to that of Amazon RDS.
The benchmark is using standard DBT-2 as the benchmarking framework.

The results show that in most cases, particularly as the number of concurrent users grows, Xeround performs much better than RDS. Xeround cloud database represents a leap forward compared to “old school” database technology, offering significantly better handling of large numbers of concurrent users, and very stable performance and latency under high loads.

See the full benchmark »

Update: a number of folks & folkesses have contacted us with requests for more information on how the benchmark was carried out. We’ve compiled the following list to answer these questions – let us know if we missed anything!

• Tool:
  • We used the TPC-C-variant DBT2 tool, specifically dbt2-0.37.49
  • We compiled the benchmark as a stand-alone, single process
  • The benchmark executed on an EC2 large server instance (m2.4xlarge)
• Settings:
  • Workers per warehouse were set to 1
  • The number of warehouses was increased with each cycle as shown in the report
• Cycles:
  • Run time was set for 300 seconds per interval
  • No ramp up or ramp down between cycles
  • Each cycle was executed 3-5 times against both platforms

We also added a couple of indexes to the benchmark’s database schema – here are their definitions:

• CREATE INDEX ix_new_order_wd_btree ON new_order(no_w_id, no_d_id) USING BTREE
• CREATE INDEX ix_stock_si ON stock(s_i_id)
• CREATE INDEX ix_district_d_w_id ON district (d_w_id)
• CREATE INDEX ix_order_line_ol_owd_id ON order_line(ol_o_id, ol_w_id, ol_d_id)
• CREATE INDEX ix_order_line_btree_ol_wdo_id ON order_line(ol_w_id, ol_d_id, ol_o_id) USING BTREE
• CREATE INDEX ix_customer_wd_id_last ON customer(c_w_id, c_d_id, c_last)
• CREATE INDEX ix_orders_wdc_id ON orders(o_w_id, o_d_id, o_c_id)

This add-on, currently in Alpha, enables Heroku users to easily create their Xeround cloud database instance in one click from within their Heroku environment.

Interested in testing your Heroku application with this add-on? 
Email us to request an invite »

Congratulations to Graham Weldon, from CakePHP, on being our first weekly winner. The issues he reported during his evaluation of our cloud database service earned him a $50 Amazon Gift Card! (Check your email Graham :))

We want to thank all the beta testers who are taking part in the Bug Hunt – your efforts are greatly appreciated.

Three additional $50 Amazon gift cards and an iPod Touch are still up for grabs!

Next week’s winner would be announced on Sunday, and be sure to stay tuned for our 1st prize winner coming March 6th!

We’re excited to offer one of our beta testers the opportunity to join us at the biggest MySQL event of the year – for 4 days of “Everything-MySQL” – where we pick up the check!

Win an all-inclusive trip to the conference, including:

1. Air fare
2. Hotel accommodations
3. Conference admission pass

What do you need to do?

1. Try Xeround’s MySQL Cloud Database
2. Test our cloud database with your sandbox data or with your live apps
3. Complete our short feedback survey to let us know what you liked or didn’t like about the service
4. Email us at info@xeround.com to share why you needed a cloud database solution and what you thought of Xeround.
   Tell us:
   • How do you plan to use Xeround with your live applications?
   • What benefits do you look for in a cloud DBaaS? How were these addressed by our service?
   • What did you think was the best feature of the product? What still requires work?
   • Describe your experience with the product
   • And anything else you’d like to share…

From all submissions, we’ll choose the most interesting use case as the winner!

The winner will be featured in a case study and will be awarded an all-expense-paid trip to the 2011 MySQL conference!

You can submit your entries until April 1^st.

So get cracking – we’d love to meet you in-person at the conference! :)

*Note that by participating in this challenge and sharing how you use Xeround with your app, you acknowledge that we may share this information publicly at our discretion as part of various marketing efforts (case studies, etc.).

Database-as-a-Service (DBaaS), Data-as-a-Service (DaaS) and Cloud Storage all relate to data management in the Cloud. The differences between them lie mainly in regards to the forms of data being stored and how the data is managed.

Cloud Storage services such as Amazon S3 or Dropbox enable users to store data in the cloud as they would on any other storage device, only the data is uploaded to a virtual storage.  By ‘data’ we’re generally referring to documents and objects being stored in the cloud for backup, DRP or distributed retrieval.

DaaS (Data-as-a-Service) describes the ability to define data lists in a cloud service and then query against this data.  DaaS is not to be confused with a database. Unlike database solutions, DaaS cannot be accessed via common interfaces (SQL or alike). DaaS is suitable only for basic data management querying and manipulation – think of a Microsoft-Access hosted and run by someone else and offered as a service.

DBaaS (Database-as-a-service) is the most robust data solution being offered as a service. DBaaS offers full-blown database functionality, accessed via common set of APIs.

In a DBaaS, the database tier in the backend is being overseen by a management layer that’s responsible for the continues monitoring and configuring of the database to achieve optimized scaling, high availability, multi-tenancy and effective resource allocation in the cloud. In a DBaaS solution, the developer is spared much of the hassles of the tedious ongoing DB management tasks and operations, as those are automatically handled by the service itself.

Cloud applications commonly connect to a database that is also being run on the cloud. It can take the form of a manually configured database, like MySQL on an Amazon EC2 instance; preconfigured MySQL, like Amazon RDS; or a native cloud Database-as-a-Service like Xeround’s MySQL cloud database. What we’ve seen is that native cloud databases are better equipped to optimally use cloud resources and to guarantee availability and stability, compared to “patched” software being adopted for cloud use.

When choosing a data solution for the cloud, application developers and IT managers need to asses their needs and the nature of the underlying service they seek. Do they only require a simple remote storage/ data retrieval, or do their applications require more extensive database operations? One also needs to assess the app’s growth potential and future uses and transactions.

And naturally, if your app does require a SQL database in the cloud – Xeround is here to help!

That’s how we feel after reading Relational Cloud: A Database-as-a-Service for the Cloud – a paper submitted to the 2011 Conference on Innovative Data Systems Research (CIDR) by a group of students and professors from MIT. The paper describes the main aspects of a project called Relational Cloud that is an effort to investigate technologies and challenges related to DBaaS within cloud computing.

Besides coming up with a great name for the project, the team that is responsible for the effort really put a lot of thought into identifying the main challenges for a cloudy DBaaS that are: efficient multi-tenancy, elastic scalability and privacy. The paper goes on to present the approaches that they had developed to meet these challenges and emphasizes an underlying notion of workload awareness that is ingrained in their overall design of the system.

Reading through the paper, one (and especially us) cannot ignore the similarities between this project and Xeround’s DBaaS. Moreover, even the differences between the two serve to show that there is more than one way to achieve a goal.

We’re thrilled to see such significant progress that’s being made on the same challenges that we set out to solve with Xeround. If you haven’t already- why not register for the beta to try us out and see how we’re doing (you may even win yourself an iPod Touch!)

Some technical glitches are to be expected from a beta service. The feedback from the community and the bugs reported to our Support team have been invaluable to us as we work on improving the features and stability of our product.

We greatly appreciate everyone’s enthusiasm and help with beta testing –so we want to give something back! That’s why we’re happy to announce Xeround’s Bug Hunt Sweepstakes! One lucky beta tester will win an Apple iPod Touch, and 4 additional winners will each get a $50 Amazon gift card.

To win the prizes, all you need to do is register for the beta, test Xeround, and report any bugs you might discover to our Support Team.

• Every bug that you report before March 5^th entitles you to one sweepstakes entry. The more bugs you find – the more you increase your chances of winning.
• From the submitted and approved bugs:
  • Every week, we will randomly select the weekly winner, who will receive a $50 Amazon gift card.
  • The weekly winner will be announced on our blog (so on top of everything, you’ll get eternal fame too!) on the following dates: February 6^th, 13^th, 20^th, and 27^th.
  • At the end of the sweepstakes, after March 5^th, we’ll randomly choose the 1^st prize winner, who will receive an iPod Touch 32GB.
• Note to our Private Beta Testers and to anyone who has already reported bugs: We keep meticulous records and the bugs you’ve already reported in the past will count towards the Bug Hunt Sweepstakes.

Happy Hunting! :)

We look forward to hearing from you.

In the cloud environment, on the other hand, decisions about infrastructure, specifically databases, are often driven by more objective considerations.

The model proposed here suggests a simple yet powerful way to compare database solutions. The model is based on three dimensions:

1. Scale – The level of scale required by the application. Scale encompasses measurable parameters such as size, throughput, and high availability.
2. Simplicity – Keep it simple for development and operations.
3. Cost – How efficient the solution is in relation to the application requirements. For example, high fixed costs are often inefficient. If we could directly tie the cost to the scale and usage while keeping it lower than fixed costs- that might be more efficient.

Introducing: The Box

Let’s consider the box in the diagram. Its attributes can vary along three dimensions:

1. The Cost Axis: Varies from zero cost to excess cost, which means that whatever solution is chosen, the cost structure will never be efficient. This applies in the case of over-provisioning for example, where users are required to over-pay for resources that they do not necessarily consume.
2. The Simplicity/Complexity Axis: This shows the “sweet-spot” of the Simple Enough” point – where beyond this point a given solution becomes too complex for the application’s needs.
3. The Scale Axis: Varies from zero-scalability to the point of Excess Scale. The optimal point is the right scale to accommodate the needs of the application. Beyond this point, any addition in scaling capabilities will go un-utilized.

The Blue box in the diagram represents the optimal zone: The optimal zone is where the infrastructure chosen best serves the application’s operational requirements at any given time. A solution that is located within this blue box would be considered an optimal one in terms of cost, scalability and simplicity.

Now, let’s move from the theory to some concrete examples:

Large Databases Use Case: Is Oracle RAC the right solution?

With Oracle RAC, the scale that should be chosen for an application should be one that can deal with predicted peak points. Thus, the average utilization of the database is generally low. If we consider the 3D Box model – on the Scale axis, Oracle would be on the Excess Scale point compared to the required average usage.

Oracle pricing model is by CPU. Since the infrastructure mandates over-provisioning – the Cost axis would point at Excess Cost.

An Oracle on-site is relatively high maintenance and requires a dedicated DBA for on-going maintenance. Therefore, on the Complexity axis it would be positioned as a complex solution.

Overall, when positioned within the 3D Box diagram, Oracle RAC would be located outside the optimal zone of the blue box.

MySQL Instance on EC2:

This solution is most suitable for smaller scale requirements. In this case, scale is not an issue but simplicity is the key factor.

A standard SQL over Amazon EC2 will be optimal in terms of simplicity of the solution and will require lower maintenance overhead.

On the cost factor – since Amazon’s instance cost is fixed, the question is: Can the right EC2 instance be purchased for the application’s needs – both initial needs and in preparation for future peaks?

When there is a need to scale, the DB can be migrated to a larger machine up to a point (limited by Amazon’s instance sizes). However, this may lead to low average utilization of the server, and therefore would also not be the optimal solution.

If we position the Amazon EC2 setup on our 3D Box diagram, we can see that the Scale and Complexity are within the optimal range, yet the Cost is higher than optimal.

Amazon RDS:

Amazon RDS’ architecture is closer to a Database-as-a-Service, and is best suited for small to medium scale requirements. On the Simplicity axis, RDS provides relative ease-of-use for DB operations. Yet, Amazon’s cost is still based on fixed server pricing, which means the cost is higher than the optimal point due to low utilization of the server or due to over-provisioning.

So, placing RDS within our 3D Box model – its overall positioning would still be “out of the box” in terms of optimal solution, mainly due to the cost factor.

Xeround MySQL Cloud Database-as-a-Service:

So how do we measure up?

Xeround cloud DBaaS is another step forward:

Xeround is suitable for databases of various sizes, from small to large ones. It offers a pay- per-use pricing model, which effectively links the cost factor to the scale factor. Users pay more when there’s increased demand and when you are effectively showing growth and require more resources.

One of the unique features of Xeround is the ability to scale exactly to the needs of the application, with no over-provisioning and with no operation downtime. Your application can get the exact scale it needs from the database, as your DB scales across multiple nodes when you need it to and shrinks back down when you don’t – and pricing is based only on actual usage and scale.

On the Simplicity axis – Xeround offers standard SQL interface and does not require any code changes to your application or any need for you to be bothered with the configuration and on-going maintenance. Xeround seamlessly configures and optimizes your database’s performance and availability in the cloud, with all DB management tasks and daily operations done automatically as the application demands.

Turning to our 3D Box diagram once more, Xeround is positioned well within the blue box, showing optimal infrastructure both in terms of scale, simplicity and cost.

So – for once – staying “inside the box” is a good thing! :)

Contrary to common perception, Amazon RDS is not a truly elastic cloud database service, but an implementation of MySQL on EC2.

While Xeround runs on Amazon EC2, our database is vastly different than Amazon’s MySQL offering. Xeround is a native cloud database, which offers a simple database-as-a-service that seamlessly configures and optimizes your MySQL’s performance, elasticity and availability in the cloud.

Xeround’s DBMS automates management tasks that are aimed to ensure high availability, elasticity, and geographical distribution, as well as on-going tedious daily operations.

So with a click of a button you can set up your highly-available and elastic database on the cloud.

With Xeround MySQL Cloud Database You Get:

1. Rule-based Auto Scaling up & down with no downtime – vs. manual scaling with down time on RDS
2. Pay per actual usage – vs. pay per instance size, resulting in over subscription
3. Xeround never fails – even when Amazon’s instance fails: Xeround offers a highly available, self-healing, database, with no downtime. Amazon RDS cannot guarantee no downtime, both planned (4 hour / week maintenance) and unplanned
4. Unlimited database size – vs. limited to Amazon’s instance sizes
5. Database configuration does not require code changes to your application (replication etc.)
6. Xeround is agnostic to cloud service providers – your database will run with low latency on any cloud service provider of your choice

Check out our detailed feature comparison table »

Click to view comparison table

Today we’ve expanded our Cloud DBaaS offering for MySQL apps to run on Amazon EC2 in Europe. This is in addition to our already active datacenter on Amazon EC2 in the US.

Xeround’s multi-geographic capability lets organizations choose to run their database instances closest to wherever their applications are running. By having both applications and the databases hosted on the same cloud and in the same geographical region, companies that rely on Xeround can address the key issue of performance in a cloud environment and significantly decrease latency of their applications.

When signing up for Xeround and creating your new cloud DB instance, you can select the data center closest to where your application is hosted.

Hundreds of users have already tried Xeround since we announced our private beta in September; many of them expressed interest in a datacenter in Europe. With the expansion into Amazon EU, we are also announcing that our MySQL cloud database beta service is now available to the public.

We’ve recently released an upgrade version that addresses many of the performance issues, stability and bug fixes that have been reported by our valuable beta testers during the private beta stage, so if you haven’t already- be sure to try us out!

And as always– stay tuned for more exciting news coming up. In addition to offering multiple data center locations, we will support multiple cloud providers over the next year. Because Xeround’s cloud database is agnostic to your choice of cloud provider, those that choose Xeround can avoid vendor lock-in and migrate seamlessly between different clouds.

This is one of the things Xeround can help with – reducing the need for complexity in the application, at least on the database front. Xeround cloud database can scale automatically to suite the application needs for throughput and size, no need for reconfiguration, code changes or complex database migrations.

1. Database models and alternatives settle back on SQL

   The recent hype around NoSQL will continue to decline, as DBAs and enterprises return to the proven SQL solutions. As it turns out, the promise for great scalability and distribution that drove the NoSQL adoption early on could not compensate for the lack of the very basic transactional and relational functions, which are core requirements for any commercial application.In turn, alternate use cases will be found for NoSQL, and early on signs indicate it is picking up on DW/BI uses – where extra-large data sets and types encompassing high performance key.

2. Enterprises and Developers will realize that databases in the cloud have specific needs

   Discussion around databases in the cloud is maturing. On the one hand, enterprises and developers started realizing the benefits of the cloud, while on the other hand, they become aware that the cloud is not only about abstraction of virtualization.Databases are not only the most mission-critical part of the application, but it’s also becoming abundantly clear that databases in a cloud environment are inherently different than traditional installs. This increased attention given by CIOs and IT professionals to the unique requirements of databases in the cloud will grow stronger in 2011.

   It has become evident that running a database in the cloud is not as simple as installing it over a virtual machine – mostly because of the fluidity of resources and the highly fragmented nature of the cloud. Those who have made their first steps in cloud database architecture discovered that achieving high availability, scalability and multi-tenancy in a cloud setup is more difficult than first perceived.

3. 2011 is the year of Database-as-a-Service (DBaaS)

   The promise of databases in the cloud goes beyond mere cost reduction and operations efficiency. It is all about simplicity and a “worry free” philosophy.The cloud DBaaS delivers seamless configuration and optimization for your database performance and availability on the cloud. Setup issues and the on-going DB operations become automated or as easy as a click of a button away.DB management tasks aimed to ensure high availability, elasticity, and geographical distribution, as well as on-going tedious daily operations – that typically require long and detailed planning, extensive resources and complex execution – all become as simple as click-and-go.

   2011 will be the year of “plug-and-play” for databases – where you could be set up with your highly available database in the cloud in a matter of minutes. Plug-and-play also implies no vendor lock-in, which is a major barrier in current setups. DBaaS will also be implemented in private clouds, as more and more local platforms mature and become similarly plug-and-play.

   Last but not least is the smooth transition – typically no code changes are required in order to run your database in the cloud. In fact, architectural and code scaling considerations such as memcached, sharding etc. become redundant.

4. Native SaaS pricing

   The SaaS model comes as close as it gets to on-demand computing, where consuming software over the cloud as a service disarms the need for oversubscription (and over-paying) for users and/or for resources.2011 will be the year where databases and infrastructure models are pressured into applying the same “keep it simple” SaaS model: pay per actual usage.
   
   The vision behind the cloud being an on-demand per-use framework does not coincide with the architecture and pricing models of leading services today, such as Amazon RDS, or even databases which are manually configured on pre-set virtual machines. Traditional pricing models for enterprise databases will adjust to reflect the flexibility and the dynamic nature of the cloud.

5. Elasticity is the key – and in 2011, we expect it to be automatic

   At the end of the day, the availability and potential growth of your application is only as good as the elasticity of your database tier. If previously developers had to choose between elasticity and simplicity of NoSQL, and the transaction and query capabilities of SQL – 2011 will bring more and more live applications that prove you can have it both.Elasticity reflects all gating clauses for the application growth (data and throughput), scale, availability and distribution. Offering a dynamically cost effective and operations efficient service boils down to an essentially elastic nature.

   Do not get confused with linear scale that can be typically achieved by scaling a database up (in the same node). It is about scaling out – across nodes: In the enterprise world, being able to burst out for resources or spill-over means scaling out. This is a mandatory requirement for the Cloud Olympic Games.

   True to the plug-and-play ease of use principle, in 2011 we expect elasticity to be automatic. Why be bogged down by manual monitoring and configuration, when you can have your database solution ensure automatic scalability, tuning and backup.

Vote Now »
(Requires a LinkedIn account)

..Don’t we know it! :)

The data management needs of large scale services such as web search engines and global social networking cannot be properly served by ”old school” data management systems. Comparing today’s hardware to the past, your average $200 netbook has the computing power of a $10M mainframe of the 90’s. Yet the data growth we’re experiencing these days far exceeds hardware improvement and scaling, and many databases cannot be contained in a single server.

Distribution of data across multiple machines enables you to deal with large amounts of data and improve throughput. However, once the data is distributed, it becomes more difficult to maintain data consistency. For example, transactions may change data that resides on multiple servers. To be able to synchronize all the changes made by the transaction into a single known state (before and after committing), a synchronization point is needed, in the form of a transaction state.

Some NoSQL solutions loosen the requirements when it comes to consistency by not supporting transactions, thus reducing the need for synchronization points. This relaxed consistency approach may suit some use cases where consistency is less important, but would be unsuitable for others.

Let’s consider the example of social networking applications. In these applications, operations over the data objects are well spread, and there is a low likelihood of collision to start with. On top of that, data is mostly added and rarely updated. By contrast, NoSQL’s compromise of consistency can create major problems for most applications, some of which include CRMs, ERPs and trading applications — those cannot accept data integrity inconsistencies, even if they are temporary.

To date, I have yet to see proper research that recommends a viable approach to dealing with the problem of data inconsistency. Most applications are very intolerant to the “third state of a bit” –computer systems by nature are very dichotomic — it’s either Yes or No. There is no easy way to obtain a programming paradigm that deals well with an unknown state of data.

Unless a worthy solution at the application level is found that can deal with the data inconsistency issues in NoSQL, most applications can only find limited use of NoSQL in the form of caches, accelerators for specific tables, and more.

The question is: can distributed data services (NoSQL) help to scale data, even if it takes into account the existence of synchronization points and their limitations? What would be sacrificed if synchronization and transaction mechanisms were added on top of NoSQL foundations?  The answer is performance. Distributed and consistent data services will always be slower than pure raw distributed data service.

Is sacrificing performance worth it?

Yes. Despite the performance penalty introduced by adding the consistency governing mechanisms, performance would still be reasonable for the majority of applications. It would not be as fast as a single server, all in-memory data service – but for most needs, the performance provided by a distributed yet consistent service would be good enough and comparable with standard database performance.

What do I get in exchange for higher performance?

The gains would be:

• Larger storage space
• X times more throughput than a single node
• More stable and predictable performance
• Better average performance under load

What would be the performance of a SQL implementation on top of Consistent NoSQL foundations?

Because the level of parallelism in a distributed system is high (yes, even with locks and transactions), the average performance of such a solution could exceed that of a standard database if the right optimizations are done to realize the parallelism and distribution potential.

So what sacrifices would I need to make for a distributed SQL database as opposed to a single server database?

When the database load is low, a single server will probably be faster. In this case, parallelism has a smaller effect and single server has no network overheads. Single server solutions have their drawbacks in the form of scalability, availability, throughput and stability, and therefore they are usually not a good solution.

Xeround’s cloud database is a SQL database that combines NoSQL principles to facilitate elasticity, alongside the mechanisms to support locks, transactions and query capabilities as in relational databases. Xeround’s SQL cloud database couples both SQL and NoSQL to create a highly parallel, highly scalable, and available cloud database.

Try it out now!

We thought this would be a good opportunity to suggest our “recipe” for a highly available web architecture and to compare different options. Please feel free to contribute to this thread by proposing your own solutions to “high-availability on a budget.” :)

Here are some guiding principles:

1. The solution must provide high availability and failover at all levels – application tier and the database tier
2. There must be low maintenance overhead
3. A cost estimate per month should be provided

Now, to my recipe:

I thought the best way to approach it is would be from the most common web stack: LAMP. Besides being widely used for web applications and relying on open source, other advantages of using the LAMP stack include its ease of development and management, as well as the maturity of the platform. All of these are factors that affect cost, so taking them into account can save you a lot of money in the long run.

The next logical step is figuring out the easiest and cheapest way to deploy a highly available LAMP-based application.

The ingredients:

1. Two small, standard and on-demand Amazon EC2 Instances, to be used for the Apache PHP
2. Elastic Load Balancing service
3. A small-sized highly available Xeround Cloud Database instance, MySQL compatible

Estimated Cost:
$18/month for load balancing

$0.085/ hour for EC2 instance — for two servers, the cost is about $122

Xeround’s cloud database is free while in beta – you can give it a try, and enjoy the elasticity and high availability that Xeround provides. Total estimated cost, excluding traffic, is around $140/month.

What do you think? Feel free to share your thoughts here and propose other competitive deployments.

Some Thoughts on Database.com and the Cloud Ecosystem:

One of the interesting things about Salesforce’s new initiative is the fact that the database service offered can be used from anywhere, not necessarily from the same location as the database, which is a leap forward in the way applications are perceived today.

Working with a remote database can introduce high latency and slightly less reliable service than running both the application and database on the same premise. However, there are ways to deal with these issues and there are benefits to using the service, even when latency is higher.

One of the things I think Database.com will provide (compared to standard databases) is good scalability, especially for high throughput applications — with relatively the same required investment in terms of budget and administration costs.

In addition, I’m sure Database.com will have beefy network bandwidth compared to major cloud providers, and obviously with Force.com and SalesForce.com, so that applications running on these services could get a higher level of service.

Furthermore, performance and latency can be improved significantly when using a similar approach to stored procedures, allowing the business logic to run in the database, or next to it, thus avoiding too many hops and iterations across the network. So even if this approach swims somewhat against the current in terms of application tiering, it is still a valid solution for very specific, complex database operations.

From the information provided by Salesforce and their demo, it appears they are aimed at more complicated applications that have broad and various needs for data consumption. Those types of applications require all the benefits of a relational data model, as opposed to specific use cases that may gain more from Restful API. The REST/SOAP APIs provided by Database.com are better optimized to work on individual objects rather than complex DB operations. Things like joins implies many REST operations, the use of stored procedures, or – as stated in Database.com FAQ – the use of a third party ODBC / JDBC driver. Regarding transactions -with Database.com every REST / SOAP operation is a transaction.

Many things are still unclear about Database.com and how it is going to operate in different scenarios, but one fact is known: it is based on an Oracle solution which could, in some cases, pose a limit on scalability and elasticity and does not really adopt deep cloud concepts and architectures. As I explained in my previous post on Organic Cloud Services, solutions for the cloud that are not native cloud services carry mid- and long-term implications.

If we make yet another assumption about Database.com’s architecture, we can guess that it employs a serious storage solution (Netapp, EMC etc.) to serve those massive Oracle instances. These have a very high cost compared to organic cloud storage.

Non-organic cloud database services result in future limitations, either in scale, efficiency or costs. Will Database.com be able to compete with similar or better services that have fewer limitations in the long-term and cheaper admin costs?

In conclusion, Salesforce’s announcement strengthens the position of the relational cloud model, mostly because it seems businesses in the real world today can’t find a good alternative to that model to service their mission-critical applications.

I believe the best way to interact with this model is through its natural language – SQL. And here lies part of the problem with Database.com – as it is providing a different interface to the relational model. Developers will need to interact with SalesForce’s database solution using SOAP, or REST APIs and Object Model. This does not prevent customers from migrating to a different database service, but it does make it more difficult than plain SQL. Thus, there is a sense of customer lock-in when choosing Database.com. In addition, do you really want to go into changing the code of all your existing applications only to enable them to work with a new cloud service? What happened to plug-and-play?

SQL=+Simple

With the arrival of cloud computing – which represents a new IT model – databases still remain, in many respects, the exception to the cloud infrastructure rule. When most of the infrastructure is spread across numerous virtual resources, the database still resides on a fixed set of machines, in the cloud or outside of it, and frequently, using a specific storage solution, like Netapp or EMC. This mean that the DB is not an integral and inherent part of the cloud. You could say it’s doing it’s best to come along for the ride – but currently it’s too much baggage for the conventional cloud set-up to know what to do with :)

The Native Cloud Database

Native cloud Databases are using only cloud resources for all their needs. Storage for such a database is based on the servers’ local drives, spread across as many machines as needed, and as allocated by the cloud on standard machines. Alternatively, the storage layer can be based on General Cloud Storage such as Amazon EBS, which is using the same paradigm, but provides Block storage as a service.

DB processes consume fragmented resources that the cloud can allocate to the DB, and elasticity is key – so resources can be returned to the cloud when they are not needed.

Native cloud databases need to provide a reliable view of the database state for monitoring and resource allocation purposes. For example, they need to be integrated with the cloud management system, and allow the management system to control the database and monitor it.

Since data loss is costly, cloud DBs need to be able to maintain multiple copies of the data, so hardware failures could not cause complete meltdown of a system or an application. Alongside this capability, the cloud database needs to be able to “self heal” itself from failures up to certain level.

Clouds run many applications, and as a data service, the cloud database is required to have multi- tenancy, and also to allow different configurations to different instances within the DB.

Why Are Native Cloud Databases So Important?

It is important to have a database as an organic part of the cloud for one key reason: to avoid dedicated and complex maintenance required to “babysit” the odd-child in the cloud infrastructure.

Any non-cloud service will become some kind of an exception which requires special maintenance, skillset, procedures etc. It’s definitely true long-term, but even in their day-to-day operations today, DBAs and System Administrators can attest to how much time and energy (and admin costs) go into monitoring their DB and ensure it “plays well” and is properly integrated with the other components of the cloud.

In addition, non-native cloud services will not enjoy the benefits achieved by natural tenants of the cloud. These benefits include, for example, all the automation, resource-optimization, dynamic networking, and more.

Databases should be regarded as integral part of the cloud so that the IT infrastructure can really be a commodity, which can be bought, traded, re-allocated and moved around as needed.

On the other side of the equation, to live up to the theory, the cloud database technology itself must deliver a convincing paradigm and proof for its ability to keep the data safe, secured and always available, at least on the same level as enterprise databases today.

Xeround’s MySQL Cloud Database is an elastic, always-on database that lets you run your existing MySQL-based application in the cloud.

As we develop our Database-as-a-Service cloud offering, we’d like to hear from you: If you have an application running on MySQL, please help us by answering a few questions about your experiences with databases in the cloud.

To frame the discussion, it’s important to note that my analysis of MySQL and NoSQL’s pros and cons relates to how large, medium and even small businesses today would result to using these databases within their cloud environment.

We are not talking about the mammoths of this world, which deal with monstrous amounts of data and very extreme use cases – these would be willing to pay a high price to find a working solution to their problems. However, for 90% of operations interested in benefiting from the cloud – there needs to be a simpler solution, which can work with their echo system, not to mention within their budget, and still support future scaling and optimal performance.

*Popescu responses to my previous post are marked in Italic.

Why NoSQL

I’d say that data normalization is not a goal per se, but a solution to a problem (data duplication, frequent updates to common entities). But what if this solution is introducing another bigger problem (read JOINs)?

I believe there is considerable value in normalization – in both SQL and NoSQL, especially in read Joins. Non-normalized models mean you are required to transfer a lot more data on the network than you would have had to if you were using normalized data model. Normalized models can bring this overhead to a minimum. I do agree though, that sometimes non-normalized data models can be faster; still, this can also be implemented in SQL.

[Alongside the ability to easily scale, NoSQL] may give you more flexibility in your data model, plus it may be a better (as in operational, complexity, performance, etc.) storage for different formats of data.

Looking at the context of medium to large business, and not huge enterprises with obscene amounts of data (and funds), these could actually be disadvantages rather than advantages, because the IT service in the organization would have to struggle with implementing these new tools and approaches across the organization and get it all the way to production. I’m not dismissing, though, the option of using NoSQL for very specific use cases.

Why not NoSQL

Previously, i had stated that at the system level, data models are key. Not having a skilled authority to design a single, well-defined data model, regardless of the technology used, has its drawbacks.

Actually I think the reality might be a bit different. Because NoSQL imposes a “narrow predefined access pattern” it will require one to spend more time understanding and organizing data. Secondly, the final model will reflect and be based on the reality of the application, on not only on pure theory (as is the case with most initial relational model designs).

I agree this can be good and beneficial for very specific use cases, but the Skillset is still an issue. Who is the right person to design a NoSql schema? What is the price of an error in such a design? Do enterprises today have the tools to lower the risks involved in bad NoSql design? Moreover, what happens when the application needs to get out of the “narrow predefined access pattern”? Say you need to switch engines (you competition had acquired the open source you rely on) – if switching from one SQL provider to another is hard because of deviations from the standard, moving from an entirely different data model is so much more.

At the architecture level, I pointed to two major issues: interfaces and interoperability. Interfaces for the NoSQL data services are yet to be standardized.

The interface limitation is a temporary issue in terms of getting more/better/quicker tooling support and probably a longer term issue for developers needing to learn different models. But as we’ve agreed, NoSQL has a small, predefined access mode and so we are not talking about learning completely new languages.

Personally, I think the real issue is steep learning curve of understanding each of these NoSQL databases semantics and operational behavior then not having a common API.

I agree with Popescu. The API issue is just the shell of the problem, the different data models are the real problem; this is why the absence of clear NoSql standards is so critical.

I claimed Interoperability is an important point, especially when data needs to be accessed by multiple services.

I’m not seeing the problem here. As far as I know each relational database is coming with its per-language drivers. On the NoSQL side, there are already quite a few products using standard protocols.

I think this is a good progress in the NoSql arena. However, many NoSql solutions find it hard to externalize their special features via standard protocols, thus, forcing you to choose between standards, better performance or richer set of features. However, as pointed out, you can work using different protocols from different locations, as needed.

I maintain the operational environment requires a set of tools that is not only scalable but also manageable and stable, be it on the cloud or on a fixed set of servers. […] Operation needs to be systematic and self contained.

Now, this is completely the other way around. If you read any large scale application story, you’ll notice the pattern: the operational costs where a significant factor in deciding to use NoSQL. Just check the stories of Twitter, Adobe, Adobe products, Facebook. Complexity is a fundamental dimension of scalability and right now the balance is towards NoSQL databases .

I fully agree that these kind of companies require special solutions, as well as numerous other organizations such as government agencies, research centers etc’. However, these are the mammoths I’m referring to. I think your average Joe (as well as below-average or above-average :)) will need something else entirely. I also believe that even in the case of the Heavy-Lifters such as the Twitter and Facebook of the world – they will still keep 95% of their databases as SQL, and will look for SQL solutions for the cloud. And also, let’s not forget, that Twitter’s fale-Whale and other similar examples occurred because there weren’t scalable SQL solutions available – which is exactly what Xeround addresses! :).

It is my opinion that a SQL database built on NoSQL foundations can provide the highest value to customers who wish to be both agile and efficient while they grow.

Unfortunately I don’t think that’s actually possible or at least not for all solutions. But If we just want some common access language, we will probably get it.

If, on the other hand, what we want is more tunable and scenario specific engines, we will probably get these too. (nb: as far as I’ve heard the PostgreSQL community is learning a lot from the various NoSQL databases and trying to bring in as many of the good ideas they can).

Agility requires a very flexible solution, based on readily available resources. Agility and Efficiency will allow making changes at a reasonable cost and faster time-to-market. Many companies cannot pay an upfront price for potential growth, therefore, the model I present works well for them. There will always be specific applications that will need special data models, where RDBMS will not be a good fit. But let us not forget, that for general enterprise applications – it’s a practice that has proven itself.

Conclusion

My conclusion is simple. As with programming languages where we are not stuck with COBOL, polyglot persistence is here to stay and it’ll only get better.

I do not see a contradiction between Popescu conclusion and my post. Many companies will deploy NoSQL solutions in addition to SQL Solutions. Plus, with a SQL DB, which is based on NoSQL foundations, you can get the best of both worlds using polyglot. I also believe that SQL is here to stay, and it will get better and more scalable implementations – like Xeround.

Let’s start with a simple question: What is the real difference between NoSQL and SQL?  In my view, the different access patterns provided by NoSQL and SQL result in very different scalability and performance.

NoSQL elements allow data access only in a narrow predefined access pattern. For example, DHT (Distributed Hash Table) is accessible via hashtable API; given the exact key, the value is returned. The access pattern for other NoSQL data services is similarly narrow and well-defined, and as a result scalability and performance structure are predictable and reliable.

In SQL, the access pattern is not known in advance, the tables are modeled, assumptions are made regarding the access patterns, and these assumptions are translated into predefined optimizations like index definitions. SQL is by definition a generic language that allows access to data in various ways. The programmer also has limited control over the execution of the SQL statements; mostly, the database engine is responsible for optimizing the execution of the statements. In other words, in SQL, the data model does not enforce a specific way to work with the data — it is built with an emphasis on data integrity, simplicity, data normalization and abstraction, which are all extremely important for large complex applications.

Why NoSQL

The NoSQL approach presents huge advantages over SQL databases because it allows one to scale an application to new levels. The new data services are based on truly scalable structures and architectures, built for the cloud, built for distribution, and are very attractive to the application developer. There’s no need for DBA, no need for complicated SQL queries and it is fast. Hooray, freedom for the people!

This is no small matter — a good programmer’s freedom to choose a data model, write a program or an application with familiar tools, reduce dependencies on other people, test and optimize the code without doing guesswork or counting on a black box (DB). Yes, it’s slow on the test system, but someone will take care of it later by tuning the DB…these are all major advantages of the NoSQL movement.

And Why Not…

There are some disadvantages to the NoSQL approach. Those are less visible at the developer level, but are highly visible at the system, architecture and operational levels.

1. At the system level, data models are key. Not having a skilled authority to design a single, well-defined data model, regardless of the technology used, has its drawbacks. The data model may suffer from duplication of data objects (non-normalized model). This can happen due to the different object model used by different developers and their mapping to the persistency model. At the system level one must also understand the limitations of the chosen data service, whether it is size, ops per second, concurrency model, etc.
2. At the architecture level, two major issues are interfaces and interoperability. Interfaces for the NoSQL data services are yet to be standardized. Even DHT, which is one of the simpler interfaces, still has no standard semantics, which includes transactions, none blocking API etc. Each DHT service used comes with its own set of interfaces. Another big issue is how different data structures, such as DHT and a binary tree, just as an example, share data objects. There are no intrinsic semantics for pointers in all those services. In fact, there’s usually not even strong typing in these services — it’s the developer’s responsibility to deal with that.Interoperability is an important point, especially when data needs to be accessed by multiple services. A simple example: backoffice works in Java, web serving works in php, can the data be accessed easily from both domains? Clearly one can use web services in front of the data as a data access layer, but that complicates things even more, and reduces business agility, flexibility and performance while increasing development overhead.
3. Moving to the operational realm, here, from my experience, lies the toughest resistance, and rightfully so…The operational environment requires a set of tools that is not only scalable but also manageable and stable, be it on the cloud or on a fixed set of servers. When something goes wrong, it should not require going through the whole chain and up to the developer level to diagnose the problem. In fact, that is exactly what operation managers regard as an operational nightmare. Have you ever tried getting a developer to diagnose why a payment system is not functioning while he’s at a bar and a few beers in? I’m sure the developer’s date would be impressed by his dedication to his work, but that’s a pretty expensive way to impress someone :)Operation needs to be systematic and self contained. With the current NoSQL services available in the market, this is not easy to achieve, even in managed environments such as Amazon.

So, how can we gain the major advantages of the NoSQL approach while keeping the advantages of the SQL approach?

SQL and NoSQL Joined:

A SQL database implementation that uses NoSQL infrastructure is a good solution. A SQL database that is scalable, manageable, cloud-ready, highly available and built entirely on NoSQL infrastructure, but still provides all the advantages of a SQL database, such as interoperability, well-defined semantics and more. Xeround’s cloud database is just such a solution.

This hybrid would not be as fast as a NoSQL service, but it may be good enough for the 80% of the market that needs stronger scalability and organic cloud behavior.

Such a solution would also allow migrating existing applications easily into cloud environments, thus protecting huge investments made by organizations in those applications.

It is my opinion that a SQL database built on NoSQL foundations can provide the highest value to customers who wish to be both agile and efficient while they grow.

There are two main architectural approaches to partitioning:

1. “Shared Nothing” approach - where each partition is handled by just one server. Each node is self-sufficient, and there is no single point of contention across the system. An example of a “shared nothing” database is IBM’s DB2 solution, a partitioned database in which every partition is in charge of only a slice of the database.
2. ”Shared Everything” - where the database is not partitioned — all the data is managed by all the nodes in tandem. The worker nodes are identical and each of them can access each piece of data. A notable example of “shared everything” database is Oracle’s commercial solution, RAC.

Partitioning has two major benefits:

1. You can scale very effectively for write purposes
2. You can easily fetch information from the server if you know how the data is split between different partitions

The Xeround approach to Partitioning:

Xeround offers a Cloud DB for MySQL apps, which is based on a “shared nothing” architecture and wheredata is partitioned spread across numerous servers.

There are two primary challenges with the “shared nothing” approach:

1. Sometimes your partitioning scheme needs to change. Let’s say you have a database of Social Security numbers and server A contains SSNs from 1-10,000. If there’s suddenly an influx of people with SSNs in that range the server will become overloaded and you’ll have to introduce a new partitioning scheme. Repartitioning is a major task that involves doing a lot of administrative work and taking down the database, which results in downtime and inaccessibility for users.
2. Trying to access data that doesn’t follow the partitioning scheme takes more time and energy. Using the Social Security database example above, let’s say you’re looking for all the people named “Mary” in the database, regardless of their SSN. Because the servers are divided by SSN and not first names, finding everyone named Mary is a trickier task because then all the servers and machines must be scanned using a different criteria.

Xeround circumvents the aforementioned obstacles by introducing virtual partitions as another layer between the hardware and the partition. Xeround’s patented technology allows users to enjoy all the benefits partitioning offers (more scale!) without the burdens of reassigning hardware to data – which means less administrative annoyance and code changes to your apps.

As you scale, your partitioning schema is bound to scale as well and become more complex. Handling its logic and on-going maintenance is a major headache.. :) Good thing this is what we do here at Xerond – allowing you to easily plug in to a DBaaS that’s always-on and supports your changing scalability needs.

Want to go under the hood? Take a look at our Technical Whitepaper for more information on Xeround’s unique technology and architecture.

Register for our Private Beta to experience Xeround MySQL Cloud Database for yourself.

With more than 20 years of experience in technology and application design, Avi brings deep market and technical domain expertise in Cloud Computing, specifically Data and Storage challenges, systems scalability, performance and distribution.

In recent years, Avi focused on cutting edge development and research projects such as next generation Internet, Content Oriented Networks, Cloud data services and large graph applications in companies such as Yahoo, Huawei and Verint.

Avi believes in breakthrough via innovation and simplicity – so he’s in the right place, as Xeround defines the future of cloud databases and cloud computing infrastructure.

Cloud computing relies on the interconnection of resources. Network latency usually plays a critical role in the application flow from the front end, through the middle tier to the database and all the way back again.

Setting mobile access aside for the sake of this discussion, the performance one would get would depend on the proximity to the cloud entry point (datacenter). For example, if your SaaS application is deployed in the Amazon EC2 West Availability Zone, users on the East Coast would not get the same level of performance as those on the West Coast. That’s reality at work – no bending of physical laws.

One way to work around this issue is to deploy the application in several geographical locations (in this case East and West Coasts) so that the majority of users closer to each location will enjoy better performance.

Pursuing this solution assumes a couple key architectural and configuration considerations:

1. The application is stateless and therefore agnostic of the servers that are actually active in the flow.
2. The database can be replicated to several locations.
3. The database’s replicas can operate in multi-master mode.

Running a database with multiple replicas is usually done using a single master that ships updates to several passive copies. The passive copies can be used to offload read operations, but not writes.

Regardless of the exact replication method, failing over (and ultimately back again) from master to a stand-by passive node takes time and can be painful. And if you need to have your database support heavy-duty online transaction processing that entails both reads and writes simultaneously, in several locations — that’s where it gets interesting.

Xeround addressed this specific challenge early on when we designed our solution as a subscriber database management system for telecoms. The very nature of the solution had to be distributed, serving roaming users in multiple locations — a core GSM function. Users would use and access the nearest database.

After moving to the cloud, we refreshed this core capability and applied the same principles to multiple copies of the same cloud database that span multiple locations. In fact, since our core technology allows us to effectively and transparently distribute the database across multiple nodes, it is not really an issue if the same data is spread across multiple nodes or locations – the basic logic remains the same.

At this point, we’re often asked about the “CAP Theorem.” While it’s true that we can’t defy the laws of physics, we can certainly track, manage and synchronize multiple copies of the database and clear conflicts as and where applicable.

To do this, we keep a transaction log constantly updated in the same way we write transactions to multiple replicas. We organically provide this service out of the gate to ensure high availability. We’ve dubbed this concept “Active Global”, because groups of geographically-dispersed clusters of MySQL are accessed and managed locally while they’re synchronized with a top-level, global logic layer. Active Global ensures for near real-time “clearance” anytime, anywhere.

Read more about the challenges databases face when running on a cloud environment on our Cloud Challenges for Databases Series.

Addressing Rosenberg’s point, I described the 4 key issues every system architect should take into account when designing their database for the cloud — and why achieving them on a Cloud environment might be more complex, tedious to manage, and way more expensive than you might think.

Basically, you need:

1. Replicable, high-availability set-up - because the cloud is an unstable, unpredictable, environment.
2. Database that scales elastically - and scaling out by adding nodes is harder on a cloud infrastructure.
3. Distributed databases – which require building the logic to handle conflicts, network and latency problems.
4. True Multi-tenancy - And not a simple standard SQL database installed in multiple copies on the same virtual machine – which can cause more headaches and management overhead to keep running.

This is all hard work – we know..

In his review, Rosenberg also describes why relational databases are here to stay, and why NoSQL isn’t necessarily the answer for your cloud concerns.

At Xeround, we’ve always felt the answer lies in making SQL Cloud-able – for REAL! Our technology for managing data in the cloud provides both the transactional and query capabilities of relational databases, along with the simplicity and scalability as of NoSQL data stores.

Xeround SQL Cloud Database, offered for both public clouds (IaaS) and private clouds, was designed specifically for the cloud, to give you multi-tenancy, high-availability, auto-scaling and self-healing – all without being bogged down by the development, management and expenses overhead.

If you haven’t tried us out yet- sign up for the private beta and check it out for yourself!

You can read more on CNET’s Are databases in the cloud really all that different?

Attending CloudCon Israel? be sure to stop by the Xeround booth for a live demo of our SQL Cloud Database and some cool freebies :)

CloudCon 2010
Tuesday, November 16, 2010  |  Avenue Convention Center, Airport City, Israel

Real Life Cloud Architectures Track
Friday, 4:50PM – 5:50PM @ Olympic Room

Xeround’s CEO, Razi Sharir, will be participating in a panel at QCon with other leaders of modern data management in the cloud. The discussion will cover the different aspects of managing data in the cloud, as well as the various challenges and solutions that are available today.

From the panel’s abstract:

Scaling out the data tier has always been a challenge, but it is exacerbated in the cloud. By nature, cloud computing environments are dynamic and elastic. That, coupled with the fact that today’s applications need to handle web-scale data volumes and transactions, makes the traditional approaches to data management unfeasible. This panel will discuss the unique challenges of managing data in the cloud — and the solutions from a variety of perspectives: database-as-a-service (DBaaS), NoSQL, cloud-specialized relational databases and more.
More on QCon Agenda and Speakers Panel »

P.S. – here’s a photo of Razi, so you can come and say hi!
(he will be in live color :))

If Cloud, distributed technologies and solutions to complex problems are what you find interesting – look no further.

Join Xeround’s innovative team and take part in defining and building the future of computing, making Cloud a reality!

Check out our open positions and submit your resume »

Multi-tenancy and its implications have been the primary concerns of companies that have avoided using the cloud. The underlying reasons mostly involve potential security vulnerabilities but also include the effect of one user’s utilization on other users who share the same physical, or worse, the same virtual resources.

Another layer of complexity is added when considering Database-as-a-Service (DBaaS) and multiple tenants – not only do different users share the same physical host but even the database instance itself is shared between them.

There are no databases where a single virtual instance can be “sliced” and offered to several distinct users. When one signs on an Amazon RDS instance, which is a pre-configured EC2 instance with preinstalled MySQL on top, the relation is always 1:1 – one virtual DB instance per customer. This implies a managerial overhead for the service provider on top of inefficient and ineffective use of resources. This is because the end customer often gets a database that is significantly larger than what they need, not only to allow for scaling but also because customers are often unsure of their data’s size, growth rate or what processing power they require.

Xeround designed the core underlying database engine from the bottom up to be a virtual, scalable, distributed solution aimed at making optimal use of resources.

That’s why Xeround can take a single database virtual instance and slice it to be consumed by several users simultaneously. Each customer runs as if they are the only ones using this instance. Since our technology enables transferring a live working database from one instance to another without affecting service or performance, if one becomes overly “noisy” and starts consuming lots of resources, it’ll be moved to another, less burdened instance. Service providers are then able to utilize their resources in a more cost-effective and efficient operations manner.

The same considerations also apply in a private cloud, often associated with a single large enterprise. In this case, operational expenses like the number of required database admins plays an even more critical role in driving a cost-effective yet operationally efficient IT service.

Xeround, in a sense, is also “built to fail” but unlike the traditional approach of using storage and redundantly building bigger machines, Xeround is built in such a way that although discrete components may fail, the system knows exactly how to isolate the failures and won’t bring the whole database down.

If a Xeround component fails, other components will seamlessly replace the lost component and the system will continue to operate. You can read more about our technology in this paper.

The servers that make up the cloud are relatively simple. The issue here is no longer the server but the availability. Even though many virtual databases tout the number of available resources they have, this doesn’t speak to the stability of the virtual environment.

Predicting every move the virtual environment will make isn’t feasible, just as it’s impossible to predict exactly what traffic will be like when you get in a car to drive. Nevertheless, there are times when you can predict that traffic will be bad (i.e. rush hour) and when it shouldn’t (but still could) be bad (early morning, late evening). The same goes for the cloud environment. Some spikes in traffic are known, or can at least be predicted, but many are unexpected. Much like road traffic, the cloud is a dynamic fluctuating environment.

In an attempt to manage the unpredictable nature of the cloud, Xeround uses replication. Users can make as many copies as they wish, and the copies are stored in active-active mode (both can be written to and read simultaneously) as opposed to active-passive copies (which are read-only or write-only).

If you’re interested to learn more about Xeround and the solutions we provide, sign up for our beta right here.

Currently the public, EC2-style cloud providers make no guarantees as to whether your instances are put on a single server or multiple servers. Other options, as VoltDB’s post points out, are too costly or too weak. But is the lack of assured ability to separate inter-dependent instances across different physical servers an obstacle to achieving high availability in a public cloud?

Here at Xeround we are busy putting the final touches on introducing support for Amazon’s cloud offering. During the private beta that we’re running we plan to let our users decide between having their databases residing in our own data center or Amazon’s. Our database is highly available via the use of — you guessed it — node redundancy much like VoltDB’s (see here for more information on our technology). So how can we make high-availability claims?

The answer is simple and can almost be considered a byproduct of the way we operate our service. Our capability for multi-tenancy allows us to take the biggest and meanest machines that Amazon has to offer (currently the m2.4xlarge type). This not only gives us the financial upside of buying resources comparatively cheaply, but also allows us to guarantee that no two of our instances reside on the same physical server. Our resource management algorithms slice, dice and provision chunks of these big servers to  our users, while ensuring no two inter-redundant nodes are hosted on the same server. This way, despite getting no assurances we can still make our own.

If you haven’t already, sign up for our private beta and see for yourself.

But cloud computing comes with risks. Maintaining high availability is one of the biggest challenges databases face in general, and this challenge is compounded in the cloud.

In a recent analysis of major cloud outages SearchCloudComputing.com said, “Even the biggest and best cloud companies have seen their best-laid plans go to waste as their services go dark for hours at a time.” So what is this inherent availability problem, and how can we address it?

One of the prominent issues with the cloud infrastructure is that the availability of resources is not guaranteed. The lack of assurance in the continuous operation of resources generally stems from two reasons:

1. Structured downtime: Many SaaS providers warn their users about planned outages and times the sites and applications will be down for maintenance. While it is a nice gesture to let people know exactly when the system will be down, it is still inconvenient. Major cloud service providers like Microsoft, Amazon and Google also provide SLAs, or Service Level Agreements, that guarantee their systems will be up and available for — typically — 99.9% of the time. In the event that they do not meet their service commitments, they compensate customers with service credits. While these SLAs don’t cover the aforementioned scheduled downtime, they try to account for…
2. Unplanned issues that cause downtime: Downtime can occasionally happen unexpectedly. When outages occur without warning it can be difficult to get the system up and running again quickly. On September 10th Microsoft issued a mea culpa on their blog called “Meeting Your – And Our Own – Expectations” for several recent outages affecting its Business Productivity Online Suite, which includes cloud-based versions of Exchange, Sharepoint and Office Communication Server. Other high-profile outages are aplenty. Facebook endured its worst outage in four years on September 23rd due to a software flaw in its database clusters.  On top of outages resulting from various hardware failures, highly-fluctuating demand patterns coupled with multi-tenancy achieved via co-hosting of virtualized servers also play a considerable part in destabilizing cloud-vendors environments.

The issues of downtime and availability are inherent in the design of the cloud. Users don’t own the infrastructure, but rather consume it freely via Software-as-a-Service (SaaS) applications for example. However, those applications often reside on the public cloud infrastructure, leaving them at mercy of providers, other users and nature et al. in terms of availability.

Xeround’s architecture is designed to ensure high availability and full resiliency in case of software or hardware failure. With no single point of failure, Xeround is resilient to failures of any of its software components across servers, sites, networking elements and virtualization technologies.

Maintaining availability is achieved by Xeround’s built-in full redundancy in terms of all processes and data. Setting the system to withstand any arbitrary number of server failures is easily achieved via configuration of the number of data replicas that are managed and the components/servers deployment. Furthermore, even the availability implications of complete site failures can be averted by distributing the components and data between different data centers (e.g., Amazon’s availability zones). On top of that, once a failure is detected, the system can be set to automatically takes proactive measures against the next potential failure by using available resources in order to re-spawn missing data copies and processes.

Xeround’s Databases are thus always available, not only during downtime, but also during benign, planned maintenance activities as Xeround guarantees continuous service during the following activities:

• Resource Changes & Scaling – During addition or removal of physical resources, the virtual partitions reallocate autonomously, without any effect on the service. The database transparently performs any additions or removals of components to accommodate changes in size or throughput needs.
• Schema Changes – The database treats any change to the schema, such as adding tables, columns or changing index definition as a Write operation; thus, the database totally operational throughout the process.
• Backup – The database is backed up while the database is online and fully operational.

Although many assume that virtualization originated a few years ago with VMware’s technologies, virtualization has actually been available since the very early days of the mainframe and the introduction of the client-server model. The front-end layer (the GUI, or Graphical User Interface) was virtualized while the other parts in the stack run from the server.

Later, as software evolved and Microsoft introduced distributed technology (also known today as the .NET Framework), virtualization extended to include the middle tier (software layer) and clients started to include business logic.

The latest and greatest full virtualization stacks by VMware and others (Microsoft’s HyperV, Sun’s containers) are more inclusive, containing all parts of the software flow/stack including the server itself.

Now that the complete software stack is decoupled from the hardware layer, software can be run virtually anywhere. While this represents a breakthrough in many ways, it has also introduced numerous new challenges.

These challenges mostly pertain to the ability to manage a distributed, virtualized environment and ensure resources (physical and virtual), applications, users, transactions and overall service are working in concert. The “Cloud” is a unified framework that integrates all the latest virtualization technologies and provides the most benefits. The Cloud can be run publicly with Amazon’s RDS or EC2 offerings for example, or privately, replacing the “old world” internal data centers of large organizations.

When organizations move to the Cloud, not only do they have to deal with a constantly changing environment, they must also introduce new development methods to support the very rapid development cycles.

Platform-as-a-Service (PaaS) is among the latest additions to the *aaS stack, and is essentially the best representation of the Cloud as a framework. The modern incarnations of Microsoft Visual Studio, IBM Eclipse and other similar development suites (IDE – integrated development environment) are focused on making everything simple. Sketch your GUI, drag-n-drop the various pre-packaged functional components and related business objects, define a couple variables and relations, click run and you’re ready to go.

So what’s the big deal? With limited need for real coding and simplified transition from test to live production, the time to market is significantly shorter. Is there a catch?

Well, let’s say you need to develop complex, distributed and scalable applications providing distributed functionality to multiple users in multiple zones and generating a zillion concurrent transactions. Complex means the needed functionality is not available in a pre-packaged consumable object.  Scalable means the application needs to allow for scaling up and down, but also for out and in. That is where it gets tricky — the critical component is the database at the very narrow end of the funnel.

Traditional databases were not built for virtualized environments and thus do not support these basic requirements. Modern, trendy databases like NoSQL overcome these limitations, but they also impose new ones. With their lack of transactional model and relational capabilities NoSQL databases making it tough to benefit from the true abstracted, stateless dynamic model of the Cloud.

When standards around the underlying virtualization and new data management solutions that fit the new Cloud emerge the Cloud will really pick up and perhaps render the private cloud obsolete.

When Xeround designed our virtualized database over five years ago we were way ahead of the virtualization, let alone cloud trends.

Having proven our ability to meet the very strict telco-grade certification and being the only virtualized-by-design database, we now aim to solve the critical path in the transition to the Cloud (public and/or private). In a sense we allow for the best of both worlds by enabling the use of the known and trusted relational database management system (RDBMS) methodology in its SQL form, as well as offering the great distribution and scaling benefits provided by modern database engines like NoSQL.

We started sending out a few dozen invitations and more are on the way every week — and more importantly, users have started launching databases, creating tables and loading data to their MySQL DB in the cloud.

On our beta invitation request form, we asked people to tell us a little bit about their database and application, and we thought we’d share this info. There were a couple of surprises in there for us.

The first question was how large are you expecting the database you are going to load into Xeround to be. It’s important to note that during the private beta, the capacity we can make available is fairly limited so the maximum size option we gave is “More than 10 GB”. Some people have expressed concerns about this, but have no fear: this is only a limitation during the early stages of beta. That said, it seems that a database size of less than 10 Gb will address the needs of three quarters of the folks who signed up for the private beta.

The next question had to do with the MySQL version. Here are the results:

There was no surprise that the dominant version was 5.1, but we were somewhat surprised to learn of the level of adoption version 5.5 has received. As a result, we are accelerating our support for this release.

Finally, we asked people to tell us about the environment their application is running on (whether hosted or in-house). Here are the results:

Depending on your perspective, these results may or may not be surprising. It’s not a big shocker that more than 50% of people who sign up for a “cloud database” are hosting their app in the cloud. And the fact that Amazon and Rackspace are the leading cloud hosting providers is also consistent with other surveys and measurements out there.

For this question, the other category was larger and some of the smaller players in there deserve honorable mentions including Slicehost (a Rackspace property), Media Temple, GoGrid, Heroku, Engine Yard and Saavis.

Initially, in the private beta, we are running the Xeround service on our own cloud, but we will be soon rolling it out over time on EC2, Rackspace, GoGrid and other cloud environments. We’ll keep listening to what our users are telling us they need.

Any thoughts on these results? Please share in the comments.

In recent years, as social media has developed, more data types have become common — movies, music, pictures, and more — which introduced new requirements. In addition, the Cloud model offers another facet of distribution and scale: multiple users in multiple places running multiple applications and generating multiple transactions — all simultaneously.

Surprisingly, the “traditional SQL DB” does not adhere to the modern web 2.0 and Cloud requirements. As such, modern models have been developed and the result is the NoSQL trend. The key idea behind NoSQL is the theoretical and potential unlimited scaling and distribution capability. In an RDBM world, NoSQL lacks three critical capabilities: 1) NoSQL is not a transactional model, 2) NoSQL is not persistent, and 3) NoSQL is not a relational model.

Long development cycles reflecting complicated architecture and mission-critical designs (often found in a database) share the same destiny as long production cycles of carefully developed aging wines. Just as many good wines have been aged for years in a French Oak barrel and a properly cooled cellar, if you’re looking for software that has been carefully designed, properly developed, and fully tested — there are no short cuts.

Trendy, fruity and sweeter wines are like the cutting-edge, web 2.0 applications that, while they can get to market quickly, can be limited by their own schema-less benefits. Alternatively, B2B, B2C commercial-grade applications or Enterprise solutions that are transactional and relational based will need to migrate from private data centers and into the Cloud (private or public), and thus will need to seek more powerful, SQL-based databases that work effectively and efficiently in the cloud. Like “old world wine,” modernized versions of traditional apps and databases are here to stay and Xeround is pleased to be part of their development.

We’re starting to send out invitations to our first private bata users this weekend. We will be rolling out more private beta invites gradually, so if you haven’t received one, please be patient with us.

Stay tuned!

And if you haven’t yet requested a private beta invitation, please do.

Also, keep in mind that the private beta is limited. We want to test our cloud database together with a small number of users and make sure it is hardened and take out all the kinks.

Also, we received some nice coverage in the press yesterday and today. Check it out:

• Dave Rosenberg, CNET: Xeround Scales MySQL for the Cloud
• Audrey Watters, ReadWriteWeb: A SQL Database Built for the Cloud
• Mike Vizard, CTO Edge: Xeround Brings MySQL to the Cloud
• Kristen Nicole, SiliconAngle: Xeround Launches MySQL for the Cloud. It’s All About Scale.
• Paula Rooney, ZDNet: Xeround announces MySQL for the Cloud

Cloud databases currently face a number of challenges, including the need for elastic usage, as well as data consistency and availability. While NoSQL databases have garnered a lot of buzz, they don’t offer ACID guarantees and queries require re-architecting and recoding of existing products. Also, consistency isn’t guaranteed and transactions are not supported in NoSQL. Because NoSQL is still relatively new to this space it will take some time for people to have enough expertise with its different variants.

Xeround aims to solve these problems by creating a database that can scale elastically in the cloud, without changing code or architecture, and without downtime.

Our technology that we’re unveiling today combines the transactional and query capabilities of relational databases with the simplicity and scalability of NoSQL datastores. Xeround was born in a telco operations environment so we know data needs to be available at all times. That’s why we guarantee continuous service during schema changes, resource modifications and the scaling process.

Interested in checking it out further? During our beta trial period, we’re offering Xeround as a Database-as-a-Service (DBaaS) on Xeround.com and Amazon EC2. So if you’re using Amazon RDS and/or running MySQL on Amazon, using Xeround is as easy as changing the connection address, loading the schema and running it. Xeround will soon be available on other leading cloud service providers as well.

If you’re interested in participating in our private beta we encourage you to request an invitation. We’re eager to hear what you think.