We've posted quite a bit about best user practices to maintain the integrity of your IT infrastructure, especially strong password hygiene, the use of antivirus/antimalware, and the importance of backups in the case something goes awry. With user negligence causing up to 68% of breaches, according to a Ponemon Research study, these practices are essential. But how can you make sure your employees adhere to them?
But a recent article covering the Clinton presidential campaign staff methods to encourage information security reveals one secret to IT security: being kind of annoying.
Placing data in the cloud comes with a set of concerns — accessibility (will my information always be available if the cloud has technical problems?) and security (how safe is my data when I can’t control the security measures?) chief among them. Of these, security has long been the primary concern for technology decision makers considering the cloud.
Recent surveys reveal that while security remains top of mind, the location of data is rising in prominence as a barrier or concern for cloud adoption. These concerns stem in part from the difficulty of visibility into data transit and storage. Customers might want to know where exactly their data is residing so they can retrieve it quickly — and also for legal implications.
Two recent court cases between Google, Microsoft, and the Federal Government highlight the legal entanglements that could come with storing information in the cloud. Read on to learn why the location of your cloud data is vital.
The term “cloud” may only have reached our collective consciousness in the past few years, but the concepts involved in cloud computing date back many decades. Starting with utility computing and moving on to virtualization and grid computing, distributing compute resources has long been a way to minimize costs involved with IT infrastructure.
Let’s see how we moved from the mainframe to Salesforce with this quick history of cloud computing.
When designing the architecture for your SQL Server virtualized on VMware vSphere, your requirements will determine which SQL availability or vSphere availability features you should use. There are several availability features packaged with SQL server before you even get to vSphere features like Distributed Resource Scheduler, High Availability, Fault Tolerance, or vMotion, each of which have their own considerations when interacting with SQL.
To get started, you’ll want to ask yourself a few questions about your SQL deployment.
“Can my application run in the cloud?”
It’s a question we get more frequently than you might think — and the answer is almost always yes. Just yesterday, we got a web chat from an individual who wanted to know if a cloud server could run his e-mail server, SMTP-based, with PowerMTA, or if he would need a dedicated option. Mail servers are frequently run on virtual machines, so this configuration should pose no problem as a cloud server.
There are thousands of applications, running on a wide variety of operating systems, that play nice with VMware virtualization platforms (the basis of the gBlock cloud). Here are four hybrid cloud use cases to get you started.