Rethinking Databases for the Cloud

[Ken North]

NoSQL or NewSQL?

"Four Companies Rethink Databases for the Cloud"
http://www.pcworld.com/businesscenter/article/231059/four_companies_rethink_databases_for_the_cloud.html

New England Database Summit Papers
http://db.csail.mit.edu/nedbday10/htdocs/papers.php

Ken North
________________
www.kncomputing.com
@knorth2
kncomputing.tumblr.com

 

[Gilad Parann-Nissany]

Thanks Ken. Perennially interesting...

Most interesting point (from where I sit) is that 3 out of the 4 panelists at GigaOM where representatives of SQL DB brought to cloud scale, each with its own approach. 

There seem to be two different buzzes (if that is good english ;-)  coming out of the market.

NoSQL and "CloudSQL".

Do I have a chance to get copyright on coining CloudSQL? ;-) ;-) ;-)

Regards
Gilad
__________________
Gilad Parann-Nissany
CEO, Founder
Porticor Cloud Security
http://www.porticor.com/

--
~~~~~

Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net

Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://www.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration

or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC, http://www.amazon.com/gp/product/B004L1755W, http://www.amazon.com/gp/product/B002H0IW1U

~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com

[James Phillips [Personal]]

While both NoSQL and "NewSQL" (which I define as the ability to scale a relational database horizontally) solve the "scale out" problem, NewSQL still uses the relational data model, meaning one must define a schema before inserting data into the database. And one must change the schema when data requirements change. Many argue this lack of flexibility/the hassle associated with making these changes, is the biggest driver for the emergence of NoSQL. Indeed, at Couchbase most of our customers approach us for precisely this reason. Obviously I have some bias given I work for Couchbase. But the observation is based on real conversations with real users struggling with data management in the cloud.

james.

[Ray Nugent]

Om's conferences tend to be pitchfests and the cloud focused ones are absolutes echo chambers. We stopped attending for these reasons. Not sure you can divine any usable info from a panel there.

[Jim Starkey]

I'm sorry that you find schemas cumbersome, but schema declarations are necessary for a database system to create secondary indexes, perform data validation, enforce integrity constraints, perform joins, sort data, and optimize retrievals.

And schema declarations are cast in concrete.  The SQL standard and virtual all relational database systems support schema updates and many, probably most, support schema updates with the database online and pumping transactions.  It's a very simple trick to tag records with a table version number so schema changes don't require any restructuring.

And some database system go further, allowing non-bounded types, e.g. String, Number, that don't require any schema when data demographics change.

Your poin seems to be that not be able to do things that other systems can is a virtue in itself.    This strikes me as a hard sell, but I guess I'm old school.  The question should be whether a data declaration is useful, and if useful, at what cost.

[James Phillips - Personal]

Perhaps we are simply arguing terms. One can most certainly create secondary indices, perform data validation, etc. with a document database like couchDB. But ex-ante schema creation/declaration is not required in order to do so. 

I certainly didn't mean to imply your system, or any "NewSQL" solution lacks merit. Simply pointing out one of the differences that seems to get lost in the discussion. 

I believe there is a place for both explicit, ex-ante schema definition and implicit, ex-post schema expectation (to make up a term).

And no, my point was not that not being able to do things is a virtue in itself :)

James Phillips

408-832-3066 (cell)

[Stephen Pollack]

It’s often the case that language features and constructs are put into place so that the pool of developers expands to encompass those with less high end skills and experience. Afterall, we could still program everything in assembler, but eternity waits. In our world where near everything has a technology component, the tools need to be usable by most everyone regardless of skills, aptitude and experience. The traditional technology languages and systems that spawned the first main stream generation of computing were designed for the skilled developer, someone who understood the nature of the computer and could make it ‘sing’ the way they needed to. Subsequent generations of technology serve to allow the everyday person to join in – perhaps in more of a karaoke mode I suppose.

 

From my perspective, database technology is about information storage and access – SQL constructs, although rich in functionality, are by no means the ideal way to store and access the kind of information we are warehousing around the world today. Surely our database software can be written to become self-efficient through how it is accessed in application usage (e.g. based on what us humans want to use it for) – if we continue to rely on people to predict the future of how information would be used and therefore lock in schemas, index strategies, etc forever more, we’re missing the opportunity to start singing again in proper harmony.

 

