ITO Services Blog
Utilize ITO Services from HP to achieve insight into the latest thought leadership, as well as information about HP Infrastructure Technology Outsourcing at the HP Blog Hub.

Design to Scale in the Cloud – Part 2

By: Joost van der Vlies, HP ES Account Chief Technologist

One of the characteristics that make cloud unique is elasticity, the cPresentation1.jpgapability to scale outward and inward, based on demand. This flexibility, combined with pay for use, makes cloud technology very attractive.

But this is easier said than done. Scaling is not only an infrastructure play but for sure a play for the application on top of it.

This is the second part of a series of blog series of three around Cloud Scaling, and discusses When to scale.

Being able to scale provides the capability, but it is even more important to be able to define when to use this capability. Defining workload types are important, as well as the types of data which can be used in assessing the necessity to scale.

Let us first look at workload types, then the types of data, and then how to combine them to define ‘When to scale’.

Workload types

Regardless of cloud, analyzing the workload types in a solution should be a standard activity in a project or in a service delivery program when a solution is implemented. In a project it provides input in the solution design; during service delivery it provides input to additional measures to dynamically handle the workload, or even a new project to change the solution design to accommodate it.

We can roughly identify the following workload characteristics:

  • ‘On and Off’: Temporarily needs resources for a given job

  • ‘Growing’: Continue providing support with the right resources

  • ‘Shrinking’: Being able to reduce the resources to the level needed

  • ‘Unpredictable growth’: The workload spikes randomly

  • ‘Predictable growth’: The workload grows in known periods, such as festivities

  • ‘Stable’: No significant growth or shrinkage occur

It is important to identify these characteristics on a requirements level. This can lead to the implementation of foundational scaling services for use in multiple solutions. This will be elaborated in the third part of this blog series.

On a high level, two categories of data can be distinguished which can lead to a scale event: Technical and Functional.

 

  1. Technical data provides information on the usage of resource components, such as the amount of memory used, the load of the CPU, the IO load and so on. Depending on defined rules, a continuing 99% load of the CPU could be interpreted as the need to have an additional server to redirecting the load to. Care has to be taken for this, as it might also mean something like a non-efficient program. Originally, technical data was the primary means of generating a scaling request. Now, generating requests through functional data is becoming a possibility.

  2. Functional data provides information about what’s happening, functionally on an application level, such as the amount of specific types of transactions in time, the average response time on requests, the number of unique users, and so on. Depending on defined rules, an increase in response time could be interpreted as the server being busy and additional capacity is needed. The increase of specific types of transactions could be interpreted as the need for an additional environment to manage a specific type of transaction.

Combining the two types of data:

When a solution has a pre-defined workload type, technical and functional data can be used to monitor the situation and send events to scale or de-scale depending on pre-defined rules. Mostly, this will be an input for capacity management. In case of ‘unpredictable loads’, a business case should be made regarding solution versus cost. It can be very expensive to accommodate an automated scaling solution to support unpredictable loads, but when these are business requirements, a cost based evaluation should lead to the right decision.

The same applies for situations where the workload type is not fully known, or if there is a requirement to support any changes in workload type. In fact, for every workload type a cost based evaluation for a scaling solution needs to be done.

Ok, so we now know the workload type and we can identify if we need to scale based on technical or functional data.

But ‘How’ are we going to scale? That is the topic of the third part of this blog series.

Let me know your view on ‘When to scale’ and especially what makes it different in cloud environments.

The next part of this blog focuses on How to scale.

 

About the author:

My photo.pngJoost works as Account Chief Technologist, at the Enterprise Services CTO Office. In his current role he is responsible for technology strategy and innovation at a global retail account. He was a lead architect for the first release of the HP ES application cloud offerings. He has created several cloud webinars for HP, including one about re-architecting a current environment to a scalable cloud version. He has been an HP contributor to the Open Group, most recent as co-author of the Legacy to SOA best practices guide. Joost has a degree in Software Engineering, and is a Master of Science in a combined study of Information Technology and Psychology

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation