Open Stack

On 21/06/17 01:49, Mark Kirkwood wrote:
> On 21/06/17 02:08, Jay Pipes wrote:
> 
>> On 06/20/2017 09:42 AM, Doug Hellmann wrote:
>>> Does "service VM" need to be a first-class thing?  Akanda creates
>>> them, using a service user. The VMs are tied to a "router" which
>>> is the billable resource that the user understands and interacts with
>>> through the API.
>>
>> Frankly, I believe all of these types of services should be built as 
>> applications that run on OpenStack (or other) infrastructure. In other 
>> words, they should not be part of the infrastructure itself.
>>
>> There's really no need for a user of a DBaaS to have access to the 
>> host or hosts the DB is running on. If the user really wanted that, 
>> they would just spin up a VM/baremetal server and install the thing 
>> themselves.
>>
> 
> Yes, I think this area is where some hard thinking would be rewarded. I 
> recall when I first met Trove, in my mind I expected to be 'carving off 
> a piece of database'...and was a bit surprised to discover that it 
> (essentially) leveraged Nova VM + OS + DB (no criticism intended - just 
> saying I was surprised).

I think this is a common mistake (I know I've made it with respect to 
other services) when hearing about a new *aaS thing and making 
assumptions about the architecture. Here's a helpful way to think about it:

A cloud service has to have robust multitenancy. In the case of DBaaS, 
that gives you two options. You can start with a database that is 
already multitenant. If that works for your users, great. But many users 
just want somebody else to manage $MY_FAVOURITE_DATABASE that is not 
multitenant by design. Your only real option in that case is to give 
them their own copy and isolate it somehow from everyone else's. This is 
the use case that RDS and Trove are designed to solve.

It's important to note that this hasn't changed and isn't going to 
change in the foreseeable future. What *has* changed is that there are 
now more options for "isolate it somehow from everyone else's" - e.g. 
you can use a container instead of a VM.

> Of course after delving into how it worked I 
> realized that it did make sense to make use of the various Nova things 
> (schedulers etc)....

Fun fact: Trove started out as a *complete fork* of Nova(!).

>*but* now we are thinking about re-architecting 
> (plus more options exist now), it would make sense to revisit this area.