I for one applaud anyone who wants to bring forth new paradigms to adapt to the needs we have today – i would prefer to have NoSQL actually mean no more convoluted syntax for data manipulation, but i’ll take the advances it brings nonetheless. For those situations where the old paradigms are needed so that old contexts of access are locked in, so be it.

 

/sp

[Adrian J Duncan]

This was going to come one day soon and here it is.
http://www.infoworld.com/d/the-industry-standard/eu-upset-microsoft-warning-about-us-access-eu-cloud-092

MS have warned the EU that under US Law MS (and all other US companies)
must provide the US with all data that they ask for. This includes data
from EU countries. The US companies are also prevented from telling
their customers that the data has been requested and sent.

This goes against EU law which states that the data holder must be told
before any data is shared with any second party.

I am not 100% sure from the article if this still applies if MS / Amazon
etc have a server located in the EU with EU customers' data on. If that
is the case, could it be a huge downside for EU companies using US cloud
companies and a great opportunity for UK / EU cloud providers?

What are your thoughts guys?

Cheers
Adrian

[J. Andrew Rogers]

On Tue, Jul 5, 2011 at 4:35 PM, Jim Starkey <jsta...@nimbusdb.com> wrote:
> I'm sorry that you find schemas cumbersome, but schema declarations are
> necessary for a database system to create secondary indexes, perform data
> validation, enforce integrity constraints, perform joins, sort data, and
> optimize retrievals.

Nonsense, these things can be done without schema declarations. Such a
limitation is self-imposed and implementation dependent.

--
J. Andrew Rogers

[Gilad Parann-Nissany]

Hi

I am pretty sure this does not apply when the server is actually in a data center in the EU (e.g. Ireland), even if its run by a USA-based company (MS or Amazon). I am not a lawyer but did actually check this point. On European soil - local laws apply and not USA ones.

Regards
Gilad
http://www.porticor.com/

[Roland Rambau]

Adrian,

well, its not "a huge downside" but simply a show stopper.

However, this only stops commercial or governmental use of
any US-based or US-managed cloud - private citizens are still
free to decide that they want to load their data into any cloud
( as long as it is not personal data of someone else).

A good positive example is the old New York Times archive format
conversion example: here the articles to be converted in the cloud
are all already published, so there are no (new) privacy concerns
at all. This would work exactly the same in the EU, no problems.

A negative example would be any data that is materially relevant
to the evaluation of a public company (e.g. product design data) or
that is subject to EU privacy law (any personal data, i.e. non
anonymized data about any real people). In those cases the company
or person handling the data is required (by law) to control access
to those data and e.g. to report, correct and possibly *delete* data
on request.

Therefor I believe that a EU company cannot legally use an
US could provider expect for trivial cases (like cloud-based
format conversion of already public data).

Or, more precisely: The EU company CAN legally use an US cloud
provider if they just put the necessary contract clauses in their
contract. It would then be that providers legal problem if they
fail to comply and get caught.

We have seen that all before when "GRID" was the hype, everything
was technically working just fine, but the legal and contractual
issues just turned out to be insurmountable.

my 2 eurocent

-- Roland

[Steve Caughey]

My understanding is that US and EU law are in conflict over this issue. However, if a US company (or an EU subsidiary of a US company) is required to hand over data to the US government it will do so – any consequent EU action will be closing the stable door after the horse has bolted.

[Roland Rambau]

Gilad,

Am 06.07.2011 17:05, schrieb Gilad Parann-Nissany:
> Hi
>
> I am pretty sure this does not apply when the server is actually in a
> data center in the EU (e.g. Ireland), even if its run by a USA-based
> company (MS or Amazon). I am not a lawyer but did actually check this
> point. On European soil - local laws apply and not USA ones.

IANAL either but I assume different: I believe the key is where the
*person* is located that is supposed to do or not do something.

So if there is an operator physically in the US that *can* (remotely)
access data in the EU, then US law will require him/her to disclose
the data.

So what is needed is an ultimately responsible person and all down from
there to operators that are all local in the EU.

Otherwise you get into the conflict that you may have a manager in the
US who is legally required to command the disclosure of certain data
and on the other side an EU-local operator who is legally required to
not disclose it. How are you proposing to handle that conflict ?
(Note that the company is going to get sued either way.)

-- Roland

