Category Archives: Data Centre

Fluffy white cloud computing – hype or here to stay?

Cloud Computing – Hype or Here to Stay?

Summary: Cloud computing is over-hyped but it is important and businesses will increasingly be run on cloud resources, both because new businesses will start up on the cloud and because existing businesses will slowly migrate onto the cloud.

The other day I read a review for an inkjet printer – the Lomond Evojet 2. Standard inkjet printers have about 4,600 nozzles on a print-head that moves back and forth across the paper. The Evojet has about 70,000 nozzles on a stationary print-head under which the paper travels, allowing for crisper graphics and faster print speeds, but at a higher cost of construction. It turns out, though, that over time the cost per printed page is quite economical and in many cases actually lower than competitive inkjets that may have lower up-front purchase prices. So what has Lomond done about this, and, in general, what’s a company to do when they have high purchase price but lower total cost of ownership? For a hint, let me digress even further, and then I’ll get to the fluffy white stuff.

A company once made drill-bits that lasted 5 times as long as their competitors’ drill-bits, but cost twice as much to make. Market research and real-life experience taught them that the average consumer, standing in the tools section of the hardware store, 9 times out of 10 would choose the lower cost drill-bit. This company should have stopped selling drill-bits and started selling holes! It’s a hypothetical example to make a point, but consider the very real example of Rolls Royce. You may think they sell jet engines, but they actually sell thrust, or hot air ejected out the back of jet engines, what they call and have trade-marked as ‘power by the hour’. Rolls Royce provides jet propulsion as a service, a remarkable and successful business model. They take on all of the up-front costs and risks associated with development and manufacturing, as well as ongoing costs for maintenance and spare parts. Clients avoid high costs for purchase and maintenance programmes, and can more accurately predict their operating costs. It’s a pay-per-use model where clients pay for the amount of thrust they consume. And if you’re still interested in the printer example, Lomond will provide you with a printer and charge you per printed page.

In business computing, not PCs, but data centre computing where organisations run their core business applications, there have been previous attempts to adopt this model. Some have been successful, like But most have fallen by the wayside, for many reasons that we’ll explore later in this article. But in the meantime, does anyone remember ASP? And no, I don’t mean Microsoft’s Active Server Pages. I mean “Applications Service Provider” which, for those of us who were in IT back then, was widely touted as the next big thing in computing at the tail end of the 90s. Although the Internet actually dates back to ARPANET in the 70s, it didn’t really pick up and become mainstream until the mid 90s with the development of the World Wide Web and the decommissioning of NSFNET, removing the last restrictions on the use of the net to carry commercial traffic.

I can’t find the original quotes on-line any more, after all it was 14 years ago, but I remember headlines like “ASP will dramatically change the way companies do business” and “I can’t imagine why any company would ever buy their own hardware or software when they can purchase business applications on-line for a fraction of the cost and hassle”. Well, I for one can imagine why they would continue to do so. Security and legacy integration are huge issues that need to be dealt with before a company will feel comfortable running their business on shared infrastructure.

Google Trends - ASPI love Google Trends. Since 2004 they’ve been collecting and indexing data about what people search for on the Internet, and now you can perform trending searches against a whole plethora of topics. This chart tells us what’s happened to ASP. Quite likely more of the hits against ASP are to do with ASP.NET than they are with Application Service Providers, but either way it’s dropped almost completely out of the public consciousness.

Now take a look at ‘cloud computing’:Google Trends - cloud computing

Basically nothing before 2008, peaking at the beginning of 2011, and now appears to be heading fairly rapidly in the same direction as ASP. So is that it for cloud computing? Probably not. Google Trends is just a tool that tells us what people are searching for and doesn’t necessarily correlate to what businesses are buying.

Amazon Web Services was on track to earn $1.5bn in 2012, now apparently accounts for 1% of global business computing, and has 70% market share in infrastructure-as-a-service. Their closest competitor is Rackspace at 10%, with everyone else making up the difference. Everyone else is Microsoft Azure, HP Cloud Compute, Google, Oracle, IBM, Dell and numerous others. It seems that hardware vendors are recognising that more and more of their customers want to buy holes as well as drill-bits!

