Xeround’s leadership forum has recently decided to re-focus the company’s effort. This means we will no longer be able to support our service over public clouds, across all of our currently active data centers.

What this means for your database?
We ask you to please export your database instance and migrate your database to another service of your choosing before the termination date.

We sincerely appreciate the support that our thousands of customers have shown us over the last couple of years. We regret the inconvenience this causes you, and hope your migration to a new DB solution goes smoothly.

We thank you for your business and for the overwhelming support of our users.

With the deepest respect,

Xeround Team

In particular, Mobile gaming applications are often characterized with fluctuating demand patterns and sudden spikes in throughput- either when there’s a tournament, or during certain hours of the day or periods throughout the year, when more users play the game.

The cloud has all but become the standard for mobile and gaming apps, allowing developers to quickly deploy and go-to-market with their applications, and providing the scalability needed to accommodate the varying demand patterns of those apps – that often start small, but can sky-rocket at any moment.

At Xeround, we see many customers in the business of creating mobile and gaming applications using our database service. Often, they choose Xeround primarily for our unique auto-scaling capabilities – allowing the database to seamlessly scale-out to support any demand from the application, then shrink back down for when it is underutilized.

One interesting example of such a customer is Dogfight - a popular multi-player airplane combat simulator available for Apple and Android mobile devices.

From small beginnings, the game now has over 3 million gamers world wide – playing against each other in real time, maneuvering historical WWI fighter planes and taking on rival airplanes in head-to-head air battles.

Learn how Dogfight uses Xeround Cloud database to ensure both high availability and seamless, unlimited, scalability to support any spike in demand – even when Apple promoted the game resulting in X3 traffic peak!

With Xeround’s auto-managed database service, Dogfight manages to keep their 3 million users – across three application servers in Europe, US, and Asia – all happy and engaged, as they battle to shoot each other in the skies :)

Read the Case Study »

Take DogFight for a spin – download the game to your phone »

We’re happy to announce that, in addition to our free plan, we’ve now announced support for Xeround’s paid plans on HP’s data center.

Now, HP Cloud users can enjoy larger DB sizes, scheduled backups – and of course our industry-first auto-scaling capabilities – all part of our Xeround BASIC and Xeround PRO paid plans.

The first 30 days of using any of Xeround’s paid plans on HP Cloud are free!

Check out our pricing on HP here.

To create your cloud database on HP’s data center, log in to Xeround’s Management Console and choose “Create New”.

• Interested in seeing the biggest MySQL “earthquakes” of all time? The infographic below tells their stories, including the lessons learned after each database failure, from reputable sources including Wired, Slashdot, TechCrunch and ZDNet.
• Did you know that data loss and corruption accounts for only 10% of MySQL failures? The rest are due to hardware/OS, performance and replication issues. See this and other interesting statistics further down in our infographic. Data was taken from Percona’s MySQL Failure Causes White Paper.
• Deleted your InnoDB data file? Don’t worry, you can probably recover it. See this and 7 other common causes of MySQL failure, and how to recover or prevent them altogether. This last part of our infographic was based on Ronald Bradford‘s classic book, Effective MySQL Backup and Recovery.

Here at Xeround, we make MySQL more reliable with a cloud database service that guarantees high availability (even during Amazon outages!) and automatic elasticity with no downtime or application changes. If you want to try disaster-free MySQL on the cloud, create your free database now!

(Click to enlarge infographic)

We’re excited to announce our latest product upgrade out today, which includes some key enhancements to Xeround’s Cloud Database service.

First and foremost, we’ve achieved SIGNIFICANT performance improvements:

Check out the updated benchmark comparing our service to Amazon’s RDS (single, and Multi-A-Z) and to Rackspace’s MySQL cloud database.

Tests were conducted on the actual cloud live environment to make sure there was no environment-specific bias, using standard DBT-2 database benchmark application.

See how this latest release compares to our previous one, and to RDS’ performance:

1. Support for Full Text Search via Full Text Index
2. MySQL version upgraded to 5.5.20
3. Xeround BASIC edition now supports restore-from-backup capability
4. Caching of static tables and Btree indexes

Check out the Release Notes for detailed list of features.

This index type is particularly popular when working with large text files, or with some specific CMS application uses – such as Wordpress or Joomla!.

This latest product upgrade also introduces significant performance improvements, upgrade to MySQL 5.5, ‘restore-from-backup’ support for BASIC customers, and more.

See more on Xeround’s Full Text implementation and MySQL 5.5 support in the Release Notes.

*Existing Customers:

If you have an existing Xeround DB instance running, and want to take advantage of Full Text Index, you’ll need to migrate your instance to the new release (create a new instance and import a dump of your old database to it).

Note the new release supports MySQL version 5.5. While for most users the upgrade is seamless, please consult the release notes to see if any differences between MySQL 5.1 (Xeround’s previous release) and MySQL 5.5 might have an affect on your app.

If you have any questions or need assistance migrating oyur DB to the new release, please contact Xeround Support.

To create a new Xeround DB instance, simply log in to your AppFog account and add the Xeround add-on. This automatically creates a MySQL-compatible cloud database that easily connects to your application.

We are initially offering our FREE edition to AppFog users, soon to expand to additional paid plans supporting automatic scaling and more robust features.

The Fiz let’s go places mobile app lets you discover and explore places nearby, or in a far flung part of the world.

Places are filtered by interest – everything from dining and nightlife, to art, culture, outdoor activities, sports and fitness centers, and even health and road services, and much much more. Places are brought to life with photography and tips, tweets, reviews and ratings from other Fiz users. An essential stress-buster, Fiz is also ultra-practical with weather, traffic, maps, routes and telephone numbers. And it’s socially embedded too.

Fiz’ location-based application was developed on DotCloud and deployed on AWS. The application uses large amount of data – both from external sources, as well as data generated by the growing volume of users. Therefore, scalability and high availability were essential prerequisites during initial planning of the service. Fiz wanted to ensure speedy, real-time access to their wealth of travel-related data in a way that could both support their need to “start small”, and their future scaling requirements.

Read the case study to learn how Xeround supports Fiz’ application from early development stages – using Xeround’s FREE edition – up to automatic scaling as demand increases, with no management overhead or any changes required to Fiz’ architecture or code.

Read the Case Study »

Download the Fiz app to your iPhone »

Just as developers struggle to manage their specific DB instances; similarly- cloud operators are expected to offer robust database solution – which guarantee high availability and scalability – and manage them across sometimes thousands of instances. In addition, cloud operators are also expected many times to offer a free tier as a way to ease developers’ path from development to production on their platform. The effective management of so many databases is expensive and takes a toll in terms of management and operational overhead.

With Xeround, cloud providers can offer their own database-as-a-service running on their cloud infrastructure. Not only are databases a key service for end users, but by using a zero-management solution to automatically manage multiple database instances, cloud operators can run thousands of databases with a click of a button in the most efficient cost and operations model.

Xeround is cloud agnostic, and can run on any cloud and any stack.

Watch this video to learn what Xeround offers cloud providers running Citrix cloud:

Learn about GreenQloud’s 100% renewable-energy-powered cloud, and how you can create your FREE Xeround DB instance on GreenQloud’s IaaS.

Xeround powered by GreenQloud Webinar: Easy, Clean DBaaS for MYSQL apps on Vimeo.

You can now use GreenQloud’s clean energy Compute Qloud™ to power Xeround’s zero-management cloud database-as-a-service. In this webinar, you will learn how!

Xeround is a simple cloud database-as-a-service (DBaaS) for MYSQL applications, that guarantees automatic scaling and high availability with just one click. Xeround customers can select GreenQloud’s renewable energy-powered IaaS to run their Xeround Cloud Database instance.

GreenQloud offers scalable, secure and distributed high performance servers and on-demand storage with AWS-compatible APIs and an easy-to-use management console. GreenQloud uses highly efficient hardware and is the only cloud IaaS provider powered by 100% renewable energy, providing its customers with a unique feature allowing them to monitor energy metrics and carbon emissions savings. GreenQloud is ideal for web storage, backups, key-value databases and scaling web apps.

Clean. Easy. Better for the environment. Join us to learn more!

Register to create your free cloud database on GreenQloud

Not too long ago, a good friend of mine started Blue Saki Online, a small development shop focused primarily on analysis, application design, and development. They offer an exciting new way to engage customers with highly interactive applications that can be easily integrated (or added) to any website. I quickly decided I wanted to be a part of this departure from traditional web application development, and became a partner.

Today, many organizations are questioning the transition of their applications to the cloud so I thought it would be timely to write about our experience at Blue Saki Online and more specifically, how the cloud helped our team cut down on development and operational costs, enabled faster deployment and improved reliability for mission-critical applications like our online video marketing platform, AMANDA.

Unlike a majority of organizations, we’re used to moving applications to the cloud. It’s what we do, so it came as no surprise that we were commissioned to migrate AMANDA from a traditional data center to the cloud. While getting in the cloud was a breeze, our main struggle turned out to be the cost of the additional database servers and the on-going maintenance needed to configure and support a MySQL environment. We estimated it would cost us an additional $300 per month. Given the growth AMANDA had already experienced, we knew scaling issues would come into play requiring more servers and more on-going maintenance to support high throughput demand.

We quickly realized that we would also need to offload our database management to the cloud in order to maintain the application and provide an excellent user experience to our customers. But since we are a small shop, infrastructure expertise such as system administrators and database administrators are expensive resources that we only use if absolutely necessary.

That’s when we found Xeround’s DBaaS for MySQL applications.

We were able to easily launch a cloud database instance with Xeround and connect it to AMANDA within minutes. Once the database was created, there was no need to visit the management console to configure or manage anything. Xeround automatically keeps the database always available and allows it to scale to accommodate the application no matter what – with no need for manual intervention, on-going maintenance or development efforts to support the database tier.

By choosing Xeround, we know our database is always live and scales automatically without having to worry about maintaining and supporting it ourselves. Rather than focus on the IT, we’re able to save time, effort and cost as well as focus on what really matters as developers: our code.

AMANDA, which has been in production for nearly a year, generates more than 20,000 transactions a day and is used by more than 2,000 customers. If you’re moving to the cloud, it’s worth considering other cloud-based services like a DBaaS to help automate and manage different tiers of the application stack to lighten your development load.

Rajiv sporting one of Xeround's T-shirts

AMANDA - Video Marketing Platform

Read the case study to learn about the additional cloud services chosen for the migration of AMANDA’s video marketing platform to the cloud.

GreenQloud offers scalable, secure and distributed high performance servers and on-demand storage with AWS-compatible APIs and an easy-to-use management console. GreenQloud uses highly efficient hardware and is the only cloud IaaS provider powered by 100% renewable energy, providing its customers with a unique feature allowing them to monitor energy metrics and carbon emissions savings.

Xeround Cloud Database is the only database-as-a-service offered to GreenQloud customers, providing zero-management experience and seamless high-availability for MySQL in the cloud- and it even has a free version!

