CLOUD MIGRATION 
Cloud Migration
C2B2’s cloud migration service enables you to move your Java Enterprise applications to the Amazon cloud and benefit from reduced cost, improved performance and enhanced scalability.
Migrating systems to the cloud requires careful analysis and planning, the right architecture and a detailed migration process. For early migrations this needs to be supported by a Proof of Concept to identify risks, effective approaches and build team skills and confidence. Shown below is an overview of our approach.
Product vendors want to migrate you to the same products in the cloud and the big system integrators are interested in pushing their own private clouds. At C2B2 our architects and consultants can provide you with independent advice dedicated to ensuring your system goes live Fast, Reliable, Manageable and Secure.
Migration Assessment
The migration assessment commences with a discovery phase where application components are catalogued and analysed. An application will typically be comprised of components which are specific to the supported use cases combined with others which are shared.
The use case specific components may be a web application with user interface logic, HTML, images and JavaScript and this will depend on a range of shared components such as:
- Applications – a presentation tier application may consume web services from an ESB
- Business processes – an application may wait for a notification from a business process
- Data services – services may depend on each other e.g. composite web services or may depend on JEE services such as JDBC.
- Databases – a batch process may perform bulk transfer
- Identity store – accessed via LDAP this might be OpenLDAP or Sun Directory Server
This catalogue will support the grouping of components to be migrated and is captured in the C2B2 assessment tool as below.
At this stage we are trying to identify how loosely coupled the application is, the complexity of the dependencies and identify those which will most benefit from a cloud migration.
Having established a basic catalogue of applications, services and their dependencies we need to consider non-functional requirements such as:
- Licenses – can they be transferred?
- Regulatory, contractual and intellectual property – for example can the data go abroad?
- Security – what encryption is required for data in transit and stored?
- Performance, latency and bandwidth – what response time requirements are there? Do certain connections have specific requirements? Are there workload spikes?
- Data - how is it backed up, what are the long term archiving requirements? What upload, purging and cleansing processes are there? How can it be transferred out?
- Network – does traffic need to be segmented between management and production or for security?
Architecture and Planning
The architecture and planning phase is focused on understanding how we move the candidate application or services to the cloud. In reality this is an iterative process conducted along with the Migration Assessment activities. The two key questions when developing the cloud architecture are:
- How can I reuse my existing components?
- How can I exploit the cloud services?
We map the current architecture to cloud services and evaluate how much effort is required to make the transition and what benefits will be realised for any refactoring. The cloud offers a range of services such as auto scaling, high reliability and utility based pricing but some of these can only be realised with systems specifically designed to exploit them. We therefore consider the mapping of existing functionality to cloud based services as below.
| Type | Typical Current | Amazon Alternatives |
| Database | MySQL or Oracle | SimpleDB, Amazon RDS |
| Messaging | JBoss Messaging, HornetQ | Simple Queue Service Simple Notification Service |
| Backup | Tape | S3 |
| Provisioning | Manual | AMI boot process |
| Load balancing | F5 | Elastic Load Balancing |
| Network segmentation | VLAN | Virtual Private Cloud |
The alternatives do not have to be used as JEE applications can be deployed unchanged to the cloud and MySQL and Oracle are supported by Amazon. However, this is the time to investigate how cloud features can be exploited and this can form part of any Proof of Concept. Options enabled by a deployment to the cloud include:
- Data grids – what data can be cached?
- Distributed processing – can I exploit Amazon Elastic MapReduce ?
- Data representation and scaling - does it need to be relational? Is a NoSQL option such as Cassandra or HBase valuable?
- Auto-scaling – can I use Elastic Beanstalk? Should I use custom developed scaling?
- Edge caching – can I use a content delivery network like CloudFront?
In planning the migration approach we have two basic options:
- Lift and shift – migrate the whole application
- Incremental – split the application into components and move aver time
The lift and shift approach is optimum where the application components are tightly coupled or for example have stringent response time requirements between application components or services. An incremental approach is favoured to mitigate risk, when migrating a message based or asynchronous set of services or simply because the application has too many dependencies to move all at once. To pursue an incremental approach we need to identify the potential integration points such as in the diagram below behind the load balancer, web tier and middleware.
These integration points establish a hybrid cloud with some components remaining in the company data centre and some migrated to the cloud.
In formulating the hybrid cloud we need to consider and pros and cons of moving:
- the data to the processing
- the processing to the data
As we clarify the architecture we determine:
- Security - required security users and groups
- Virtual images - are suitable AMIs available, should I build my own, should they be minimal and configure on boot or fully loaded?
- What region should components be deployed to? Should I use Multi-AZ deployment?
- Storage options – choosing between S3, EBS and ephemeral, trading off availability, performance and transience
- Data upload – how will the data be upload to the cloud?
As we work through these questions we create a roadmap for migration which often starts with a Proof of Concept.
Proof of Concept
The proof of concept phase is an important step in mitigating risk and building the team capability. If we have redesigned applications and services to exploit cloud features, validation any design choices is important. We therefore select an architectural slice or significant functional grouping to assess the issues.
From the architecture and planning phase we should have a set of draft build instructions which specifies the tasks required to build the environment including an assessment of the required skills and tools. We proceed to create the PoC updating the instructions and at the same time developing the team capability. Following build we execute functional and non functional tests to assess the migration process and the environment build. Finally we feedback lessons learnt into the architecture and planning process in readiness for the full scale migration.