Amazon pretty much invented the market back in 2004, and their cloud services now run hundreds of thousands of companies, including Netflix, Pinterest and Dropbox. Even organisations like NASA, Samsung and Unilever run some of their business on AWS. Thirteen employees built photo-sharing and social networking service Instagram on AWS and sold it to Facebook two years later for $1 billion, not bad for a company who didn’t have to buy any hardware or software.

But in terms of the global spend on data centre infrastructure to run their businesses, $1.5 billion is a drop in the ocean. So are we any closer to answering the question – is cloud computing hype or is it the next big thing?

Let’s consider for a moment the nature of business over time, and who buys compute infrastructure. New businesses are starting up all the time; certainly more and more new businesses are starting up directly onto cloud computing with no consideration for owning hardware or operating system software and all of the associated management bits and pieces around it. Existing businesses are doing what they do: changing existing systems, building new ones and rolling new ones in the door. More and more, however, the enterprise architects and solution designers in existing IT departments are considering their options for deploying at least some of the new stuff onto cloud resources. So I believe that over time we’ll see an increase in cloud adoption by existing organisations, but I don’t think many companies will actually sponsor the migration of existing applications. This costs money and the business case to change things that already work is often hard to prove. But new stuff, whether it’s new build or new COTS integration, is definitely a candidate for cloud deployment.

Then there’s the consideration of so-called private cloud. To me this is a sort of cloud lite – a different commercial model for hardware manufacturers to sell you their kit. But if it comes bundled with the same tools that public cloud has – allowing users to commission and decommission compute, storage and network services and only pay for what they use – and if it manages to increase utilisation because multiple departments and business units are sharing infrastructure, and if it actually costs less than buying the hardware outright, then okay, it’s a good thing. And I recognise that many organisations will struggle to trust the security of publicly shared infrastructure, and many will also struggle with the ability to connect cloud applications to legacy applications and data, because their legacy infrastructure is in different data centres and possibly different countries to the cloud resources. But I’d be wary of things like lock-in, minimum commitments, scalability, time to commission and de-commission, and interoperability with other cloud services, and whether this was going to give me a real cloud or just a different way to pay. But to give credit where it’s due, if I built servers or storage, I’d be building and selling public and private cloud offerings too. Or I’d be going out of business.

IT Stack As-IsCompanies will not only look to deploy their business applications on cloud resources. They will increasingly look to run their businesses on-line using commercial applications-as-a-service. I already mentioned, one of the original ASPs and still the most successful on-line provider of sales and customer management solutions, and who will turn over $3bn in revenue this year. Did you know that in the airline industry, most of the Star Alliance airlines run key operating functions like sales, reservations, inventory management and departure control on a shared applications-as-a-service model. Or that many Swiss banks run their entire businesses on a shared platform where they do not own any of the hardware or software? It’s taking a lot longer than anyone in the late 90’s anticipated, but applications-as-a-service is here to stay and will continue to grow. Already we see more and more migration onto standard business tools like email as a service or collaboration as a service (e.g. SharePoint). This trend will only add to the erosion of traditional hardware and software markets.

IT Stack - To-BeIf you asked me to look into my crystal ball, then I’d say I have no doubt that in ten years time a majority of organisations will be sourcing at least half of their business applications as a service where they don’t own any hardware or software; and for the applications they want to own, they’ll be running at least half of these on hardware they don’t own. So if I’m right, this means that in ten years time only a fraction of the server and storage infrastructure out there will be owned by companies for their own use. This will have major implications for hardware and software companies, and if they cannot re-invent themselves, they’ll go the way of DEC, Sun Microsystems and many others.

Fluffy white computing is a big topic with many interpretations and players. I hope the above discussion has given you some insights and perhaps sparked some questions. If you would like help with cloud strategy or IT strategy in general, please get in touch.

Considerations for Data Centre Migration

The vast majority of applications, once implemented into production, will never move. This is for two simple reasons: 1) It’s difficult and therefore costly and risky, and 2) it’s hard to build a business case to fix something that isn’t broken.

