Data Center

Expert Advice: Considerations for Moving Data Center Applications to the Cloud

By Elevate posted 08-14-2015 16:40


“How does the large enterprise today determine which application should be taken to the cloud?”

I am often asked about my thoughts on bringing enterprise applications to the cloud. For most applications and enterprises, the answer is dependent on many factors, both technical and organizational.
Use these guidelines to determine if your enterprise is ready.
Like with most things in IT, a greenfield environment is orders of magnitude easier to take to the cloud. But the reality is that few enterprises have the ability to start from scratch. That leaves us in a universal brownfield environment, where humans and internal processes are the hardest problems to address.

Is Your Application Ready?

Given our enterprise focus, we will only consider the brownfield (existing application and environment) scenario for now. 
Application Suitability
The first point to consider is suitability. Is the app a viable candidate to consider moving? Theoretically all apps could be rewritten and migrated to platforms, not all apps should be. “Cloudifying” an existing enterprise app is fundamentally a migration problem. We (well, not me, but folks older and wiser than me) saw: Mainframes ? Desktop ? Client/Server ?


These evolutions and migrations have been ongoing for decades, and yet mainframes are still a viable and growing business.
Some apps that aren’t suitable today generally fall into this bucket because of design choices relating to high availability (broadcast/multicast on networking, shared storage on storage). While high availability can theoretically be architected around in a cloud environment (overlay networks and direct connect to existing shared storage), often the solutions create a Rube Goldberg IT environment.
Add to that the fact that support is ambiguous for overlay networks from cloud vendors and from software vendors whose applications will run on it. And direct connect short circuits much of the value of going to the cloud because you end up with an app or apps that straddle both traditional and cloud environments. 
To my sensibilities that’s overly complicated, overly complicated things break, and then I don’t get to sleep.
Architectural Readiness
Next we come to architecture. To paint with broad strokes, I would consider your app to be suitable for moving to the cloud if it is:
  1. IP unicast only
  2. Has no shared storage – local/NFS/object (again IP unicast )
  3. Has no physical dependencies – host cards/devices
  4. Already virtualized
  5. Latency tolerant
  6. Has a documented security posture
  7. Stateless
Statelessness is key for both scalability and availability. Cloud vendors can, have, and will experience outages and maintenance issues that can bring down virtual machines with little or no warning. Apps need to be able to withstand this. A common approach is to spread the application out over at least two data centers and put heavy reliance on some type of proxy or load-balancer. Most enterprise applications scale up today and are not fault withstanding.  
There are some broad brush questions you can ask yourself that can shed light as well:
  • If you lose your primary datacenter with this app does it stay running?  Why/How?  
  • If you lose X hosts tied to this app does it stay running?  Why/How?
Organizational Readiness
Finally, in a brownfield environment, are the app owners, systems folks, and support teams properly trained and staffed? There are lots of things that make the app work today in production, and they aren’t tied to inherent architecture from the enterprise software perspective:
  • Escalations
  • Security
  • Runbooks
  • Legal
  • Contract
  • Change management
  • Backup
  • DR
  • Monitoring
  • Logging
  • Analytics
The set is probably larger than I have captured, but is illustrative. Just because an app has been “built for the cloud” doesn’t immediately imply it can successfully run in the cloud under production loads for your business.
What to Take Away
Moving to the cloud is inherently a technical shift, but—like most large decisions in large enterprise environments—the harder problems are resolving people and process issues. Recognizing this up front and planning appropriately will help lower the risks of any app migration.
Part of the planning process is determining where to begin. Starting with a net-new, non-critical application is extremely advantageous as a path forward. Automating these deployments from day one helps to instill the processes that the most agile companies have adopted. The learning curve and customer demand are generally more manageable and tolerant of any bumps the team may encounter.
Another successful approach we have seen has an enterprise take an existing app with a fully automated lifecycle and bring that to the new environment. The automation in many ways can act as a safety net—both in bringing up the new environment and in rolling back in the event of catastrophe. It also forms an inherent rule book for the interdependencies among the enterprise systems.
All of this has relevance to us at Juniper as we help customers architect and build their next-generation networks. It is critical that we fundamentally understand the use cases and challenges facing the modern data center operations team. Adopting an “automate first” mentality across the data center operations teams has yielded great results here and at many customer sites. We would love to talk with you about it.


Written by Scot Junkin
Automation Architect, Americas CoE at Juniper Networks