Home » Posts tagged 'lift and shift'

Tag Archives: lift and shift

NCSC cloud anti-pattern #4: Don’t build an ‘on-prem’ solution in the cloud – Fedr8

NCSC cloud anti-pattern #4: Don’t build an ‘on-prem’ solution in the cloud

Lifting-and-shifting (Rehosting) is perceived as the easiest, Occam’s Razor method of migrating applications from on-premises to the cloud. Rehost is the defacto standard migration method for large-scale migrations where time is of the essence. “Let’s get it done and finesse it later,” goes the refrain.

As long as you configure the cloud to be similar to on-premises then your application is compatible and requires no changes. Vendors will promise, “Just make the cloud look similar to on-premises then you can drag-and-drop your application from one to the other.” Painless, right? Not according to the National Cyber Security Centre (NCSC).

In their 2019 whitepaper, “Security architecture anti-patterns”, NCSC recommend *not* treating the cloud the same as on-premises. Like all good security recommendations, this is based on common sense.

It is a fact that when you lift-and-shift to Rehost your application to the cloud you will also:

  • Lift-and-shift the issues you had on-premises into the cloud.
  • Fail to exploit the advantages of the cloud.

It’s possible to understand some of your exposure to this anti-pattern. Using discovery tools to map your on-premises infrastructure and applications to infer how you might refactor and replatform for the cloud and build migration plans that do not include security anti-patterns.

You need two-perspectives to discover the anti-pattern

Infrastructure-centric tools only tell you the bottom-half of any application story because the application is an opaque entity to infrastructure tools.

Bottom-up infrastructure reports might only list the server name and its address on the network. Or, like the AWS Server Migration Service agent, it might list the processes and network ports inside the server.

This is the “edge” of the application, where it touches the infrastructure, it is not inside the application. You can discover that “MySQL” is running on “port 3306”, and they might even tell you that a Java application is running on the server (because a JVM process is running) but they can’t tell you what that Java application is doing:

  • Which database is it using, and how?
  • Is the application logging to local disk?
  • Is the application using on-server session management?
  • Is the application sending emails to an on-premises server?
  • Are there hard-coded IPs for on-premises resources?

This is where the application-centric Fedr8 Green Rain engine complements infrastructure tools and completes the picture by analysing the application code to answer these questions and more.

Replatform and refactor to fix anti-pattern #4

Each of these technical dependencies is an opportunity to implement the recommendations from the NCSC white paper to “use higher-order functions in the cloud”.

Cloud consultants use the Green Rain technical report in the early assessment phase to define work packages. For example, if a hard-coded IP is found, the work can involve understanding what that remote service is and if it’s critical or can be disregarded. Application owners also benefit because Green Rain reveals technical dependencies at the line-of-code level from inside the application.

In effect, Green Rain creates a joint perspective between infrastructure and application owners. This is missing from many cloud migration projects.

Green Rain is also used in post-migration to analyze the code of already-migrated applications. By discovering if they applications are exposed to the NCSC anti-pattern #4 it’s possible to uncover more opportunities to optimize the application for the cloud.

Application refactoring and replatforming is not just about fixing and mitigating security risks. Adapting your application to exploit the cloud can return significant benefits. Comic Relief reduced their cloud spend from £83k per month to £5k per month.

Getting started with Green Rain

Contact Green Rain and we can help you analyze your application whether it’s on-premises today or already in the cloud. You’ll get access to an experienced cloud and application migration consultant who can guide you through the two-step process:

  1. Analyze your application with Green Rain
  2. Use the Technical Report to build your own migration or remediation plan

More resources

Learn more about how Fedr8 Green Rain can help you.

Kelsey Hightower: Why modernizing at the infrastructure layer is half the problem – Fedr8

How Green Rain provides insights to the 6Rs of migration

Lifting-and-shifting virtual machines from on-premises to a cloud can treat the application as a fragile black-box.

To make this black-box operational in the cloud without adapting it means you have to change the environment — the cloud — to fit the black-box. This is great news for vendors like VMware because they specialise in “normalizing cloud” to look like the same everywhere.

