All posts by Guest Author

Taking In-Memory NoSQL to the Next Level

Guest Post by Ofer Bengal, Co-Founder & CEO, Garantia Data

 

Ofer Bengal

Ofer Bengal has founded and led companies in data communications, telecommunications, Internet, homeland security and medical devices.

Today Garantia Data is launching the first in-memory NoSQL cloud that promises to change the way people use Memcached and Redis. I think this is a great opportunity to examine the state of these RAM-based data stores and to suggest a new, highly-efficient way of operating them in the cloud.

Challenges of Cloud Computing

Memcached and Redis are being increasingly adopted by today’s web-applications, and are being used to scale-out their data-tier and significantly improve application performance (in many cases improvement is x10 over standard RDBMS implementation). However, cloud computing has created new challenges in the way scaling and application availability should be handled and using Memcached and Redis in their simple form may not be enough to cope with these challenges.

Memcached

It’s no secret Memcached does wonders for websites that need to quickly serve up dynamic content to a rapidly growing number of users. Facebook, Twitter, Amazon and YouTube, are heavily relying on Memcached to help them scale out; Facebook handles millions of queries per second with Memcached.
But Memcached is not just for giants. Any website concerned with response time and user based growth should consider Memcached for boosting its database performance. That’s why over 70% of all web companies, the majority of which are hosted on public and private clouds, currently use Memcached.

Local Memcached is the simplest and fastest caching method because you cache the data in the same memory as the application code. Need to render a drop-down list faster? Read the list from the database once, and cache it in a Memcached HashMap. Need to avoid the performance-sapping disk trashing of an SQL call to repeatedly render a user’s personalized Web page? Cache the user profile and the rendered page fragments in the user session.

Although local caching is fine for web applications that run on one or two application servers, it simply isn’t good enough when the data is too big to fit in the application server memory space, or when the cached data is updated and shared by users across multiple application servers and user requests. In such cases user sessions, are not bound to a particular application server. Using local caching under these conditions may end up providing a low hit-ratio and poor application performance.

Distributed Memcached tends to improve local caching by enabling multiple application servers to share the same cache cluster. Although the Memcached client and server codes are rather simple to deploy and use, Distributed Memcached suffers from several inherent deficiencies:

  • Lack of high-availability – When a Memcached server goes down the application’s performance suffers as all data queries are now addressed to the RDBMS, which is providing a much slower response time. When the problem is fixed, it could take between a few hours to several days until the recovered server becomes “hot” with updated objects and fully effective again. In more severe case, where session data is stored in Memcached without persistent storage, losing a Memcached server may cause forced logout of users or flush of their shopping carts (in ecommerce sites).
  • Failure hassle – The operator needs to set all clients for the replacement server and wait for it to “warm-up”. Operators sometimes add temporary slave servers to their RDBMS, for offloading their Master server, until their Memcached recovers.
  • Scaling hassle – When the application dataset grows beyond the current Memcached resource capacity, the operator needs to scale out by adding more servers to the Memcached tier. However, it is not always clear when exactly this point has been reached and many operators scale out in a rush only after noticing degradation in their application’s performance.
  • Scaling impact on performance – Scaling out (or in) Memcached typically causes partial or entire loss of the cached dataset, resulting, again, in degradation of the application’s performance.
  • Manpower – Operating Memcached efficiently requires manpower to monitor, optimize and scale when required. In many web companies these tasks are carried out by expensive developers or devops.

Amazon has tried to simplify the use of Memcached by offering ElastiCache, a cloud-based value-added service, where the user does not have to install Memcached servers but rather rent VMs (instances) pre-loaded with Memcached (at a cost higher than plain instances). However, ElastiCache has not offered a solution for any of the Memcached deficiencies mentioned above. Furthermore, ElastiCache scales-out by adding a complete EC2 instance to the user’s cluster, which is a waste of $$ for users who only require one or two more GBs of Memcached. With this model ElastiCache misses on delivery of the true promise of cloud computing – “consume and pay only for what you really need” (same as for electricity, water and gas).

Redis

Redis an open source, key-value, in-memory, NoSQL database began ramping-up in 2009 and is now used by Instagram, Pinterest, Digg, Github, flickr, Craigslist and many others and has an active open source community, sponsored by VMware.

Redis can be used as an enhanced caching system alongside RDBMS, or as a standalone database.
Redis provides a complete new set of data-types built specifically for serving modern web applications in an ultra-fast and more efficient way. It solves some of the Memcached deficiencies, especially when it comes to high availability, by providing replication capabilities and persistent storage. However, it still suffers from the following drawbacks:

  • Failure hassle – There is no auto-fail-over mechanism; when a server goes down, the operator still needs to activate a replica or build a replica from persistent storage.
  • Scalability – Redis is still limited to a single master server and although cluster management capability is being developed, it probably won’t be simple to implement and manage and will not support all Redis commands, making it incompatible with existing deployments.
  • Operations – Building a robust Redis system requires strong domain expertise in Redis replication and data persistence nuances and building a Redis cluster will be rather complex.
DB Caching Evolution

The Evolution of Caching

A new cloud service that will change the way people use Memcached and Redis

Imagine connecting to an infinite pool of RAM memory and drawing as much Memcached or Redis memory you need at any given time, without ever worrying about scalability, high-availability, performance, data security and operational issues; and all this, with the click of a button (ok, a few buttons). Now imagine paying only for GBs used rather than for full VMs and at a rate similar to what you pay your cloud vendor for plain instances. Welcome to the Garantia Data In-Memory NoSQL Cloud!  

By In-Memory NoSQL Cloud I refer to an online, cloud-based, in-memory NoSQL data-store service that offloads the burden of operating, monitoring, handling failures and scaling Memcached or Redis from the application operator’s shoulders. Here are my top 6 favorite features of such service, now offered by Garantia Data:

  • Simplicity – Operators will no longer need to configure and maintain nodes and clusters. The standard Memcached/Redis clients are set for the service DNS and from this moment on, all operational issues are automatically taken care of by the service.
  • Infinite scalability – The service provides an infinite pool of memory with true auto-scaling (out or in) to the precise size of the user’s dataset. Operators don’t need to monitor eviction rates or performance degradation in order to trigger scale-out; the system constantly monitors those and adjusts the user’s memory size to meet performance thresholds.
  • High availability – Built-in automatic failover makes sure data is guaranteed under all circumstances. Local persistence storage of the user’s entire dataset is provided by default, whereas in-memory replication can be configured at a mouse click. In addition, there is no data loss whatsoever when scaling out or in.
  • Improved application performance – Response time is optimized through consistent monitoring and scaling of the user’s memory. Several techniques that efficiently evict unused and expired objects are employed to significantly improve the hit-ratio.
  • Data security – For those operators who are concerned with hosting their dataset in a shared service environment, Garantia Data has full encryption of the entire dataset as a key element of its service.
  • Cost savings – Garantia Data frees developers from handling data integrity, scaling, high availability and Memcached/Redis version compliance issues. Additional savings are achieved by paying only for GBs consumed rather than for complete VMs (instances). The service follows the true spirit of cloud computing enabling memory consumption to be paid for much like electricity, water or gas, so you “only pay for what you really consume”.

We have recently concluded a closed beta trial with 20 participating companies where all these features were extensively tested and verified – and it worked fine! So this is not a concept anymore, it’s real and it’s going to change the way people use Memcached and Redis! Am I excited today? Absolutely!


Bursting into the Clouds – Experimenting with Cloud Bursting

Guest Post by Dotan Horovits, Senior Solutions Architect at GigaSpaces

Dotan Horovits is one of the primary architects at GigaSpaces

Dotan Horovits is one of the primary architects at GigaSpaces

Who needs Cloud Bursting?

We see many organizations examining Cloud as replacement for their existing in-house IT. But we see interest in cloud even among organizations that have no plan of replacing their traditional data center.

One prominent use case is Cloud Bursting:

Cloud bursting is an application deployment model in which an application runs in a private cloud or data center and bursts into a public cloud when the demand for computing capacity spikes. The advantage of such a hybrid cloud deployment is that an organization only pays for extra compute resources when they are needed.
[Definition from SearchCloudComputing]

