Cloud computing is so alluring. The public cloud economizes infrastructure resources and creates a scalable, on-demand source for compute capacity. Additionally, the cloud can be a strategic asset for enterprises that know how to migrate, integrate and govern deployments securely.
Apple co-founder, Steve Wozniak recently said, "A lot of people feel 'Oh, everything is really on my computer,' but I say the more we transfer everything onto the web, onto the cloud, the less we're going to have control over it."
In fact, over 70% of IT professionals worry about security according to an IDG Enterprise Cloud Computing Study.
Boiled down, security, access and connectivity are really issues of control.
As any prudent cloud user, the application has its own unique security features, such as disk encryption and port filtering. But do these layers of security features overlap or conflict? What happens to ownership after migration? Do solutions really have to be architected before and after deployment?
Take an application-focused approach to security from the beginning. The application-controlled, application-owned security layers will ease the decision to deploy, test, and develop in the cloud and save on IT training and time along the road.
Control of Security: Who Has It?
Part of the "magic" cloud providers and vendors supply is wrapped up in layers of ownership and control in the form of firewalls, isolation, and the cloud edge. Most enterprise application owners hope that these layers will cover the possible gaps in security after migration. Unfortunately most enterprises need security controls they can attest to and providers ultimately own and control these security features.
Unfortunately the needs and concerns of the cloud service provider are distinctly different than the needs and concerns of the enterprise cloud service user (the application topology deployed to the cloud and its owner). Security loopholes can exist because there are gaps between the areas users and providers control and own. The known boundary between what the cloud user can control and view and what the cloud provider can view and control is the root source of enterprise executives' concerns with public cloud.
The provider-owned, provider-controlled features (as in the cloud edge, cloud isolation), the provider-owned, user-controlled features (or the multi-tenant API controlled router/ hypervisor), and the app-owner, app-controlled features (OS port filtering and disk encryption) can be configured in an overlay network to give the user the ultimate control of security.
Application-to-cloud migration and software defined networking (SDN) capabilities out there offer additional, overlapping layers of control and security that span the spheres of the traditional cloud layers.
In order for cloud projects to succeed, IT executives need methods and tools they can attest to and can pass audit. Understanding the perimeter of access, control, and visibility between the application layer and the cloud provider layers is the first step to a less painful cloud migration. With this knowledge enterprises can then design a migration process that fits their use-case to deploy application topologies to the public cloud in a secure and controlled fashion.
Three Migration Rules We Recommend Breaking
Today's migration "rules" create more hurdles than solutions. Rapid industry changes, lack of standard security approaches, and the confusion on the proper steps to cloud deployment cause enterprises to overlook the issues of application-level control.
In fact, application-centric concerns are not even being addressed. Popular migration advice urges enterprises to tackle huge hurdles before and during migration, including deploying all at once, re-architecting before migration, and postponing the cost benefits of using the cloud.
Break the following three migration rules and it is possible to renovate more efficiently, capitalize on the cloud's economies of scale, and quickly, easily, and securely control enterprise networks and applications in the cloud.
Rule 1: Deploy all at once or not at all
Just as lemmings became extinct by all jumping in head first, most enterprises require time to analyze and adjust to new technologies before committing serious time and effort. Employees, customers, and shareholders would not be happy if companies jumped into new technologies without first proving value. Thankfully, enough enterprises, organizations and governments have already seized the benefits of the cloud's flexibility, cost savings, and connectivity.
Now, the challenge for IT professionals is to find the cloud architecture and provider(s) that fit their enterprise's needs and avoid having to reinvent the cloud to do so. With proven solutions in the market, enterprises can skip the bare metal to virtual to test cloud development life cycle. Simply deploy directly to any cloud environment, develop, test, then release to speed the time to market.
Rule 2: Re-architect before migration
Most providers and brokers want enterprises to spend time and effort to re-build IT systems and as a result re-learn/re-train before migration. Advice articles list migration steps of parsing applications, virtualizing, re-architecting and then migrating. Cloud pundits advise IT professionals to be wary of all cloud security and take valuable time to renovate before migrating - which will slow down the process and postpone or even wipe out the financial benefits of the cloud.
The traditional datacenter has too much knowledge flowing in a vertical direction from application to infrastructure and infrastructure to application. Migrating to the cloud before the renovate, design, or innovate steps can cut down on the upfront hassle by removing the burdens of re-architecting and re-learning skills before migration. Saving time, IT resources, and forgoing the arduous re-training speeds up the process for migrating to the cloud and ultimately how the organization capitalizes on the cloud's flexibility.
Rule 3: Pay upfront for design and renovation costs
Why stop with the cloud's physical economies of scale when there are potential savings on the costs of IT overhead? The same time and effort put into saving "design economies of scale" can be used to save major overhead costs too. A single migration, rather than the process of backup, re-architecture, and then migration is more cost-effective. Why wait for cost savings until after migration when there is an option to realize faster deployment and speed to market?
The added customization and control needed to migrate in a logical set of steps puts the control and security solidly back into the application layer.
Enterprises will likely face a long, slow migration to the cloud but, with the tools to capture the efficiency of migrating through logical steps before designing, the process can be significantly less painful. The application-controlled, application-owned security layers will ease the decision to deploy, test, and develop in the cloud and save on IT training and time along the road.
Conventional wisdom is missing the application layer importance of security and control in the cloud. So only one migration question remains - why take the stairs when you can take the elevator?
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