However, it means your application is not adapting to exploit the cloud and you are likely missing out on big benefits. Look at Comic Relief who refactored their app to reduce monthly costs from $83,000 to just $5,000. That is not possible without opening the black-box and changing it.

The inimitable Kelsey Hightower of Google recently tweeted that migrations are lacking an application perspective:

The answer for businesses is to look at the code they own — not 3rd party products — and see if it’s cloud ready, or container ready and what their license exposure is.

The black-box challenge

Even if you know that you need to open that application black-box and adapt it: can you?

  • It cannot be assumed that the application is perfectly supported with in-house expertise in all technical aspects of the application.
  • It cannot be expected that the application documentation is complete and up to date. Expect missing, out of date and plain wrong documentation.
  • It’s not a given that you have the time or resources available to focus on reviewing the application.

Ideally what you need is a helping hand to get going with the application analysis. A new addition to your team that is an expert in analysing all modern application languages and knows about cloud, containers and licensing.

This new member of your team is called Green Rain.

Analyzing the application layer with Green Rain

Green Rain answers the “application layer” part of Kelsey’s tweet:

  • The application’s code is the source of truth: not just an interpretation in developer’s heads and the documentation.
  • By analyzing the code, Green Rain can identify technical dependencies that are risks and/or opportunities in the cloud.
  • A cloud expert takes the Green Rain application analysis to define the investment required at the application layer.

For example, the following screen shot shows some technical dependencies that Green Rain has discovered that requires application investment.

Bar chart showing the number of discovered technical dependencies by category

In the chart above, Green Rain is advising you to invest in the following to prepare the application for cloud readiness:

  1. Look at local DiskIO writes and consider cloud patterns to modify these to fit ephemeral and immutable virtual machines or containers.
  2. Make sure the email service is accessible from within the cloud, or migrate to a cloud mail service.
  3. Modify logging from local server to distributed cloud logging service.
  4. Consider moving from server-based self-managed database to cloud database service. Potential database migration.
  5. Consider moving from local server state management like sessions to distributed session management in the cloud to allow for autoscaling.

The key findings from Green Rain show you where the break-points are on the edge of your application.

That is, where Green Rain discovers your application is dependent on something that is commonly different in the cloud, it tells you so you can consider it and take action.

How to add Green Rain to your team

Green Rain is really easy to use. You can:

  • Use a Fedr8-hosted version
  • Get a virtual appliance to run on yours or your clients’ premises or cloud

All you need to do is contact us below and we’ll get you up and running in no time. You’ll get access to one of our cloud application experts to understand your situation, guide your analysis and help you build your unique application migration and remediation plan.

Comic Relief achieved 16x value with application-centric migration instead of infrastructure-centric

Comic Relief changed their infrastructure-centric AWS bill from £83k per month to £5k per month.

Their 16x cost reduction was achieved by refactoring their application to exploit the cloud. But not everyone is refactoring their applications.

Rehost is the most common cloud migration strategy (40%) of the 6Rs. Also known as Lift-and-Shift, is a bottom-up infrastructure-centric migration approach:

  • To Rehost you have to replicate the infrastructure topology from non-cloud on-premises to the cloud (networks, security, storage, compute). Then you black-box migrate an application to its new home (usually copying a virtual machine and a dump of the database from on-premises to cloud).
  • Rehost is like kicking the cloud can down the road because you still have work to do on your application to help it exploit the cloud.
  • Rehosted workloads can benefit from some cost optimizations such as forward-contract purchasing of cloud resources (Reserved Instances), that is a welcome optimization and can chop 20-30% off your bill. Surprisingly, many companies don’t achieve this and still pay the full-price on-demand cost of cloud.
  • Rehost = minimum change = minimum cloud value.

You will never achieve the same savings as Comic Relief by rehosting your applications to the cloud. A 16x magnitude of savings is only possible by refactoring your application.

In this post, we compare and contrast Rehost with Refactor and describe how Green Rain by Fedr8 can help you get the best of both worlds.

