Home » Posts tagged 'memcached'
Tag Archives: memcached
Five things your code can tell you about migrating to AWS – Fedr8
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