Journey to the Private Cloud

Journey to the Private Cloud

Siddharth Jaiswar

Principal Architect, Syntel’s Cloud Labs Syntel Limited

Building No. 4, Mindspace Thane Belapur Road, Airoli, Navi Mumbai,

Maharashtra, 400708, India

Yusuf Rangwala

Technical Architect, Syntel’s Cloud Labs Syntel Limited

Building No. 4, Mindspace Thane Belapur Road, Airoli, Navi Mumbai,

Maharashtra, 400708, India

ABSTRACT

Cloud computing is all the rage today. As an innovative model of using and delivering IT and business services, the hype around cloud computing also brings in a lot of confusion, which may deter the overall adoption to cloud. With its various models - Public, Private, Hybrid and Community cloud - organizations have considerable decision-making to do in order to choose the right model. To add to the confusion, there is a plethora of cloud management platforms and vendors available for each particular implementation of the cloud model, which one has to carefully select. Implementing a cloud computing model is a major challenge for organizations that need to best leverage its vast potential to gain maximum results. Enterprises considering cloud computing need to take a holistic approach that would involve a new focus and method to ensure accessibility, resiliency and security. Like with any new technology, it is prudent to decide on the strategy and methodology of migrating business applications to the selected cloud platform. Moreover, the operational semantics of the application deployed on the cloud needs to be worked out as well. This paper offers important considerations that organizations need to reflect upon before beginning their cloud journey.

General Terms

Private Cloud Maturity Model, First Step: Assessment, Build Cost Preparing for Cloud through Consolidation and Virtualization and ROI Models, Moving to the Cloud, Making the Cloud Efficient

Keywords

Cloud Maturity Model, Assessment, Build Cost Preparing for Cloud through Consolidation and Virtualization and ROI Models, Moving to the Cloud, Making the Cloud Efficient

1.

INTRODUCTION TO THE CLOUD:

BASICS

With all the hype around cloud, it is difficult to understand just what the basic components are. In a nutshell, cloud computing as a whole is composed of three primary segments: IaaS, PaaS and SaaS.

IaaS, or Infrastructure as a Service, involves providing a virtualized infrastructure that can be scaled up or down depending on usage requirements without requiring prior investment in infrastructure. Amazon EC2 and Go Grid are some examples of IaaS service providers. IaaS is typically leveraged in a public cloud scenario where infrastructure providers have a large, organized, redundant and virtualized data center across the globe. Subscribers deploy their applications/data on these data centers and pay for the infrastructure they use.

PaaS, or Platform as a Service, involves provision of a software platform, which facilitates running a business application in an optimized and highly available manner in a cloud infrastructure. These platforms also come with their own set of administrative tools that makes provisioning and management of these applications over the cloud easier. PaaS offerings facilitate building scalable, reliable applications. Cloud Foundry and Microsoft Azure are some examples of PaaS offerings.

SaaS, or Software as a Service, involves hosting business applications that are created keeping a particular industry requirement in mind so that multiple organizations can use the same business applications hosted on the cloud without requiring application modification. In other words, business applications that are multi-tenantable, cater to needs of not just one but multiple enterprises and hosted on a cloud infrastructure/platform can be qualified as SaaS. SalesForce.com is an example of one such offering.

Each of these segments can be offered in the following topologies:

Private topology relates to Enterprise data centers which can be transformed to support IAAS, PAAS and SAAS. Based on whether the data center is totally owned and co-located in the enterprise, or managed by 3rd party or hosted by 3rd party, there are further categorizations of private cloud. However the commonality in all three types of private cloud is that there is a single enterprise using it and has complete control of how the cloud is configured and implemented.

Public topology relates to data centers owned by IT companies like Amazon, Microsoft, CenturyLink, etc. where all or some services of cloud are offered through an infrastructure owned by these providers. Users pay for their usage based on the billing options offered by these providers for the cloud usage. The data center is entirely managed and operated by these providers and users just use its services.

Hybrid topology refers to a combination of public and private topologies, where some services are consumed through a public cloud whereas some services are based on private cloud, or a duplication across both.

Clearly, organizations embarking on a cloud journey do not have to implement IaaS, PaaS and SaaS together. Implementation of each service is contextual and depends on multiple parameters. Moreover, each of these services can be implemented in private, public or hybrid cloud models, depending on an organization‟s needs.

2.

THE PRIVATE CLOUD MATURITY

MODEL

The below diagram depicts the various stages to be considered in the journey of an enterprise towards private cloud enablement.

Figure 1: Private Cloud Maturity Model