> <mailto:cloud-c...@googlegroups.com>

> To unsubscribe from this group, send email to
> cloud-computi...@googlegroups.com

> <mailto:cloud-computi...@googlegroups.com>

[Ken North]

Jim Starkey wrote:
> I'm sorry that you find schemas cumbersome, but schema declarations
are
> necessary for a database system to create secondary indexes, perform
data
> validation, enforce integrity constraints, perform joins, sort data,
and
> optimize retrievals.

J. Andrew Rogers wrote:
<< Nonsense, these things can be done without schema declarations.

Perhaps we don't have the same understanding of data validation.

How do you validate data before inserting it in a database, without
having schema declaration?

If you use SQL DDL to create a schema, you specify rules about your
data - its type, length, permissible range of values and so on. The
schema provides consistency because the rules it defines are uniform
for all applications, services and scripts that operate on a database.

[Ken North]

Stephen Pollack wrote:
> I for one applaud anyone who wants to bring forth new paradigms to
adapt to the needs we have today – i would prefer to have NoSQL
actually mean no more convoluted syntax for data manipulation, but i’ll
take the advances it brings nonetheless. For those situations where the
old paradigms are needed so that old contexts of access are locked in,
so be it.

NoSQL lacks precise definition but in general we are talking about
technology such as key-value stores and navigational programming to
access data. That's not a new paradigm. It was an approach to data
access that preceded SQL and the declarative approach instead of
writing procedural code.

The biggest contribution of NoSQL technology has been the ability to do
web-scale applications, such as social networks, by exploiting sharding
for horizontal scalability. But recent research has uncovered some
innovations that provide similar benefits to the SQL crowd:

"Sharding, Replication, Caches, and In-Memory Databases" | Dr Dobb's
Journal
bit.ly/jf51U4

[James Pulley]

There are several easy market responses to this challenge

