Home » Posts tagged 'rehost'

Tag Archives: rehost

April 2020

Applications are the cogs in your business value stream, and applications are made of code. When it comes to planning cloud migration and application modernization for your business, it’s fundamental that you ask questions of your code.

Questions like

What will break?
What can I optimize?
What is the risk?
What is the effort?

These questions are not always answerable by developers or documentation. Why? Because it’s a fact of life that developers have moved on and documentation is incomplete. Without asking these questions and finding the answers, application modernization and cloud migration can be like flying blind in fog through a mountain range: it’s risky and the crash could be fatal or very expensive.

The top five common Green Rain discoveries

We repeatedly discover the same five technical dependencies that might break in the cloud out of the hundreds of gotchas that Green Rain can discover in your code.

These offer an opportunity to do things in more cloud-ready way:

User session/state management
Database technology
Third-party services
Local disk I/O
Logging

These are really common. There are a few hundred technical dependencies that the Green Rain engine has been taught to find in all the popular modern languages. It also knows whether these dependencies are critical for different clouds such as AWS, Azure and Google.

How does it work?

Green Rain isn’t a simple pattern matcher. It’s not a rules engine. Green Rain is unique in that it’s a learning engine. Green Rain uses what it’s learned to go through every file in your codebase and infers things like complexity, entanglement and dependencies.

Being a machine learning engine, Green Rain gets the majority of discoveries right and some things wrong; just like a human, but faster and with more accuracy. And unlike a human, it can analyse a million lines of code in an afternoon, with:

No guidance from you.
No customization for your organization or application.
No custom rules.
No configuration.
No learning curve.
No huge and clever human resources to find and allocate.

Green Rain works out of the box: just import and go.

But Green Rain doesn’t replace humans. The report it produces is interpreted by a human that reads the signposts that are discovered. The human expert then uses these insights to develop a remediation plan to migrate and modernize the application. This human is usually a cloud migration consultant.

Green Rain is doing what computers do best: complementing its human friends by taking on the complex, gargantuan and mundane and leaving the humans to do the clever stuff on top.

Let’s look at the five common findings in more detail.

1. User session/state management

Perhaps the most common application technique that Green Rain finds is session management. This is how your application tracks things for users as they use your application. However, outside of the cloud, this might be done in a fragile manner by storing state locally on the server – in memory or on local disk in temporary files. If the server bombs, then so do all your user sessions. Imagine using your banking app and being logged out halfway through making transactions.

Session management is always an opportunity to fix fragility and use cloud architectures like distributed session management. Why not use an external, fast, Cloud Service Provider-managed cache like Memcached or Redis and refactor your code to use them instead?

2. Database technology

I remember the days when the same RDBMS from the same vendor was used for everything. Nowadays, different database systems are used for different purposes:

MongoDB for NoSQL
MySQL for SQL
Neo4j for GraphQL

Do you know what your application uses? You could ask a developer or check the documentation… but is that possible, and will it be accurate? By analysing your code with Green Rain you’ll find things like this:

Green Rain has worked out that — in your Ruby application — it’s using MySQL and has listed down some key files where the code is using it, to prove it to you, write down to the line of code.

This app is definitely using MySQL — but so what? Using this, the human expert can decide:

Yes, this is the only database engine this app is using.
It’s MySQL so we can migrate it to the AWS and use their MySQL RDS instead of packaging our own.
If this was Oracle, maybe we could have looked at migrating from Oracle to AWS Aurora

3. Third party services

On-premises, behind those high datacenter fences and thick walls, there are often shared IT services that your application can rely on for things like email and authentication: but what happens if you move your application to the cloud? Things break.

In this case, the application is expecting to speak with a Microsoft LDAP server. Can it connect if the application is running on AWS and the LDAP server is being those high datacenter fences and thick walls?

Maybe you can create a VPN, or Direct Connect, or maybe use cloud-based authentication.

4. Local disk I/O

It’s normal for a long-living application on a long-living server to read and write from the local filesystem. And, of course, you can do this on virtual machines on the cloud. But should you?

Typically the things you find that an application is writing to the local filesystem are configurations and logs. These are all opportunities to replace them with more distributed, resilient and cloud-native technique. For example, instead of storing configs on the local filesystem, put it in something like AWS Parameter Store. It’s more secure and, well, just better!

5. Logging

If there’s one thing that’s probably, most definitely, needs to change when you move an application to the cloud, it’s logging. But how does your application do logging? Where is the logging code in your application?

This application was a enormous 562,000 lines and 6,100 files. Amongst all of that code, Green Rain has found 72 logging-related code dependencies in 34 files. Armed with this, the expert can start to work out the size of the problem and think of a cloud-based solution.

Logging is an important application subsystem that mustn’t break when you migrate it to the cloud: imagine your application not working properly in the cloud, but you aren’t aware because logging isn’t working either.

Logging is also a great opportunity for modernization and use modern observability techniques and cloud-based products for even better application insights.

Conclusion

Your application’s source code is the source of truth. It can tell you what can go right and wrong when migrating and modernizing on the cloud.

What Green Rain does is not feasible for a developer to do: go through thousands of files and lines of code and find hundreds of dependencies that may or may not break.

In our experience, an application’s documentation is often missing, incomplete, incorrect or out of date. You can find out some things from documentation, but how correct is it? Can you make decisions based on that kind of documentation?

It’s so quick to run a codebase through Green Rain it’s a no-brainer. It might confirm what you think you already know, and that’s valuable in itself. But it’s very likely that it will find a few things that you didn’t know. Armed with this uptodate and accurate knowledge, your experts can plan their way through the clouds.

Getting started with Green Rain

Green Rain can delivered in different ways: we can host it for you, or you can get a virtual appliance and run it on your premises or cloud.

Chat with someone at Fedr8 about your situation and how Green Rain might help and get a demo
Learn more about Green Rain
Watch some short Green Rain videos
Checkout Green Rain pricing

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

28th February 2020 / Leave a comment

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:

You are migrating all the technical debt and non-cloud practices (e.g. scripts, tools) into the cloud.
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.
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.
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...