By: Andy Troup
Successfully assessing workloads and placing them in the appropriate private, hybrid, and public cloud environments can make or break a cloud strategy, enabling greater agility and cost efficiency.
In this series, I’m reviewing four key areas to look at when performing a workload assessment. Last time, I suggested a framework for classifying workloads as potential candidates for moving to a cloud environment. Next time I’ll look at the approach for assessing the costs and benefits of moving particular workloads to the cloud, and then in the final part I’ll cover stakeholder analysis.
For now, though, let’s think about service portfolio mapping and how to determine the target cloud service and deployment model for each candidate workload.
First Steps
Let’s assume you’ve established which workloads you’d like to put in the cloud. Now you need to establish a catalog of standardized services that will be placed in the cloud to offer to your customers, as well as to assist in your workload migration.
A service catalog may already exist. But if it doesn’t, this post shows you how to go about establishing one, and how it evolves over the lifespan of a migration project.
To do this successfully, you need to understand the impact that workloads have on the service catalog and vice versa, including:
- Placement strategy – where workloads can be placed & the impact of placements on the service catalog
- Workload strategy – how to fit workload analysis with placement strategy
- How to use the workload and placement strategy to build a service catalog
- How to use the service catalog to help with workload analysis
Defining Your Placement Strategy
Your workload placement and cloud strategy are based on trade-offs around cost, quality of service and risk.
It’s best to first establish what types of cloud services would be most appropriate to provide and build a roadmap of service types into your cloud strategy. This strategy should be very closely aligned with the requirements of your business partners to ensure you can service their needs when required. So you need to ask: what’s your service model?
- Infrastructure as a Service (IaaS) only? Offering IaaS services is the most common first service type for new cloud adopters. This is especially true when these adopters already have workloads running on their virtual infrastructure, as they have gained experience of offering virtual machines to their customers.
- Platform as a Service (PaaS)? This is typically a follow up to providing IaaS, as you can build on your lessons learned and the technology stack you have already created. However, if you have business demands for PaaS over and above IaaS, then this service type should be taken on board right away.
- Software as a Service (SaaS)? Whether you provide SaaS services is directly influenced by the business requirements that exist. For example, certain application environments might need to be upgraded/replaced and a logical replacement SaaS offering would need to exist in the marketplace. Initially, these SaaS services will more likely be procured from public cloud providers rather than hosting them yourself.
Then you need to formulate your deployment strategy to decide where those services should run:
- Private Cloud: (most common initially for IT) where dedicated cloud infrastructure is operated to provide cloud resources for a single organization. It may be managed by the organization or a third party and may exist on or off premise.
- Public Cloud: the cloud resources are made available to the general public or a large industry group over the internet and are owned by an organization selling cloud services.
- Community Cloud: the cloud resources are shared by several organizations and support a specific community that has shared concerns (e.g., educational organizations, government organizations). They may be managed by the organizations or a third party and may exist on or off premise.
- Hybrid Cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary technology to provide cloud resources that enable data and application portability (e.g., cloud bursting for load-balancing between clouds).
For the official definitions of both the service models and deployment models, please refer to The NIST Definition of Cloud Computing.
Assessing Workloads for Best Fit
To be sure that you select the right location to host your services, you also need to analyze your proposed workloads in more detail. In Part 1 of this series I provided some thoughts about how to identify and analyze workloads. Now that you have also established a placement strategy, you can start asking some additional questions:
Benefits:
- Will migration into the cloud give me the benefits I expect?
- Will this migration help me achieve my goals for cloud migrations? For example, will the service be more reliable, will it be more agile, will I reduce my overall costs?
Migration:
- How will the migration be performed?
- How difficult will it be? For example, if a large amount of data is to be moved, that move may not be achievable in the outage window provided.
- What challenges will you face?
Asking these questions might change where you decide to place your workloads and your approach to their migration.
- The workload placement might need to change due to particular functional or non-functional requirements.
- You might need to reevaluate your selection of cloud providers.
- You might need to renegotiate with your cloud provider.
- There might be a requirement to re-architect the workload.
- Risk of migration might be high, thus requiring additional remediation activities.
- The migration approach might change from being a migration to instantiating a new service from the service catalog.
- The migration might simply not be worth performing.
- The workload SLAs (if they exist) may need to be renegotiated.
Using Your Workload and Placement Strategy to Build a Service Catalog
By taking the approach I’ve described, you’re now in a position to start thinking about how the workloads you’re assessing will impact the offerings you want in your service catalog.
During the process, you’ll discover workloads that have attributes and functions that are in demand from some of your other customers. For example, you may find a LAMP stack application that contains the version of RHEL that is your standard within your organization along with versions of Apache, MySQL, and Perl that make this workload one that you’d like to offer as a standardized service to other customers. In that case, you would want to prioritize its migration and also take the workload and put it into the service catalog (after performing any clean up work that may be required).
By taking this approach, you are ensuring that your org’s cloud service catalog is being populated with the best-of-breed workloads that have been deployed into your environment.
Leveraging Your Service Catalog to Analyze Workloads
Whether you already have a service catalog for your cloud services or are putting it together while performing migration, you can work the other way around, and leverage your catalog to analyze and migrate workloads.
When it comes to assessing workloads, you can start using the service catalog more and more as it grows to decide whether a migration is required or whether deployment of the service from the service catalog would be a better approach to provide you with a best of breed implementation based on your agreed standards.
Also, depending on your deployment strategy, you may have a number of different potential destinations for your workloads, with each having its own unique service catalog. Your goal should be to mask the complexity of all those catalogs by presenting a single enterprise service catalog to the users of your cloud. This puts you in control of the destination for all the workloads being instantiated into the cloud.
Finally, you’ll be able to compare the requirements that you have for each workload against the services you’ve established for it in the enterprise service catalog. You’ll get two possible answers:
- A component exists within the enterprise service catalog that matches the requirement.
- The service might be provided from the public cloud.
- The service could be already within the private cloud service catalog.
- No component exists within the enterprise service catalog that matches the requirement, i.e. neither service provider or the private cloud provider have this workload within their catalog.
- You might want to develop this service within the private cloud and add it to the private cloud service catalog.
- You may choose not to develop this service within the private cloud.
For a private solution, you can test which workloads fit the service catalog you have defined and potentially alter the catalog based on your results.
For a public or managed solution, you would need to understand which workloads fit the technical and nonfunctional requirements of your targeted public or managed cloud.
For all services, you will want to consider any service-level agreements and penalties for noncompliance that might influence price or cost.
Set For Life
As you can see, over time, the service catalog will mature and feature more and more services within it that you have accepted and that are properly compliant with your organization’s policies.
Review:
To create a service catalog that evolves over the lifespan of a migration project consider:
- Placement strategy – ask where workloads can be placed & the impact of placements on the service catalog
- Workload strategy – ask how to fit workload analysis with placement strategy
- Use your workload and placement strategy to build a service catalog
- Leverage your resulting service catalog to help with workload analysis
If you missed part one of this series on identifying and analyzing your workloads, you can find it here.
Check out our list of blogs on workload migration and stay tuned for Part 3, where we’ll look at cost/benefit analysis.
Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.