(1) If you have a concern for the risk of your data being requested and sent
to an overseas government then do not use a public cloud provider which has
a USA-based operation. Or conversely if you don't want an EU gov't to have
access to your USA based data then don't use an operation which has a basis
in the EU. (Just so I don't pick on one side of the pond vs the other)

(2) Private clouds managed/controlled in-house or caged at a CoLo facility.

(3) Extremely high levels of encryption at the OS level in your public cloud
infrastructure. In a utility computing model you will pay dearly for the
CPU cycles required to encrypt and decrypt everything going/coming from the
file system on the fly. This will also slow your system down, akin to
having a drag anchor out the back of a high performance speed boat. I for
one would find a lot of humor in any government paying sparse funds for
months of computing cycles to decrypt grandma's pound cake recipe that was
being sent around through email.

Data management always involves a set of trade offs on cost versus risk. If
you believe the risk is too high in this one area then you need to be
willing to tolerate a bit higher cost to manage that risk through
encryption, provider selection or self managed clouds. As was noted
earlier, a contract with your organization is likely not going to carry as
much weight as a demand from a government where a cloud provider could play
stupid or a "hold harmless" tactic in court.

James Pulley
CTO, Newcoe Performance Engineering

-----Original Message-----
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of Roland Rambau
Sent: Wednesday, July 06, 2011 2:25 PM
To: cloud-c...@googlegroups.com
Cc: Gilad Parann-Nissany
Subject: Re: [ Cloud Computing ] US Law colides with EU Law

[Roland Rambau]

Steve,

Am 06.07.2011 19:19, schrieb Steve Caughey:
> My understanding is that US and EU law are in conflict over this issue.
> However, if a US company (or an EU subsidiary of a US company) is
> required to hand over data to the US government it will do so – any
> consequent EU action will be closing the stable door after the horse has
> bolted.

well, more likely it will litigate and punish the person and/or company
that illegally has opened (or not sufficiently secured) that door ...

-- Roland

>
> *From:*cloud-c...@googlegroups.com
> [mailto:cloud-c...@googlegroups.com] *On Behalf Of *Gilad
> Parann-Nissany
> *Sent:* 06 July 2011 16:05
> *To:* cloud-c...@googlegroups.com
> *Subject:* Re: [ Cloud Computing ] US Law colides with EU Law

> <mailto:cloud-c...@googlegroups.com>

> To unsubscribe from this group, send email to
> cloud-computi...@googlegroups.com

> <mailto:cloud-computi...@googlegroups.com>

[Gilad Parann-Nissany]

Hi Roland

Thanks for your note. Well. as mentioned I am not a lawyer. Still. Regarding the manager issue. The legalities here are similar (IMHO) to "physical" situations. A manager living and working in the USA cannot force a subordinate living and working in Europe to break European law.

Take a completely "physical" situation. A USA-based manager at FedEx gets a court order to hand over a parcel to someone. He checks his lists and the parcel is in Germany, at FedEx offices in Hamburg, and it is destined to be delivered to someone in Switzerland. However, our manager now sends an email to the a FedEx employee in Hamburg, telling them to send that parcel over to the "someone with the court order" in the USA.

Legally, that works only if it is done in a way that complies with European law. USA authorities have no way to force the manager or her employee in this situation. That parcel will go to Switzerland unless a EUROPEAN court order is obtained.

The legal way out is this: the manager tells USA authorities that the package is in Hamburg. The USA authorities talk to the European authorities and request assistance. The Europeans decide to give assistance. Then the package goes to USA (or not).

If the manager tries to force it, then FedEx will be in trouble in European courts. If the manager refuses, she IS NOT in trouble in the USA in this situation.

My 2 cents.

Regards
Gilad
http://www.porticor.com/

   cloud-computing@googlegroups.com

   <mailto:cloud-computing@googlegroups.com>

   To unsubscribe from this group, send email to

   cloud-computing-unsubscribe@googlegroups.com

   <mailto:cloud-computing-unsub...@googlegroups.com>

--
~~~~~

Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net

Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://www.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration

or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC,
http://www.amazon.com/gp/product/B004L1755W,
http://www.amazon.com/gp/product/B002H0IW1U

~~~~~
You received this message because you are subscribed to the Google
Groups "Cloud Computing" group.

To post to this group, send email to cloud-computing@googlegroups.com

To unsubscribe from this group, send email to

cloud-computing-unsubscribe@googlegroups.com

[Jim Starkey]

Please correct me if I'm wrong, but these operations are implemented in
CouchDB as procedural code masquerading as views. As such, CouldDB
views occupy exactly the same ecological niche as relational schemas,
which is to tell the database enough about the data semantics to enforce
rules and relationships. The only significant difference is that in the
relational world these are declarative while in CouchDB they are
procedural (relational triggers are also procedural).

But all this is beside the point. Relational database have withstood
the test of time. The only problem is one of scale. It is true that
"old SQL" databases scale poorly and expensively. And it is also true
that NoSQL grew up as an answer to the problem of scale.

The "new SQL" databases exist to address the problem of scale while
retaining that which has proven effective, specifically the relational
database model and the SQL language. Database folklore (aka Computer
Science) says this is impossible, but folklore sooner or later has to
give way to reality.

I submit that the issue is not SQL. SQL is indeed more complicated that
NoSQL APIs, but then it can do more than retrieve records by primary
key. The issue is also not the relational model. The real issue is
ACID transactions. SQL databases can do them, NoSQL can not. It is
often argued that with enough time, money, and skill reliable systems
can be implemented with NoSQL. But most folks choose database systems
to save money, save time, and to let their application programmers write
applications rather than system software.

So I think the real question is this: If NewSQL databases can
demonstrate elastic scalability with ACID transactions on commodity
hardware, what is the future of NoSQL?

Personally, I think a "movement" that defines itself by what it can't do
is unlikely to demonstrate long term persistence. But I could be wrong.

[Peter Shenkin]

On Wed, Jul 6, 2011 at 3:35 PM, Gilad Parann-Nissany <gilad....@gmail.com> wrote:

Hi Roland

Thanks for your note. Well. as mentioned I am not a lawyer. Still. Regarding the manager issue. The legalities here are similar (IMHO) to "physical" situations. A manager living and working in the USA cannot force a subordinate living and working in Europe to break European law.

However, if the manager or the US employees have the ability to access the data on the European server, then the above does not apply.

IANAL, either, but perhaps this would be trumped if the US organization set up a fully owned subsidiary in Europe, subject to European law, which owned the servers.

-P.

[Gilad Parann-Nissany]

Hi Peter

Sorry, beg to differ. The legalities do not change even if "the US employees have the ability to access the data on the European server".

To take again the "physical" FedEx example, even if the FedEx operation in Hamburg is automated, the manager in USA cannot reroute the parcel from Switzerland to USA without European law being satisfied.

Its the law... (as far as I understand) and the law is the same regardless of the technique.

It is true that in the Internet age, it is easier fro that hypothetical manager to break the law. But if she obeys the law, she can't do that.

Regards
Gilad
__________________
Gilad Parann-Nissany
CEO, Founder
Porticor Cloud Security
http://www.porticor.com/

--

~~~~~
 
Posting guidelines: http://bit.ly/bL3u3v
Follow us on Twitter @cloudcomp_group @cloudslam @up_con
Post Job/Resume at http://cloudjobs.net
 
Download hundreds of recorded cloud sessions at
- http://cloudslam.org/register
- http://www.up-con.com/register
- http://cloudslam09.com/content/registration-5.html
- http://cloudslam10.com/content/registration
 
or get it on DVD at
http://www.amazon.com/gp/product/B002H07SEC, http://www.amazon.com/gp/product/B004L1755W, http://www.amazon.com/gp/product/B002H0IW1U
 
~~~~~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.

To post to this group, send email to cloud-c...@googlegroups.com
To unsubscribe from this group, send email to cloud-computi...@googlegroups.com

[Jim Starkey]

I'll go into more detail later in the post for those who care, but the executive summary goes like this:  Network latency is relatively high and human attention span is relatively low.  So human facing computer systems have to perform their work in a small number of trips between the client and the database server.  But the human condition leads inexorably to data complexity.  There are really only two strategies to manage this problem.  One is to use coarse granularity storage, glombing together related data into a single blob and letting intelligence on the client make sense of it.  The other is storing fine granularity data on the server and using intelligence on the server to aggregate data to be returned to the client.

NoSQL uses the former for a variety of reasons.  One is that the parallel nature of scalable implementations make maintaining consistent relationship among data elements problematic at best.  Another is that clients are easy to run in parallel on multiple nodes, so moving computation from servers to clients makes sense.  The downside is that there is only one efficient way to view data.  A shopping cart application, for example, can store everything about a single user session in a single blob that is easy to store, fetch, and contains just about every necessary take an order to completion.   But it also makes it infeasible to do reporting without moving vast quantities of unnecessary data.

SQL databases support ACID transactions that makes consistent fine granularity data possible, but also requires server side intelligence to manage the aggregation.  The SQL language, ugly as it may be, performs the role with sufficient adequacy (we could do better, but not significantly better).   Stored procedures using any sort of data manipulation language also works.  But distributed intelligence, declarative or procedural, pretty much requires regularity of data.  Hence schemas.  They don't have to be rigid or constraining, but whatever intelligence is going to operate on bulk data needs a clue of what it looks like and what the relationships are.

So that's the short version.  The long version requires a historical understanding of how we got from an abstract to structured views of data.

On of the earliest high performance database systems (they weren't called that yet) was a mainframe product, circa 1969, whose name eventually settled on Model 204 (person node:  I did the port from DOS/360 to OS/360 MVT).  Model 204 had records that were arbitrary collections of attribute/value pairs.  The spooks loved it -- dump everything you know into cauldron and throw queries at it.   But it couldn't handle relationships among records without a lot of procedural code.

There were two data models that attempted to capture data structure (relationships).  One was the hierarchical model, IBM's IMS and the ARPAnet Datacomputer (personal note here, too).  The other was the CODASYL (aka network) data model where individual records "owned" chains of other records.  IDMS, the premier CODASYL product roamed the earth in the late Jurassic period until an alternative emerged from the primordial swamps (sigh, I was on the team that ported IDBMS to the PDP-11, often likened to an elephant on a bicycle).  Both the hierarchical and network models required data manipulation languages that an orc's mother couldn't love.

Codd's relational model, once stripped of the unnecessary mathematical trappings, was a very happy compromise between simple regular tables and ad hoc joins for inter-table relationships.  And it made for straightforward transactional semantics as well.  It was a hit when the first commercial implementation came out and has persevered (I put out DEC's first relational database, Rdb/ELN, in 1984).

The OO data model (encapsulated objects and pointer) pops up and dies with great regularity, as does its close relative, object/relational mapping.  Neither is particularly suited for the distributed world, however, but the refugees can generally find work in other companies.

Over the years I've had a professional affiliations with the amorphous data model (Model 204), hierachical (Datacomputer), CODASYL (DBMS-11), and relational (Rdb/ELN, Interbase, Firebird, MySQL, and NimbusDB).  And my friend Tom Atwood started at least half of the OO database companies.  So, if I can't claim objectivity, I can at least claim in depth personal experience.

Everything is a compromise.  And I deeply believe that the relational model is the best compromise among simplicity, power, performance, and flexibility of implementation.  It does require data description, but so do all other useful database management systems regardless of what it is called.

The scale problems with legacy relational databases have nothing to do with SQL, the relational model, or ACID transactions.  The essence of the problem is theoretical -- the conflation of consistency and serializability.  Serializability is a sufficient condition for database consistency but not a necessary condition.  The NewSQL generation of products recognize this and refuse to be limited by lock managers of any ilk.

It's a brave new world out there, ladies and gentlemen.

[Adrian J Duncan]

Hi and thanks for everyone who has commented.
It validates my concern for all cloud users and providers when I read
the article.

It does show that there are some complex issues here for both EU and the
US companies. I take the point about Grandma's cake recipe, but maybe
MI5 hacked her account and changed the recipe? ;)

