Applications in the cloud – Cloud native vs migration

Graham Thompson   ·   Wednesday, May 19th, 2021

During a recent Certificate of Cloud Security Knowledge (CCSK) training session, I was asked a question about custom in-house applications running in a cloud environment.

The student’s concern was that all applications had to be developed on-premises and not in a cloud environment. They would build the applications in-house and then migrate them to a cloud environment.

This is most likely a fairly common scenario among large enterprises where they want to continue doing things the way they have always done them, but are being forced to start leveraging cloud services.

I’m going to attempt to address some of the larger issues with applications running in the cloud, from development to operations.

Please note: I’m restricting this discussion to applications running on virtualized servers that you manage. In other words, Infrastructure as a Service (IaaS). The question wasn’t Platform as a Service (PaaS) specific and quite frankly, adding all the possible permutations involved with PaaS would change this from a blog entry to the contents of a book.

Migrating applications

The big issue with simply migrating applications to run on a server in someone else’s data center is that you aren’t transforming anything from a technical perspective.

You’re simply moving an application from one server in your data center to a server owned by another party in their data center.

When “forklifting” (also called rehosting) an application, you do benefit from outsourcing the procurement and security of underlying hardware. The business also gains the ability to fully “write off” expenditures associated with running the application in the year the expenses occur instead of the common capital cost depreciation (allowance) model used by most governments around the world.

Then there is your data center.

Many companies are migrating to the cloud not to abandon their data centers.

In fact, I think it is fair to say the average company, especially large enterprises, will always have data centers.

But with the explosion of amounts of data and servers needed to collect and process this data, it isn’t unimaginable that companies are looking to extend the life and capacity of these extremely expensive buildings.

The more applications and servers you migrate to cloud providers, the lower your data center utilization rates are. I have little doubt that some companies are also looking to cloud to lower their carbon footprint.

This said, there are business benefits of forklifting, or “lifting and shifting” applications, but in no way are you gaining the full benefit of cloud by moving them without any changes.

Integrating cloud functionality into an application for a specific cloud environment (replatforming) can reap many benefits such as agility the cloud is world renowned for.

Bottom line is this: Unless you build applications with a cloud native approach, you aren’t going to reap the full technical benefits of the cloud. You might even be unimpressed with the issues you may run into.

The Cloud Security Alliance Guidance (page 7) states the following: “Taking an existing application or asset and simply moving it to a cloud provider without any changes will often reduce agility, resiliency, and even security, all while increasing costs”.

You’ll need to ensure your metastructure is secured, not just the application code alone.

What about migrating older applications to the cloud?

Is there any technical benefit in doing so?

Yes, there are potential benefits, even if you aren’t gaining all the potential benefits of cloud.

Migrating older applications can offer an opportunity to address outstanding issues, as changes will likely be required, such as authentication services.

Essentially, by refactoring the code, making required changes and addressing areas of opportunity to fix the codebase itself, you will likely improve outstanding issues within applications that have been known for a while, but there just hasn’t been time to get around to fixing.

Jurisdictional issues

When dealing with on-premises applications, you know where the application, and more importantly the data is physically located.

With cloud environments, this data may be located anywhere in the world. Some form of a Privacy Impact Assessment should be performed on the data stored to determine if there are any jurisdictional law issues that your company may face.

This will require a data flow analysis to be done to understand what data sets are stored in which jurisdictions if an application has multiple components in multiple locations.

Applications in a hybrid world

It’s nice to think that all applications are completely independent, but in reality, they likely won’t be.

Now the question is what about interoperability and latency if you have a system that runs some components in the data center and other components in a cloud environment thousands of miles away?

This is very difficult, if not impossible to test without actually having components running in a cloud environment.

Then, there’s the difficult consideration of encryption.

How do you deal with integrating encryption into an application to address data protection while it’s at rest?

Encryption of data in transit between components is another consideration. Ask your cloud provider if all data is encrypted by default within the cloud provider’s network.

Always remember that when you run one or more components of an application, you are creating a new trust boundary. This trust boundary may require additional security consideration since it is in a third party environment.

Cloud-native

You’ve likely heard the expression “cloud-native” before.

Cloud-native architectures are usually built using containers (such as Docker) and a scheduling/orchestration system (such as Kubernetes).

Neither containers nor Kubernetes are specific to the cloud, far from it. Approximately half of surveyed companies are using these technologies in their internal networks today.

A recent Capital One report shows that over 85% of senior IT leaders plan on expanding both the use of containers for more applications and expanding cloud-native application development.

Since we now know that cloud-native applications are supported by containers, what is generally specific to cloud that can be integrated into a cloud-native application architecture?

The two top things that come to mind are Function as a Service (FaaS) and Serverless Computing. What does the integration of provider-specific features add to your application architecture? A beautiful feature called lock-in.

Lock-in issues with cloud native

See, here’s the thing: The more provider-supplied services your applications consume, the more locked-in you are to a provider.

Does an architecture call for a provider’s Identity Management system?

How are you planning to replace that functionality?

Does this impact your disaster recovery and business continuity planning?

Basically, there are two degrees of cloud-native architecture: One that uses commonly supported containers and another that leverages provider services at the cost of varying degrees of vendor lock-in.

Another potential issue that may occur in a poorly governed application development environment is a jurisdictional one. Is it possible that an application is run in a different jurisdiction because that’s where the service is actually available?

Not all services are available in all regions. I would like to think this is unimaginable, but I’ve seen some pretty crazy things over the years.

Conclusion

So let me go back and answer the original question.

Building an application in-house, and then migrating it to the cloud shouldn’t be a problem.

Migrating a single system component of a larger system and thus creating a hybrid cloud application must be properly secured and will likely require refactoring.

A challenge may be addressing encryption (at-rest and in-transit). I’d also like to add this application component should be seen as its own trust boundary. This will ultimately dictate required controls to address application security issues.

As for cloud-native, this pattern is rapidly gaining traction. I think most companies will be there in a few years.

In the meantime, continue to build your applications internally and then migrate them to the cloud.

Just be aware you’re not getting the elasticity that is available in a cloud environment…until your company decides that built in the cloud, for the cloud is an opportunity worth pursuing.