Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

Four Years Later Expand / Collapse
Author
Message
Posted Tuesday, October 15, 2013 8:44 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:56 PM
Points: 31,168, Visits: 15,612
Comments posted to this topic are about the item Four Years Later






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1505050
Posted Wednesday, October 16, 2013 1:39 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 5:04 AM
Points: 941, Visits: 2,935
I live and work in Africa and here our bandwidth is too expensive, too slow and too unreliable. We are a long way from "leaning cloud first". At the moment, cloud is appealing to offload some data for reporting and web services, but not to replace in-house OLTP servers.





The SQL Guy @ blogspot

@SeanPearceSQL

About Me
Post #1505091
Posted Wednesday, October 16, 2013 2:01 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:00 AM
Points: 5,576, Visits: 3,427
I live in rural England but my village/town is not tiny and has an (telephone) exchange which I live close to - luckily for my broadband speed. There are too many places where internet speed and reliability of connection is not brilliant. It can be quite surprising how some urban locations fail in this regard. So I guess I am adding to Sean's (heavily paraphrased) argument that until we have a near universal reliable and fast internet connection then, for some, cloud hosting is not even on the table.

For others, however, it does appear the simplest of options.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1505097
Posted Wednesday, October 16, 2013 6:37 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 2:36 AM
Points: 2,840, Visits: 3,970
i live in INDIA which is known as World's IT hub (atleast we indian think that though there could be another reasons too why US outsource their IT work here but thats another story).

Here Companies are moving to Cloud Computing eveb smaller companies too (one of my friend spoke about it last week to me that they (smaller advertisment company) are going to use Clould environment soon).

So things are moving towards Cloud computing.


-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done
Post #1505158
Posted Wednesday, October 16, 2013 6:38 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 2:48 PM
Points: 685, Visits: 1,721
Sigh! Four years and folks are still trying the upsell the cloud. Maybe the NSA is offering an additional bonus?

Most of us who've been in this business awhile understand the benefits of various technical and business solutions. The "cloud" or service providers work better in some circumstances and for a sub-set of institutions. We still have the same issues we had four years ago: bandwidth, service, accountability and security.

And security is a much larger elephant considering the events of the last year. It's apparent that an insider or an government agency can totally damage an organization. Why do you want yet another company and their employees/contractors to have access to your data by outsourcing it? You're increasing the liability and attack surface.
Post #1505159
Posted Wednesday, October 16, 2013 6:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, July 30, 2014 11:37 AM
Points: 37, Visits: 59
Speaking about the company I work for (for the last 8 years), we are very careful about "cloud". The CEO is very protective of the data we generate, and for a good reason, I think. So, I don't see us ever going "cloud" on someone else's servers, but we are, at the moment, migrating all of our infrastructure to a "cloud"- like solution on our own premises.
Post #1505162
Posted Wednesday, October 16, 2013 6:45 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:42 PM
Points: 2,599, Visits: 3,936
I wouldn't say we are thinking cloud first, but, the cloud is now in the mix when discussing options.
Post #1505163
Posted Wednesday, October 16, 2013 7:19 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Yesterday @ 11:51 AM
Points: 629, Visits: 2,131
Its possible that smaller businesses developing new systems from scratch are thinking cloud first, or starting to.

But I haven't seen any sort of groundswell to move existing database implementations to the cloud. The pace of change for those sorts of things is far slower, and often cost driven. Also, many small and medium businesses buy off the shelf software and then customize around it. And I have not yet seen many vendors of core business software (HR systems, GL) pushing implementations using cloud databases.

It likely will come, but it seems to me that businesses have a much slower adoption of technological trends than consumers do.
Post #1505178
Posted Wednesday, October 16, 2013 9:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 4:40 PM
Points: 67, Visits: 435
I live in the Netherlands (some of you may call it Holland) and I do believe we have a superb internet connectivity. By now most parts of our beloved country have a 4G super fast mobile network allowing to work nearly everywhere with a bandwidth that allows HD television on a tablet. Even here companies are quite reluctant to move their business into the cloud. If you look at the technical possibilities the are no barriers, take for example the cloud based BI solution offered by Birst.

But it requires a whole different way of thinking to view a database as a service and not as a resource. In most cases using a connection with limited bandwidth for INSERT and UPDATE statements will not slow down the application enough to be noticeable. However for queries using SELECT it is a completely different story. Most developers will only replace the notorious SELECT * FROM ... with a set of named columns when the expected number of rows is really huge. Sucking all the data into the application server and then decide what to use is so common that some applications even need a database service on the same server to avoid the network overhead. Sometimes you cannot blame the developer, the ORM might access data 'one object at a time' thereby generating loads of tiny SELECT requests for all columns of a single table row. For queries the YAGNI design rule (You Ain't Gonna Need It) clearly does not apply.

As soon as each SELECT request is kept as small as possible the amount of data an application needs becomes manageable. Then it might be possible to move de database into the cloud because the extra overhead does not significantly slow down the application. That requires a different approach to data access for both the developer and the ORM he uses, with Linq (from Microsoft) as a good example that it is possible to offer such a bandwidth efficient framework for data access to the developer. Even with Linq it is still up to the developer to limit the request to the columns used; the compiler has not yet capabilities to determine which columns are used and thus limit the request to these columns. Making an application 'cloud ready' might require some effort, making that application 'cloud database ready' certainly does!
Post #1505306
Posted Wednesday, October 16, 2013 10:04 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:00 AM
Points: 5,576, Visits: 3,427
vliet (10/16/2013)
I live in the Netherlands (some of you may call it Holland) and I do believe we have a superb internet connectivity. By now most parts of our beloved country have a 4G super fast mobile network allowing to work nearly everywhere with a bandwidth that allows HD television on a tablet. Even here companies are quite reluctant to move their business into the cloud. If you look at the technical possibilities the are no barriers, take for example the cloud based BI solution offered by Birst.

But it requires a whole different way of thinking to view a database as a service and not as a resource. In most cases using a connection with limited bandwidth for INSERT and UPDATE statements will not slow down the application enough to be noticeable. However for queries using SELECT it is a completely different story. Most developers will only replace the notorious SELECT * FROM ... with a set of named columns when the expected number of rows is really huge. Sucking all the data into the application server and then decide what to use is so common that some applications even need a database service on the same server to avoid the network overhead. Sometimes you cannot blame the developer, the ORM might access data 'one object at a time' thereby generating loads of tiny SELECT requests for all columns of a single table row. For queries the YAGNI design rule (You Ain't Gonna Need It) clearly does not apply.

As soon as each SELECT request is kept as small as possible the amount of data an application needs becomes manageable. Then it might be possible to move de database into the cloud because the extra overhead does not significantly slow down the application. That requires a different approach to data access for both the developer and the ORM he uses, with Linq (from Microsoft) as a good example that it is possible to offer such a bandwidth efficient framework for data access to the developer. Even with Linq it is still up to the developer to limit the request to the columns used; the compiler has not yet capabilities to determine which columns are used and thus limit the request to these columns. Making an application 'cloud ready' might require some effort, making that application 'cloud database ready' certainly does!


SELECT * FROM

is never acceptable. The application will usually only deal with columns it expects anyway so it is simply a waste and poor, lazy practice. I have yet so see an application that does something with unexpected data nor continues with a subset of what was expected.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1505316
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse