Hybrid Application Workload Management

Authors: William Dupley, Tom Scott

Introduction to Hybrid Application Workload Management

IDC (International Data Corporation) has described that there are three application development platforms[ii].

These platforms are:

1st Platform: Centralized IT, Mainframe.
2nd Platform: Decentralized IT, Lan/Internet Client.
3rd Platform: Democratized IT. Democratized IT is an environment that enables anyone to do the work that historically only IT did.

A Hybrid Application leverages the following capabilities:

Ability to integrate SaaS with back-office systems.
Ability to facilitate citizen Integration.
Ability to migrate production workloads from a private, public or community cloud to a separate private, public or community cloud provider on demand.
Ability to merge traditional deployments with software as a service (SaaS), across various cloud types, public, private, etc., using managed cloud resources

Most applications system today are now delivered according to a Hybrid IT operating model. Almost all are accessible via mobile devices and most back office systems are now integrated in some way to cloud services.

Following is an example of a Hybrid Application stack. There are thirty applications in this system. Seven are in the cloud, the reminder are the customer’s data center. There are four different communication protocols.

It is important to determine where each workload in the Hybrid Application Architecture is best facilitated in order to address location and integration challenges . Determining where each workload in a Hybrid Application Architecture is best facilitated has several challenges.

Introduction to Hybrid Application Workload Management Challenges

Challenge 1: How do you decide where an application workload should be placed?

The challenge in developing a Hybrid Application workload architecture is where should workloads be placed. The first step is to classify the workload for example, IT resources with a utilization that grows or shrinks constantly over time experience “Continuously Changing Workload”. By identifying this pattern on can apply the correct architecture to the deployment model. Determining what workloads should remain in a traditional data center, and what workloads should be migrated to a Cloud Service requires some in-depth analysis.

Several key areas of analysis must be considered when making these decisions. Here are a few:

Location and capacity of data movement.
Workload Patterns[iii] describe workload experienced by applications. Workloads Static as a process to describe workload experienced by applications. The service can be static, periodic, once in a lifetime, unpredictable, continuous changing, or high growth.
Deployment models employed by cloud providers, and the different deployment options for clouds need to be understood in order to architect the right solution.
WAN demands.
Seasonal or project-oriented capacity demands.
Country regulations.
The speed of new service development requirements.

A great many voices are calling out saying “place your services on our SaaS service,” or “develop your application on our platform services.” Others cry out “utilize our Infrastructure as a service, and we dynamically increase the supply of computing power as your application service requires it.”

All these options are viable and may be an excellent solution to your enterprises demand however there are many areas of impact on an application architecture that the placement of a workload can dramatically impact. This Impact could be mitigated by identifying the ‘Application Workload Pattern’. For example, if the workload describes what the application is experiencing. It then uses this to measure the form of application utilization, for example, the number of requests, server load etc. This is a good example of how an application experiencing this workload can benefit from cloud computing.

Application performance: The performance of the application service from the user’s perspective. If an application is slow from a user’s point of view, it is now considered down.
Response time to real-time decision making: The ability of the application to make a real-time decision based on the data being collected
Volume of Data: All Data must move over networks, the more data, the slower the performance, the higher the networking costs, higher capacity to meet demands.

Using these key KPI will simplify the decision process of application placement.

Challenge 2: How do you bring consistency to the application development process.

With so many ways to build an Application stack, it is now possible for each development group to develop the same requirements using entirely different approaches, tools, and SaaS services. The result will be extra costs and support services. There needs to be a solution to standardize the method and develop a standardized set of building block as that are developers utilize. Consistency in development applies to all aspects of development, i.e., code style, comments, tools, onboarding, creation of new services, etc. It also extends to product management, defining and tracking tasks, and using the same method should produce similar results. This is one of the most important aspects to be taken into account in the measurement methods of the software. For more information on how to bring consistency to the development process read on the Joint Information Environment (JIE)[iv]

Challenge 3: Don’t start thinking about application workload placement when you are in the Technical view.

The requirements of workload placement must be first defined in Business and Functional views. The Technical view further defines requirements such as the required response time (mobile access) and the decision time frame. Unfortunately all too often a technical decision such as: “We are going to use this SaaS supplier” is made before any requirements are actually defined. This can often lead to user dissatisfaction with the new system.

The historical approach of Application Workload Management is each component in the architecture is managed independently. Unfortunately, this approach will not allow us to achieve the new service levels we now must deliver. We need to control/monitor the service as a whole, and integrate the Application Workload Management processes, responsibilities, and architecture into one integrated system. To accomplish this, we need to make changes in the following three specific areas:

Hybrid Application Workload Management processes and roles
Application architecture patterns of use
Hybrid Application Workload Management architecture

1. Hybrid Application Workload Management processes and roles

The following graphic outlines the work, roles, and OACA domains that Application Workload Management involves. The overall responsibilities of the Shared responsibly model are as follows:

Facilitate integration of application delivery options to meet user workloads
Provision integrated platform as a service to power users citizen integrators and project developers
Provision of data and information services
Provide integration fabric that reduces complexity, enables self-service, and integration reuse

The Functions/activities required to accomplish this are:

Facilitate Workload analysis for optimized sourcing
Integrate SaaS with enterprise workloads
Managing API and Providing Artificial Intelligence
Provide local data storage for SaaS
Modernize workloads for agility cost-effectiveness
Ensure compliance to enterprise security policies
Enable the ability to scale up and down infrastructure and provision applications

To implement this model, the following changes are recommended

Each enterprise is unique; constructed of unique organizational structures, products, services, operating environment and technology infrastructure. Decisions for moving business functions, services and applications to the cloud are unique to each individual enterprise. Yet, as more and more enterprises move a business to the cloud, a general pattern for progressing through this change has emerged.

We do this by employing 4 viewpoints, delivered as a series of stages, in forming a strategy for hosting a function or a component thereof in the cloud:

Business View
Functional View
Technical View
Implementation View

Historically these groups operated independently. However, they now need to be integrated into one unified force that looks at the service as a whole. It starts by all agreeing that services need to be measured at the user’s screen and not on the individual parts. The overall Application Service Manager is responsible for coordinating all parties in this decision.

Appendix A of the “ODCA Digital Transformation to Cloud adoption considerations and methodology”(need URL for this) contains a set of questions that need to be considered in each viewpoint. These questions have been compiled based on the experience of many enterprises that have implemented cloud solutions. They were asked, “what had they wished they had known before they committed to a cloud solution or provider.” We recommended that you answer each of these questions as you work through your transition to a Cloud Operating model.

Method

There are a series of steps which flesh out these viewpoints, possibly as a multi-pass process, represented generically as follows:

Business View

Business View Summary Questions

The key to a successful move starts with understanding the business of an enterprise. Identify the vision of the company, its business model, strategy and objectives, to guide the teams’ decision making. Without a foundation in these objectives, it will be difficult to move to the second step. Complete Appendix A Business view questions in the “Cloud Adoption Framework”

Functional View

Functions Inventory and Functional view questions

The second step is a documented understanding of the functions within the enterprise that delivers the business capability. Leverage the OACA Cloud Maturity Model (CMM) in this step to consider the Enterprise capabilities per Domain. Complete Appendix A Functional view questions in the “Cloud Adoption Framework

Technical View

Application Inventory & Technical view questions

The third step is to inventory the applications and technology services across the enterprise. The CMDB is the best place to start. It should contain all the applications and relationships. Starting with an application inventory, applications should be grouped into classes based on size, complexity, dependencies and technology platforms. The OACA CMM is a useful tool for analyzing the current state of (for example) the Data, IT Architecture and Infrastructure environments. Complete Appendix A Technical view questions

Application/Function Mapping

Once all applications have been assessed, applications should be mapped to the functions they support.

Why Cloud

Now ask “Why Cloud?”
1. Assess why a cloud deployment would be beneficial for that application/ asset group/ asset portfolio, what considerations to list (such as speed to value, IT simplicity or currency, primarily leveraging the innovation or scale in the marketplace, for availability requirements, or financial drivers/ business scaling elements).
2. Not all apps are suitable for cloud deployment or can leverage the benefits offered by a service-based model. Based on the characteristics of the application, use those to complete a rough estimate of whether the application should move to the cloud or remain on-premise, whether there is a clear-cut provider choice, and whether it would likely be refactored or not (e.g., old technology, does adequate technical documentation exist, are there SME’s still at the company, etc.). Once “why cloud” is answered, we can assess the “how to adopt cloud” question – worrying about architecture, design for failure, cloud-aware architecture, licensing, etc.

Cloud Service Inventory

Having completed the business, functional and application assessments, the analysis turns to the cloud provider(s), and whether the provider(s) is/are external to the enterprise or not. An understanding of the cloud provider(s) products and services is critical for mapping applications and services to the optimal cloud provider services. It is important to keep in mind that there are now two development teams working, the provider team and the consumer team. It is important that they are in sync else one can build over the other.

Application Design

The sixth step is to work through each application in the inventory to document its design; ensuring that each application’s architecture, service dependencies, technology platforms, risk and compliance posture, and operational support requirements are documented.

Application / Cloud Service Mapping

With this detail in hand, decisions for matching a given application to a set of cloud provider services follows.

Implementation View

Application Migration Approach

The next step in the process is to determine the migration approach for each application. An application’s value to the company should be weighed against the effort, risk, and complexity of rewriting the app to take full advantage of the cloud. In some cases, a lift and shift approach, merely moving the application as-is to the cloud, is the best balance of risk/reward (even if this approach minimizes the value of hosting the application in the cloud). In other cases, if the application’s value to the company is sufficient and the risk posture low enough, it may be viable to support refactoring or re-writing the app to take full advantage of the cloud platform. The OACA Cloud Maturity Model (CMM) should be used in this step, to identify the impact on all the domains of implementing the new application ecosystem and to identify the additional work that will be required in those domains to successfully implement the operating model to support the cloud application ecosystem. Complete Appendix A Implementation view questions

Migration Plan

This analysis should be completed for each application in the application inventory. Having classified each application for its potential move to the cloud, appropriate project management processes may then be applied to develop a migration plan and ultimately deliver the migration of selected applications to selected clouds.

Migration execution

According to the migration plan, migration from selected applications to selected cloud services should be executed step by step. Eventually, the business function, which is used to be supported by a selected application, will be hosted by the new cloud services. This transfers the ongoing business function transformation from on-premise to the cloud.

2. Application Architecture Patterns of Use

There are many ways to deliver services today. Two issues need to be addressed to ensure that the best application architecture is implemented.

Issue #1: Favorite way: Developers become comfortable developing with specific tools. Sometimes developers do not want to try to use new tools or approaches and prefer to build applications using their favorite way. This is typical response however it is an impediment to adopting new technology.

There are two ways to overcome this resistance to change. The first is to implement a compensation program that rewards those will adopt and recommend new technologies and deployment approaches.

The second way is to implement a design review process step that requires all new applications be reviewed by a panel of developers to determine the best way to design the new app. This will minimize the “favorite way” pitfall.

Issue#2: Lack of Knowledge or multiple variations to the design approach. Lack of Knowledge is merely a developer doesn’t know how to implement an application using new technologies. Multiple variations are caused by each developer developing an application using a different set of tools. Both of these issues are addressable using standardized patterns of use.

Below is an example of a standardized pattern of use that explains how an application should be designed for a specific business category of applications

3. Hybrid Application Workload Management architecture

The next area of change is to the technical architecture of the application workload.

Below is an example of a technical architecture that reinforces a common Application Workload Management Architecture. This architecture looks at an application service as a whole, not just the individual components.

This architecture defines the standardized technologies that a developer can choose from to develop their new applications. In the manufacturing industry, the cost is driven down by publishing the standardized parts catalog that a designer can build a product from. This approach helps eliminate unnecessary variation in the complexity of the new product and help purchasing increase their buying power. This same discipline needs to be implemented in IT. Using this approach the overall application architecture will be more straightforward, and purchasing will have to ability to negotiate a better deal with Cloud providers.

Close

The transformation to a Hybrid shared resource Application Workload Management model requires new skills, new methods, new process steps, and artifacts to be produced by an IT organization. If done well an organization can rapidly exploit new technologies and bring new capability to market much faster than their competitors.

For additional information on the OACA cloud Maturity model go to: https://www.oaca-project.org/cmm40/

About the Authors:

William Dupley

Bill is the Digital Strategist for Liam Associates Inc. Formerly the Cloud Chief Technologist for Hewlett-Packard Enterprise Canada, Bill has provided Hybrid IT and IoT Strategic Planning advisory and planning services to over fifty Private and Public sector clients to help them migrate to a Hybrid IT Cloud Operating model. These transformation plans have helped both government and industry reduce the cost of IT, re-engineer their IT governance models, and reduce the overall complexity of IT. Bill is also a member of the Open Alliance for Cloud Adoption Team and has co-authored several documents on Cloud Maturity and Hybrid IT implementation.

Tom Scott

Tom Scott is currently a Principal Technology Architect at The Walt Disney Company. He is a future-focused technologist with over 30 years of technology innovation and experience. From being awarded a US patent for his work in mobile device news delivery to building innovative workflow solutions for broadcast television to architecting cloud solutions. He is also a member of the OACA Business Transformation Work group and has authored and co-authored numerous whitepapers and documents ranging from the published Cloud Maturity Model through Integration and Business Strategy for Cloud Adoption. As a pragmatic technologist Tom consistently implements technology that drives business.

[i] Photo by rawpixel on Unsplash

[ii] https://en.wikipedia.org/wiki/Third_platform

[iii] http://www.cloudcomputingpatterns.org/cloud_computing_fundamentals/

[iv] https://en.wikipedia.org/wiki/Joint_Information_Environment