More and more public cloud companies are moving to managed cloud
services to improve their value-add (price premium) and the
stickiness of their solution. However, the shift to a database as
a service (DaaS) severely reduces the DBAs visibility into the
business, thus limiting the ability to hand tune the database to
the requirements of the application and the database. The
solution is a cloud database that eliminates the hand-tuning of
the database, thereby enabling the DBA to be equally effective
even with limited visibility into the business and application
needs. It is these unique needs, particularly for SQL databases,
that is fueling the NewSQL movement.
DBAs traditionally have insight into the company, enabling them
to hand tune the database in a collaborative basis with the
development team, such as:
1. Performance Trade-offs/Tuning: The database is partitioned and
tuned to address business requirements, maximizing performance of …
As public clouds are commoditized, the public cloud vendors are
increasingly moving to higher margin and stickier managed
services. In the early days of the public cloud, renting compute
and storage was unique, exciting, sticky and profitable. It has
quickly become a commodity. In order to provide differentiation,
maintain margins and create barriers to customer exit, against
increasing competition, the cloud is moving toward a collection
of managed services.
Public clouds are growing beyond simple compute instances to
platform as a service (PaaS). PaaS is then comprised of various
modules, including database as a service (DaaS). In the early
days you rented a number of compute instances, loaded your
database software and you were the DBA managing all
aspects of that database. Increasingly, public clouds are moving
toward a DaaS model, where the cloud customer writes to a simple
database API and the cloud provider is the DBA. …
Not every company or application needs an elastic database. Some
applications can get by just fine on a single database server,
rendering database elasticity moot from their perspective. To
make this determination, simply ask yourself:
1. Will I need more than a single database server? Look at your
current load and your projected growth and ask yourself whether
it will exceed the capacity of a single server. If it doesn’t
now, nor will it in the future, then you don’t need an elastic
database.
2. Will my load fluctuate sufficiently to warrant the investment
in elasticity? If your database requirements won’t experience
fluctuations in demand—e.g. daily, weekly, monthly, seasonal
changes in the number of servers required—then elasticity isn’t
important. For example, if you have a social networking
application that requires 2 database nodes 24x7, but peaks at 10
nodes for 2 hours a night, then elasticity is important. If your …