Public cloud is more secure than private cloud, many specialists will tell you, and they are probably right. But that’s not the point as most companies going for hybrid environments. Let’s take a look at the predictions from Industry analysts:
- IDC predicts that more than 80% of Enterprise IT Organizations Will Commit to Hybrid Cloud Architectures by 2017, Vastly Driving the Rate and Pace of Change in IT Organizations.
- Hybrid cloud adoption grew 3X in the last year, increasing from 19% to 57% of organizations surveyed. (Building Trust in a Cloudy Sky: The State of Cloud Adoption and Security )
All in all, Hybrid Cloud and more generally hybrid environments are there to stay. Security and Compliance aspects leads most organizations to hybrid environments, but multiple scenarios are seen.
SaaS services is a no brainer
As SaaS services increase and as ServiceNow, Office365, SalesForce and Workday increase their dominance, more companies are integrating SaaS services in their portfolio of services. And it’s a no brainer, at least at first sight. The main question though relates to who owns the data and how can you get the data back in case you decide to change service. If you want to understand more about the implications of putting your data in the cloud, read “Cloud, data and your peace of mind”. You may also want to read “Compliance in Hybrid Cloud, the 5 CNIL recommendations” to understand the responsibilities of the Data Processor and the Data Controller. The questions you have to ask yourself ultimately are related to whether you are OK with your data hosted by a SaaS provider, if you are finding his security levels adequate to protect the data and if you feel you are not getting locked in while the amount of data you host with the provider grows. Alternatively you may want to look at mechanisms to either have the SaaS application pointing back to data you host or have a copy of the data in your own control.
Development and Testing, why not?
In a traditional world, developers spend a fair amount of time setting up their environments at different stages in the process. Cloud computing is a way to reduce that time drastically by allowing them to provision the required environment automatically. It also brings a side benefit as it enables the standardization of the tools used during development. Performing that activity in a public environment makes sense as it removes the need for the IT department to maintain a cloud environment specifically for development. If environments are provisioned only when needed and de-provisioned when the task is finished, cost can also be reduced. However this requires the developers to be disciplined and not keep unused servers provisioned.
Most of the testing can also be done in such environments as long as the data used for testing is anonymized, in other words that it does not reflect actual data that can be traced back to individuals. During the testing cycle the amount of infrastructure required can vary greatly, making testing in public environments cost effective. Indeed, performance testing may imply the use of a large server pool for a short period of time for example.
If the new functionality that is developed and tested is sensitive, it’s important the key stakeholders are confident this is done in the cloud, not that public cloud is less secure than private cloud, but it is often perceived to be so.
One good practice would be to maintain at least one copy of the source code repository on the enterprise infrastructure, being it in a private cloud or on a traditional environment to ensure nothing is lost if the connection with the public cloud is broken for one reason or another. But that is just good practice, isn’t it?
What about staging and production?
A good practice is to have staging and production environments to be as closely aligned as possible. Some will even tell you to do version control to ensure they are running the same software versions. The objective is to perform thorough final testing on the staging environment, identifying as many issues as possible to enable a smooth taking in production.
This implies staging and production environments should look alike. Does that mean they both need to be in a private or public cloud environment. Not necessarily, but this implies that, if production runs in a private cloud and staging in a public one, we use strictly IaaS functions with consistent software versions. Having both on the same platform makes it easier to ensure full compatibility though.
So, let’s start with production. In some industries, compliance issues may force production systems to run in a private environment. For example, in some countries financial and utility applications need to stay in country. If no public cloud provider can guarantee the location in-country of all versions of the application and its data, a private cloud becomes the de-facto norm.
Companies may want to keep CORE systems in private environments. A while ago I talked about positioning applications in light of their importance to the enterprise. You might want to perform that exercise and identify which applications can go to the public cloud in your mind. This would result in positioning both the production and staging instances of these applications out there. For the ones you put in the private cloud, the easiest is to have the staging systems located in the same environment. The advantage of using cloud is that you are no longer required to keep systems available just for the staging. You will however need enough capacity to be able to provision the largest staging environment you require. But if you plan your releases correctly, this may give you extra production capacity at month or year-end or during busy periods.
OK for hybrid, but what implications?
The discussion above demonstrates why most companies end up with a hybrid environment resulting from trying to optimize costs while maximizing business. This is particularly true for enterprises enabling digital transformation. There are a couple caveats though:
- Hybrid environments tend to be complex. You want to make sure your end-users have an easy access to all the functionality available. This means you’ll have to front-end the environment with a single portal for them to access what they need. You want the complex topology of the infrastructure and applications to be transparent to them. This is where the service broker concept applies.
- The provider of each service within your hybrid environment will ensure the security of his offering. But you are left with the responsibility to ensure those disparate secure environments are tied within one end-to-end security. It is up to you to ensure there is no place where hackers can break in. This is probably worth another blog entry, but I just want to make sure you take end-to-end security into account.
- Compliance plays an important role in defining what date resides where. Although most compliance is related to data, some applications also require compliance. For example, here is a developer guide for HIPAA compliant applications. It shows you what you need to do to be compliant.
When designing your hybrid IT environment, there are many points you need to take into account. Look at your application portfolio in two dimensions, application classes and environment type (dev, test, staging, production) and think through security, compliance, but also the economics and the requirements prior to decide where to position your application. Doing this takes time, but it will save you a lot of time and effort later on and keep you out of trouble. That’s worth thinking through those different aspects, isn’t it?