Cloud Bursting appears to be a prominent use case in cloud on-boarding projects. In a recent post, Nati Shalom summarizes nicely the economical rationale for cloud bursting and discusses theoretical approaches for architecture. In this post I’d like to examine the architectural challenges more closely and explore possible designs for Cloud Bursting.

Examining Cloud Bursting Architecture

Overflowing compute to the cloud is addressed by workload migration: when we need more compute power we just spin up more VMs in the cloud (the secondary site) and install instances of the application. The challenge in workload migration is around how to build a consistent environment in the secondary site as in the primary site, so the system can overflow transparently. This is usually addressed by DevOps tools such as ChefPuppetCFEngine and Cloudify, which capture the setup and are able to bootstrap the application stack on different environments. In my example I used Cloudify to provide consistent installation between EC2 and RackSpace clouds.

The Cloud Bursting problem becomes more interesting when data is concerned. In his post Nati mentions two approaches for handling data during cloud bursting:

1. The primary site approach – Use the private cloud as the primary data site, and then point all the burst activity to that site.
2. Federated site approach – This approach is similar to the way Content Distribution Networks (CDN) work today. With this approach we maintain a replica of the data available at each site and keep their replicas in sync.

The primary site approach incurs heavy penalty in latency, as each computation needs to make the round trip to the primary site to get the data for the computation. Such architecture is not applicable to online flows.

The federated site approach uses data synchronization to bring the data to the compute, which saves the above latency and enables online flows. But if we want to support “hot” bursting to the cloud, we have to replicate the data between the sites in an ongoing streaming fashion, so that the data is available on the cloud as soon as the peak occurs and we can spin up compute instances and immediately start to redirect load. Let’s see how it’s done.

Cloud Bursting – Examining the Federated Site Approach

Let’s put up our sleeves and start experimenting hands-on with the federated site approach for Cloud Bursting architecture. As reference application let’s take Spring’s PetClinic Sample Application and run it on an Apache Tomcat web container. The application will persist its data locally to a MySQL relational database.

The primary site, representing our private data center, will run the above stack and serve the PetClinic online service. The secondary site, representing the public cloud, will only have a MySQL database, and we will replicate data between the primary and secondary sites to keep data synchronized. As soon as the load on the primary site increases beyond a certain threshold, we will spin up a machine with an instance of Tomcat and the PetClinic application, and update the load balancer to offload some of the traffic to the secondary site.

On my experiment I used Amazon EC2 and RackSpace IaaS providers to simulate the two distinct environments of the primary and secondary sites, but any on-demand environments will do.

REPLICATING RDBMS DATA OVER WAN

How do we replicate data between the MySQL database instances over WAN? On this experiment we’ll use the following pattern:

1.     Monitor data mutating SQL statements on source site. Turn on the MySQL query log, and write a listener (“Feeder”) to intercept data mutating SQL statements, then write them to GigaSpaces In-Memory Data Grid.

2.     Replicate data mutating SQL statements over WAN. I used GigaSpaces WAN Replication to replicate the SQL statements  between the data grids of the primary and secondary sites in a real-time and transactional manner.

3.     Execute data mutating SQL statements on target site. Write a listener (“Processor”) to intercept incoming SQL statements on the data grid and execute them on the local MySQL DB.

 

 

 

 

 

 

 

 

 

 

 

 

To support bi-directional data replication we simply deploy both the Feeder and the Processor on each site.

AUTO-BOOTSTRAP SECONDARY SITE

When peak load occurs, we need to react immediately, and perform a series of operations to activate the secondary site:

1.     spin up compute nodes (VMs)

2.     download and install Tomcat web server

3.     download and install the PetClinic application

4.     configure the load balancer with the new node

5.     when peak load is over – perform the reverse flow to tear down the secondary site

We need to automate this bootstrap process to support real-time response to peak-load events. How do we do this automation? I used GigaSpacesCloudify open-source product as the automation tool for setting up and for taking down the secondary site, utilizing the out-of-the-box connectors for EC2 and RackSpace. Cloudify also provides self-healing  in case of VM or process failure, and can later help in scaling the application (in case of clustered applications).

Implementation Details

The result of the above experimentation is available on GitHub. It contains:

§  DB scripts for setting up the logging, schema and demo data for the PetClinic application

§  PetClinic application (.war) file

§  WAN replication gateway module

§  Cloudify recipe for automating the PetClinic deployment

See the documentation on GitHub for detailed instructions on how to configure the above with your specific deployment details.

Conclusion

Cloud Bursting is a common use case for cloud on-boarding, which requires good architecture patterns. In this post I tried to suggest some patterns and experiment with a simple demo, sharing it with the community to get feedback and raise discussion on these cloud architectures.

More information can be seen at an upcoming GigaSpaces webinar on Transactional Cross-Site Data Replication on June 20th (register at: http://bit.ly/IM0w9F)


Does PaaS Really Mean No-Ops?

Guest post by Yaron Parasol, Director of Product Management, GigaSpaces

Yaron Parasol is GigaSpaces Director of Product Management

I’d like to start with a brief overview of the evolution of the cloud – and why I think a new approach to PaaS solutions is needed – and the best scenarios for this to come into play.

First there was IaaS. Cloud was created with the notion of IT agility and cost-reduction. You need servers? No problem! Forget about red tape, forget about sys admins. You create an account and in few clicks you select the hardware profile and OS image you need, and voila, your server is out there, ready for you to use. No hassles, immediate gratitude.

Well, this is true as long as the images you get form your cloud provider match your needs. If you have custom needs, you will have to create and maintain your own image. So, you need the sys admin’s knowledge. However, we’re also seeing a change in methodology here – sys admins no longer need to install the servers once they’re up. Instead, they provide their expertise using approved and maintained images on the cloud. Application developers can choose the right image for them and from that point on, create virtual machines in the amount and hardware size they need for their applications.

Now let’s switch to PaaS. The idea of no-ops is the guideline for many of the existing PaaS offerings. Their use cases and features are all about developers. As Michael Cote put it:

“The point of PaaS is to make a developer’s life even easier: you don’t need to manage your cloud deployments at the the lower level of IaaS, or even wire together your Puppet/Chef scripts. The promise of PaaS is similar to that of Java application servers: just write your applications (your business logic) and do magic deployment into the platform, where everything else is taken care of.”

Developers need to deploy applications to the Cloud. They don’t want to care about the OS but they also don’t want to care about platforms, load balancers etc. They want to focus on what they know – writing code.

This is definitely a very productive approach for some developers and some applications. Reality shows that a big portion of Cloud users don’t find these solutions a good fit for their purposes. These users continue to deploy and manage their applications on infrastructure clouds, as if they were running on premise leveraging the good old Ops folks. Others have taken a more agile approach, using configuration management and automation tools such as Chef.

These users chose not to use PaaS because they need flexibility and control. PaaS doesn’t seem to answer a lot of the current IT challenges – see for example here and here.

Existing applications with a variety of platforms, some using extremely complex topologies (like Hadoop, or a sharded MongoDB setup) are some of the reasons why PaaS won’t cut it for many users.

They would like to install their chosen versions of their preferred platforms, use their OS image, with their configured security groups, tune them in a manner that fits their applications and deploy their applications with the topology they choose.

Chef, like other DevOps tools, go a long way here and helps to achieve the flexibility while re-establishing a new agile relationship between Dev and Ops. Ops bring in their knowledge and skillset, but they document it and maintain it as code in a more structured and configurable way. This in turn gives the application guys the agility they need, putting a complex application to work in a single click and eliminating the platform black box experience which they dislike so much.

Application vs. Separate Platforms

However, DevOps tools still fall short when it comes to managing applications. They are not aware of the application’s inner dependencies. They don’t know how to monitor the application, scale it or even run a complex multi-tier recovery process. Most of these tools can’t even provision an entire application on the cloud.

So what if you could extend the DevOps experience to apply to the entire application lifecycle?

What if you could use Chef and the likes for installation but not stop there – automate things like failover and recovery, and even monitoring and scaling? You will still have all the Ops wisdom tailored to each of your applications and be able to automate any of your existing applications without re-architecting them.

This is exactly our take on PaaS, a DevOps style process that can describe any application’s lifecycle on any runtime environment, providing full automation without taking away the control.  And this is exactly what we set out to do with our Open Source PaaS platform – Cloudify, borrowing the idea of recipes but extending it to be application-centric and not infrastructure-centric.

The recipe describes the application dependencies and lifecycle events externally without any code or architecture change.

lifecycle{
init "mongod_install.groovy"
start "mongod_start.groovy"
postStart "mongod_poststart.groovy"
}

view rawmongod.groovyThis Gist brought to you by GitHub.

See how to create your own recipes here.

Mapping events like installation, start, post-start and stop to scripts or Chef cookbooks, exposing groovy andREST interfaces for context sharing and dynamic configuration and even provide a way to describe monitoring techniques, scaling rules and process “liveness” detection.

So think about it this way: while most PaaS services come with a catalog of predefined application blueprints, allowing the user to control only the application code, this new kind of PaaS stack, allows the user to define the blueprint, that is – any blueprint!

So, the recipes combine the Ops expertise with the power of automation for the developers. They completely remove the lock-in risk from the application-stack perspective.

You can read more the recipes, download Cloudify and experience it yourself or even join the community and influence the roadmap at cloudifysource.org. Or you can come see more when we present at HP Discover next week in Las Vegas.


The Consumerization of IT: No Longer Just About Phones or Tablets

Pete Khanna of TrackVia

Pete Khanna is the CEO of TrackVia, a cloud-based application platform that allows business users to build and deploy their own enterprise-grade SaaS applications.

Guest Post by Pete Khanna, CEO, Trackvia

What CIOs Need to Know – And Consider Doing – About the Emergence of Build-it-Yourself Enterprise Applications

It used to be that when a department or even a single employee wanted a new business application, they submitted an IT ticket and patiently waited for an answer. IT would evaluate the request, and decide whether to buy something, build something or simply do nothing. Often, this process took weeks, months and sometimes even years.

Emboldened by the “Consumerization of IT” trend and empowered by new cloud-based build-it-yourself application platforms, more front-line workers are bypassing IT all together, using their corporate credit cards to buy, build and deploy their own enterprise-grade SaaS applications within hours or days.

Experts agree this trend is likely to continue – and even accelerate. Analyst research firm Gartner predicts that “citizen developers” will build 25 percent of all new business applications by 2014.

Early case studies showed employees were building and deploying highly specialized or one-of-a-kind ‘rogue’ applications. These were the type of applications where an off-the-shelf software or SaaS solution either didn’t do the job or simply didn’t exist. However, more and more often, workers are using these build-it-yourself applications to deploy highly customized versions of common department applications, ranging from CRM SaaS solutions and inventory applications to HR systems and even customer service software.

The benefit of building your own department solution is that it’s often as much as 80 percent more affordable than off-the-shelf software or SaaS solutions. More importantly, these build-it-yourself solutions can be designed, customized and tailored by the users to meet the exact needs and requirements of the business. So instead of departments changing their processes or workflow to match that of the solution, users can change the solution to match their own processes. Simply put, features can be added, removed, changed or tweaked with a few clicks of the mouse. This leads to both greater efficiency and satisfaction by users.

All of this poses a growing challenge to IT professionals. Namely, how does IT manage the implementation of these so-called rogue applications without impeding employee productivity? The biggest concern from IT professionals is that they don’t want to be in constant clean-up mode, fixing or supporting solutions that end-users built themselves. A close second is that they want to be assured that the application is secure, ensuring that sensitive company information isn’t being compromised.

Having worked with thousands of businesses – from small cash-strapped start-ups to Fortune 100 companies – to implement their own custom applications, we’ve complied this list of best practices.

Step 1: Surrender to Win

The first and perhaps most important (and difficult) thing to do is decide whether or not to fight or embrace the “Consumerization of IT” movement. Even in highly regulated industries like banking and healthcare, where they use airtight firewalls, employees are finding ways around the lockdown mode of their internal IT organization. Doctors are bringing iPads into the examination room with their own apps installed. Marketers within banking organizations are using social media tools to distribute information. USB ports can be used to transfer information from unsecured laptops to company computers. The simple question becomes whether or not you want to use your limited IT resources and time policing employees or educating and empowering them. Getting alignment on this critical question at the highest levels of the organization is key.

Step 2: Offer Something Secure, Scalable and Supportable

Rather than hope you’re employees find and pick a secure and reliable build-it-yourself solution, many companies get out in front of their users and identify a single platform that meets both IT’s requirements and end-users’ needs.

This is where cloud-based application platforms are showing the most favorable response from business users and IT managers alike. Most organizations have larger, more complex enterprise-level applications that on some level need some customization. By adopting and implementing a secure, cloud-based application platform, CIOs proactively meet their own requirements while still providing end-users with a solution they can use to meet their own unique individual or department-level needs.

Implementing a single platform solution also helps streamline ongoing management and support, while making it faster and easier for employees to learn. For example, if all in-house applications are built atop a single platform, employees don’t have to learn to use multiple solutions. It also means IT doesn’t have to support multiple solutions. Everyone wins.

Step 3: Consider the Reliability

Nothing gets CEOs cackling faster than an email about a server or a critical system going down and employees checking out for the rest of the day. It’s also no fun for CIOs or IT Directors who have to deal with the hundreds of emails from employees asking, “Is the server back up? When will the CRM system be back up? What’s going on?”

A recent Constellation Research study shows most SaaS vendors report internal reliability ranging from 97 percent to 99.1 percent. However, it’s not uncommon to expect or demand that your cloud vendor partner demonstrate four-nine reliability. Most vendors will bake this guarantee into a standard SLA agreement. And as always, check the vendor’s track record and ask for customer references.

The Road Ahead

Like water, businesses and workers will always find the path of least resistance when it comes to working faster, more efficiently or effectively. The role of IT has always been to help clear technical obstacles for users, and protect them along the way. That hasn’t changed.

What has changed, however, is that IT has the opportunity to get out in front of the cloud computing and the “Consumerization of IT” trends, while playing a more proactive and strategic role in the overall organization’s future, versus trying to play catch up and doing damage control.

And that’s something I think we’d all agree is a good thing.


Industry Dynamics of Online Storage and the Decade Ahead

Guest Post by Eric Greenwood

Eric Greenwood is a technophile whose interests have led him to study all things related to the cloud computing movement from online storage to software as a service. Get more tips and advice on his Cloud Computing blog.

Online, or cloud storage, is a massively growing industry, already poised to change the way we use our computers. By 2016, consumers are predicted to be spending as much $16 billion on cloud storage annually.

Big names are flying into the cloud. Oracle and Hewlett Packard are rushing to sell cloud computing tools; Amazon’s cloud services division has earned an estimated $750 million from cloud services in 2011 – and predictions are for earnings of $2.5 billion by 2014 from all cloud services including their Simple Storage Service. Amazon CEO Jeff Bezos suggests potential for Amazon Web Services could surge to match that of its retail earnings, which last year topped $25 billion. Rackspace’s cloud servicing is also surging.

While currently only approximately 10% of global spending IT goes to cloud computing, the shift to cloud storage is a growing trend and market.

Popular cloud storage service Dropbox already has over fifty million users, and $250 million in venture capital; and Google Drive’s new online storage is poised to rival them. Like Dropbox’s chief competitor, Sugar Sync, Drive offers 5 GB of free storage, over doubling the free storage amount provided by Dropbox.

Storage competitors are also likely to follow Dropbox’s option of gallery pages that allow users who follow a link to see photos, presentations and videos without downloading each individual file. Dropbox is valued at approximately $4 billion, currently. The company’s CEO recently turned down a reported nine-figure offer from Apple. Apple of course maintains its own online storage system, iCloud, free to all users of iOs5. iCloud’s seamless interface with Apple products keeps this cloud storage service somewhat above the competitive fray.

Dropbox was recently voted “startup of the year,” and is reportedly the fifth most valuable web start-up, globally. But along with iCloud, SugarSync, and Google’s new drive, competition is fierce from other online storage startups ranging from Box.net, now known simply as Box, to Microsoft’s massive SkyDrive, Carbonite, which offers solid data backup services, and SpiderOak, which offers data encryption. Each of these cloud storage companies have greatly benefitted from the decline in pricing for online storage. Clearwell Systems research estimates that the storage cost for 1 gigabyte of information that cost $20 in 2000 is now approximately ten cents. HTML 5 has also greatly accelerated the growth of cloud storage companies. The cost and technology trends that have made cloud computing expand will only accelerate over the next ten years.

Dropbox’s popular rival SugarSync is an outgrowth of Sharpcast, the 2006 creator behind Sharpcast Photos, utilized for synching photo images to multiple devices. SugarSync’s differentiation with its competitors is based on its use of an automated refreshing process which means users don’t need to update their own synced files.

Microsoft’s recent overhaul of its SkyDrive online storage has doubled the storage file limit size, and made sharing as well as file management simpler for users. Just last month, Microsoft released a desktop app for SkyDrive, and allows direct file sharing to Twitter.

On the downside, there may only be a finite amount of users willing to store their data in the cloud, and a lot of competitors vying for a slice of the same pie. What’s good for consumers in terms of free storage or service perks may be difficult to sustain an entire industry of cloud storage competitors. Consolidation of some companies may be necessary.

A recent cautionary note was also founded when the file storage and hosting business Megapuload in Hong Kong was shut down by the U.S. Justice department for assisting in the violation of U.S. copyrights due to the ability of users to upload copyrighted material and distribute a link to it.

Megaupload’s violations bring up a key point in cloud storage, leading to the question as to whether or not Microsoft, Google, Dropbox, and all their competitors must scan files for copyright violations. Should this occur, the market will likely improve for Google with its Content ID already in place. Privacy and trust issues are also key in cloud storage growth. The only online storage company that claims to be unable to view users’ stored data is SpiderOak.

Online storage may be still in a speculative stage, but with data volumes predicted to multiply over forty times by the year 2020, data storage in one form or another is not only here to stay, it’s here to grow. Publicly traded companies such as EMC Corporation, NetApp, Isilon, Amazon, and CSC are providing expanded cloud storage options, and growing in financial leaps and bounds. IBM is working on a cloud system that can create virtual machines, able to integrate data without the costs of standard IT development, and simplifying cloud resources.

Complete data management through the cloud is clearly coming in the near future. Personal computer users and businesses multi-national to mom and pop size, must address data storage. Cloud storage is the go-to storage of the future, protected from human error, disasters, theft, and hardware malfunctions.


Three Reasons to Use Cloud Anti-Spam

Guest Post by Emmanuel Carabott,  Security Research Manager at GFI Software Ltd.

GFI Software helps network administrators with network security, content security and messaging needs

Budgets are stretched thin, you already work too many hours, and you’re always trying to find a server that can run the latest requested workload.

For companies with the flexibility to take advantage of cloud-based technologies, there’s a quick and simple way to win back some time, save some money, and free up some resources on your email servers and reallocate the ones that are running your current anti-spam solution – cloud anti-spam. Here’s how:

Money

Cloud anti-spam solutions require no up-front costs, no hardware, operating system, or software investments, and operate on a simple per-user subscription model. They are a great solution for companies looking to implement anti-spam technologies without a major investment. They keep your costs low, predictable, and easy to allocate. The subscription model means you even have the option to take what has always been considered a capital expense and turn it into an operational expense, which may make your CFO as happy as your CIO would be about the budget you save.

Time

Cloud anti-spam solutions will give you back hours in your week taking care of the infrastructure, but that’s not all. The best cloud anti-spam solutions offer you a user self-service model, where each user can get a daily summary of messages that were filtered out, and can click a link in that summary to release a false positive, or log onto a web portal at any time to check for missing or delayed messages themselves. They get instant gratification and your help desk works fewer tickets related to spam. Everyone wins, except, of course, the spammers.

Resources

Spam, malware, and phishing messages don’t just cost time and money, they can consume significant server resources. Anti-spam solutions running on your email server take a lot of CPU cycles to run filter lists and scan for malware, RAM to expand all those attachments before they can be scanned, and disk space to quarantine what inevitably will be deleted. Moving that entire load to the cloud anti-spam solution frees up resources on your servers, can free up space in your racks, and will save you tons of bandwidth you can put to better use since spam is stopped before it ever reaches your border.

Companies that for legal and compliance reasons, or that prefer to maintain complete control of all aspects of the email system may not find cloud anti-spam solutions are the best fit, but for companies with the flexibility to do so, they are the right choice for IT teams looking to save money, time and resources, and who also want to provide their end users with a great email experience. You’re already stretched thin; give yourself, your team, and your budget a break by choosing a cloud anti-spam solution today.


Benefits of Cloud Based ECM Systems

Guest Post by Steve Williams

Smart businesses everywhere have begun to take advantage of Enterprise Content Management (ECM). This system helps companies organize, store and retrieve eDocuments. Encompassing a variety of different programs, ECM helps businesses to organize their work flow and be prepared in case of any future litigation. Moving the ECM to the cloud presents even greater benefits.

Benefits of the Cloud

  • Security. Prevent the loss of critical data with regular backups of infrastructure hardware and more.
  • Cost. A cloud solution costs a fraction of an on-premise ECM solution. The pay-as-you go nature of cloud services also make it scalable to your needs.
  • Reliability. Cloud solutions can offer high uptime and keep planned downtimes at a minimum Access. Access all your content remotely through any device (mobile, desktop etc.)

Top 3 Benefits of ECM:

1. Improve Organization

Without an ECM system, employees may find it difficult to access records held by coworkers or find older documents. With an ECM system, the business can reduce its volume of content up to 50%. In the event of litigation, having fewer documents to search through and a more organized system helps employees and lawyers to prepare. The ECM system manages all of the data throughout its lifecycle and keeps it in one central place.

The Advantages:

  • One central location to retrieve all content.
  • Ensures compliance with new standards and policies.

For larger companies, having a central location means lawyers do not have to rush around various locations and can easily carry out the discovery process. To facilitate the legal team’s work, employees should be trained on policies regarding the various regulatory requirements or the company’s internal policies.

Prior to having an ECM system, a company would have to go through files by hand to check and see if workers were complying with the regulations. In the case of a hospital, new policies may get missed by workers. A proper ECM system could alleviate the problem by electronically tracking which employees signed new policy forms and ensure that everyone at the company is on the same page. Numerous state and federal regulations exist—each business must ensure that their employees are complying completely. Without an ECM system to track employee training and policy updates, employers are left without the safeguard they need to make sure that everyone is kept up-to-date on new regulations.

2. Prepare for Litigation

No business plans on having court battles, but in the event that it happens, being prepared early on makes litigation easier. Various regulations like Sarbanes-Oxley require that eDocuments be kept for a certain length of time. The ECM can be set to automatically put documents on hold and store them for a defined period of time. This aspect protects the documents from being deleted on purpose or by accident.

Instead of hiring out help, companies can handle litigation internally and reduce their overall cost. The system seamlessly integrates real-time updates and records prior versions of the file. Although no one intends to have a court case, preparing in advance saves the company valuable time and money.

3. Save Money

Having double copies of a file makes it more difficult for employees to access, change and use data. An ECM system works to prevent this by organizing the volumes of information in one location and with an easily searchable system. A user merely has to type in a keyword in the search box to have their file and related documents popup. Instead of having to search through documents by hand or go to different networks to find data, users have one location that they can access. Overall, this saves the company time and money spent on wages.

The Bottom Line:

Creating an ECM will require some initial spending, but overall the company will see immense savings on labor and IT infrastructure costs by moving to the cloud. If any litigation takes place, the company will save even more money on lawyers’ fees and throughout the discovery process. By being able to easily access old files, the company is protected from any allegations that they violated regulations. This protects them legally and financially.

This system also gets employees out of low-value tasks and into a role that makes the company more money. No more faxing over documents or hand-picking through old files. With a cloud-based ECM system, the program is intended to do all the work so the company does not have to hire an employee to do it.

Across the board, having a cloud-based ECM saves the company money and makes doing business more efficient. It improves the company’s ability to manage information and comply with federal regulations.