Migrating business systems from one or more locations is a complex undertaking that involves a number of issues including connectivity, application compatibility, shared data, inter-system communications  OS compatibility, hand over of support mechanisms, and more. The level of complexity is usually aligned to the business criticality of the associated systems. If the business can be without the system for a few days, then by all means, unplug it, throw it in the back of a truck, drive it to its new home, plug it in and fiddle with the network connections until it’s back on-line  But for systems where the business cannot tolerate more than a few hours of downtime, or none at all, you’re looking at a whole new level of complexity, time, cost and risk.

At a high level, data centre migration is more often an exercise in replicating application code, data and connections, rather than in migrating physical hardware. There is no one-size-fits-all approach; a number of migration strategies exist. In some cases where the business could survive without the system for two or three days, physical ‘lift and shift’ may be the recommended approach. However, for most systems the approach will be more complex, cost more, take longer but be less disruptive and less risky. These various approaches are outlined later in this article.

Any system migration does introduce risk. The objective of a chosen approach is to balance the cost, time and effort involved against the allowable risk to the business. It is therefore necessary to understand the potential impact to the business should the migrating system be unavailable for a period of time, and to involve the business stakeholders in deciding which approach is appropriate for each business system or grouping of business systems. This implies that a critical objective in the analysis and planning phase of a migration programme is to facilitate the decision making process with clear and business-appropriate inputs. These might include: a) Per system or system grouping, the assessed criticality and impact should the system be unavailable for longer than agreed during the migration, expressed in financial and reputational terms; b) Analysis of the migration approach options, with a recommendation, for each system or system grouping, in terms of time, cost, dependencies, assumptions and risks; c) A high level timeline for the migration, overlaid with the larger ongoing change programmes that may be in-flight or contemplated; d) A business case for the programme that proves quantitative and qualitative benefits; e) An overall programme risk plan covering commercial, financial, resourcing, third party and other foreseeable dependencies.

Some of the issues that need to be addressed when designing a data centre migration:

System groupings – There is usually a strong correlation between the time a business system has been in production and the number of connections it supports and is dependent upon. Many systems do not stand alone and therefore cannot be migrated individually. There may be inter-process and inter-system connections, real-time and batch, that work well on the data centre LAN, but which will run too slowly over a WAN connection during the migration programme. There may also be shared data or gateway dependencies between systems, meaning that both have to move at the same time. For example, a mainframe and a number of midrange systems may share the same channel-attached storage arrays or SAN. If you move the mainframe and SAN, you probably also have to move many of the midrange systems because they need local SAN speeds for data access. There will be many reasons why one system cannot migrate independently of others and so must all be migrated on the same week-end. The analysis to uncover this complexity and create these logical system groupings is perhaps the most difficult piece of work in the data centre migration analysis and planning phase. The success of the overall programme depends upon getting this right: target platform configuration, migration phasing, resourcing, cost estimating, and more.

IP addressing – Older systems, and yes, even more modern ones where there was a lack of architectural discipline, may have hard-coded IP addressing, socket connections, ODBC connections and other direct access methods embedded into code. Also, many data centre architectures use private address ranges, meaning that if more than one data centre is involved in the ‘as-is’ world, a new scheme is needed in the ‘to-be’. These issues just add to the overall complexity. A strategy is needed: clean things up before, during or after the migration?

OS compatibility – Many system environments contain a mix of various flavours and release versions of Unix, Linux, Microsoft Server, Z/OS, iSeries, P-Series, Tandem, and so on. Since the chosen migration approach for many of these systems may be to replicate them in the target location, you may not want to source, install and support old operating systems, some of which may no longer be supported by the vendor. And if you do need to install older operating systems, these may not even run on the newer hardware you want in your shiny new data centre! Replicating onto up-to-date operating systems will almost certainly introduce application compatibility risks that can be avoided by not doing an OS upgrade in conjunction with the migration. In some cases it may be advantageous to perform an OS upgrade prior to migration, in other cases it may be better to move onto an exact replica of the older operating environment and upgrade at a later date. Or you might get lucky and be able to migrate directly onto an updated platform. Discussions with applications providers, testing and trade-off analysis between cost and risk is needed.