Assessment: Being the starting phase, an enterprise takes stock of its existing infrastructure assets, staff resources and other holdings to facilitate a cost benefit analysis based on the target cloud platform. A RoI model and high-level strategy document is prepared as the outcome of this assessment.

Consolidation: During this stage, opportunities for consolidation of IT infrastructure and budgets are explored and implemented.

Virtualization: All opportunities of virtualization of the IT physical infrastructure are explored and implemented.

Migration: Applications are selected for migration to cloud and ported to a reference architecture that is prepared for the private cloud platform.

Automation: In this stage the administration, management which includes provisioning of additional computing resources are automated, so that time and effort required for these activities are reduced by leveraging the automation opportunities offered by the cloud platform.

Optimize: This is the final stage where the first batch of migrated applications are offered for use to intended users and closely monitored to get usage metrics. The metrics obtained then needs to be validated against the cost benefit analysis done earlier and appropriate optimization steps need to be undertaken.

There will be different considerations and guidelines for each of the stages in the model above. Some parameters might be obvious, and could be considered earlier in the process than as listed in this paper. Our intention is to highlight some of these parameters to help organizations succeed in their migration to private cloud.

3.

YOUR FIRST STEP: ASSESSMENT

This signifies a preliminary stage that any organization that intends to consider cloud for its enterprise landscape will undergo. The primary goal of this stage is to assess what exists currently in order to have a view of the overall enterprise landscape. This stage in itself does not signify any improvement in the maturity model, but is more of developing a baseline for subsequent stages. Assessment also provides the organization with:

 Strategy Inputs: Comprehensive picture of the enterprise and parameters that can be considered for

future stages. For example, utilization numbers are used for consolidation and virtualization phases to optimize infrastructure usage.

 Performance Benchmarks: This stage also provides the necessary baseline numbers in terms of utilization and performance to be measured against after migrating to cloud.

 Cloud Adoption Roadmap: This stage will provide the overall strategy for migrating to cloud, which can include decision on what platforms and offerings to select for migration, the roadmap for applications to be migrated, and the feasibility assessment of moving to cloud.

3.1

What to Assess

To prepare for the cloud journey, it is important for an organization to assimilate the right information. This section provides guidelines that will help evangelists collect the key data points.

In general, you must collate a comprehensive list of infrastructure assets including applications in the enterprise landscape. Though quite elementary, this is something that might not be created or updated due to various reasons ranging from employee turnover to deadline pressures. The following information should be reflected upon:

 Utilization levels

 Performance benchmarks

 Application infrastructure inventory

Collecting utilization levels for infrastructure on application basis will help primarily in scenarios of consolidation, as well as to predict cost savings. Overall, utilization parameters should include:

 CPU utilization (average and peak)

 Memory utilization (average and peak)

 Disk storage utilization outside of databases

 Database data files and predictive database growth

 Database log/transaction file sizes and truncation frequency

 Network utilization

Performance benchmarks for each of the applications will assist in developing the right SLAs on the cloud. Generally, it is advisable that the performance benchmarks include:

 Average performance numbers across three performance testing cycles

 Peak usage performance numbers

 Stress performance numbers

Additional information would include outage related information, maintenance schedules and usage patterns.

Lastly, an application infrastructure inventory should be compiled to include all applications that are deployed and used in the enterprise. This is imperative to assess cloud migration compatibility. The following data points should be gathered:

 Technology platform that supports the application

 Architecture layout

It is always useful to envision the overall architecture of the final private cloud environment. When building the strategy, a good idea would be to build a private cloud framework. This could be similar to the following:

Figure 2: Reference Cloud Architecture Framework

Though very nascent, the idea is to identify the basic building blocks for your private cloud. As indicated above, the following components can be included in a framework

 Virtualized Infrastructure proves as a base on which the entire cloud is erected.

 The cloud fabric would contain the application and the platform part of the cloud. On a basic level, we will have the following:

 Management Fabric, which should take care about the monitoring, provisioning and management of the cloud.

 Communication Fabric, which will accept requests from applications for compute, as well as make the requests to invoke application APIs. This will provide the scalability to the cloud.

 User Applications, which are the modified applications for the cloud platform.

 Security aspect covers the various measures and applications to make and maintain the cloud platform secure. This phase should also assess these. However, documenting the security considerations will be an approach paper by itself, and is hence not covered in this whitepaper.

3.2

How to Assess

For each of the above points, care needs to be taken to collect the information in the right manner.

