ClearDB Logo
Posted by Cashton Coleman on 4/11/2013 07:11AM

Why use a database-as-a-service instead of do-it-yourself MySQL in the cloud?

When you're looking to move your website, app, or even your whole business from your traditional hosting provider, one of the first challenges that you're faced with is whether or not to run your own MySQL database and MySQL powered infrastructure (the DYI approach) vs. using a cloud database service to run it for you. In fact, that's one of the many options that suddenly becomes available - the ability to run 80-100% of your app using readily available services to reduce your non-business-centric time, work, and cost vs. trying to conquer the world by yourself and "roll your own" components, including your database. If you're not sure what to do, here is a countdown of five reasons, with pros and cons on why working with a cloud database-as-a-service like ClearDB is a win for your business.
 

Reason #5 - The cloud is a complicated environment that is constantly changing.

The same uptime challenges that exist in the traditional hosting world also exist in the cloud, but with a twist: there are new gotchas that suddenly become apparent, as well as new ways to solve those problems. For this example, let's consider storage, and how that can be a threat to your data. In EC2 and Windows Azure, traditional cloud server instances have what is called "ephemeral" storage. If you don't know what that word means, look it up - in a nutshell, it means temporary. If the server instance fails, or if the local storage on the host server where the server instance fails, or even if your server instance is stopped and then started, that ephemeral storage is going to be wiped clean of your data.
 
How does one get around this issue? Well, most cloud providers also offer non-local storage (in EC2, it's called Elastic Block Store, or EBS, and in Windows Azure it's called Windows Azure Drives as well as Blob and Table Storage). These services use highly redundant disks to store your data, and greatly reduce the risk of data loss by persisting your data, no matter what happens to the server instances themselves. 
 
The Pros for this are: highly persistent data that can survive server instance failures and can be re-mounted/attached to other server instances. 
 
The Cons for this are: they cost extra (some as high as $0.12 per GB, not including transaction fees), and that they can be slow at times unless you purchase a performance SLA guarantee (in EC2, this is what is called "Provisioned IOPS"). They also involve system administration work that most folks who are merely interested in hosting a website are not familiar with (especially in Linux/Unix). 
 

Reason #4 - One server instance is typically never enough in the cloud, as things do fail.

While the cloud provides for the ability to recover from failures faster than having to physically go to your local data center and fix a server, there are times in which doing so would actually take LESS time because of risk mitigation during large scale failures. For example, when EC2 begins to experience a failure that is large scale in nature (a great case in point is an EBS service-wide outage in a region, which happened as recently as last year), Amazon will actually LOCK the provisioning and management API while they fix things. This means that while they are trying to revive the services that failed, you're stuck waiting until they do so - unless you provisioned more than one server instance, in more than one region, BEFORE the outage occurred. 
 
At this point, you have to consider what this means in terms of cost. How do you deal with this type of issue, when the server storage is temporary, the durable storage has failed, and your cloud provider does not allow you to create a new server instance with durable storage that you can restore a backup into until THEY decide you can? Better yet - let's say that you are okay with provisioning multiple server instances, in multiple regions. Now it's time to set up and configure MySQL replication. But wait - is a master - slave replication topology good enough to ensure that your database is always online?
 
The answer is: no, it's not. When a master failure occurs, your slave (which is probably now going to be elected to be your new master) may not be configured to log slave transaction updates. Oops. Now you have to learn to be an expert MySQL DBA before you can rest assured that everything will "just work". 
 
The Pros for this are: Wait.. there are none, unless your life revolves around creating highly available MySQL database services, and even then you still have to wear the pager for when things do fail. Additionally, have you even thought about how your application is going to handle these types of failures?
 
The Cons for this are: you're taking on a significant risk with a steep learning curve, and you are still responsible for what happens when things begin to fail (there is no "if" - it WILL happen). How significant that risk is depends on whether or not your application can continue running without your database, because it could mean loss of customers, trust, and more importantly: loss of revenue due to downtime for something that can be handled by a service that is highly proficient in running H/A MySQL. 
 

Reason #3 - How much extra time do you have to focus on your database in the cloud vs. your business?

"You'll always have the time needed to focus on creating robust, highly available, self healing MySQL while you're trying to run your non-MySQL related business!" - Said no one. Ever.
 
By working with a database as a service such as ClearDB, you can focus less on your database infrastructure and more on what you're passionate about - your business. This results in significant cost savings over DIY MySQL in the cloud, and enables your business to tap into highly skilled database and infrastructure management resources whom's sole focus is to make sure that your database experience is near zero-administration, which includes taking the pager back from you so you can sleep at night.
 
At ClearDB, we have developed a highly scalable, highly fault-tolerant database service that includes unique features such as automated failover and resume, automated self healing, and automated backup management for your databases and clusters so that you stay focused on what matters to you the most - your business. 
 
The pros for this are: significant time and cost savings for your business, significantly reduced stress.
 
The cons for this are: when working with a cloud database as a service, you lose certain elements of control over your database infrastructure. The vast majority of our customers feel that the pros in working with this type of solution outweigh the cons. Disagree? Contact us about it!
 

Reason #2 - The true total cost of ownership of running your own MySQL infrastructure in the cloud is significantly higher than using a database-as-a-service.

Let's face it, as much as running your own DIY MySQL cluster infrastructure in the cloud sounds cool, it's not easy, and it's not cheap. In fact, for those who think that it may be less expensive than working with a database-as-a-service like ClearDB, here's an example breakdown of costs that shed light on what it REALLY costs in comparison:
 
(For this example, the database size is 20GB, and is on our Medium DB cluster plan which costs $1,299.99/mo)
 
Server infrastructure costs: $518.40 / mo
Storage infrastructure costs: $50.00 / mo
Highly available MySQL software costs: $1,500.00 / mo ($18,000.00 /yr)
Monitoring software costs: $150.00 / mo
Human resource costs (DBA): $6,000.00 / mo
Human resource costs (IT): $3,000.00 / mo
 
In this scenario, your real TCO cost for doing DIY MySQL is actually $11,218.40. With ClearDB, you actually get MORE value than what is priced out in the above list (no other MySQL provider offers sub-second failover and resume, for example), at only 11.58% of the real TCO of DIY MySQL.
 
The pros for this are: If you're going DIY for MySQL in the cloud, you're spending HUGE amounts of money where it's not necessary. Using a database-as-a-service such as ClearDB can save you a bundle.
 
The cons for this are: cost, cost, and cost! No one is in the business of losing money over something that can be done for less than 15% of the cost by a company full of domain specific thought leaders. Your business can do better than DIY MySQL. 
 

Reason #1 - There's nothing like having enterprise-grade support, no matter what you're doing.

At ClearDB, our cluster customers get white-glove, enterprise grade support for their clusters. We pull out all the stops on our service. Our response time is 15 minutes max (we often respond within 3-5 minutes!), and our service architecture and software is designed as such that your application (and YOU) won't even notice if a failure occurs. When you need help though, we make sure that you get exactly what you need, when you need it, at a significant cost savings over our competitors.
 
There is a reason why Microsoft, Skype, Salesforce, and 27,000+ other customers trust ClearDB with their data, and with our enterprise grade support, we provide you with the right value, where you need it the most so that you can focus on your business and not your database.
 
The pros for this are: 100% customer focused goodness and support. You can now relax and stay focused on your business for a fraction of the cost of doing everything yourself.
 
The cons for this are: There aren't really any cons for great service. What can one say, that we fixed a problem for them too quickly? :-)
 
If you're interested in using ClearDB for your MySQL database needs, check out our service plans or contact us for additional information.
 
Follow us on Twitter! 
 
Cashton Coleman is the founder and CEO of SuccessBricks, Inc., the makers of ClearDB. Cashton has been building highly available systems and services for over 15 years, and designed and implemented the core technology behind ClearDB. You can reach him via Twitter: @cash_coleman. 
 
blog comments powered by Disqus