Xeround customers will now be able to select to run their cloud database on GreenQloud’s Truly Green™ Cloud IaaS, powered by 100% renewable energy. Initially, we are offering our FREE edition on GreenQloud, with additional plans scheduled to launch in the coming months.

Create your FREE cloud database on GreenQloud Today >>

Xeround and GreenQloud will host a joint webinar on November 28, 2012.

Register for the event to learn more about GreenQloud and how to make your MySQL deployment both easy and green.

We’ve recently launched our FREE plan on Joyent Cloud, providing a zero-management MySQL in the cloud at no cost.

We’re happy to announce that as of today, Xeround’s paid editions - Xeround BASIC and Xeround PRO - are also available to Joyent customers.

Xeround PRO includes our unique auto-scaling capabilities, along with automatic failover, scheduled backups and additional  features- making it the most robust solution for managing MySQL in the cloud today.

To create your cloud database on Joyent’s data center, log in to Xeround’s Management Console. Joyent customers that already use Xeround’s FREE edition can easily upgrade their DB instance to one of Xeround’s paid plans from the Management Console.

Remember that the first 30 days of using either Xeround BASIC or Xeround PRO are free!

You may also want to check out the recording of our recent webinar to see how Xeround runs on Joyent Cloud and what a scalable cloud database can do for you.

Venga’s platform collects vast amounts of transactional data from restaurants’ point-of-sales systems – such as customers’ orders, server, check amount etc. This data is sent in near real-time to Venga’s cloud-based analytics application, and is then augmented with feedback sent by restaurants’  guests using Venga’s mobile app.

Venga’s business has seen tremendous growth in a short few months, resulting in exponential growth of the underlying database powering the platform’s .NET analytics app and its RUBY mobile application.

This had prompted the company to look for a cloud database solution to support its scaling needs in an automated way, without the management and maintenance overhead entailed in ensuring smooth operation of this growing database.

In comes Xeround…

Check out the case study to learn how Xeround proved valuable to Venga’s guest management platform in providing automatic scaling, one-click deployment and seamless migration of the company’s on-premise DB to Xeround’s zero-management solution.

Read the Case Study »

It was exciting, though at times, and incredibly rewarding. Just like the database business world ;)

Among other sites, the WasThis™ app is also being used on Ripoffreport.com - the largest consumer advocacy site in North America, which boasts over 250,000 page views per day.

WasThis™ is a write-intensive application which required a zero-management DB solution that could support automatic scaling of throughput to accommodate sudden spikes in demand.

Read the case study to learn about the value Xeround delivers to WasThis’ 10GB DB running on Rackspace, and how you too can ensure elasticity and reliability of your DB within a cost-effective, zero-management service.

Read the Case Study »

Xeround is excited to be joining the Cloud Advisory Council, taking an active role in designing the future of database solutions and data services for the cloud era.

Read more about the CAC and its members on the official announcement.

Model T Fords at the end of the assembly line Library of Congress. Keesee and Sidwell, p. 433

As a long time start-up veteran, I always felt that the most exciting, challenging and rewarding time is what I refer to as the “inception” stage; the very first people to share your idea (the founders), the first developers, the mentor, the brainstorming, the beer, the late nights, the dream. This is how dreams take shape; it requires everyone to stay focused, sharp and agile. Decisions taken during the early days will greatly affect your ability to execute later on. And just to be perfectly clear, when I say startup I mean both “let’s empty this garage and get started” and “I have this great idea. Let’s meet the brass and convince them to found this internal initiative” type of start-ups.

Over the years I have had the opportunity to work with many other entrepreneurs. Their path to deployment – or their path to realizing their dream – can be characterized as one of two approaches:  Those that felt they must do everything themselves, regardless of the costs (anti-pattern NIH); and those that wanted to focus on their core expertise and, where possible, leverage existing building blocks or services on their way to the finish line.

During my early days as a developer I was more of the “do-it-yourself” ranch-in-hand type of developer. We’ve all been there- this “I know best” or “just let me play around with it, I’m sure I can get it right eventually” attitude. Today, reflecting back on those days I can say that I made my fair share of mistakes and as I gained more experience I came to realize the error of my ways J

Most of us know that the key success factor for any new initiative is focus; the one thing that you plan on doing, solving or improving. You need to be laser focused on solving one particular problem, not many problems. The more you try to do the bigger the chance you’ll fail. In other words, you should focus on your core technology and innovation and leave the rest to others. My guess is that not a lot of people would want to develop their own billing, CRM or database systems for that matter. You simply install and run a product from a vendor who is focusing on that particular piece of technology.

Today as the proliferation of cloud services grow, these truths remain the same – companies should focus on their code and innovation not on cloud infrastructure or SLAs. Staying focused by consuming services might not be the simplest decision to make but once taken you’ll quickly realize that it’s not that that different than the one made when choosing to buy a certain piece of the technology instead of developing it. Sure you can do it but developing the expertise, developing the product and ensuring the appropriate SLA will cost you…

Put in a different way, why re-invent the wheel when you can leverage what’s already been done?

Xeround has taken this notion to heart; we have been developing our Telco-grade distributed database for the last 7 years. 3 years ago we decided to offer it as-a-service over popular clouds, like Joyent. Truthfully; it took us a while to figure it out… We also practice what we preach – in fact we’re extensively leveraging the as-a-service concept in house, from billing and CRM to helpdesk.

Back to the matter at hand, running a database in the cloud is a lot harder than spinning up a VM and installing a database on it – there’s a lot of management overhead and challenges associated with cloud environments. The on-demand model which seems very promising does not always work and developers need to make sure their applications are geared to handle such surprises.  On top of that, cloud IT operations are tedious, complex and often more cumbersome.  Maintaining high availability requires continuously monitoring the cloud environment for any failures, configuring auto-failover mechanisms and keeping multiple copies of the database tier always synchronized and ready to spring into action.

Once we managed to resolve these issues (and quite a few others) we were able to offer our expertise as a best-in-class service, with all management resources, such as DBA or Sys Admin, already included in our pay-as-you-grow plans. By providing a clear understanding of monthly costs, eliminating any hidden ones and making the Xeround database-as-a-service easily accessible to everyone, we were able to help developers, technology companies and SMBs to not only better determine the costs to develop a product or service (which in-turn impacts revenue and profitability) but also focus on what they know best – development. Leaving all related infrastructure issues to be handled externally by those that do it for a living; knowing that there’s a solid service supporting the infrastructure, redundancy, monitoring, support, etc.

Now all you have to do is check out the 1:30 minutes product tour video and start using Xeround!

P.S Don’t forget to join me at the DIY vs As-A-Service: The Economics and Practical Benefits of Leveraging Cloud Services webinar

Joyent, has chosen Xeround as part of four leading cloud service providers to participate in an online panel discussion taking a closer look at the economics and practical benefits of leveraging cloud services.

Join Xeround, Clodant, MongoLab, Nodejitsu and Joyent on Wednesday, August 22 at 11AM PDT, for this special webinar.

We’ll talk about how to select the right service for your design goals, the trade-offs of in-house vs. cloud-delivered models, and some benefits that your CEO, CFO or Board Member will love to hear.

Topics include:

• When and Why PaaS/DBaaS
• Commoditization of Automation
• Economics & Expertise
• Portability of Flexibility

Register for the webinar »

Also, be sure to join us before and during the webinar at #asaService on Twitter to ask questions and comment on what you’re hearing.  There’s a swag package prize for the best twitter question!

Everything we do focuses on freeing up your IT resources and reducing the need for IT expertise, so that you can concentrate on what you do best – cranking out kick-ass code. Enjoy!

Thanks to Aaron on the Wiremob team and Manner Oshaf for suggesting two great services missing from our previous list – CakePHP and Jelastic. If you spotted a free cloud service that’s not on this list, just let us know in the comments below and we’ll add it in a jiffy.

See FREE cloud computing services by category:

Few of us can get around without good developer tools, but having to pay for, install and configure them is a drag. Here are a few IDEs, source code management systems, issue tracking tools and other cloud computing services that offer an ongoing free plan.

Know a free cloud computing service we missed out on?

Our free Cloud Database has been a success in no small part because of the feedback we receive from the Xeround community. If you spotted a free cloud computing service that’s not on this list, just let us know in the comments below.

Here’s to creating the coolest apps on the planet!

A couple of days ago I had breakfast with a friend of mine. In between courses we talked about the food, the level of service we received and how hard it must be for the (very) few waiters we saw to cater everyone.

Towards the end of the meal our conversation shifted towards work and I found myself talking about Xeorund. I quickly explained what we do – hey, it’s not that hard explaining the notion of a database as a service and why it makes sense to “outsource” this aspect of development to experts :).

What I had to spend more time talking about was how we do it. How can a relatively small group of individuals manage such a large customer base? Sure, we have great people, all experts in their fields, all super-professional and motivated. But even to a great team like ours- managing Xeround’s ever growing user base could have been a handful.

As the popularity of our service grows (we appreciate your support!), Xeround’s fleet of active databases continues to grow exponentially.

Today, Xeround’s database-as-a-service boasts more than 15,000 databases live at any given time. Sure- some databases are more active than others: we’ve all been there where in those early stages of development nothing much happens in your DB, and we all know developers can put a project on the backburner and come back to it at any time. So to be even more strict on the numbers: our current stats show that over 9,000 apps are served DAILY using Xeround as their DB, with more than 50,000 concurrent connections.

That’s a lot of databases. A lot of people counting on our service.

So how do we do it? Automation. If I had to sum it all up in one word, automation would be it.

Automating DB Management in the Cloud

I went on explaining that Xeround uses extensive business logic and employs automated mechanisms in order to manage our customers’ databases. There’s a lot of magic that goes on behind the scenes – a lot of knowhow and a lot of experience (building on our roots providing database solutions to Telco operators- where downtime is simply not an option). But, basically, we knew from day one that the only way to succeed in managing data in the cloud is to be prepared to handle EVERY eventuality automatically. Be it availability issues, replication, burst in demand or what now. The brain of the system need to know how to handle it.

Xeround’s ‘system’ is unique. I personally see it as the mother-of-all-“M”s in RDMBS :).

It’s unique in the sense that  there’s nothing centralized, no single or centralized brain that’s taking care of everything, no single point of failure, no middleware or hardware for that matter. The system is made up of virtualized MySQL frontends, distributed data stores, quorums and quite a few constructs all of which work together to insure Xeround’s high availability and elasticity. The Xeround system manages itself automatically; it grown and shrinks; it heals itself and even buys/terminates virtual machines (VMs) as needed.

The algorithmic notions that lie at the heart of Xeorund revolve around distributed decision making, quorums and leader elections. Xeround users are able to access their databases using a DNS that is mapped to Xeround frontend machines. Through these machines data is automatically partitioned and replicated across existing data stores. Each data store can manage this process by becoming the ‘leader’ of this activity. If something “bad” happens to a leader, a new one is selected in its place. The selection process is distributed and is based on quorums and leader election algorithms. And while, naturally, our OPS center is manned 24×7 and we receive alerts and notifications in real time when anything “bad” happens, allowing us to monitor the situation closely – we allow  the system to continue to run automatically and heal itself.

