Category Archives: Agile

The False Promise of Cloud Auto-scale

Go to the cloud because it has an ability to scale elastically.

You’ve read that bit before right?

Certainly if you’ve been involved in anything remotely cloud related in the last few years you will most certainly have come across the concept of on-demand or elastic scaling. Azure has it, AWS has it, OpenStack has it.  It’s one of the cornerstone pieces of any public cloud platform.

Interestingly it’s also one of the facets of the cloud that I see often misunderstood by developers and IT Pros alike.

In this post I’ll explore why auto-scale isn’t black magic and why your existing applications can’t always just automagically start using it.

What is “Elastic Scalability”?

Gartner (2009) defines it as follows:

“Scalable and Elastic: The service can scale capacity up or down as the consumer demands at the speed of full automation (which may be seconds for some services and hours for others). Elasticity is a trait of shared pools of resources. Scalability is a feature of the underlying infrastructure and software platforms. Elasticity is associated with not only scale but also an economic model that enables scaling in both directions in an automated fashion. This means that services scale on demand to add or remove resources as needed.”

Source: http://www.gartner.com/newsroom/id/1035013

Sounds pretty neat – based on demand you can utilise platform features to scale out your application automatically.  Notice I didn’t say scale up your application.  Have a read of this Wikipedia article if you need to understand the difference.

On Microsoft Azure, for example, we have some cool sliders and thresholds we can use to determine how we can scale out our deployed solutions.

Azure Auto Scale Screenshot

Scale this service based on CPU or on a schedule.

What’s Not to Understand?

In order to answer this we should examine how we’ve tended to build and operate applications in the on-premise world:

  • More instances of most software means more money for licenses. While you might get some cost relief for warm or cold standby you are going to have to pony up the cash if you want to run more than a single instance of most off-the-shelf software in warm or hot standby mode.
  • Organisations have shied away from multi-instance applications to avoid needing to patch and maintain additional operating systems and virtualisation hosts (how many “mega” web servers are running in your data centre that host many web sites?)
  • On-premise compute resources are finite (relative to the cloud).  Tight control of used resources leads to the outcome in the previous point – consolidation takes place because that hardware your company bought needs to handle the next 3 years of growth.
  • Designing and building an application that can run in a multi-instance configuration can be hard (how many web sites are you running that need “sticky session” support on a load balancer to work properly?)  Designing and building applications that are stateless at some level may be viewed by many as black magic!

The upshot of all these above points is that we have tended to a “less is more” approach when building or operating solutions on premise.  The simplest mode of hosting the application in a way that meets business availability needs is typically the one that gets chosen. Anything more is a luxury (or a complete pain to operate!)

So, How to Realise the Promise?

In order to fully leverage auto-scale capabilities we need to:

  • Adopt off-the-shelf software that provides a consumption-based licensing model. Thankfully in many cases we are already here – we can run many enterprise operating system, application and database software solutions using a pay-as-you-go (PAYG) scheme.  I can bring my own license if I’ve already paid for one too.  Those vendors who don’t offer this flexibility will eventually be left behind as it will become a competitive advantage for others in their field.
  • Leverage programmable infrastructure via automation and a culture shift to “DevOps” within our organisations.  Automation removes the need for manual completion of many operational tasks thus enabling auto-scale scenarios.  The new collaborative structure of DevOps empowers our operational teams to be more agile and to deliver more innovative solutions than they perhaps have done in the past.
  • Be clever about measuring what our minimum and maximum thresholds are for acceptable user experience.  Be prepared to set those CPU sliders lower or higher than you might otherwise have if you were doing the same thing on-premise.  Does the potential beneficial performance of auto-scale at a lower CPU utilisation level out-weigh the marginally small cost you pay given that the platform will scale back as necessary?
  • Start building applications for the cloud.  If you’ve designed and built applications with many stateless components already then you may have little work to do.  If you haven’t then be prepared to deal with the technical debt to fix (or start over).  Treat as much of your application’s components as you can as cattle and minimise the pets (read a definition that hopefully clears up that analogy).

So there we have a few things we need to think about when trying to realise the potential value of elastic scalability.  The bottom line is your organisation or team will need to invest time before moving to the cloud to truly benefit from auto-scale once there.  You should also be prepared to accept that some of what you build or operate may never be suitable for auto-scale, but that it could easily benefit from manual scale up or out as required (for example at end of month / quarter / year for batch processing).

HTH

Tagged , , , , ,

Agile Requirements – An Introduction.

I did a session today with the team at work around how Agile Requirements fit into the bigger picture of Agile project delivery.   The presentation is up on SlideShare so if you’re looking to bootstrap a presentation please feel free to use the contents.

Helping Your Teams To Success

I was going to write a big post about this but every time I come to work on it I find I spend more time that I intend to capture what is actually a fairly easy to understand set of principles that I’ve been lucky enough to pickup during my time working on software delivery teams.  So here they are:

Flexibility: a lot of people join teams expecting to play only one role.  While specialists can probably expect this to be the case, the rest of us should really be prepared to play whatever role is required depending on circumstances.  I’ve seen a lot of people who have been unprepared to show role flexibility where the result is that some aspect of the project delivery is negatively impacted.  Software delivery is not all glamour – there’s a lot of grinding leg work needs doing on any project in order for it to succeed.

Commitment: think about how many teams you’ve been on where you’ve had people who have contributed but ultimately their contribution is dwarfed by others on the team.  What commitment boils down to is doing the things you say you will do by the time you said you will do them (or otherwise early and clearly communicating why they won’t be done). 

Respect: pretty much all the best working relationships I’ve had (and continue to have) are based on respect.  If you approach all relationships you have with your team mates on this basis you will find that your team is far more successful than it could ever be otherwise.  Yes, if you are having challenges with other team mates around "101" concepts it can be a bit hard to proffer respect for them, however you should try your hardest to make it work and to find elements that you can respect. 

Communicate: be open and keep everyone across what you’re doing.  Be pro-active about communicating – don’t wait for someone to ask you for information.  The one proviso here is that you determine what is appropriate for others to be told.  I lean more towards over-communication – people will soon let you know if they don’t need to know the level of detail you are giving them.

Reliable: don’t be random.  Try to keep your behaviour the same as often as you can – people should come to expect you to behave in a certain way in a certain situation.  Some of being reliable goes back to commitment: do the things you say you are going to do when you said you will do them.  Delivery of any project is challenging enough without having team members going off-piste and doing ad-hoc work that was never on the cards.  Ultimately if people don’t find you reliable then you will struggle to be trusted and trust is certainly at the core of any great team.

Well I guess I could ramble about this topic ad nauseum and if you’re reading this far then I salute you!

As always, any discussion of teams and teamwork would not be complete without the obligatory Dilbert cartoon! 

Happy teaming, enjoy!

Tagged , , , ,