Scenario: a mission-critical application is having performance issues during peak business hours. App developers blame the storage. The storage team blames the network. The network admin blames the infrastructure. The cycle of blame continues until finally someone shouts, “Why don’t we just put it in the cloud?” Certainly, putting the application into the public cloud will solve all these issues, right? Right?! While this might sound like a tempting solution, just simply installing an application on server in the public cloud may not resolve the problem—it might open the company to more unforeseen issues.
Failure to Plan Is Planning to Fail
The
above adage is one of the biggest roadblocks to successful cloud migrations. Often when an application is looked at to be moved to the cloud, the scope of its interactions with servers, networks, and databases isn’t fully understood. What appears to be a Windows Server 2016 box with four vCPU and 16Gb RAM running an application turns out to be an interconnected series of SQL Server instances, Apache Web Servers, load balancers, application servers, and underlying data storage. If this configuration is giving your team performance issues on your on-premises hardware, why would moving it to hardware in a different data center resolve the problem?
If moving to the cloud is a viable option at this juncture of your IT strategy, it’s also time to consider refactoring the application into a more cloud-native format. What is cloud-native? Per the Cloud Native Computing Foundation (CNCF), the
definition of cloud-native is:
“(Cloud-native) technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
Cloud-native applications have been developed or refactored to use heavy automation, use containers for application execution, are freed from operating system dependencies, and present elastic scalability traditional persistent virtual servers cannot provide. Applications become efficient not only in performance, but in cost as well with this model. However, refactoring an application to a cloud-native state can take lots of time and money to make the transition.
The Risks of Shadow IT
If you’ve taken the time to understand the application dependencies, a traditional application architecture can be placed in a public cloud while an app is refactored to help alleviate some issues. But again, the process can be time-consuming. Administrators can grow impatient during these periods, or if their request for additional resources have been denied, can grow frustrated. The beautiful thing about public clouds is the relative ease of entry into services. Any Joe Developer with a credit card can fire up an AWS or Azure account on their own and have a server up and running within a matter of minutes by following a wizard.
Cool, my application is in the cloud and I don’t have to wait for the infrastructure teams to figure out the issues. Problem solved!
Until an audit finds customers’ credit card data in an AWS S3 bucket open to the public. Or when the source of a ransomware outbreak is traced back to an unsecured Azure server linked to your internal networks. Oh, and let’s not even discuss the fact an employee is paying for these services outside of the purview of the accounting department or departmental budgets (which is a topic for another blog post later in this series).
Security and compliance can be achieved in the cloud, but much like before, it comes down to planning. By default, many public cloud services aren’t locked down to corporate or compliance standards. Unfortunately, this information isn’t widely known or advertised by the cloud vendors. It’s on the tenant to make sure their deployments are secure and the data is backed up. Proper cloud migration planning involves all teams of the business’s IT department, including the security team. Everyone should work together to make sure the cloud architecture is designed in a way allowing for performance, scalability, and keeping all data secure.
Throwing an application at the cloud isn’t a fix for poor architecture or aging technologies. It can be a valuable tool to help in the changing world of IT, but without proper planning it can burn your company in the end. In the next post in the “Battle of the Clouds” series, we’ll look at determining the best location for the workload and how to plan for these moves.