Simply put, Xeround’s database apparatus isn’t a case of some watch dogs and scripts that instantiate the database. It’s an orchestra of sorts, designed to handle it all automatically so that our users won’t have to, and so that neither would our employees.

What DB Automation Means for Your Bottom Line

We usually say in house that what we invested in R&D getting things just right, we save on Operations and IT. So this is how we come to manage over 15,000 databases across 4 public clouds, 6 data centers worldwide and various PaaS integrations – all with only four people in charge of our production environment. Yes. Four.

I can tell you I get to meet with a lot of cloud providers, different cloud platforms, IT services operators and even managed hosting providers- all with thousands of customers and DB deployments – and neither have that ratio of DBs per Admin. So not only does a database service save on operational costs and management headache for end users (waking up at 4am trying to solve some problem), but it makes sense for those running the infrastructure as well.

And to sum up: it suddenly hit me that we’re closing our 1 year anniversary in production, after launching commercially in July of last year. And, sure, I get to boast a bit in this post, but this is what proud fathers do ;)

Cake anyone?

See how easy it is to:

1. Create a new, fully functional, FREE database instance
2. Seamlessly connect your new cloud database to your application
3. Auto-scale your database when more resources are required – with no need for configuration or management overhead on your part, and with no need for the application to be aware.
4. Ensure high-availability with just 1-click: See how a cloud server crashes and your database survives as if nothing had happened!

Sign up to create your free cloud database on Joyent Cloud

The Rackspace Cloud Tools Marketplace is a catalog of innovative, third-party developed tools and applications available for the Rackspace open cloud.  We’re thrilled to offer both free and paid plans of our database-as-a-service through the new marketplace, available for both Rackspace first generation Cloud Servers and Cloud Servers powered by OpenStack.

Rackspace users can experience the most robust solution for running MySQL in the cloud with no installation, configuration or management overhead by simply adding the product to their account within the Marketplace.

To use Xeround’s Cloud Database via the marketplace click here.

Integrating with Rackspace’s marketplace is in addition to the option available to Xeround users of choosing to create their cloud database on our Rackspace U.S. or Rackspace UK data centers from within Xeround’s management console.

Until now, Rackspace users were offered Xeround’s paid editions, Xeround BASIC and Xeround PRO.

Xeround FREE is limited to 10MB and is most suitable during the development stages or for small-scale applications. With the addition of Xeround FREE on Rackspace,  Rackspace users can now streamline their development in the cloud – enjoy a highly-available MySQL database service with no installation and without having to pay for database hosting.

Register to create your free cloud database on our Rackspace US data center.

Xeround PRO:

• Now supports up to 4,800 connections by default.
• (As before, Xeround PRO’s connections limitation can be increased to support unlimited throughput, as part of Xeround’s auto-scaling capabilities.)

Also, both Xeround BASIC and Xeround PRO now support SSL connectivity.

If you haven’t already, we invite you to sign up to start a 30-day free trial of Xeround BASIC or Xeround PRO – to enjoy the most robust, highly-available, zero management solution for your database in the cloud.

Start your free trial today »

*Existing Xeround BASIC customers will see the new pricing in effect as of July 1st, 2012. All current Xeround BASIC instances (including Trial instances) are already updated with the new plan’s thresholds.

What is SSL?

To those of you who are not familiar with SSL, it is a cryptographic protocol that provides communication security over the Internet. Formally, SSL encrypts the network connections, using asymmetric cryptography for key exchange, symmetric encryption for privacy, and message authentication codes for message integrity. A less strict way to think about SSL is that it simply protects your sensitive information as it travels across the Internet. Last but not least, SSL is used as an authentication means; allowing you to be sure that you are connecting to the service/site you intended to connect.

Why use SSL to connect to your Xeround Cloud Database?

So, now that we know everything there is to know about SSL :), you might ask yourself how this relates to your Xeround database. I mean, you know you have a username and password for your Xeround database instance and that you can’t connect to your DB without authenticating, Right?. So why SSL?

SSL does improve your level of security and makes it that much harder for prying eyes to examine or change your data while it is making its way from the application to your database and again from the DB to your app.

The simplest way to think about it is that you communicate with each Xeround database instance using signed and wax sealed mail envelopes. The envelope contains your SQL queries. Before sending your envelop you sign it using wax and your own seal (which the Xeround service generated for you). You send your envelope to a certain address, and once it reaches its destination, the database verifies that you sent the original envelop (remember Xeround generated your seal). Query results are returned in much the same way.

How to use SSL with your Xeround DB instance?

Now, back to the matter at hand; in order connect securely to your Xeround database you need to obtain the SSL certificate from Xeround and embed it in your code or application.

In order to obtain your SSL certificate, log into Xeround’s Management Console and follow these simple steps:

1. In the Management page, select your DB instance from the instances list
2. Go to “Advanced” Tab
3. Click on “CA-Certificate” link
4. When prompted, save the file (“ca-cert.pem”)
5. Click on “Client-Certificate” and “Client-private-key” links and save these files as well. Two files will be downloaded: -client-cert.pem and -client-key.pem

Once you’ve retrieved your certificate, edit your application’s connection string to use the client certificate and client key to connect securely to your database instance.

Needless to say, making sure that your database connection is set-up to use SSL varies according to your programming language. Just to get you going, below is a simple code snippet that shows how to connect to Xeround from a PHP app:

$host = '<your instance's DNS>';
  $port = '<your instance's  port>';
  $user = '<instance's user  name>';
  $password = '<instance's  password>';
  $dbname = '<DB name>';

Connecting via SSL to Xeround using PDO API:

try {
  $pdo = new PDO(
  "mysql:host=$host;port=$port;dbname=$dbname",
  $user,
  $password
  array(
  PDO::MYSQL_ATTR_SSL_KEY    =>'path/to/<instance-id>-key.pem',
  PDO::MYSQL_ATTR_SSL_CERT=>'path/to/<instance-id>-cert.pem',
  PDO::MYSQL_ATTR_SSL_CA    =>'path/to/ca-cert.pem'
  )
  );
  }
  catch (PDOException $e) {
  print "<br>Error!: " .  $e->getMessage() . "<br/>";
  die();
}

See more code samples here.

Should I use SSL for my application?

Now that you know how easy it is to use Xeround with SSL, you might ask yourself why not use it all the time? To that I can only say that – as most other things in the known universe – nothing good is free :)

SSL does incur certain performance degradation due to the fact that every communication to and from the database is encrypted.

So, whether you choose to take the red pill (SSL) or the blue one (no SSL) is up to you. I only want to show you the way… ;)

*Note:
All new DB instances created and all current Xeround BASIC customers can use SSL. The upgrade of existing Xeround PRO customers will be completed within the next couple of weeks. If you are a Xeround PRO customer and require this feature sooner, please contact our support team at support@xeround.com and we’ll upgrade your account ASAP.

A little over a week ago, Amazon’s EC2 East coast data center suffered another outage affecting well-known sites such as Heroku, Pinterest, Quora, and HipChat.

// UPDATE July1st, 2012:
Update; Yup, it happened again. Amazon experienced another outage in its east coast datacenter. The outage started Friday evening, June 14th and lasted until next morning, US Pacific time. This time it wasn’t a lightning strike rather a faulty breaker. Talk about a Déjà vu…

Once again, we’re confronted by the fact that the notion of the cloud as being always available and never going down is just plain wrong (as we’ve seen several times before).

In the dynamic environment of the cloud- availability issues should be treated as a given. You know that they will eventually happen. So: you could be afraidddd, be very afraid! :) or, you could be prepared. Cloud users must be ready to minimize the risk and effectvly handle availability issues – but they shouldn’t panic…

That’s life.

As with many other things in life, cloud developers could be categorized roughly into three groups:

• Those who know that clouds are dynamic environments and bad things happen from time to time.
• Those that upon hearing such news, go “Wow, hold your horses there; how can a cloud go down?”
• Those that don’t really care, or more accurately –  those that can wait it out until the service interruption has passed (clearly, won’t work for mission-critical applications).

Developers who are aware of the dynamic nature of clouds take extra care protecting their assets (applications and more importantly data) and trying to minimize business interruption as much as possible. A cloud high-availability / auto-failover solution should be implemented in such a way that does not require the application to be aware of it, that responds to any cloud failure immediately, and all in a painless manner as possible – so you do not need ot struggle to maintain service.

Developers might start with low-end solutions like backups, Elastic Load Balancers, manual redistribution of apps on different geographies – all of which are far from ideal. In fact they add additional burden in terms of management overhead and configuration changes, when you need to re-deploy servers, sync data, etc.

Alternatively, you can opt to go with higher-end solutions such as Xeround’s Database as a Service – that was engineered exactly for such eventualities by ensuring high availability in a zero-management, 1-click, service.

So needless to say– we hope your app and its availability in the cloud matters to you, and that you give us a try before the next cloud failure.

As for the developers who were not aware of the cloud’s inherit availability problem, they should use this blog as a wake up call and make sure they are protected.

Those that don’t really care or the ones that think ensuring high availability is about as fun as reading Vogon poetry! (The third worst poetry in the universe…) should take heed. You never know who might want to build an intergalactic highway through your cloud / data center when it would most matter…

Anyway, I’ve laid out towels for everyone.

So long and thanks for all the fish.

Xeround Cloud Database is the only free relational database offered to Joyent customers, providing zero-management experience and seamless high-availability for MySQL in the cloud- all in a simple database-as-a-service.

When creating their cloud database via Xeround’s Management Console, users can now choose to create it on Joyent Cloud’s data center. Other Xeround plans to complement Xeround’s FREE edition are scheduled to launch in the coming months.

See it in Action! Attend our live webinar:

We’re hosting a joint webinar with Joyent on July 18th, 2011 @ 10AM PST. Register for the event »

In this session you will learn how to:

1. Create a new, fully functional, FREE database instance in seconds running on Joyent cloud
2. Seamlessly connect your new cloud database to your application
3. Auto-scale your database when more resources are required – with no need for configuration or management overhead on your part, and with no need for the application to be aware.
4. Ensure high-availability with just 1-click: See a live demo of how a cloud server crashes and your database survives as if nothing had happened!

Register for the webinar »

3 Database Bugaboos Facing Platform as a Service

PaaS solutions strive to offer an environment that’s scalable on all tiers, yet their forte is the application layer. Many PaaS providers experience limitations when it comes to the database tier, particularly when dealing with relational databases. Here are three reasons why.

Read the full article on TNW »

What’s Next for Cloud Databases? Top Factors that Will Determine Success

Cloud infrastructure is being continuously improved and optimized, so that over time it will be standardized and commoditized. Today’s cloud service providers are offering nearly identical hardware and stacks, which is more cost effective on their end in terms of maintenance and operational costs. This begs the question: How will each cloud provider differentiate and survive among others?