In case of infrastructure, a monitoring tool can be extremely useful and easy to use for capturing runtime metrics. If such tools are not available or preferred, using traditional system monitoring graphs and counters can also be used to capture data during an average work period for the application. In case of applications, some general guidelines are:

 Include defining reference architecture in the strategy. This will help in standardization of the applications and ease the process of migration

 Evaluate if there is a need for assessing or refactoring the applications to be migrated for the cloud platform. This will be dependent on the cloud platform as well as the reference architecture

 Plan for discussions and workshops with all the stakeholders and application owners. They will be important in assessing applications with respect to business requirements and overcoming constraints for migrating to cloud.

4.

BUILD COST AND ROI MODELS

An important consideration for any new initiative is to evaluate its benefits in tangible terms. The cloud initiative is no different. In fact, it would be prudent to make an assessment on how this migration benefits, and if it is actually worthy of making the necessary changes. The cost and RoI models enable you to assess these benefits before migration of the applications to cloud. They also provide pointers indicating at what stage in the cloud model an organization can get the maximum value.

4.1

Cost Model

A cost model would provide an idea of what it would incur to migrate your application to a private cloud network. This module helps calculate costs of existing resources as well as projected costs in the proposed cloud environment. When you develop a cost model, here are some of the things one should keep in mind:

 Migration Costs: This should include personnel costs and cost of efforts to migrate your infrastructure onto a private cloud.

 When considering infrastructure costs, it is important to factor in costs of additional infrastructure purchase such as routers, switches and other network gears, in case of limitations in the existing infrastructure to cope with increased traffic that the cloud is supposed to handle.

 Also consider the cost of additional software and maintenance expense to run the cloud such as hypervisors for virtualization, etc.

 Cost of application migration to port the application to the cloud platform need to be considered.

 Do think of costs for additional tools to migrate the applications

 Operational Costs: Operational costs would include the actual costs of maintaining the private cloud network. This would include

 Server Cost – including network

 Software Cost  Facilities Cost

 Real Estate Cost

4.2

Benefits

etc. The following parameters should be considered when calculating the benefits:

 Reduction in resources to be brought for further expansion, if the private cloud is providing additional resources due to optimized usage

 Reduction in efforts to manage the resources, which may result in reduction in manpower, or shift focus of manpower resources to other areas.

 Optimized power consumption and cooling

 Optimized utilization of office space

Apart from these, the following non-tangible benefits could be considered:

 Increase in productivity of employees by the use of the application on the private cloud. This due to improvement in performance, or due to the change mandated by the cloud environment, which results in lesser downtimes/errors.

 Ease in the management of physical resources due to automated processes of the cloud.

 Faster time to market in rolling out new products and services. This can be measured by estimating the revenue/profit earned between the time for rolling out the application in an on-premise environment and for rolling out the application on cloud.

 Increase in responsiveness to sudden or unpredictable peaks by way of automation in terms of SLA misses or the reduction in additional hardware to be provisioned.

4.3

General Considerations and Guidelines

Every enterprise has its own unique architecture and requirements. Though most cloud platforms do provide some kind of a cost benefit calculator, it is seldom the „One size fits all‟ case. A detailed cost calculation and benefits calculation would provide tangible measurements for measuring the efficiency of applications on cloud. It is also advisable to lay down best practices of implementing the cloud to ensure that the RoI calculation is appreciated.

Based on Syntel experience, the following strategies can be considered to achieve a higher RoI:

 If the current application is not co-located, and the requirements do not inhibit it, co-locating your infrastructure for your private cloud may result in lesser burden of management of physical resources. A dedicated IaaS vendor can come in handy for this.

 Cloud bursting to public clouds to handle unexpected peaks from your private cloud can be considered for non-mission critical applications, in order to have minimal impact to mission critical applications, as well as savings in terms of procuring additional hardware to manage these peaks within your private cloud.

 Moving development and test environments with non-production data to a hosted private cloud (pay as you go) is generally beneficial as well as risk free. This ensures that these environments that are needed for a short duration do not incur complete procurement costs and continued operational costs.

However, for each of these, consider the entire enterprise scope, rather than limiting it to silo applications

5.

PREPARING FOR CLOUD

THROUGH CONSOLIDATION AND

VIRTUALIZATION

The first step towards moving to cloud would mean making your infrastructure efficient and flexible. This could be done either by adopting consolidation techniques, or implementing a virtualization solution, or a combination of both. Adopting the right strategy is dependent on the requirements of the applications in the enterprise. Apart from cost considerations to identify the infrastructure, the following are the key considerations of creating a consolidated and/or virtual infrastructure for the cloud:

5.1

Consolidation