If I run a company in the UK and most EU states, I have a duty to handle
my customers' data with care and not to share their data. The problem
for many companies like this, is that the Internet provides a nice cloak
for a company's location and the Cloud doubles that. A provider I use
may store some of my data on another company's server in another country
and I would have no idea. I know that the occasions of these laws being
enforced are probably very small, but many companies simply can't afford
a prosecution for data protection abuse (fines, reputation, etc.).

This can only harm US cloud companies surely?
Can't do a lot for relations either :)

Is it time for international law for IT?

Thanks again for the debate!
Adrian

> --
> ~~~~~
>
> Posting guidelines: http://bit.ly/bL3u3v
> Follow us on Twitter @cloudcomp_group @cloudslam @up_con
> Post Job/Resume at http://cloudjobs.net
>
> Download hundreds of recorded cloud sessions at
> - http://cloudslam.org/register
> - http://www.up-con.com/register
> - http://cloudslam09.com/content/registration-5.html
> - http://cloudslam10.com/content/registration
>
> or get it on DVD at
> http://www.amazon.com/gp/product/B002H07SEC,
> http://www.amazon.com/gp/product/B004L1755W,
> http://www.amazon.com/gp/product/B002H0IW1U
>
> ~~~~~
> You received this message because you are subscribed to the Google
> Groups "Cloud Computing" group.