Read the full article on Cloud Times »

Interview: Razi Sharir on DBaaS and Xeround’s partnership with PHP Fog

Web & PHP magazine spoke with Razi about Xeround’s NoSQL back-end and the company’s recent decision to partner with PHP-focused PaaS provider AppFog.

Read the interview on Web and PHP Magazine»

Lastly, listen to our interview with SSWUG.org and check out Forbe’s article: Xeround Fulfills the Promise of the Cloud.

As the years passed I moved on to other areas of interest and focused mainly on BI and analytical solutions.

Recently I was offered the opportunity to join Xeround and lead its product management activity.

This allowed me to once again revisit this area of computer science which I found particularly compelling and challenging.

What I found at Xeround did not surprise me. As with any other technological breakthrough or advancement, things that seem easy on the outside (hey, let’s put a database instance in the cloud) can be quite complex on the inside. Making them seem simple, now – there’s the real challenge :)

Designing, developing and releasing a product that is built to address a particular pain and that actually changes the way people use databases in the cloud – now, that’s art!

Neo once said “…I don’t know the future. I didn’t come here to tell you how this is going to end. I came here to tell you how it’s going to begin.”

Let the games begin!

Yuval

Xeround’s  add-on provides .NET and PHP developers using these platforms with a zero-management, highly available and scalable cloud database solution in just one click.

To create a new Xeround DB instance on PHP Fog and AppHarbor, all users need to do is add the add-on to their application from within their environment. This automatically creates a MySQL-compatible cloud database that easily connects to their application.

Xeround’s add-on on AppHarbor is available in Xeround’s FREE, BASIC and PRO plans as a complete end-to-end solution for seamlessly using MySQL with your .NET app. PHP Fog users will initially be offered Xeround’s FREE version, soon to expand to additional plans to enable automatic scaling and more robust features.

The four of them discuss how to choose the cloud database solution best suited for your application’s use case, the state of the market and where cloud databases are headed.

Listen to the podcast:

As more and more applications are being migrated to the cloud – we see developers choosing to integrate with their application a myriad of off-the-shelf cloud services – rather than develop components themselves or (worst yet) being bothered with the infrastructure hassles like in the past.

One such example is Blue Saki Online – a Xeround customer tasked with migrating AMANDA Video Marketing Platform to the cloud.

AMANDA is a subscription-based video marketing platform tailored to the needs of the financial, insurance and healthcare industries. AMANDA combines the features of email marketing, YouTube, social media, blackberry messenger reporting and CRM to create a powerful and effective video marketing tool for agents, representatives and consultants in the service industry.

The Challenge

The migration of AMANDA to the cloud was aimed to ensure 99.99% high availability guarantee of all application’s components – including the database tier – in a way that would:

• Minimize in-house management resources and operational costs
• Will provide a fully-managed self-monitoring environment with 24/7 support
• Will support future scaling needs in a painless manner

The Solution

Blue-Saki Online chose an all-cloud-services strategy to develop their video marketing platform and migrate it to the cloud.

From application server and load balancers, to the database service, CDN, email delivery, load testing, monitoring, financial services, and more — only off-the-shelf cloud services were chosen.

By examining the reasons for choosing only cloud services (and the specific solutions chosen)  - we can see how the cloud helps developers:

1. Cut down on development and operational costs
2. Enable faster time-to-deployment
3. Improve reliability for mission-critical applications.

Read the Case Study to learn about the economic, strategic and operational reasons behind the “Everything-as-a-Service” approach and discover its direct impact for your bottom line.

 Read the Case Study »

Xeround is already running on Rackspace Cloud in the US, as well as on Amazon EC2 in the US and in Europe, Heroku, Engine Yard, and most recently in beta on HP Cloud Services. This latest addition of Rackspace UK datacenter marks Xeround’s continued expansion to additional regions, cloud providers and cloud platforms worldwide.

Cloud users running their apps on Rackspace’s UK datacenter can now create their Xeround DB instance on the same datacenter – enjoying Xeround’s no-downtime guarantee and true elasticity.

Xeround on Rackspace UK is available in both Xeround BASIC and Xeround PRO plans.

The first 30-days of using Xeround are free - no credit card required.
Sign up to create your Xeround cloud database on Rackspace Cloud in the UK.

Initially, Xeround’s add-on is integrated with Engine Yard’s Orchestra PHP Platform, and will later expand to Engine Yard’s Ruby cloud.

Xeround Cloud Database Add-on for Orchestra PHP Cloud

Xeround’s add-on allows Orchestra users to create their Xeround DB instance with a single click from within the Orchestra environment. This automatically creates a highly-available, zero-management, cloud database that easily connects to their PHP application.

Currently, Xeround’s add-on for Orchestra supports Xeround FREE plan, best suited for small web apps and development or staging purposes. The new add-on allows users to enjoy an always-on MySQL-compatible cloud database up to 10MB at no cost.

Xeround’s additional paid plans (Xeround BASIC and Xeround PRO) will be rolled out in the coming months. Until that time, Orchestra users looking for larger DB sizes, automatic scaling, unlimited throughput and other advanced features, can register via Xeround to create their database instance – and then connect it to their Orchestra application just as they would connect their app to any external database.

See instructions on how to connect your Orchestra MySQL application to Xeround here.

See it in action!

Attend our live webinar with Engine Yard.

Wednesday, May 09, 2012
Time: 10:00 AM – 10:30 AM PDT

Are you thinking of running your PHP application in the cloud, or is it already running on Orchestra PHP Cloud?  Being one of the most popular databases out there, chances are your PHP application is also using MySQL as its database. With Xeround’s new add-on for Orchestra PHP Platform you can discover the easy way of running MySQL in the cloud.

Join us for this 30 minute webcast, where you will learn how to:

• Create a new, fully functional, FREE database instance in seconds
• Seamlessly connect your new cloud database to your Orchestra PHP app
• Auto-scale your database when more resources are required – with no need for configuration or management overhead on your part.
• Ensure availability and elasticity with just 1-click!

Register to the Webinar »

We’re happy to announce that Xeround Cloud Database is now offered in beta on HP Cloud datacenter as well.

Xeround’s cloud database architecture is vendor-agnostic and can run on any cloud service provider. We are constantly expanding our offering to include additional regions and clouds – allowing more of our users the choice to run their Xeround Cloud Database on their chosen cloud provider.

When signing up for Xeround, users can now choose to create a Xeround FREE database instance in beta on HP’s AZ2 datacenter in the US west coast. Additional Xeround plans will be rolled out in the coming months.

In addition to the new beta on HP Cloud Services, Xeround’s database-as-a-service is already available on Amazon EC2 in the United States and in Europe, and on the Heroku platform; with more PaaS partners and clouds scheduled to go live soon.

Watch the video interview:

There are plenty of options to help developers get a jump-start in the cloud with no cost at all and no need to purchase or install any software or hardware. With the myriad of free development tools and services in the cloud – you can start developing much faster; shorten time-to-deployment, and all with no upfront investment or hardware hassles.

From Development to Production – All Free in the Cloud:

Here’s a (very partial) list of some of the free cloud resources available. Feel free to add your recommended tools!

 Developing Applications

• Integrated Development Environments (IDEs) consist of source codes, automation builders and a debugger. Cloud IDEs, such as koding.com, Cloud9 or eXo are all free of charge and, because they’re in the cloud  allow for developers to conveniently edit and code anytime, anywhere.
•  In addition to cloud IDEs, there are also Platform-as-a-Service (PaaS) solutions for application development, such as Heroku or Engine Yard for Ruby, CloudBees for Java developers, or AppFog for PHP. Each PaaS offers a free version of their services allowing you to both code in the cloud and easily deploy your application later on once you’re ready.

Database-powered Applications

• Most applications today require some sort of database connectivity/usage. When you develop in the cloud, and deploy in the cloud, the easiest thing is also to have your database delivered as a service in the cloud – so naturally we should mention Xeround’s free cloud database :). Xeround FREE allows MySQL developers to create their highly-available database in the cloud at absolutely no cost. Rather than worrying about the IT and having to manually install, configure and manage your database – developers enjoy a zero-management free MySQL-as-a-service working out of the box with a click of a button.
• Another example of a free database solution in the cloud is Heroku’s free Postgres database provided for each Heroku application.

Deploying Applications

• Amazon EC2 offers a free “micro-instance” tier, where after twelve months, you’re prompted to pay-as-you-go.
• CloudBees offers a IaaS solution called Run@Cloud, which provides all services needed to deploy in the cloud, free of charge.

To save you even more time, many of these free cloud services – among them the various PaaS environment and of course database-as-a-service (DBaaS) solutions –  take care of all the operations and maintenance for you automatically, eliminating the need for manual management.

Do you have a recommendation for more free application development solutions in the cloud? let us know in the comments.

If you’re also interested in the more in-depth overview – watch our Slidecase with RichReport

We’re excited to announce the much anticipated release of “Xeround FREE” - a free version of our popular cloud database. Xeround FREE provides MySQL users with a zero-management, simple, highly available – and best of all completely free - cloud database solution.

CHILL with Your Database in the Cloud

Rather than having to install, configure and maintain a MySQL database in the cloud, you can now easily create your free cloud database with just one click.

With database creation and management out of the way — you can focus on your code rather than on the IT side of things.

Xeround FREE is great for starting out with your database in the cloud. It is suitable for on-going development, testing and staging purposes, as well as for smaller web applications. Available up to 10MB at no charge, Xeround FREE is initially offered on our Amazon EC2 US-East datacenter and as an Heroku add-on, expanding to additional regions/clouds in the future.

Free as in Beer

Xeround FREE is completely free. Forever.

Every Xeround user is entitled to one concurrent Xeround FREE database instance.

To create your free cloud database, simply log in to your account and choose “Create New”, selecting “Xeround FREE” from the list of available editions.

Xeround Cloud Database New Editions

For customers that require larger database sizes, higher levels of scalability, additional support and SLA, we are announcing two additional editions of our cloud database solution: Xeround BASIC and Xeround PRO.

Xeround BASIC is suitable for medium-size applications looking for a cost-effective, plug-&-play, highly available database solution in the cloud. Xeround BASIC is limited up to 250MB and is offered in tiered pricing starting at $17/month.

Xeround PRO (our commercial version that launched last June) is suitable for mission-critical, larger-scale applications that require unlimited scalability, high availability SLA, scheduled backups and more. Xeround PRO already has more than 300 paying customers and boasts a complete end-to-end solution for seamlessly running MySQL applications in the cloud. Xeround PRO is offered in a pay-per-use model starting at $0.21 for GB/hour of data (with a minimum charge for 0.5GB), and $0.43 for GB of data transfer.

Both Xeround BASIC and Xeround PRO are available on Xeround’s datacenters on Amazon EC2 in the US and in Europe, Rackspace and on the Heroku platform.