On an average, the overall hardware utilization levels are often between 5 percent and 15 percent of the capacity of a physical server. By consolidating servers, businesses can increase overall hardware utilization and cut the cost through reduced rack space, electricity usage, and cooling costs.

5.2

Virtualization

Virtualization is the feature of dividing physical servers into smaller, manageable, and efficient virtual machines. Traditional deployments always restricted the applications on a single server, either due to heterogeneous environments (OS, software versions, etc.), or in order to ensure lesser impact due to failures, or a combination of both. Virtualization tends to address this by providing means of hosting heterogeneous environments on a single/multiple physical server, with clear boundaries and failover capabilities.

The Virtualization solution chosen for the cloud infrastructure should be checked for the following features:

 Resource Flexibility: Any dedicated physical server resources (like RAM, CPU etc.) in a virtual machine can be easily increased or decreased, with spare capacity coming from / returned to the host server. Virtual machines can be dynamically moved to another physical server, enabling large numbers of virtual machines to be balanced across a pool of physical servers.

 Guest Operating Systems: Ability to host many different operating systems and/or different versions of an operating system on a single physical server.

 Portability and Disaster Recovery: A virtual machine can be easily copied from one server to another, perhaps in a different physical location.

 Snapshot / Rollback Capability: A powerful aspect of some virtualization platforms is the ability to take a snapshot of a virtual machine for later rollback purposes. This feature can be considered as backup/restore at the machine level.

Similar to virtualization, the entire cloud infrastructure (storage, switches, network, etc.) needs to be determined based on a number of factors and needs. The complete discussion of these is out of the scope for this whitepaper, but needs to be considered during this phase of migration to cloud.

6.

MOVING TO THE CLOUD

deploy your applications on “as is” basis, but that might be far from the actual benefits of the cloud. An efficient cloud will only hold its value if its applications can share and scale in a truly elastic and reliable manner.

It is therefore recommended to employ a staggered approach and prioritize applications to be moved to the cloud to reduce the risks associated with migration. An important aspect of the transition includes application migration and the criteria for this depends on the cloud platform one selects. For instance, some cloud platforms claim no modification is needed to the platform, others need fine-tuning. Given below are some necessary parameters to be considered when selecting applications to private cloud.

 Type of Applications:

Parameters to be considered

 Knowing the application type. Is the application mission critical?

 Are there any legal issues of co-location of application and data in a particular place?

Guidelines

If the application is mission critical then its priority to move to the cloud should be least - simply because of the uncertainty that accompanies a new infrastructure and implementation. In case of the cloud encompassing multiple geographical locations, we might have to consider any legal requirements of co-location and confine the application to a specific geographic location within the cloud if possible, or not move the application to the cloud if not possible.

 Usage and Cost:

Parameters to be considered

 Understanding the Usage pattern

 Does the application have only internal users or needs external user support as well?

Guidelines

If the usage pattern is unpredictable with peak loads causing SLA misses then such an application would demand greater priority to be moved to the cloud to resolve the issue. However this parameter has to be evaluated along with other parameters before deciding the priority. Applications which have external users will have lower priority of migration to cloud versus that of internal users.

 Architecture and Design

Parameters to be considered:

 Does the architecture and design promote parallelism of operations?

 Is the application SOA based?

 Would there be lot of calls between on-premise applications and data?

 Is the application lacking in residential nature?

 Does the application depend on third party software/components?

 Does the application contain asynchronous processing?

Guidelines

In order for applications to leverage the complete benefits of a cloud platform, the application has to have components that are atomic, stateless, idempotent and parallelizable. Some of these parameters are already present if the application is SOA based. Hence the cost, time and effort required to convert an application that does not possess these characteristics would be an important consideration for moving an application to the cloud. Additionally, if an application is dependent on many other applications or third party components and those applications/components are not to be moved to the cloud then the bandwidth costs and latency introduced because of the interactions with these on-premise applications is an important consideration for selection of an application to private cloud. In case these third party applications/components had to be moved to cloud, then we need to migrate those application/components as well. Asynchronous processing based applications are better suited for cloud execution environments.

A proper assessment by architects should consider all the parameters and document their rationale for selection based on the parameters under consideration. After the selection of all such applications within an enterprise, architects should categorize them based on the business impact so that a roadmap can be prepared for their movement to the cloud with the applications with least business impact moving first. Depending on the application, the expected requirements and the platform, one might need to identify changes required before migrating the application. These changes might be required either to realize the complete potential of the cloud environment, or to even make the application operational on the cloud. This generally depends on the supportability of the cloud platform, or the PaaS offering selected.

