Druva heeds, don't just 'plonk' data into the cloud

This is a contributed article for the Computer Weekly Developer Network written by Druva’s Dave Packer in his role as VP of products and alliances marketing at the company.

Druva is a data management and protection specialist that offers Backup-as-a-Service (BaaS) to the cloud across endpoints, servers and cloud applications — the firm augments this core offering with integrated workflows, global deduplication and encryption key services.

Packer asks, why would we build our IT and applications in the cloud?

He surmises that the reason behind the shift to cloud is simple [enough], it will allow organisations to meet business or consumer needs faster.

However, the move to cloud infrastructure can have further consequences, particularly when it comes to managing all the data our new applications and infrastructure produce over time. More traditional IT management tasks like data protection, archiving and disaster recovery can’t be solely left to the cloud platform.

Packer writes as follows 

Adopting a cloud-native strategy opens up more options. As the volume of data we create every day grows, it makes more economic sense to use cloud services to host that data and run those applications compared to building up more internal IT infrastructure.

This can vary from full cloud-based apps that run across public cloud, to more specific deployments that replicate more traditional IT designs and use cloud to help with scale. The cloud implementation that suits you best will be based on what you want to achieve.

For example, it’s possible to run specific VMware virtual machines on Amazon Web Services (AWS) alongside internal data centre workloads; alternatively, you can implement a full Software-Defined Data Centre on AWS or host these applications natively on AWS using EC2 and requisite additional services.

Don’t plonk into cloud

However, applications are not just ‘put [i.e. plonked down] in place’ in the cloud, or in virtual machines.

Let’s remember that AWS offers a plethora of ways to store data created by applications – from the object storage of AWS Simple Storage Service (S3) and traditional block storage of Elastic Block Store (EBS) through to more specific database services like Relational Database Service (RDS).

Alongside this, you can implement applications based on the full set of compute services contained in EC2, that use S3 and EBS alongside Glacier for long-term, ‘cold’ data storage. With these new services getting used to store potentially huge amounts of data, additional data management considerations should be made.

For some IT teams, moves like VMware and AWS working together will support their long term goals of migrating their workloads to the cloud, while maintaining system consistency with their on-premises environment. For other IT teams, this is a chance to review their infrastructure strategies from their choice of hypervisor through to more widespread strategic changes. Picking the right approach here will depend on previous decisions, and the process will probably result in a hybrid world for years to come.

Whatever the specific architecture choices, moving to the cloud will mean that data that is spread across more physical locations.

You may have islands of data held in different locations and used for different business applications. With more mobile employees, cloud applications and remote branch offices in place at enterprises too, it’s harder to maintain that complete picture and consolidate how the data is used and managed over time. It’s therefore important to look at how all this information can viewed and managed from a single control plane.

Keeping up with data in the cloud

Each cloud service can fulfil a role for managing data created by an application. However, without a full overview of each set of data that is being created, it can be difficult to help the business meet all its requirements. While these applications may fulfil a specific business goal, wider issues like compliance can be compromised if they are not considered.

For example, all IT teams will have seen the initials GDPR bandied about. If your customer-facing app holds customer records, then managing this data is going to be a necessary requirement over time. Establishing if your public cloud platform can help you support tracking data over time – or whether this is solely left up to you – should be thought about at the beginning, rather than added on afterwards.

Whether multiple sets of data are created on S3 or EBS – or stored within hybrid cloud infrastructure that sits across public and private cloud – business applications have to be managed and the data they produce protected. Not only should this help your overall move to the cloud, it should support any efforts taking place around compliance when it comes to customer data and GDPR.

Alongside moving applications built on cloud into production, IT teams have to look at where that application data is hosted or moved to. Whatever public cloud platforms you use, or hybrid environment is deployed, all this data will have to be protected and managed over time.

All cloud-native application designers will therefore have to think hard about how they use data, and how they maintain security, auditability and management over this.