> To post to this group, send email to cloud-c...@googlegroups.com

> To unsubscribe from this group, send email to

> cloud-computi...@googlegroups.com

[Adrian J Duncan]

Hi Gilad,
I think in some ways it may be a mute point. If I am that manager and I
have a federal document in my hand and maybe some guys in trench-coats
in my office, the pressure to hand said data over maybe too great to
resist. Who would prosecute me? Its highly unlikely that the
trench-coat ladies are going to pursue that one as it would not be
within their jurisdiction!

Cheers
Adrian

[VicWinkler.com]

This is the best overview and summary I have ever read.

Vic

(Sent from my mobile: Please excuse brevity)

[Gilad Parann-Nissany]

Adrian

All opinions here are totally valid. But, just so my opinion is clear, the answer to 

Who would prosecute me?  Its highly unlikely that the
trench-coat ladies are going to pursue that one as it would not be
within their jurisdiction!

is that in this situation the European authorities would have a major stake in making an example of you, so nobody else will ever make the same mistake. After all European sovereignty is at stake. And they can make an example out of you, because though you (the manager) do not live in Europe, part of your company does. The European authorities will use their law to make life unpleasant for your company and your managers, and you may have to answer to that..

In general folks, life is complicated, but it is sometimes just a bit simpler than we fear. Common sense does work quite often, if not always...

What will happen in reality is this. Since the USA does have rule of law - its a decent country remember - the manager (you?) will walk over to legal and ask the question: "what do I do with these trench coats?". The answer you get is: "no way, what they are asking for is illegal in Europe and they cannot force you". And then you walk back and tell them: "dear trench coats, we would love to cooperate, what we can do is tell you the exact location of that package, which is Hamburg, and its headed for Switzerland. We will be glad to divert it if you get the right European court order". And the trench coats will even say "thank you" and act nice, as they should, you really gave them everything you can.