Preparing a reference architecture based on the reference framework envisioned in assessment phase will help identify changes in applications easily. A cloud platform framework, which enforces the reference architecture, should be built to facilitate application migration.

All applications to be moved to the cloud should then be migrated to the reference architecture either by means of cloud platform framework or through manual migration. The following are the components which would get added to the reference architecture during this stage:

6.1

Guidelines during Migration

The following are some guidelines to follow during migration of applications to cloud:

 Deployment effort required for migrating applications and their updates needs to be assessed. Some platforms have simplified and automated processes and tools, whereas in other cases, you might have to develop scripts for the same.

 Factor in efforts needed for migrating data.

 Consider development environments provided by cloud platforms to facilitate changes in the application, quickly and easily.

 The use of accelerators that automate this migration process can also be considered if possible.

 A suitable testing framework should be employed or built. This will help:

 Measure the functional aspect of the application on cloud

 Collect metrics related to usage of computing resources and other non-functional aspects of the application

 Help validate the projected RoI

7.

MAKING THE CLOUD EFFICIENT

7.1

Automate

So your application is on the cloud! You are now reaping the benefits of a cloud implementation. But what if your business need demands a new application be included in the cloud? Or, what if usage or business needs increase and need more resources allocated than earlier planned? In conventional systems, this task is manually handled. In the next stage of private cloud implementation, the idea is to add automation to the cloud framework so that it becomes elastic, self-managed and reliable. The following are the primary areas where automation can be considered:

 Provisioning: In traditional environments, request for a server would take up considerable time that would involve multiple touch points, approvals etc. These can be simplified by making provisioning easier with a request to be filled online, and an image created automatically based on the request.

 Monitoring: Though traditional monitoring tools can be used to some extent, with a private cloud implementation, you would want to be more proactive and quicker to react to spikes, or failures. This can be done via monitoring the applications running for their health and in case of failures, promptly redirecting the call to another system on the cloud. At times, one might also have to put in place a failover step (i.e. in case the failover call also fails), and further more.

 Management: In traditional systems, upgrades and backups always require downtime and effort. In a cloud environment, one can ensure that their upgrades are carried out in an orderly fashion, ensuring zero downtime. This is generally accomplished by completing all pending requests on an instance, upgrading the system before moving to the next instance. In case of large instances, we can define territories to perform upgrades such that it has least impact.

All of these, if automated, would make a cloud self-healing and self-reliable.

7.2

How to go about Automating

The following features can be considered as a prerequisite for effective cloud automation:

 Standardization: Standard configurations are critical to improving quality and minimizing support costs and aide in automation. In case of physical hardware, this could mean virtual server slices that would have some predefined configuration. In terms of platforms, it would mean a virtual machine image that contains all the necessary setups and resources defined. With standardization, every request will only need to be mapped to one of the predefined, or standard configurations, rather than detailing out each requirement. One can apply standardization during the consolidation phase itself to ensure ease of implementation of the cloud.

 System Management Processes: With all the hardware consolidated, a solid system management process, something on the lines of ITILv3, would play an important role to meet the challenges of provisioning and system support. A well-defined and adhered to process can be easily automated versus something which has a lot of exceptions.

 Automation Scripts: Use cloud platform APIs to automate communication with the platform. It may involve scripting to connect the tools to the platform APIs.

 Dashboard: The dash-boarding capabilities need to be validated to know if they meet the enterprise requirements. If it fails to do so, consider enhancing it to include more metrics.

Figure 4: illustrates the components that could be added during the Automation stage:

7.3

Optimize

its proximity to the cloud application. After a predefined time period of fine-tuning and rechecking of metrics both from a cost and technical perspective, the next set of applications can be taken up for migration.

Cost models have to be revisited at regular intervals to check the efficacy of moving applications to the cloud.

8.

CONCLUSION

Cloud computing, in spite of its consortium of jargons, is definitely a worth-considering enterprise model. The considerations and parameters for a private cloud implementation are unique and contextual across all phases and stages of the cloud maturity model. However, the journey to private cloud adoption may not be complicated if one applies a consistent process based on Return of Investment model, Reference Architectures, a vision and a roadmap before embarking on the voyage.

The journey to private cloud requires a unique blend of technical skills, business skills and a comprehensive knowledge of cloud computing. The right mix of skills will ensure that all the considerations and best practices to achieve a successful cloud model are taken, thereby making the enterprise successful on the cloud.

9.

ACKNOWLEDGMENTS

Riaz Kapadia, Director – Client Solutions : For his insights and reviews on the overall journey and considerations within each phase of the Cloud Maturity Model.

10.

REFERENCES