5 Considerations When Dealing with a Complex Hybrid Cloud SLA

Dec 8 2015 | by Yoav Mor

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×

As more and more enterprises make the move to the cloud, hybrid deployment is becoming increasingly popular. Following a report by Gartner, it has been discovered that more than 55% of enterprises are currently employing a hybrid cloud solution.

While a hybrid cloud solution is an appealing option in terms of efficiency and flexibility, one of the biggest implications of this movement is the complexity of maintaining SLAs within such a complex, distributed environment. Each cloud environment (i.e., public or private) is uniquely composed of its own capabilities, features, and contracts. The only problem is that the environments don’t align with one another. On-premises environments allow you to employ your own management efforts when it comes to aspects such as performance and security, and they enable you to define customer SLAs. On the other end of the spectrum, the fact that you don’t have complete control over your resources in the public cloud could lead to discrepancies between public cloud performance levels and the SLAs that are promised to end users.

In this article, we will discuss certain key considerations when planning how to manage, maintain, and define your hybrid cloud SLA.

The Migration Phase

Migrating to the public cloud should not be detrimental for enterprises. During the migration phase, neither your users nor you should experience any degradation in terms of performance, availability, or security. In order to ensure that no degradations occur, you need to understand the criticality of the migrated services. Compromising services that are already performing well for users is the last thing you want to do. It might be ideal to start the process by moving dev/test environments first. In addition, at this stage, planning is of utmost importance. Before choosing a public cloud provider, you need to truly understand each one’s cloud SLA and be fully aware of where your responsibilities lie.

Shared Environment Interference

Utilizing the public cloud means utilizing a multi-tenant environment and, therefore, runs the risk of dealing with potential interference from other tenants. With on-premises environments, you have complete control over your siloed hardware, which has its own purpose. However, one of the main elements of the public cloud is that in order to gain the full benefits of the infrastructure, vendors must ensure that their hardware can be reused or shared between tenants. Therefore, it is important to be informed about what boundaries this may inflict in terms of guaranteeing a specific SLA. For example, if a service that is under strict compliance rules needs to scale, the public cloud is very relevant. For that matter, you should consider using something along the lines of AWS dedicated instances. Then it is up to you to keep promises to end users and have a better idea of what to expect from your environment as a whole.

Interoperability and Data Replication

An important question that will most certainly rear its head when moving workloads between environments and migrating to the cloud is: how portable is your application? How easy is it to move data between platforms? Will you need to continuously replicate the data so that it will be available in both environments? And how frequently will this need to be done in order to maintain your SLA? That being said, if your users are only entering your environment once a day, for example, replication will not be required on a real-time basis. In any case, manual implementation is time-consuming, which is why automated service migration and data replication between environments is key to maintaining a hybrid environment.

The Gap in Management Expertise

In order to successfully manage your environment, it must be monitored, secure, and highly available. The tools and expertise that are needed to manage this type of environment on-premises are completely different from the management efforts required in the cloud. Nagios is a commonly used monitoring tool for on-premises environments while CloudWatch is a tool that discovers what is going on in your Amazon cloud deployment. Extracting the relevant information from monitoring tools and working out how to view your whole environment through a single pane of glass are the challenges faced when managing a cloud environment.

The same goes for security. The building blocks used to create a VPN in Azure, for example, are completely different than the process that is used on-premises, which includes using physical devices such as switches and firewall appliances. Management should be considered with compliance. Maybe the public cloud provider you chose complies to stricter rules than what you adhere to on-premises. While this isn’t bad, if you wish to create a successful hybrid cloud environment, it’s imperative to match your management capabilities in the cloud and on-premises.


Arguably, the main benefit of switching to cloud deployment is generating cost efficiency. Therefore, the main incentive for moving to a hybrid solution is the ability to leverage cost-effective capacity that you can utilize on an on-demand basis from a public cloud provider. However, costs can get a little tricky when migrating an application across environments, which can cause hesitation. If you’re using an on-premises, siloed environment to run your application, you probably already know the TCO. But, now that you are expanding the amount of web servers you have in the public cloud, you should know what resources you need, how many you have taken, if they make sense in terms of performance, and ultimately, what the costs and TCO will be. Due to the totally different cost structures, IT organizations face the challenge of aligning the vastly different environments and unifying their TCOs. Learn more from this use case that compares VMware and AWS cloud deployment costs.

How to Define Cloud SLAs

This last, but certainly not least, challenge is probably the most difficult one to overcome. After taking all of the other complexities that make up a hybrid environment into consideration, you still have to provide your users with a very structured and defined SLA. But when dealing with such a complex environment, what sort of uptime can you guarantee? What level of security can you guarantee? What audits will be required in order to maintain a specific compliance for your end users? After examining all of the issues mentioned above, including management, interoperability, cost, migration, and so on, the next challenge is to define your SLA in such a way that it is realistic, and you feel comfortable backing it up. Furthermore, when problems do arise, you will know exactly how to approach and deal with them, and have the peace of mind of knowing that you’re upholding your promise to customers.

Final Note: User Expectations

SLAs in the cloud are still being debated. End users are yearning for transparency into service provider environments and want to know what’s going on at any point in time along with expected remediation efforts (in case of performance degradation or downtime). Not offering transparency at these times could have more severe repercussions than not abiding by your promised SLA. And not being clear with customers could harm your reputation, especially since word spreads fast these days with social media. You may have defined your SLA well and abided by it, but if you’re not transparent with end users, you’re letting down their expectations.

Start Optimizing Your Hybrid Cloud Deployment

Start your 20-day free trial today to easily identify greater cloud efficiency opportunities and view your entire AWS deployment in one place. Gain full transparency, accountability, and control.
start free trial


Forgot Password?

No account yet? Register.

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- Filament.io 0 Flares ×