The first 30 days of using Xeround BASIC or Xeround PRO are free!

To start your free trial register to Xeround, log in to your account and choose “Create New” – selecting either “Xeround BASIC” or “Xeround PRO” from the list of available plans. The 30-day free trial is in addition to your Xeround FREE database instance.

Xeround’s new editions provide you the flexibility to choose the most suitable plan for your needs.

To learn more on the differences between Xeround FREE, Xeround BASIC and Xeround PRO, visits our Plans and Pricing page.

Xeround customers: Check your email for instructions on how to migrate your existing DB to any one of the three new editions.
 

Round-robin DNS guarantees high availability of the connection to your database in a way that does not require you to tweak your application.

In the Database Manager Online Console you can see the DNS hostnames for connecting to your database.

• The Internal DNS points to the internal IP addresses and is used for accessing your DB from within the same datacenter
• The External DNS is used for connecting externally.

Each DNS routes to one of the available IP addresses we supply for connecting to your database. That way, if one IP address is temporarily unavailable, you can still connect to your database instance.

Under the Hood:

Xeround Cloud Database has multiple – and unlimited – front ends that can scale out as the application demands. We supply each DB instance with several IP addresses that are in fact load balancers that route the SQL requests to any of the database’s multiple front- ends. Those IP addresses are being resolved by the round-robin DNS.

What could cause a connection to fail?

Say a cloud server crashes (happens!). Xeround’s service management layer will monitor the machine and will remove it from the DNS entry so further attempts will not try to connect to the failed server. Moreover, Xeround’s auto-healing mechanism employs a “stand-by” machine, which will take over the failed components and then be added to the DNS entry, so further connections could be diverted to it. In the past, you had to code the failover between the connection IPs yourself, whereas now the round-robin DNS simplifies high-availability of your database connections in a way that’s completely transparent to the application.

What does the new DNS mean for our current customers:

New database instances that are created get the round-robin DNS by default. 

Existing customers or trial users that wish to take advantage of the DNS and other improvements of the new release, need to log in to their account and choose “Change Plan” to switch to one of the new editions. Switching to the new version will assign new connection DNS hostnames to your database.

For instructions and code samples for connecting your application to Xeround Cloud Database see here.

If you have any questions or need assistance, don’t hesitate to contact us.

If you’re in the neighborhood, stop by our booth (#818) and grab yourself this cool T-shirt!

Visiting the Expo hall is FREE: Get a free pass here (Use code CPNACC138)

The expo at Cloud Connect is open Tuesday – Wednesday, February 14-15 – 11am to 6pm.

Hope to see you there!

Operational Database Management:

Operational database management is made up of many different topics. Most of these aspects are by no means unique solely to databases and are shared by other types of software deployments. Databases, however, are unique both because of the variety as well as the number of the operational aspects that affect them.

To illustrate the point, consider some common examples of database management activities:

• Deployment that consists of the installation, configuration, integration and upgrading of database software (and required infrastructure) in a repeatable and predictable manner
• Software stack maintenance via patches and upgrades
• Setup, maintenance and monitoring of solutions to increase the database’s availability
• Ongoing monitoring of the database’s health, resource levels, performance and supporting processes
• Resolve potential and existing capacity and throughput issues by scaling the database
• Around the clock, as instantaneous as possible recovery of the database a host of failure types

At Xeround, we always strive to simplify and streamline the way databases are ran and managed in the cloud – so running your MySQL in the cloud is as easy and as hassle free as possible.

Zero-Management Cloud Database:

Xeround Cloud Database service is zero-management – and by that we mean that our users don’t need to manage their database because we do.

Our database-as-a-service is designed to free our users from the need to understand, invest time and effort, and become more proficient in managing their DB. If you’re like most of our users – you’d also prefer focusing on your code than mastering the IT side of things.

With Xeround, all DB management tasks – including complex, time-consuming and failure-prone activities such scaling your database and ensuring its availability – are carried out transparently and automatically by the service itself – without any efforts on your behalf. You do not need to become an expert in MySQL scalability or high availability;  You do not need to configure anything or go into the nitty-gritty of how the service is actually delivered – It simply automagically makes sure your DB is always running effectively.

Keep it Simple!

Any good “-as-a-service” needs to be simple to use and unobtrusive so that once it is employed, you can just “forget about it”.

Xeround’s database-as-a-service is designed towards maximal easy-of-use so our users get a pure service experience and do not need delve into its inner workings. We invest vast efforts in building a powerful and robust database solution without sacrificing the users’ experience from it.

We keep it simple.

1. Instant one-click deployment – your MySQL database is up and running in the cloud in a matter of seconds. Nothing to install, nothing to configure, nothing to test – it’s just there- waiting for your command(line).
2. No need to provision any cloud resources – we do it all for you
3. Built-in High-Availability – we keep your database running off multiple nodes and replicas so infrastructural failures are mitigated without discernible impacts
4. Transparent, automatic scaling – we continuously gauge your database’s usage levels and ensure optimal operation by adding and subtracting resources on the fly
5. No need to set up monitoring tools and alerts – these are included our service and we act on them on your behalf
6. Secure, automated off-site backups – we take both on-demand as well as automated backups and keep them off-site in Amazon’s S3 for maximal resiliency
7. Restore your database to an existing instance, a new instance and even to an instance on a different cloud effortlessly
8. Manage many database instances effectively – our API is the perfect tool to provision and manage multiple database instances from within your application

A simple service doesn’t necessarily imply that its operations are simple. In our case, this is actually quite the opposite, since the challenges involved in managing thousands of database instances across multiple nodes and compute clouds are anything but simple. Success in doing so, however, means that our users get exactly what they need – a database service that they can simply use without any worries.

We are constantly adding new features all aimed at making our service even simpler for you guys- so if you ever have any feedback or feature requests – don’t hesitate to share!

– Xeround’s cloud database was featured on ReadWriteWeb as one of the top 10 Enterprise Cloud Services of 2011.

Pretty cool! :)

Read the full story on RWW »

• Consistency: the same data is read across the system
• Availability: the system is always responsive
• Partition Tolerance: operation continues despite network disconnects

The diagram offers a means to visualize the theorem and its implications: each one of the triangle’s edges represents one of the characteristics that the theorem discusses (C, A and P). Each of the vertices represents a combination of two attributes (i.e., C & A, A & P or C & P). Any distributed system, according to Brewer, can be placed on the diagram only at one of the edges or one of the vertices. As a result, no matter the system’s position in the diagram, it can never posses all three attributes at the same time.

Xeround’s DBaaS is implemented as a distributed computer system and as such the CAP theorem applies directly to it. So which one of the three traits is compromised when using Xeround?

Let’s review the three system characteristics that Brewer addresses and discuss the possible impact of the absence of each of them:

• Inconsistency: it is possible to get different answers from different nodes at the same time
• Unavailability: there may be requests that will be left unanswered
• Partitioning-Intolerance: loss of messages can render the system inoperable

So where does Xeround fit in the CAP Theorem?

Q: Is Xeround Inconsistent?
A: No. Yes. No. Definitely Not.

Xeround employs a set of majority-based algorithms to facilitate its reading and writing of data from/to multiple, distributed nodes. This essentially means that every request made to the database, whether a read or a write, needs to be served by (at least) a majority of the system’s member nodes that are relevant to the request.  Via the use of these algorithms we are ensured that all access to the data is consistent so inconsistency is not an issue.

Q: Is Xeround Unavailable?
A: Nope.

There is no single point of failure in Xeround and every component that the system consists of is redundant and replaceable. Thus, if and when any of its components fail, Xeround is always available, allowing access to all data as well as all operations on it.

Q: Is Xeround Partitioning-Intolerant?
A: Yes, to a certain extent it is.

Xeround is an In-Network database and we rely on the network in keeping the database up and running. Despite the protective mechanisms that we’ve put into our technology (previously-mentioned quorum-based algorithms included), it is potentially possible for a more-than-trivial-but-less-than-total network split to bring the system to an unintelligible state. To safeguard against database schizophrenia because of split-brain (both to conserve consistency as well as avoid later conflict resolutions), Xeround’s database suspends itself when it experiences a network partitioning event that it can’t overcome by itself. In such cases, an external arbitrator (e.g., our service operators) instructs the system to continue operating by decided which of its parts is deemed active.

Got any other questions on Xeround and the CAP theorem? Post them here as comments and we’d be happy to address them.

Wishing you (and your database too ;))
a joyful Holiday Season and a happy and prosperous New Year.

As 2011 draws to a close, we invite you to check out some of our predictions for 2012, and to enter to win a $100 Amazon Gift Card – just in time for the New Year!

So, without further ado, here are our predictions for 2012:

1. The Cloud will disappear – not in the sense that it will be gone (far from it) but rather in that that it will become all-encompassing and omnipresent. We will no longer see The Cloud as a trend or even an alternate model for using compute resources – it will become transparent as it will be the de facto default means of choice for nearly all IT-backed projects across industry sectors.
2. Cloud Plurality – instead of focusing on a single cloud, we will be using multiple clouds simultaneously. Many different reasons – including cost, performance, availability, coverage and locality – will make being cloud-independent and cross-cloud-able a must requirement rather than just a nice-to-have benefit.
3. PaaS is King – with cloud resources’ commoditization on the one hand and developers’ general indifference to infrastructure on the other, PaaS providers will be in position to offer the best value to cloud consumers. This means that we’ll see fierce competition in the market as IaaS players will continue to expand their offering with integrated platform services and as PaaS vendors will diversify their platform stacks and services.
4. Enterprise Clouds – next year will be the tipping point for enterprises and mission critical applications to move to the clouds – with the technology, players and practices established. Enterprise datacenters will be migrated to private clouds and enterprise applications will be deployed there as well as on virtually-private, public and hybrid clouds. As a result we’ll see PaaS & SaaS offerings making their way as products (licensed or downloadable software) for the enterprises’ consumption in their own clouds.
5. Cloud Databases Are Here to Stay – the proliferation and maturity of cloud computing will continue to strengthen and drive the need for reliable database services in that ecosystem. The use of multiple cloud infrastructures coupled with the automation goodness that PaaS endows will make service-like cloud databases the natural choice that will be preferred over DIY as well as managed ones.

In retrospect, we were pretty much right on the money with our last year’s predictions – so as the momentum keeps, looks like 2012 is going to be an extremely exciting year!

Xeround will be exhibiting at the 2012 Cloud Connect Conference and expo, taking place February 13-16 in Santa Clara, CA.

And we want to see you there!

