Moving to the cloud!
When You have decided to move to the cloud, what should You think about?
Tameshi migration approach
We take migration tasks very seriously and treat each Client very individually. There are no universal ways or scenarios that allow to perform migration tasks as out of the box solutions. We always require to meet with the end customer either via Virtual Conference or face 2 face meeting on Clients premises. During this initial meeting we analyze current situation and gather the requirements. Next steps vary on the application, technology and scope of migration.
- Choosing proper migration technique after client meeting and approval
- Migration Plan preparation and discussion – including Customer Test cases being prepared and cross checked with Customer / Application team
- Performing initial migration – PoC is shown, tests made and overall migration report produced
- PoC migration result analysis
- Making agreement on further actions that need to be done at this point (when configuration is valid; application tested, performing well and stable)
- Setting a cut over date
- Final migration & Cut over
Most common techniques that We - as a AWS Solution Partner use
This methodology allows to migrate everything from Your regular Data Center in the exact same state as it is nowadays. This approach is usually chosen in situations where You want to empty Your Data Center as soon as possible or have no documentation over how applications work and time is the key factor. AWS provides Us with several tools that allows Us to take this approach efficientl. Usually, after Lift & Shift, We propose so called “Transformation Phase” where We advice on how to make Your applications cloud aware and, if possible, how to optimize them to work in Cloud more Efficiently.
In order to take rebuild approach We should have access to proper documentation of selected application or it needs to be already part of CI/CD process. In case there is an existing CI/CD pipeline, We analyze it and advise, which components might be moved to AWS SAAS services to get the maximum benefit from AWS Managed Services. We show costs, risks and profits of such shift in components.
If application doesn’t use DevOPS model and doesn’t have any of CI/CD pipeline – We try to rebuild it based on documentation available. We give access to test environment under which We work with customer to validate if the rebuild approach was successful. After positive validation we agree on timeline, possible downtime of application and do the actual re-build in AWS. After doing cur-over we support application rebuild and advice over further possible enhancements.
This approach consists of steps that are taken to fully migrate to the cloud. At first, proper connectivity is established between customer data center and AWS. Either thru VPN or if possible thru Direct Connect. In case application requires very low latency connectivity, We always advice to choose Direct Connect between Client Data Center and AWS. During this approach We move some components to AWS while ensuring it has connectivity with on premise services. Let’s say You want to migrate Your intranet site that authenticates users thru Microsoft Active Directory but You are not yet ready to move AD. This way You can leave AD servers on premise and move intranet site to AWS.
The biggest benefit of AWS cloud is it’s elasticity
If You decide to run application with server that has 1 CPU and 500MB of RAM You just request it by Yourself and have it within seconds.
If You need to start a server with 96 CPU-s in order to perform heavy computing for 1 hour You just do it. Don’t need to buy it for the next 3 years to do Your PoC. Just create an instance based on Your needs for desired period of time and then pay few dollars for usage – that’s it.
Second biggest benefit of AWS is the fact, that it provides services (SAAS) that You don’t need to configure Yourself to have HA available. If You decide to have a MultiAZ RDS database which – in case of failure will heal itself – You just do it. Want to rollback Your database to some point in time due to critical query? – You just roll it back. No need to setup advanced systems and pay many different people to configure on premise infrastructure to fit Your needs. You just do it in AWS and have it in matter of seconds.
Thirdly, and the most importantly of them all: There are no limits in designing. You can achieve the same goal by using different tools in AWS. You don’t need a bunch of people preparing and analyzing models for your purposes. It’s up to You to choose one, test it, pay only a few dollars and in case it doesn’t fit Your needs – throw it away and try a different one. No need to over-invest. You just need a proper Partner that will handle AWS Cloud Infrastructure so You can focus on Your business.
First thing to consider when moving to the cloud is the price tag.
Cost of migration
Migration costs are dependent on the size of application You want to move, size of databases and downtime You are willing to accept.
If Your application is simple and consists of database server + some stateless application servers with good overall documentation and You accept certain downtime – migration is “as simple as possible”. If Your application has dependencies with different applications, consists of multiple database servers and multiple different components and You have no documentation on how Your application works, then it will take a bit more time to analyze, do a PoC, test everything and then perform the actual migration.
Typical time to migrate can take anywhere from 5 working days to couple of weeks depending on application complexity.
No matter what you want to migrate – one thing You can be sure of – We will do it well.
Cost of running in the cloud
In order to calculate cost of running application on the Cloud, You need to take number of factors into consideration
- Is Your application cloud aware?
- Does Your application allow to scale out & scale down based on outside factors?
- Does application require other environments than primary and do they require to be ran 24 / 7 / 365 ?
If Your application is cloud aware, then cost of running it in the cloud should rather be lower or similar to the ones connected with on-premise server. If Your application needs to be migrated using lift & shift methodology and it doesn’t allow scaling servers out, then it MIGHT cost around the same as running it on Your on-premise servers but You gain the elasticity over other components.
Usually, the biggest cost in AWS bill is connected with storage and compute. Tameshi helps You choose proper storage types and optimize compute utilization to lower or optimize Your bill in AWS.
Problems with cloud migration?
Typical problems with Cloud migration include – but are not limited to:
- Wrong migration technique
- Movement of application without proper analysis of its components and dependencies between them
- Wrong test cases that do not reveal application errors (therefore after final migration You can notice that application misbehaves)
How do we handle such problems?
Analysis of each client’s use case is critical for successful migration. Before We even start to think about migration We have numerous discussions with application teams and end users. We analyze applications as much as we can to understand how they work. We take advantage of AWS Application Discovery products and carefully analyze the applications to be moved. Cooperation with customer is the key to successful migration. We execute all migrations using automation. This allows Us to follow an automated script during migration and ensures that during the actual migration, everything will be replicated exactly in the same way as it was done over PoC / test phase.
Test cases should cover most typical end users behavior and need to ensure that all different application components are tested. In this way We get feedback on the way application works (even on premise) and whether it suffers from any issues. Test cases should also contain performance benchmarks that show possible bottlenecks and allow to compare how application behaved on premise and how it works on AWS.