That's it. And same in the cloud. You could pay a lawyer for more professional advice, if you like, but I think you'll find common sense actually does work in this case.

Regards
Gilad
__________________
Gilad Parann-Nissany

http://www.porticor.com/

[Miha Ahronovitz]

Jim, this is a fascinating and original lecture. I like how you consider the human factor in DB design and how there is a life even if a DB is not ACID compliant 100%

Good luck with NimbusDB, I read you here for years

Miha

[Adrian J Duncan]

Gilad, thanks for the reply, which was both informative and made me
smile too.

For me, its not a US v EU thing or a 'which law is right' matter. I
think there needs to be some international law on all this now and
especially on jurisdiction. Most of us don't want criminals hiding
behind borders and exploiting the cloud to avoid prosecution.

Sometimes some thought in law making about implications for companies'
trading position as well. A law like that from any country could damage
a company's ability to attract international customers.

Is there a law on trench-coats?

Cheers
Adrian

[CloudSigma]

Dear all,

Actually what doesn't seem to be mentioned is that this isn't cloud
specific, it is just about the treatment of any data in a specific
legal jurisdiction. What most people don't appreciate is that if they
have servers hosted with a XYZ supplier from say the US, there is no
more protection over those physical servers hosted with that company
than cloud servers. You can even extend this to US data centre
companies also operating abroad. All have the same obligations to
respond to US requests for information if they can access that
information, at home or abroad exist for the US companies. Ultimately
your choice of vendor and location determines the legal access/
oversight of your data be that your servers in a data centre, your
dedicated servers with a hosting provider or your cloud servers with a
hosting provider.

It is also about more than 'criminals hiding across borders'. The
cloud as outlined above gives no more protection than other hosting
mediums. It is about customers knowing when they put their data
somewhere, they are compliant with a set of rules regarding that data
and it is handled in a transparent way. If you have anyone from
anywhere able to requisition data in a non-transparent way, that isn't
good for anybody. In any case, foreign countries can always request
information with regards to criminal proceedings through the local
legal system. The automatic access to information abroad of any
government without local due process is a bad precedent and encourages
the sort of lazy policing and trawling expeditions that are so often
undertaken by a number of governments nowadays.

Best wishes,

Robert
CTO
CloudSigma
http://www.cloudsigma.com

> >         <shen...@gmail.com> wrote:
>
> >         >         On Wed, Jul 6, 2011 at 3:35 PM, Gilad Parann-Nissany

> >         >         Post Job/Resume athttp://cloudjobs.net

>
> >         >         Download hundreds of recorded cloud sessions at
> >         >         -http://cloudslam.org/register
> >         >         -http://www.up-con.com/register
> >         >         -http://cloudslam09.com/content/registration-5.html

> >         >         -http://cloudslam10.com/content/registration

>
> >         >         or get it on DVD at
> >         >        http://www.amazon.com/gp/product/B002H07SEC,
> >         >        http://www.amazon.com/gp/product/B004L1755W,
> >         >        http://www.amazon.com/gp/product/B002H0IW1U
>
> >         >         ~~~~~
> >         >         You received this message because you are subscribed
> >         to the
> >         >         Google Groups "Cloud Computing" group.
> >         >         To post to this group, send email to
> >         >         cloud-c...@googlegroups.com
> >         >         To unsubscribe from this group, send email to
> >         >         cloud-computi...@googlegroups.com
>
> >         > --
> >         > ~~~~~
>
> >         > Posting guidelines:http://bit.ly/bL3u3v
> >         > Follow us on Twitter @cloudcomp_group @cloudslam @up_con

> >         > Post Job/Resume athttp://cloudjobs.net

>
> >         > Download hundreds of recorded cloud sessions at
> >         > -http://cloudslam.org/register
> >         > -http://www.up-con.com/register
> >         > -http://cloudslam09.com/content/registration-5.html

> >         > -http://cloudslam10.com/content/registration