The benefits and drawbacks of Rehost

The benefit of Rehost is its simplicity.

It requires only an infrastructure-centric understanding of the applications and data. Because the application isn’t changing, it is perceived as getting to the cloud by the fastest, cheapest path. Rehost is popular for mass-migration “factories”, especially where there is a deadline priority (e.g. datacenter end-of-contract/life is coming up).

The drawbacks of Rehost are four-fold:

  1. You are migrating all the technical debt and non-cloud practices (e.g. scripts, tools) into the cloud.
  2. You are not optimizing for the cloud which means that massive-sized and under-used on-premises VM is replicated to the cloud. Yes, you can optimize, but often this isn’t done because people are scared to make changes during migration.
  3. You are not leveraging cloud-managed services. For example, you still run your own database or load balancer instead of letting the Cloud Service Provider take the strain.
  4. You still have work to do when you arrive. Because you haven’t doing (2) and (3) above, then you have more work to do to become “cloudified”.

All of these drawbacks incur cost penalties.

Vendors like VMware recommend the Rehost approach because you need their software to make the cloud look like on-premises, and vice-versa. If you were doing Rehost from a VMware-dominated on-premises datacenter, then it’s tempting to migrate to VMware-on-AWS in the cloud to minimize changes, though there are higher costs to consider for this “ease of migration”.

Application-centric refactor

Refactor means modifying your application to use cloud services.

Evolving your application to a different architecture — for example, more microservices than monolith. There are new approaches to cloud applications called serverless. Refactoring can take considerable effort but the results can be fantastic, as Comic Relief found.

Read how Comic Relief swapped their monthly infrastructure-centric cloud bill of £83k for an application-centric serverless £5k.

Benefits and drawbacks of Refactor

Refactor means fully harnessing the power of the cloud.

The goal is to make your application cloud-native. It is impossible to be cloud-native without being application-centric. If you don’t understand your application, if you can’t modify it, you can never be cloud-native.

The drawback to refactoring is that you need the skills, effort and resource to evolve your application.

How Green Rain supports Rehost and Refactor migrations

Analysing an application for cloud refactoring with Green Rain

Bottom-up, infrastructure-centric cloud migration tools will analyze your infrastructure, help you configure and size the target cloud, and migrate your applications, data and databases to the cloud. But they do not understand your application code.

This is a migration blind spot, because:

  • You may be using session management that doesn’t work well in the cloud. In the cloud you need to use distributed session management.
  • You may be using just one SQL database but in the cloud you could use several types to suit the application (there are seven types of database in AWS).
  • You may be writing logs to local disk and saving state locally, which is an anti-pattern in cloud infrastructure where immutable and ephemeral servers scale out and in on-demand.

Know Your Application with Green Rain

If you want to refactor your application then you need to understand the code and what might break or what can be optimised for the cloud.

To Know Your Application means you need the application developer and maintainer to be available to contribute. Are they still employed? Is the documentation up to date? Do your talented software engineers want to work on a tedious cloud migration project or the latest cool whizbang widget?

Green Rain brings clarity to this blind spot by using a deep-learning engine to analyse your code repository and give you signposts about where you need to spend time refactoring.

The intelligent software inside Green Rain presents its findings through a user-friendly interface and tells you what dependencies are found and why they might break in a migration.

You can use Green Rain before and after Rehost and Refactor migrations to give you insights into your code and it’s dependencies on technologies that need to be addressed.

Next Steps

Learn more about Green Rain by Fedr8.

Talk to a Green Rain expert today and get a demo of what it can do for application-centric migrations. Your Green Rain expert can also arrange a trial on your applications on your premises to your cloud of choice.

I would like to receive Brand Communications updates and news...
Free Stock Updates & News
I agree to have my personal information transfered to MailChimp ( more information )
Join over 3.000 visitors who are receiving our newsletter and learn how to optimize your blog for search engines, find free traffic, and monetize your website.
We hate spam. Your email address will not be sold or shared with anyone else.