Read the full pdf here: EDR – White Paper – PART 2
As I lay awake in bed with the smell of the Pacific Ocean air blowing through the house, my phone and iPad simultaneously start to alarm. I pick up my phone to find a local alert notifying the locals of imminent fires blowing with the Santa Ana winds, it says in bold, “Take Shelter or Leave the Area.” As a CIO of a large technology company I jump into immediate action, the fires are far away from my home, but moving directly toward our data center and I think about the key operational and revenue systems under my purview. I start to put a plan together in my head; who do I call into the office, where is our DR and business continuity plan? Oh, wait a second, we migrated all of our key operational systems to the cloud last year, we no longer have a data center here in the Valley. What a sigh of relief, when it comes to our systems. Let me tell you about our journey to the cloud, hopefully, you can gain some insight and benefit from our experiences.
Our decision to migrate our tier-1 based applications were based on a couple of key factors. As a side note, a majority of these applications were from Oracle, this will eventually have a bend toward our cloud provider, stay tuned. Some of these factors were: Hardware refresh costs as well as the flexibility to have High-Availability (HA) and Disaster Recovery in different regions of the United State. Our hardware refresh cycle is approximately every 3-5 years based on the software requirements as well as the features and capabilities needed by the business.
The average cost for our tier-1 based applications hardware is in excess of 2.5 million dollars not counting the effort to install and configure these software stacks. Additionally, there are other soft costs taken into consideration before we embarked upon the Cloud migration; downtime, as well as business disruptions such as (Testing Cycles). A substantial amount of research was conducted prior to our decisions to start our cloud migration journey in order for our decision to be based on an objective fact versus that of subjective emotions.
By migrating to a cloud environment, it is clear that we would save 2.5+ million each hardware refresh cycle. The way a cloud provider manages these hardware refreshes is generally zero interruption and impact on the applications that are running. This is achieved by most cloud providers by way of and use of “Containerization” of the hardware layer. Containerization is defined as a form of operating system virtualization, through which applications are run in isolated user spaces called containers, all using the same shared operating system (OS). A container is essentially a fully packaged and portable computing environment.
Containerization in turn reduces and, in most cases, eliminates the need for testing of the applications due in part by the presentation of the VM’s under a container. Our next step in our decision process was to determine which cloud provider we should consider for our application migration. We decided to engage a partner to create a matrix and comparison to help us determine which cloud provider can give us the most flexibility, features, and costs savings. Our partner was able to achieve this task in under three weeks, once we defined the criteria and weighting. Based on the objective scoring outlined below Oracle (OCI) was the cloud vendor that was selected.
Our next step in our journey was to develop a business case with an ROI that contained both hard and soft costs related to the benefits of the migration. After this business case was developed, we socialized and submitted it to the CFO for budget approval. Once approved our next step was to identify a trusted advisor/consultancy that is versed in these kinds of projects, this step in ours and anyone’s journey is the most important component. This relationship with your partner is like a marriage, as you want to make sure you identify an organization that has the (Skills, References, and more over a similar work culture). Before you identify an organization to assist with the cloud migration some key components that should be considered as part of this selection are:
- Application(s) being migrated experience
- Detail Project Management experience
- Cloud Provider (AWS, Azure, OCI, etc..) experience
- Clear and well-defined SOW with measurable and obtainable objectives
Our partner/consultancy selection took some time, but once we landed on the selected partner our next series of steps were driven around the typical “Project Management Activities”. I have always had a philosophy of 75% planning and 25% execution of a large project. Based on these objectives it was time to kick the project off. Changes we experienced as part of our journey included the roles and responsibilities of each of my staff. Though this was expected, it was still a large organizational change. Based on new functions, I would suggest that as part of the change management component of your project that these new roles and responsibilities be outlined and understood. Some examples of these changes were based on the creation and management of environments. Where this function used to be divided up by area (Server, Storage, Network, Database & Application), there are significant changes as to who creates and manages each of these areas in a cloud environment. You can divide these functions as you previously did, but it is no longer necessary based on how environments are provisioned and deprecated. As an example, with Oracle OCI, and the use of their Cloud Manager tool a PeopleSoft or E-business administrator has the ability to provision or clone an entire environment Compute, Database, Network, Storage and Application) with relative ease. As with this one example, it is highly encouraged that these new capabilities and functions be mapped put and assigned accordingly. With our case, we created new policies to ensure the separation and management of these functions. This allowed us to take full advantage of these features while ensuring we adhered to our corporate policies.
Our organization has benefited in many ways by deploying these applications to the cloud. Some key capabilities we would have not otherwise had: High Availability, Disaster Recovery in different parts of the United States as well as better performance and analytics. Another benefit that we achieved as a byproduct of this project was increased resource capacity. This was not an expected result, but the ease of provisioning, managing, and maintaining these environments with delivered cloud tools has allowed for our resources to take on additional tasks. The average capacity increase by resource was about 22%, some resources had a higher capacity increase and some lower. This along with the benefits, some still being discovered, we concluded that this decision was not only a wise one from capabilities and cost savings perspective, but also from a business differentiator by giving us a competitive edge. Our next journey, soon to come will be leveraging some key PaaS (Platform as a Service) capabilities to increase our integration feature and functions of our on-premise, third-party, and cloud-based applications, stay tuned….