>
> >         > or get it on DVD at
> >         >http://www.amazon.com/gp/product/B002H07SEC,
> >         >http://www.amazon.com/gp/product/B004L1755W,
> >         >http://www.amazon.com/gp/product/B002H0IW1U
>
> >         > ~~~~~
> >         > You received this message because you are subscribed to the
> >         Google
> >         > Groups "Cloud Computing" group.
> >         > To post to this group, send email to
> >         cloud-c...@googlegroups.com
> >         > To unsubscribe from this group, send email to
> >         > cloud-computi...@googlegroups.com
>
> >         --
> >         ~~~~~
>
> >         Posting guidelines:http://bit.ly/bL3u3v
> >         Follow us on Twitter @cloudcomp_group @cloudslam @up_con

> >         Post Job/Resume athttp://cloudjobs.net

>
> >         Download hundreds of recorded cloud sessions at
> >         -http://cloudslam.org/register
> >         -http://www.up-con.com/register
> >         -http://cloudslam09.com/content/registration-5.html

> >         -http://cloudslam10.com/content/registration

>
> >         or get it on DVD at
> >        http://www.amazon.com/gp/product/B002H07SEC,
> >        http://www.amazon.com/gp/product/B004L1755W,
> >        http://www.amazon.com/gp/product/B002H0IW1U
>
> >         ~~~~~
> >         You received this message because you are subscribed to the
> >         Google Groups "Cloud Computing" group.
> >         To post to this group, send email to
> >         cloud-c...@googlegroups.com
> >         To unsubscribe from this group, send email to
> >         cloud-computi...@googlegroups.com
>
> > --
> > ~~~~~
>
> > Posting guidelines:http://bit.ly/bL3u3v
> > Follow us on Twitter @cloudcomp_group @cloudslam @up_con

> > Post Job/Resume athttp://cloudjobs.net

>
> > Download hundreds of recorded cloud sessions at
> > -http://cloudslam.org/register
> > -http://www.up-con.com/register
> > -http://cloudslam09.com/content/registration-5.html

> > -http://cloudslam10.com/content/registration

>
> > or get it on DVD at
> >http://www.amazon.com/gp/product/B002H07SEC,
> >http://www.amazon.com/gp/product/B004L1755W,
> >http://www.amazon.com/gp/product/B002H0IW1U
>
> > ~~~~~
> > You received this message because you are subscribed to the Google
> > Groups "Cloud
>

> ...
>
> read more »

[Olivier Colinet]

Hi all,

1) is incorrect. These regulations aren't constrained to public cloud providers. They are in effect for many years and concern as well

• EU companies which have operations in the US (they are acting legally as data controllers)
• EU companies which are having their data hosted by a third-party (let's say IBM, HP etc.) which have operations in the US (the third-party is acting legally as a data controller)

In other words, if your messaging servers are hosted externally in the EU and your hosting company is EU headquartered but has a subsidiary in the US, then the US government can still access the data (under very exceptional conditions and according to a very strict process). So does apply if your company is having local operations in the US.

Mentioning that your data is at risk b/c you are using a public cloud provider is very misleading.

Olivier

_________________________________________________
Coli.net - This message was sent from the Colinets network

[Gilad Parann-Nissany]

Oliver

Thanks for your contribution. You mention

under very exceptional conditions and according to a very strict process

Since you are knowledeable about these regulations, can you explain this process? Thanks.

Regards
Gilad
http://www.porticor.com/

[Jim Peters]

Maybe if the US and EU regulators start to get busy suing each other, they might leave the rest of us alone for a while ....

Jim Peters
+1-415-608-0851 (Cell)
+1-416-466-9790 (Home)
+1-416-785-2500 x 3315 (Office)
+1-415-508-8651 (Google Voice)

[CloudSigma]

Dear Olivier,

Exactly, as is so often the case, something that is portrayed as cloud
related is in fact a general issue to do with computing/data control
issues. What it reveals is that most people (are are still not using
the cloud at this point) don't realise the access/frameworks under
which their data is being housed already because they appear to see
this as a cloud specific issue when, as we both agree, its much wider
and is directly relevant to them already.

So, actually the question is, you are not using the cloud but you
didn't realise the obligations for data discovery that your hosting
provider already has?! :-)

Best wishes,

Robert

On Jul 12, 10:30 pm, Jim Peters <j...@jamesgpeters.com> wrote:
> Maybe if the US and EU regulators start to get busy suing each other, they
> might leave the rest of us alone for a while ....
>

> On Tue, Jul 12, 2011 at 1:17 PM, Olivier Colinet <oliv...@colinet.eu.com>wrote: