IT Services for Enterprise Transformation
In Part II we discussed the strategy, architecture and roadmap for implementation. Here we elaborate the migration process. In this step “Making the Move”, the architectural specifications are used to enable the migration. The elements of the architecture should be moved based on the prioritized roadmap. Governance processes will guide the migration activities which are:
Establish the Environments
Create the provisioning templates for the instances. Determine if images will be “baked” or “fried” using automation tools such as Chef and Puppet, and cloud management tools like ServiceMesh. Instantiate cloud resources and provision the development test and production environments based on the specifications in the solution architecture.
Develop the Migration Components
As defined in the migration approach, rework the components specified in the architecture. All the lifting occurs in the development environment. Remember, for each component, think through the SLA’s and health aspects. Identify the method to determine if a component is healthy – and if not, document (or codify) how you will go about reviving the element. For each component migrated, there should be clear directions on how to maintain the item and ensure security, availability and responsiveness.
Migrate to Test
Once the components are built in the dev environments and tested, deploy them to test. There are multiple test plans, each serving a different purpose.
Move to Production
Conclusion
The migration step is last step in the process. All the lifting as defined by the solution architecture is done in this step and the entire solution is provisioned in its new target environment. The migration sets up the process of on-going maintenance and operations. By using a proper migration process, companies are able to significantly reduce their on-going operating costs. Proper migration costs more up-front, but typically pays for itself within the first year of operations.
In Part I we discussed the planning required in moving a legacy application to the cloud. Here we discuss the next step of establishing the foundation. In the planning phase, we began by understanding the driving factors for moving a legacy asset to the cloud. We conducted an asset analysis and gathered business and technical requirements specific to migration. We identified potential enhancements to the asset even though that may not have any bearing on the migration tasks. The foundation step consumes the planning requirements and produces a migration strategy and architecture. The key activities are:
Select the Target Cloud Environment
Identify a list of potential cloud solution providers. Understand the capabilities and limitations of the providers. Use criteria to evaluate vendors such as:
The process of selecting a service provider should follow the typical RFP/RFQ process.
Develop the Technical Architecture (Logical and Physical)
By now the current state, target environment and the requirements must be understood. Review the information gathered as a sanity check, especially if there has been a long gap since planning. Once requirements are signed-off, initiate the logical and physical architecture. The logical architecture includes:
Formal review of the logical technical architecture with the technical team including the application, infrastructure, business and the security and compliance architects, to poke holes and, test for completeness and resilience. Upon approval of logical architecture initiate physical architecture.
The physical architecture elaborates the logical view further and maps all the logical elements to the physical resources in the target environment. For example, if the service provider is AWS, the servers, services and components should be mapped to AWS provided machine images, resources and services.
Select the appropriate migration approach
Analyze the architecture to determine the best approach for migration.
Update the financial views with the cost information.
Develop the Cloud Bill of Materials and prioritize
Develop a dependency tree showing the order in which the architecture elements will be migrated. Translate the dependency into a road map. Hold gate to review and approve the final technical architecture, final cost, effort and time.
Conclusion
The foundation step is important in establishing the architecture and developing a migration strategy and roadmap. A technical gate review assesses the solution architecture and provides approval to proceed as appropriate.
This post is the first in a three part series that discusses the three step approach used at MomentumSI to migrate applications to the cloud.
The Planning begins with:
Identify the key business and technical drivers
It is important to understand the motivation in terms of the issues being addressed and the potential benefits expected to be gained. For example:
Identify all tangible and intangible benefits that should result from the migration. Some examples of benefits are cost elasticity and system availability. Translate drivers into the critical success factors and key performance indicators to help measure if the values are being realized.
Assess Legacy Asset(s) in Scope
After the business motivation is clear, it’s time to begin with the migration analysis. Inventory the assets to be migrated and capture their attributes i.e. infrastructure, application and databases.
Identify all the application environments and their attributes including dev, test, lab, prod, DR and HA. If possible obtain documentation on the current state application architecture. Review trouble tickets to reveal existing issues with the application and infrastructure.
Check code documentation for other types of dependencies with specific frameworks, libraries, third party tools etc.
Determine the existing volume of data that needs to be migrated.
Determine users and roles that have to be moved. Identify all application specific configuration files and scripts, hidden dependencies such as “cron” jobs, and mechanisms for audit, error management and logging.
Inspect existing policies, procedures, triggers that may have to be moved. Determine the true cost for running the application in terms of server costs, support, data-center (power, space, incidentals using existing financial models or some approach).
Gather Business and Technical Requirements
When analyzing a system, one of the hardest elements is understanding the motivation for ‘why’ something was delivered the way it was. To understand the business and technical requirements, the analysis has to go deeper:
Not all items listed above require to be captured in depth other than those most relevant to the migration. A business case must be prepared and a gate review must be held to assess the opportunity and provide approval to proceed.
Conclusion
The planning step is very important in ensuring that the required level of breadth and depth of requirements have been gathered, the key drivers are understood and all the asset attributes have been captured adequately to create and assess the business case. At the end of the Planning phase, the business should understand 1. the scope of the migration, 2. a rough timeline for migration and 3. an initial estimate to make the move.
Relational databases, the dominant model for data storage and management for the past several decades, are not a good approach for solving some of the problems faced by today’s business. The broad success of phenomenon such as social networks, social media, mobile usage and evolution of the cloud has caused an explosion in the volume and type of data that has to be stored and managed.
NoSQL databases such as MongoDB and Cassandra have risen to the challenge. They allow horizontal scaling on commodity hardware through sharding and MapReduce, support high availability and have the flexibility to handle semi-structured data. 10gen offers a ruggedized version of MongoDB to go along with their support and training offerings. Mongolab offers MongoDB in the Cloud on platforms such as AWS.
Not only are we using NoSQL to solve the problems associated with large data volumes and semi-structured data for startups and ISVs, but we are using NoSQL to solve old problems such as integration, analytics and content management for enterprises. For some customers, we are moving application environments that use relational databases to use NoSQL databases in order to support new application architectures and agile development.
Beware! Relational databases may still be adequate or appropriate for your specific scenario. In which case, migrating to a NoSQL database makes no sense. For those that are considering migration to a NoSQL database, we have created a video and a presentation to help in your decision-making process. The video is complemented by a more detailed presentation. We welcome you to leverage this resource and let us know if you find it helpful. As always, feel free to contact us in case you need any assistance with your NoSQL initiatives and/or to help you realize broader cost-efficiences across your organization by leveraging NoSQL. Enjoy!
We have made a number of changes to protect the ELB service from this sort of disruption in the future. First, we have modified the access controls on our production ELB state data to prevent inadvertent modification without specific Change Management (CM) approval. Normally, we protect our production service data with non-permissive access control policies that prevent all access to production data. The ELB service had authorized additional access for a small number of developers to allow them to execute operational processes that are currently being automated. This access was incorrectly set to be persistent rather than requiring a per access approval. We have reverted this incorrect configuration and all access to production ELB data will require a per-incident CM approval. This would have prevented the ELB state data from being deleted in this event. This is a protection that we use across all of our services that has prevented this sort of problem in the past, but was not appropriately enabled for this ELB state data. We have also modified our data recovery process to reflect the learning we went through in this event. We are confident that we could recover ELB state data in a similar event significantly faster (if necessary) for any future operational event. We will also incorporate our learning from this event into our service architecture. We believe that we can reprogram our ELB control plane workflows to more thoughtfully reconcile the central service data with the current load balancer state. This would allow the service to recover automatically from logical data loss or corruption without needing manual data restoration.
If you try 3 different calculators, you will get three different ROI’s. We did not find a single calculator that provides a truly independent, vendor-neutral analysis of costs involved in hosting Windows and Linux based servers in the public and private clouds over an extended period. So, we built our own! And now, you can take advantage of this tool to analyze your own situation.
Our calculator can be used to compare the cost of running a private cloud in your own or leased data center, or at a large public cloud provider. If you already have a data center and own hardware, private cloud might be the right choice. However, if you need new gear or more space, public cloud will likely be the less expensive option. Give it a try and see what your costs might look like!
Note:
a) Yellow Cells are fields that you have to enter [or use the defaults when given]
b) Blue Cells are calculated values that you can modify, if needed
c) Green Cells represent calculated values
As one might expect, the Windows Report and the Linux Report have the cost comparisons between the private and public clouds – over a 5-year period.
Assumptions sheet – This captures the assumptions behind the calculations. The information is related to processor and data center costs, and some of your usage patterns. You can change some of the numbers here in case you have more precise data.
AWS Costs sheet – For the public cloud portion of the calculator, we have chosen pricing data for AWS, the leader both in market share and with cost-competitiveness. The AWS pricing data shown below is from Dec 2012. Do not modify this sheet – although you might want to review the numbers.
Assumptions sheet – This sheet has the raw data that you must enter to be able to generate the Windows and Linux Reports. Again, enter data only in the Yellow Cells and if needed, in the blue cells. The three areas in which information is gathered is:
a) the base cloud – your data center and hardware requirments
b) OS, IaaS and PaaS requirements
c) Anticipated headcount changes
Windows/Linux Report – These sheets show you the result of the calculations – a cost comparison between hosting Windows-based [or Linux-based] servers on the public [AWS] and private clouds. The breakdown of costs over a 5-year period are detailed in separate tables for the two clouds.