Application Remediation – The chances are that applications and databases as they are currently implemented will not port straight away onto the target operating environment. This is for many reasons, for example the application may not be compatible with the newer hardware and up-to-date operating system version in the target environment; or it runs on an old release of a database or 4GL framework. Or you may be migrating the application from a physical to a virtual server. You may even be planning to completely change the underlying architecture of the application to leverage cloud compute, storage, database and communications constructs. For example, today the application may attach directly to an Oracle database but you want to migrate onto a cloud platform and leverage something like Amazon’s RDS (Relational Database Service). Or you may want to consolidate several databases and database servers onto a database appliance. Whatever the reason, and even if you’re migrating to a like environment, you will have to involve inhouse and third party applications providers and support teams, and conduct testing to determine how much, if any, remediation is necessary. Remediation can include steps from a simple re-compile all the way to re-write or even replace. Only thorough analysis and testing can help you decide which is required on an application by application basis. For high level planning purposes, a rule of thumb is that 10% of applications and databases will port with no remediation necessary, 30% will require minor remediation, 20% medium, 20% high levels of remediation, and between 20% and 50% of the applications portfolio will be put on the ‘too difficult’ pile and be migrated more or less as-is onto legacy platforms that you hoped not to be filling up your shiny new data centre with!

Latency – Systems migration may introduce additional round-trip communications time, depending upon where the new data centre is, where the users are, and other factors such as network quality, link bandwidth, router quality, hops, firewalls, etc. Therefore, an important step in the detailed planning phase is testing! Perform proof-of-concept testing between users and the new site. Hire a network specialist to do an in depth analysis of your existing network situation and the implications for migration to the target site. In most cases this will be a be a non-issue, or certainly nothing that cannot be addressed through proper design or the use of WAN optimisation technology.

Time and resources – The limiting factor in data centre migration is not usually hardware or software, but is the amount of change the business can sponsor and absorb at any given time. Migrating a system involves the input and participation of business staff, internal and external application support teams, network and security experts, hardware specialists, software vendors, network providers, project managers and so on. Much of the work can be done by dedicated project staff but there will be dependencies upon people with day jobs who may not see data centre migration as strategically important to the business. The success of the migration will depend upon proper resource planning, dependency management and governance to handle issue resolution and prioritisation. And it will take longer than you think! Rule of thumb: 2 to 4 systems or system groupings per month, following 3 to 6 months of planning. So if you’re moving 20 systems, the whole project may take anywhere from 8 to 16 months.

Migration Strategies

When migrating systems from one data centre to another several migration strategies are available. Choosing the right strategy is influenced by an understanding of the following factors:

  • Criticality of the system or system grouping
  • Financial risk should the system be unavailable
  • Reputation risk should the system be unavailable
  • Number of systems involved in the grouping
  • Allowable downtime
  • OS version and compatibility of application code with newer version
  • Database version and compatibility issues with newer OS, newer hardware
  • Size of the data sets and databases
  • Number and complexity of inter-process and inter-system communications, real-time and batch
  • Nature of inter-system communications, i.e. remote procedure call, socket, asynchronous messaging, message queing, broadcast, multi-cast, xDBC, the use of message brokers and enterprise service buses
  • Amount of remediation necessary to move the application or database onto the target platform
  • Security domain considerations, the use of firewalls, and the associated constraints
  • Availability of spare hardware
  • Existing backup and restore architecture and capability
  • Data replication architecture
  • Deployment topology: standalone vs clustering, single site vs multiple sites
  • Distance between old and new site
  • DR strategy and existing capabilities; are you trying to fix this during migration?
  • Rollback / back-out strategies available
  • Life-cycle for software stack components
  • Software licensing cost implications
  • Life-cycle of the existing hardware
  • Network bandwidth
  • Opportunity windows
  • Protocols being used between different systems
  • Service levels
  • Storage architectures: direct-attached vs. network-attached vs. SAN
  • User community locations and connection methods

As you can see, this is a fairly lengthy list of things to consider during the analysis and planning phase! Certainly gathering as much of this data as possible and immersing yourself in it will help in analysis and choosing the most appropriate approach for each system or system grouping. These approaches are discussed below:

Lift-and-shift: Physical migration is the simplest form of moving a system to a new environment. Switch it off, move it, plug it in and hope it works. Since the system has to power down for the move no data synchronization issues will arise because no new updates could have been made due to system unavailability. This strategy can only be used when there is sufficient time available for the whole process. Where high availability is required with no allowable down time, then clearly this strategy will not work. This is a highly risky approach. If for any reason the shipment of the system fails or the system can not be restarted at the new site or there is a network connection issue, no rollback / back-out option is available other than to ship it back and hope it works at the old site!

Re-host on new hardware: Re-hosting on new hardware mitigates most of the risks associated with the previous strategy of ‘lift and shift’, however the cost is much higher, since you’ll need to buy all new hardware. It may be possible to buy some new hardware and re-purpose the older hardware for the next wave of migration, but this will depend upon how old and fit-for-purpose the hardware is. Installing new hardware usually requires installation of the latest OS and other software, since often the old OS may not run on the newer hardware. This may lead to extra licensing requirements for upgrading other software components in the management stack. Porting to new hardware can have the advantage that the hardware is usually faster and can support more applications, potentially reducing the amount of boxes needed and reducing the overall software portfolio required, thus reducing licensing costs. The risks involved in this strategy are lower than with the first; a rollback / back-out solution should be built into the design and tested thoroughly. Compatibility between the application and the new software stack on the new hardware can be fully tested before cut over is done. Data synchronization can be an issue since the data needs to be moved from the old to the new environment while the old system is still processing updates. There are various ways to solve this synchronization issue, such as asynchronous replication, log-shipping, or just cutting off any further updates on the older system, performing the data migration and cutover, and carrying on on the newer system.

Swing kit: Using temporary hardware is similar to the re-hosting strategy except it involves double the effort. This is because, once the application and data are moved onto the temporary hardware, the original hardware is moved and the swing kit is swapped out. This strategy can use pre-production testing or development hardware, or hardware borrowed or leased from suppliers. It doesn’t matter as long as it is suitable for the migrating system or system cluster. Wherever possible you should avoid having to migrate the applications and data twice. The associated time and cost, as well as the additional risk to the business, are likely higher than purchasing new hardware in the first place. But there will be scenarios where borrowed kit is a viable option, usually where the box is quite large like a mainframe or Superdome.

Move DR first: This strategy involves moving the disaster recovery hardware first and then migrating onto it. This strategy will work if there is a fully configured and available DR system, and if the business can tolerate the risk of downtime and lost data during the time the DR system is being moved and tested.

Half cluster migration: This strategy works where the migrating system is currently deployed in a high availability cluster such that it will continue to support 100% availability if one half has failed. Take the redundant half down, move it, bring it up in the new site and re-attach it to the old site, then take down and move the other half. There are a number of dependencies and potential issues associated with this strategy, mostly to do with the fact that many high availability architectures have a live-live configuration for application servers but the database is in live-backup mode, meaning the application servers at the new site would have to access the database at the old site. This may work but usually going from SAN-attached storage to WAN-attached storage is too much of a penalty to pay and application performance degrades unacceptably.

Many to one: This is a derivation of the re-hosting on new hardware strategy. Quite often the new hardware is bigger and faster, and so through hardware sharing or virtualization you may be able to re-host multiple applications that used to run on individual servers onto a shared physical environment, reducing cost and complexity.

Virtualised Image Movement: If you already have a number of virtualised server images, then you may be able to migrate these fairly easily. But before you set up the new virtual server environment and start moving images, however, you’re going to have to consider what the applications on the server are doing, who or what is accessing them, what other systems are called upon by the application, how the application accesses data and whether this data needs to migrate before, during or afterwards. If you move the virtual image but not the database because other applications need to access the database, then the migrating application will need to access the database over a wide area connection. Will this work? Hmmm, not as easy as it seems then!

Cloud: there, I said it, the C word. The state of the art in private and public cloud offerings has advanced tremendously in the last few years, to the point where most organisations should seriously consider migration of suitable workloads to cloud computing. This will involve some work in the applications space as the applications will likely have to be rebuilt. But if your objective is to get out of an existing data centre, then moving to a new data centre may not always be the only option.

If you have a data centre migration project and would like some help in planning it or running it, please get in touch.