Four Years Later
-
Comments posted to this topic are about the item Four Years Later
-
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.
-
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!!!
-
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;-) -
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.
-
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.
-
I wouldn't say we are thinking cloud first, but, the cloud is now in the mix when discussing options.
-
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.
-
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!
-
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 * FROMis 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!!!
-
fificito (10/16/2013)
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.I hear that a lot. But who's to say that "someone else's servers" aren't a lot more secure than yours?
-
chrisn-585491 (10/16/2013)
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.
Perhaps the NSA is, but not to me.
You have good arguments here, but those apply to some domains and not others. I would argue there are a good domain of services and businesses that don't capture PII, medical, financial, etc. information. They provide a simple service, like a grocery list or a mapping tool, or a game. In many cases, the issues with the cloud aren't as important as the scale and reach.
The issues you brought up are important, but not necessarily an issue for some domains of services.
-
Nevyn (10/16/2013)
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.
I'd agree here. It's hard and complex (and $$$) to "move" an existing application to the cloud. however for new work, it can be worth looking at.
-
It's entering the vocabulary.
Mine at least.
But then I was also slow to accept putting SQL on virtual machines, but have slowly over the last 2 years become a believer in it, at least from a disaster management perspective, if not from an operational perspective.
I expect I will come around to the "cloud" sooner or later. I do see some very cool and promising things with Azure, but security is most likely the thing that will stop this from happening to me. That and having been burnt by SQL 2000 SP4 I do not really want to have my databases hosted on a SQL Server I have no control over the patch level (or when it patches).
I am ready to start to play with it myself for some personal projects, just to make sure I have a clue what to do if my company ever decides to do it...
-
SELECT * FROM can be acceptable and a normal requirement (think data warehousing, integration and application services). A common example is selects all states and provinces to generate a list for a form prompt (a smart design keeps those results cached). Generally speaking, it is not ideal in regards to end user queries and it is a reality that can be addressed by policies. Regardless of policy, it is always going to happen for as long as we provide non technical staff with tools that require technical training.
Now, take that scenario to the cloud. Can those services fully integrate with one another from a data perspective. In my experience, the answer is sometimes. In terms of development costs, software licensing costs, hosting costs, et al. The ROI for public cloud solutions isn't always as robust as they are in internally hosted private cloud environments. In many cases, public cloud offerings are not an option at all until the cloud service fully aligns with the features offered in the internally hosted version of the product. My internal bandwidth is exponentially greater and faster than my bandwidth to cloud services. Changing that requires spending more dollars on bigger circuits that are much more expensive that the VM's I host internally.
And don't get me started on security or lack thereof in the cloud world...
Viewing 15 posts - 1 through 15 (of 21 total)
You must be logged in to reply to this topic. Login to reply