Register for the conference to learn about the latest cloud computing innovations, or grab your free Expo-only pass and stop by our booth (#818) for some conference swag and a demo of Xeround Cloud Database.

Use code CPNACC138 to:

• Register today and save 25% off Conference Passes 
• Or get a free Expo-only pass

Hope to see you there!

This funding is yet another affirmation to the genuine need in the market and to the success of Xeround’s patented technology in simplifying the way databases are ran and managed in the cloud.

We’re very excited about this news and the vote of confidence from our investors, and are even more excited to think of all the great things we can do as we put this money to work!

Xeround was founded in 2005, originally offering distributed database systems for internal operations of mobile carriers. Less than 2 years ago we made the decision to focus our offering on the public cloud — and to repackage our telco-grade, highly available and scalable database for cloud users out there.

While this financing round is the 3rd in the history of the company, it is the first one under Xeround’s new mandate, supporting our cloud database offering – which makes it all the more important for us.

In the past year Xeround has grown tremendously. After launching commercially just last June, we already have hundreds of customers using our cloud database on Amazon EC2, Rackspace and Heroku.

This additional funding will power Xeround’s continued expansion to additional cloud platforms (PaaS) and cloud providers — bringing our always-on, super-elastic database-as-a-service to a cloud near you.

From our press release:

“Xeround has emerged as a leader in cloud-based data management and the company’s execution on product and services is impressive,” said Arad Naveh, Partner at Benchmark Capital. “Developers will continue to need scalable, zero maintenance solutions for managing their data in the cloud. Xeround is well-positioned with its unique patented technology to excel in the market.”

So stay tuned- great things are just around the corner!

We are using tens of Amazon’s servers to power (and test and develop) our Database-as-a-service solution. Judging from our inventory, here’s what we do know:

• More than 80% of our servers are scheduled for reboot
• The maintenance-bound instances are both in the us-east as well as the us-west regions
• It looks like only the newer instances (those started in last couple of weeks) are exempt

Like earlier events, this is another reminder of the fact that availability in the cloud shouldn’t be taken for granted and if there’s one thing to expect it’s the unexpected. Unlike previous outages, this time it’s a planned maintenance event and Amazon is doing a great job (at least in our case) in keeping us informed, providing documentation and assisting us to cope with the maintenance window.

The good news are that since these are instance reboots (and not system reboots), we’ll actually be able to control the schedule of reboots ourselves and keep the risk of any interruptions to our service to the absolute minimum. Leveraging on our DBaaS’s built-in availability mechanisms, we don’t expect  our users to experience any impacts as a results of this reboot cycle. We’re planning to do this next week and we’ll be sure to keep you updated on our progress.

So the countdown has begun: little more than a week to go!

And yes: we shall overcome! :)

A fair share of our users are already using Xeround to power their Joomla! sites. This is hardly surprising considering Joomla!’s popularity as a CMS (Content Management System) and how simple it is to use it with Xeround’s cloud database.

Typical Joomla! installations usually start using a MySQL database that is locally installed on the same server as the application. This single-server deployment model is common for development, testing and even the early production stages of the application.

As the application gains popularity, and as content and users increase, more of the server’s resources are consumed by the application and the database. To maintain the performance of the application, decoupling of application and database tiers is oftentimes the first optimization step. After that, adding new Joomla! servers to handle the increase in the volume of traffic is an easy task. Making sure, however, that the underlying database is available at all times and is able to scale alongside the application can be anything but.

This is why Joomla! site owners are migrating their databases to Xeround’s database service. Doing so ensures that their databases are available and can scale to accommodate their applications’ needs. And the best thing is that whether you are installing a new Joomla! site or migrating an existing deployment to work with Xeround – it’s as easy as 1-2-3!

Are You Running Your Site on Joomla!?

Check out our step-by-step guide to learn how to easy it is to have your Joomla! database in Xeround »

Xeround’s solution is a simple and powerful way to get your MySQL DB as a service in the cloud. This out-of-the box service is the perfect companion to many PaaS solutions – and we share the same basic principles as today’s cloud platforms – with our automatic scalability, ease of use and efficient cost structure.

Want to see Xeround as an add-on for your chosen platform? Let us know which environment you’re using- and you may see our Add-on integrated with it soon!

Take our Facebook Poll »

For me, one of the highlights of the expo was Cory Issacson’s session about ‘Scaling Your Database in the Cloud‘. Cory, the CEO of CodeFutures, gave the audience an excellent review of database scaling challenges in general and their manifestation in the cloud as well as how his company’s sharding solution addresses these.

The neat thing about sharding solutions is that they attempt to provide the application developer with all the benefits of database sharding whilst masking the underlying complexity of the setup. This presumably rids developers of the need for shard-aware code in the application and for sharding maintenance. Put differently, modern sharding solutions encapsulate the sharding logic that had to be coded in the application before their debut.

Naturally, for me the motivation to attend the session are the real and perceived similarities between our companies’ solutions (read competitive analysis). Coincidently, on the day before the session, I had posted my MySQL Sharding vs. MySQL Partitioning on our blog, so the topic of database sharding was still quite fresh in my mind.

It was then and there that it dawned on me that in my discussion about sharding vs. partitioning I had left out one aspect that I feel is central in the development of contemporary cloud applications, so I’d like to take this opportunity and present it. That missing aspect is stack ownership in the Cloud and its effect on the feasibility of database scaling solutions.

PaaS Solutions and Stack Ownership in the Cloud

Long ago, when the Cloud was still in its infancy, we used to deploy applications on it just like we always did – we’d take a bunch of machines and install them with everything that was needed for the application to run, including the OS, drivers, libraries, runtime components and so forth. This collection of odds and ends that’s required for the application’s normal operation is the stack. And stack maintenance was a real pain for developers.

Then PaaS (Platform-as-a-Service) was born, and allowed developers to focus on their programmatic strengths by taking care of the stack’s nitty-gritty for them.

However, by eschewing stack ownership and giving it to PaaS providers, application owners are also giving up much (if not all) of the control and flexibility that stemmed from their owning of the stack. As a developer using a PaaS you are restricted, for better and for worse, to your application’s code and in most cases you can no longer make changes to the underlying stack. Every PaaS player recognizes that this is one of the biggest challenges in providing a viable platform solution to its users and the common approach taken to addressing this is building a strong add-ons program. Add-ons are, in a manner of speaking, the way PaaS providers provide the developers to customize their stacks.

MySQL Sharding Solutions and Stack Ownership

Tying this to the original discussion about sharding and cloud applications’ development, not owning the stack is a real issue when you need to change it so it accommodates your application’s needs.

Because sharding is external to the database and because the stack is no longer yours, finding the place in the PaaS for your sharding solution can prove to be a non-trivial task when you want to replace your database driver with a shard-able one (such as CodeFutures’) or if you want to incorporate sharding middleware (such as ScaleBase’s) to your setup.

Furthermore, PaaS providers will usually have their own database services and/or database add-ons that are integral to their offering and taking the DIY approach to sharding these only compounds the complexity of the challenge.

Xeround, MySQL Scalability and the PaaS Ecosystem

Xeround offers a Database-as-a-Service (DBaaS) that can be used as a drop-in database replacement for your MySQL applications. MySQL scalability and availability challenges are addressed internally by our database’s design and do not require any external resources or management from the application.

Regardless of the techniques that we use to achieve these goals, what our users get is a truly transparent database solution in Service form. This means that we play nicely with PaaS, whether via an add-on or not. Being a fully managed service, you can integrate Xeround’s database with your PaaS-based application just by changing its connection string and nothing more.

Watch the short video interview:

There’s no one-size-fits-all solution for scalability, and each service or configuration available in the market addresses scalability in a different way. It’s up to you to make sure the MySQL scalability solution you end up with matches your specific DB scaling requirements.

MySQL Partitioning

Database partitioning is one of the approaches used to address scaling challenges. Partitioning a database means splitting the database and handling each of its parts independently. While the logical database remains the same (it is made up of all of its partitions), its fragmented physical form allows each partition to be scaled (as well as managed and protected) separately. Because each partition is, by definition, smaller than the entire database, the challenges associated with scaling it shrink in size as well.

Partitions come in all forms and sizes (pun intended) and there are different ways to chop up your database in order to render it into digestible pieces. High-end, commercial RDBMSs offer built-in partitioning mechanisms for a premium, but the humble MySQL database isn’t that well-endowed in that department by default. MySQL has the ability to harness storage parallelism to improve performance by partitioning a database by its tables and even the tables themselves, but that’s all. MySQL simply lacks an integral partitioning mechanism that allows the different partitions to be assigned with dedicated compute, memory & network resources.

MySQL Sharding

Database Sharding, which is a form of partitioning, has gained popularity and acceptance as a complementary scaling solution to MySQL databases. With Sharding, you can assign dedicated resources to each MySQL database “chunk”/partition.

Sharding is outside-the-box thinking in more ways than one. With it, each database partition is in fact an entirely independent database by itself that is oblivious of its peers. Getting to the data is just a matter of accessing the right database shard. It brings the ability for MySQL to scale out via horizontal partitioning of the database where different tables, as well different rows from the same table, can be managed across separate, independently scalable database servers. It is external to the database management systems themselves so these need not be partition-enabled and you can even use different types of DBMSs on different shards if you are so inclined.

MySQL Sharding: Pros and Cons put on the Scale

With all that sharding goodness there’s a price to pay, and it is a hefty one because sharding rips your database’s soul! OK, maybe that was a bit too dramatic ;-). But understand that when you shard your database what you’re actually doing is transferring the management layer of the logical database from the database management system to a different layer: that of the application.

Yes, scaling issues are mitigated now, but at what price – what were you forced to let go of?

Your application’s innocence for one thing. It may have to be taught about shards and how to work around the limitations that are the result of “outsourcing” the ownership of the logical database to it.

Arguably, via the use of a shard-able database driver you can save on implementing shard routing in the application. Similarly, by using a shardware (own-coined term for sharding middleware) allowing for auto sharding, you can skip over the more grueling aspects of shard management and provisioning. The issue of cross-shard transactions, on the other hand, is harder to solve and these need to be managed by dedicated application-side mechanisms. Having isolated shards of the database also means that you’ll be out of luck if you are using triggers – the logic in these will have to be migrated and carried out by the application to ensure its proper execution across shards. Same goes for stored procedures. And if the application is using an ORM tool, it better support sharding or you won’t be able to use it anymore.

Sharding isn’t evil and there are well known success stories supporting its case. That doesn’t make it the silver bullet for database scaling problems, but rather another approach that’s valid in some cases. It is simple and dirt-cheap to set up initially – but may be a hassle to support on-going in the long run, so beware and be aware of the implications.

Xeround and MySQL Partitioning

At Xeround, we proudly employ the the partitioning practice. Our database utilizes virtual partitions to transparently divide the database to manageable chunks, allowing us to reap the scaling benefits of that approach. However, unlike sharding, our partitioning is carried out inside the database and deep in its data storage layer. Being integral to the database, our partitioning is entirely unobtrusive and does not impede that standard functionality that’s expected from a DBMS. The application is unaware of the way data is organized within the database and continues to regard the database as one logical whole without having to undergo any changes. With all scaling issues resolved at the DB level, the application remains stateless – as is the best practice, particularly for a cloud deployment.

So there you have it: MySQL partitioning done by the database service itself – automatically and seamlessly–  for guaranteed scalability without the headache.

In general, today’s databases are divided into two categories, depending on where the data is stored: disk-based databases and  main memory databases. Disk-based databases are more common, whereas in-memory databases are usually used for  high performance solutions.

This categorization doesn’t mean however that in-disk databases do not use the memory, or that in-memory ones don’t use the disk. Naturally, for the sake of durability, when writing the data in a memory based database, it must also be written to disk (although not necessary for all data and index files, but at least some form of redo logs is required). In-disk databases can usually cache the disk data in-memory, depending on the available memory. This cached data can later be used to serve some queries faster – from memory rather than going to disk.

With this in mind, we could argue that in-disk vs. in-memory categorization is less about the physical location of the data, but rather more about where in the database architecture is the slowest link for serving queries.

In-Network Cloud Database:

Xeround’s Cloud database for MySQL apps is an in-memory, distributed database, where several replicas of the data reside on several machines. Because of the distribution element and replication, we could categorize it as an In-Network database.

And indeed, the gating factor where it comes to performance is the network.

In a regular DB, the application would connect to the database via the network, and then data is retrieved locally (either from memory or disk) and sent back to the application. (Sometimes, the client can save the network hop when collocating the DB and the application). With Xeround there are extra hops from the frontend to the backend – at least one in a simple read and sometimes more than one depending on the operation type.

Benefits and Considerations When Working with an In-Network Database:

Xeround’s distributed architecture allows us to scale beyond the boundaries of a single machine by harnessing the capacity of main memory and CPU of several machines. This both lifts the key limitation on in-memory databases (the available RAM of any single machine) and enables MySQL high availability by replicating the data to more than a single location.

This however implies that the lower boundary of how fast Xeround serves a query is set to four network hops: client à frontend à backend à frontend à client; whereas in a non-distributed database you could get a response to a query in two network hops (client à DB à client). In that case, if the database is served from memory, then the operation will most likely be quicker (primary key search on cached data), but if data is not cached and a disk seek is needed it will probably be slower compared to Xeround’s performance.

Xeround’s solution balances our distributed architecture – which enables elasticity and high-availability – with an in-memory database for improved performance.

The key thing you should be aware of when connecting your app to Xeround has to do with optimizing complex queries. As one of our customers put it: “You don’t give me any passes on inefficient queries but you also don’t ever refuse to serve them.” We do accept any queries you have, no matter how inefficient, but it could just take you longer. Wrong indexing will cause more network hops and will increase the response time (whereas, in traditional DBs this can sometime be handled by caching.)

Xeround is 100% MySQL compatible so that you do not need to change your code to use a cloud database, and we always strive to make the move to the cloud as plug-and-play and as simple as possible. This, however, doesn’t negate the need to optimize your SQL queries :) as is the best practice no matter what DB solution you use.

Some best practices to keep in mind:

While these may seem obvious, it’s always good to make sure that you follow these best practices:

• Be sure that you’re using indexes and avoid full-table scans.
• If you’re noticing a query takes longer than you would have expected, use EXPLAIN statement to make sure there are no full-table scans and create indexes as needed.
• BTREE and HASH indexing: the default type of indexing is BTREE. However, equality operations with high cardinality are served faster with HASH indexing.
• It is better to use “ORDER BY” by columns that are BTREE indexed.
• It is better not to store large BLOBs – the larger the record the longer the response time.

If you need any help or have specific questions regarding your indexes or common queries types- you can always email our support at support@xeround.com

Learn about how Xeround got started, what’s next for Xeround’s cloud database service, how it compares to other offerings in the market, and more.

Database Replication

Database replication is the practice in which we maintain multiple copies of the database. It is an approach that is generally used to address two types of challenges that databases are faced with:

1. High availability
2. Scalability

High Availability with Database Replication

High-availability of the database tier is paramount for business-critical applications. Naturally, when the application needs to demonstrate high availability, the availability of the underlying database layer is  key. That is where replication first shines through.

Keeping multiple identical replicas of the database ensures its availability via redundancy – for example, if one MySQL replica fails, you can  simply switch to another for continuous service.

A simpler Master-Slave Replication model is usually sufficient to ensure high availability in most (if not all) cases. In this model, one (master) MySQL database is used exclusively for accessing the data, while an additional (slave) MySQL replica (or replicas) is synchronized with all updates. (While admittedly, Master-Slave Replication is a broader subject with fine nuances, this simplification should suffice for the purpose of this post.)

Scalability with Database Replication

It also happens that the Master-Slave Replication approach is an appropriate solution for scaling issues, albeit not all of these.

The need for scaling occurs when the size of the database and/or the traffic against it (=throughput) grows to the point of crossing an optimal level of performance. This optimal level is influenced by the database’s implementation (hardware, software, data structure & access patterns).

Unless addressed, from that point onwards, the database’s performance is impacted, and if goes untreated – its availability is threatened. This could results in connection timeouts, loss of business and service interruptions.

Once we identify the need to scale, the easiest way to achieve it is by upgrading or even replacing the hardware. This solution, however, can carry you only so far — because at some point (providing that growth continues) the database’s performance requirements will outgrow any existing hardware solution (that you can afford.. J), and there will be a need to scale beyond the limit of a single machine.

Considering that in most cases the attempts to optimize or upgrade the remainder of the stack are too costly, complex and only temporarily effective – a different strategy is required.

Once again, replication can provide the means for effective scaling.  By creating fresh clones of the database and enabling the load balancing of the application’s traffic against multiple replicas of the database you can in fact “split” the load and achieve better performance.

But the plot thickens…

Given that it is based on a single writer – with all writes done against the Master database – Master-Slave Replication can only help in resolving Read Scalability issues where the volume of read requests outgrows the database’s capacity to serve them. Depending on their freshness and the application’s requirements, slave replicas can be used to read data from and effectively distribute the reads’ load.

As for Write Scalability, however, the slaves are worthless since the premise of the Master-Slave model depends on using a single master database for updates and that single master is a bottleneck.

So it comes to be that in order to scale the database’s writes a different replication model is required – and this is where we arrive to Master-Master Replication.

MySQL Master-Master Replication

In Master-Master Replication, or Multi-Master Replication, there are multiple MySQL master databases and every master can be used both for reading from as well as writing data to. Updates can be made to any of the masters and are propagated to all other masters. Since masters are abundant and can be (arguably) added on a whim, write scalability becomes a non-issue.

Sounds too good to be true? It is.

MySQL Master-Master Replication is notoriously hard to set up and maintain, and that’s even before taking into consideration real-world facts such as communication latencies, bandwidth issues and network failures. The main difficulty with multi-master replication is in effectively resolving conflicting updates whose existence is made possible by the multiple masters. Because this setup potentially allows simultaneous conflicting changes to the same data by different masters, a conflict resolution policy has to be implemented in order to protect against these. There are numerous approaches when it comes to conflict resolution, and choosing the right mix of resolution methods in a policy largely depends on the actual requirements that the application poses. Ironically, best practice and common sense suggest that the simplest and most effective conflict resolution strategy is to avoid conflicts altogether (and thus save the need to handle them).

Putting aside the challenges involved in keeping a MySQL Master-Master gig going and conflict-free, the real issue is that the Master-Master Replication model rarely provides a viable, long-term solution for Write Scalability.

This is because every additional master that gets added to the gang carries the price of having to synchronize it with all updates as well. As all masters update all other masters, the marginal cost of every additional master actually increases and introduces more communication into what will eventually become the setup’s bottleneck – the interconnect.

By opting for Master-Master Replication to address the need for scalability in MySQL, we merely transferred the problem from the domain of a single server to that of the network (after having added a lot of complexity along the way).

What Are You Getting At with Master-Master Replication?

The reason asking for Master-Master Replication isn’t the right question to ask lies neither in the model’s complexity nor in its limitations. It is wrong to ask for it because Master-Master Replication is a means and not the goal. Choosing a tool without regards to the task at hand is always poor strategy. A better question would be – what do I need Master-Master replication for – leading to “How are database availability and scalability addressed by Xeround?”.

The Benefits of Master-Master Replication in a MySQL Cloud Database Solution

Xeround’s Cloud Database Service employs a mix of three unique capabilities:

1. Data replication at the storage-engine level
2. Overall components redundancy: of both the data storage, load balancers and front-end nodes
3. Xeround’s patented Virtual Partitioning technology

Let’s examine how these come into play to provide you with all the benefits of master-master replication, but with none of the headaches.

Our distributed cloud architecture spreads the data across virtual partitions, with each single partition replicated across multiple servers. This, along with the redundancy of all elements in the system, ensures  the availability of the data and the service at all times.Failures of individual components or of the data replicas do not affect the database’s availability, and are mitigated automatically and resolved online. The replication algorithms that are used by the storage engine accommodate both Master-Slave and Master-Master replication models. The choice between replication models is not only configurable but is also dynamic, as the system automatically adapts its behavior in response to topological events such as failures. Currently we offer our service with two built-in Active-Active replicas, and in the future we will offer DRP options that allow for Master-Slave configurations as well.

In addition to already maintaining replicas to achieve MySQL high availability, Xeround’s scalability does not rely on these. Scaling is made possible because of our use of our patented Virtual Partitions technology. This technology enables us to transparently distribute the database between any arbitrary number of servers, and to have multiple back end nodes connected to multiple front-end nodes. Both layers can scale indefinitely- the backend to accommodate any MySQL DB size, and the front ends to accommodate any throughput. This allows the resolution of scaling needs, both of reads as well as writes, to be carried out by the simple addition of resources and the automatic on-the-fly redistribution of data partitions across the system.

So there you have it- MySQL Master-Master with no management worries,  no configuration and re-configuration issues, no special handling in the application side, no hassles – it just works! :)

In the interview we discuss:

• What are databases in the cloud?
• Why are people using databases in the cloud?
• SQL databases in the cloud versus NoSQL
• Xeround’s solution underneath the hood
• Oracle and the SQL game
• And more.

You know you’re in the right field, and that there’s a genuine demand from the market, when the big guys want in!

And what a month it has been for cloud databases: October 2011 saw two announcements from the mega-corporates of the business world- Oracle and Google. Let’s examine what each means for the heating cloud database arena.

The Oracle Cloud

In his closing keynote at Oracle’s OpenWorld Conference in San Francisco at the beginning of this month, the always-controversial Larry Ellison – Oracle’s CEO – announced Oracle’s public cloud.

While this announcement comes a bit too late in the game, it’s an important validation to the proliferation of the cloud: after completely dismissing the cloud a few years ago, the Oracle giant now has to admit it is here to stay.

This announcement doesn’t position Oracle as a market leader, but rather it is seen more as a “me-too” tactic. It’s interesting that even Ellison’s delivery of the news during his talk was phrased along the lines of “now that everyone else has got a cloud, we need one too”…

While there’s still no clear indication when will Oracle’s cloud become available, Ellison describes the new offering to be a mix of PaaS and SaaS capabilities (not that different form Salesforce’s offering), and promises no vendor lock-in (would you believe it ?!). This naturally raised quite a few eyebrows, and flared up its fair share of jokes regarding Oracle’s pricing (“if you pay a million dollars- then, sure, no vendor lock-in” :)). In addition, the Oracle cloud architecture won’t support multi-tenancy (allowing customers to share the hardware but keep their data separate) but rather dedicated machines per user.

Oracle sees its cloud in direct competition with Amazon, Rackspace, Salesforce and other public cloud vendors. But is it really?

If we look at their product – the Oracle commercial database is optimized for single storage (no distribution) and high-end hardware. This simply doesn’t work well in a virtualized environment and with commodity cloud hardware. This, along with its high price point, means cloud users are effectively moving away from Oracle, and doubt they would ever reconsider it as a valid – and cost effective – option in the cloud.

While Oracle is trying to take a (belated) piece of the cloud pie, since it doesn’t re-engineer its database to handle distribution well, basically the Oracle cloud is just another set of physical machines, and the Oracle DB in the cloud isn’t really a cloud database- but simply the same old RAC installation- suffering from the same old problems.

The reason Ellison is so against multi-tenancy is because Oracle doesn’t support it and it’ll take them a quite a while to develop it. Using multi-tenancy as “big-bad-wolf” made-up argument to supposedly strike fear in perspective clients to get them to pay more for the dedicated option won’t fly. Done right, true multi-tenancy and properly designing the database for a virtualized framework to begin with – actually adds value, rather than risk. Many times, sharing the hardware is your best bet for getting your infrastructure costs down; scale-out cost effectively and enjoy unlimited throughput and computing power when you need to without breaking the bank.

What will happen to Oracle’s cloud only time will tell, but as we stated before: in the cloud, big names don’t necessarily mean big value.

Google Cloud SQL

So Google is also seeing potential in a relational database designed for the cloud.

Makes sense :)

This is very good news for cloud databases, as yet another indication that despite the NoSQL hype, SQL is not going anywhere. While NoSQL may be most suitable for heavy numbers-crunching and BI applications, SQL is still the preferred choice for 99% of use cases – so there’s better be a way to ensure it runs smoothly in the cloud.

Google’s Cloud SQL is still in beta, but the offering seems like a shared environment that’s a combination of Salesforce’s Database.com and Amazon RDS – suffering from both platform’s limitations. The key benefit to Google’s SQL offering is its built-in integration with Google’s App Engine, but here also lies its limitation – as it’s limited to those running on Google’s cloud.

Another key limitation, and possibly the most important one is that MySQL scalability in the cloud is a major issue still not addressed.

Where Google’s and Oracle’s new offerings would end up and how they would stack up against other database capabilities for public clouds remains to be seen. The more products and unique capabilities we have out there, the more choice users have to find a good fit for their specific use case. One thing is certain: it’s going to be interesting playing with the big guys!

Many developers and organizations are using WordPress, the popular open source CMS, to power their sites and blogs.

By default, WordPress uses a MySQL database. We’ve seen many of our users migrating their WordPress DB to Xeround’s cloud database service — thus ensuring high availability, scalability, and support for fluctuating throughput requirements, for their WP-powered application.

Basic WordPress/DB configuration

Typically, a basic WordPress installation relies on a MySQL DB residing on the same server as the WordPress Application. In this single-server deployment, developers often need to choose a server that can handle both resource-heavy processes: those of the MySQL database and those of the Apache-PHP-WordPress application.

When your WordPress application needs to support highly fluctuating traffic, and the server needs to deal with occasional peaks in I/Os, you end up over-provisioning and committing to a larger server instance. However, when examining your server’s performance, you’d see it is idle for most of the time – as most of the resources are spent on I/O requests and the Apache processes are using only small CPU chunks even as load increases.

Scalable WordPress/DB architecture

A more optimal deployment to ensure elasticity of your WordPress site and better handling of fluctuations in load, is to separate the application and the database tiers into different servers. A smaller server is used to run the Apache-PHP-WordPress and another one, tuned for I/Os, is used for the database. With this configuration, developers can more easily scale either layer, particularly when higher loads are generated for the database.

When plugging in Xeround as the DB component, you can be confident that all availability and scalability issues of your WP database are handled for you by the service itself, so that you can simply kick back and relax.. :)

Got a WordPress Site?

Check out our step-by-step guide to learn how to easily migrate your WP database to Xeround.

Learn what makes Xeround’s Database-as-a-Service (DBaaS) unique and how easy it is to get up and runnnig.

When evaluating a database solution, it’s important to make sure your database scales in a way that is optimal for the needs of your application. From traffic considerations, to downtime, performance and cost perspective — see what are the main things you should know for ensuring database scalability.

Read the full article on Mashable »

Got a preference? Want to see Xeround at your datacenter of choice?

Take the poll on our Facebook page to let us know where you’d like to see Xeround Cloud Database
next.

Click to vote!

We’ve listened and we’ve delivered!

We’ve just released the first version of the API to our service. The new API allows developers to configure their application to remotely call our service to create and manage multiple Xeround database instances in the cloud.

Xeround Cloud Database API supports both SOAP and REST, and allows you to:

1. Create a new database instances
2. Get the connection IPs for your instance, status, DB size and other info
3. Drop a database instances

API support is extremely useful, for example, if you are developing a SaaS or PaaS solution, which often requires the creation of a new database instance for every end user or account that uses the service. Another possible use for Xeround’s API is to power an IDE add-on that creates a fresh database for each project that’s created.

Effectively managing sometimes thousands of database instances is becoming a major operation problem for many application providers. Each database has its own needs in terms of size, throughput and performance – and ensuring multi-tenancy, scalability and availability, is challenging.

With a couple of API calls you can now integrate Xeround’s Database-as-a-Service (DBaaS) with your platform, and easily create numerous database instances and assure they are optimally running in the cloud.

This takes the headache, guess work and management overhead out of manually dealing with multiple database instances. With scalability and availability automatically handled by the service itself – developers are free to focus on their application rather than on the IT side of things.

See the documentation to learn more about Xeround’s Cloud Database API and how to use it.

We’re already working on the next version of the API. As always, your feedback is extremely helpful: if you have any input, such as improvement suggestions, missing functionality, supporting your specific use cases, etc. – please don’t hesitate to share by emailing info@xeround.com .

This is in addition to commercial availability on Amazon EC2 and the Heroku platform announced last June.

Xeround’s service on Rackspace is initially offered on Rackspace’s data center in Chicago, and will expand to additional regions in the next few months.

Xeround customers running their applications on Rackspace can now choose to create their cloud database for MySQL apps on Rackspace’s data center as well, and enjoy Xeround’s no-downtime guarantee and true elasticity.

Xeround’s service on Rackspace includes:

• Auto Scaling
• No Downtime SLA Guarantee
• Scheduled Backups
• Unlimited Throughput
• Phone, email & web support
• Zero Maintenance

Start your 30-days free trial today!

Xeround customers are entitled to a 30-day free trial, after which the database instance will be charged by actual usage- depending on its data size and data transfer.

No Credit card is required for the trial, and there are no minimum charges or subscription fees.

See Xeround’s prices on Rackspace »
Also check out our price calculator.

Register for our joint webinar with Rackspace »
October 4th, 2PM CST.
See how easy it is to create your database instance, connect your app to it, scale automatically, and even survive a server crash.

Create your free cloud database »

Come by our booth for some freebies and to learn how Xeround Cloud Database ensures reliable database operations for business-critical applications in the cloud.

Razi Sharir, Xeround’s CEO, would also be attending Strata Summit, September 20-21. Look for him if you want to catch up, discuss business opportunities or learn more about Xeround and what the future holds for IaaS and PaaS database services.

Different PaaS platforms are commonly built for specific technology stacks. For example:  Heroku for Ruby on Rails, VMware with Spring on CloudFoundry or CloudBees for Java, AppFog for PHP, and more.

At the application level, most PaaS solutions provide a suitable way for dealing with  fluctuating demand or changing needs of the application (devlopment, production etc.,) This elasticity and flexibility at the application tier are built in to the platform itself.

Unlike the application tier, things are different at the database level. Most PaaS still offer data management services with only limited scalability, not in par with the application level. Most PaaS use some MySQL, PostgresSQL, CouchDB or other open source data management solutions that are easy to integrate with the platform’s backend, but that provide very limited scalability/functionality for end users. It would appear the reason for this is that PaaS providers usually have strong capabilities at the application framework –  and that is their core business. However, supplying an on-demand scalable database infrastructure on a large scale is much more complex. Having said that, while many PaaS providers could experience limitations where it comes to the database tier, at the end of the day end users would require effective data management services as an integral part of their application running on the platform.

The data management services that should be offered on the various PaaS solutions  should have several tiers, as well as open source, simple configurations. For example, a plain MySQL on a virtual or shared environment would be a good starting option for basic tiers. More advanced tiers should include much more robust data solutions. These tiers need to be able to scale and provide enterprise-level service like SLA, high availability, DRP and more features that are not provided by the plain open source solutions.

One requirement that is extremely important for data management service on top of PaaS is efficient cost structure. Customers need to be able to acquire add-on services, including  advanced data management services, and be presented with a pricing model that’s coherent with that platform and with the way cloud businesses operate. For example, Oracle could be a relevant database solution for some applications, yet, for most PaaS customers it is not even offered as an option because it does not have a suitable pricing model.

Most PaaS solutions offer a variety of third party add-ons, including data management and database services. RDS, for example, is offered as an optional add-on on Heroku. Yet, RDS has its limitations when hooked up to a platform like Heroku, as it does not offer the level of granular scalability that the platform offers at the application level. An Heroku application can  deal well with fluctuations in demand with no need for manual intervention, and costs are on a usage basis. In contrast, as RDS is a static database service, where the server size and capacity are determined when purchasing the instance, both cost and scalability are not in par with the Heroku platform and the cloud’s operations model.

Xeround Cloud Database, built natively for the cloud, shares the same basic principles as PaaS solutions, with its out-of-the-box MySQL scalability, simplicity and efficient cost structure. It automatically scales as needed, just like the platform does at the application level, It offers high availability and DRP options, and has great performance and low latency. On top of that, it is priced in a flexible pay-per-use model which effectively ties the costs of running the database to the demand of the application.

Today Xeround offers an add-on on Heroku and is expanding to additional commonly used platforms soon. While we may not already have an add-on offered on your chosen platform at this time, you can always integrate Xeround with your application running on any PaaS – simply by registering to create your free cloud database and connecting your application to it.

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.

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 DB – 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 apps in the cloud, 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:

MySQL Scalability Issues – 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 MySQL 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 resolve MySQL scalability issues. 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 scalability 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 Amazon RDS cost or 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.

Amazon RDS 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 cloud 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 of MySQL cloud databases.

• 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 cloud MySQL database?

• 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 MySQL high-availability and automatic MySQL scalability, 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)