The term Bring Your Own Cloud (BYOC) is commonly associated with personal clouds like Dropbox and Box. However, another equally important component of the BYOC conversation is when business units access public clouds, like Joyent and Amazon Web Services, without informing IT.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
From a service delivery perspective, accessing public clouds creates service degradation if the right tools are not in place.
Alan Conley, Zenoss CTO
The reason why business units do this is simple: IT is too slow to provide them with the infrastructure they need to get projects done. Instead of waiting for IT, they look to pre-constructed and easily accessible clouds to solve their problem. After all, a credit card is all one needs to do so.
If you do not have policies or the right tools in place to handle this type of BYOC, data security and service delivery problems occur. From a service delivery perspective, accessing public clouds creates service degradation if the right tools are not in place. Additionally, different service providers have various policies, and not understanding the rules of your service-level agreement (SLA) can cost you money.
From a security perspective, you run the risk of data leakage and non-compliance to regional standards.
But simply telling your company to stop accessing public clouds is not realistic – it is so simple and can provide great benefits. In order to curb the security and service delivery problems that arise with rogue access to public clouds, ask yourself the following questions and make sure you have the right policy and monitoring tools in place:
1. Do you have the ability to monitor your services no matter where they are running?
Using a public cloud is a technology decision that should not change business needs or expectations. As an IT manager/service owner, you are responsible to your users for the availability and performance of your service while ensuring delivery is within your SLAs. It is essential to have a service assurance tool in place that provides a holistic view of the health of services running in-house or in a cloud. This will help you confirm your SLAs and user-experience is being met.
2. How does your service provider compensate you for non-compliance of SLAs?
Have you read between the lines of your service level agreement? Service level agreements may state a guaranteed uptime of 99.9%, but take a look at how they compensate you if they fail to meet the SLA. You also need to look at how service level agreements measure uptime. Many may offer you service credits. Beware! The downtime cost to your business will often far exceed what you will get back in service credits. Understand this business risk and negotiate appropriately before you agree to the SLA penalties.
3. Do you know the privacy and security policies of your provider?
See what the physical and logical security policies are and always know where your data is hosted. Privacy restrictions depend on location, most or some European countries require that data is stored within the country and do NOT allow data to be stored in the US.
Beyond just looking at the personal cloud angle to BYOC, you should also think about how your business is accessing public cloud offerings. BYOC is not going away, so as an enterprise you need to embrace and cater your policies and tools towards it.
About the author:
Alan Conley joined Zenoss in 2011 as CTO where he is responsible for driving the Zenoss cloud management vision, direction and on-going innovation. He brings over 20 years of hands-on experience running large scale IT operations and building management products that span virtual, physical and cloud-based IT.
Prior to Zenoss, he served as CTO of the Network Management Group and as a Distinguished Engineer at Cisco Systems, where he was a key driver of Cisco's strategy and architecture for Cloud management, next generation network API, OpenStack, DMTF OVF 2.0, and Open Network Foundation (ONF). He holds a Bachelor of Science degree in Mechanical Engineering from the University of California, Davis.