I have spent the last 18 months working on a cloud evaluation and adoption program. 

These slides are a updated version of a presentation I gave at the CAUDIT Enterprise Architecture Symposium recently.

In that time I have learnt a great deal about cloud services, such as the obvious that it doesn’t live up to the hype that it is quick and easy to deploy.  

To successfully deploy cloud  in a controlled and supportable fashion requires:

‐ Considerable thought to the technology and security

‐ Organisations  to make fundamental changes to their structure and the way they operate.

‐ Different skill sets 

‐ An ability to occasionally take things on face value and trust that just because things appear to defy the logic you’d apply to physical data centres doesn’t mean that it isn’t possible in the cloud. For example cloud providers will not tell the exact location of their data centres, for very legitimate reasons. You need to trust that they are well managed and where they say they are. No more site visits to look a battery rooms and diesel generators is possibly worth the adoption of cloud computing.  

‐ A great deal of patience as cloud computing is still relatively immature and it doesn’t have the features you would expect and are maybe used to in your physical data centre.

1

The term ‘cloud’ gets applied to anything that is delivered as a service.

There are existing managed services and internal shared services that I have seen rebranded as cloud services. Private Cloud is a term that is used on a regular basis and applied to what, for example used to be a VMWare cluster. 

There were some fairly clear demarcation lines between the types of cloud services

IaaS  ‐ Infrastructure as a Service

PaaS – Platform as a Service 

SaaS – Software as a Service

The lines are increasingly blurring.  For example Amazon Web Services (AWS) which is purportedly an IaaS has Relational Database Services (RDS) is technically a PaaS. My advice is relax and try not to worry about it, its all just computing stuff.

There are some excellent formal definitions for cloud services. Good  places to start are: 

NIST http://www.nist.gov/itl/cloud/index.cfm

ISO http://www.iso.org/iso/catalogue_detail?csnumber=60544

2

From an Australian perspective the Australian Department of Finance is an excellent repository 

http://www.finance.gov.au/cloud/

In particular the Australian Government Cloud Computing Policy  

http://www.finance.gov.au/sites/default/files/australian‐government‐cloud‐computing‐policy‐3.pdf

2

One of the first things to learn when you start looking at cloud services is that you actually already have and use them. 

If you were an early adopter of Hotmail you’ve been using a Software as a Service (SaaS) solution for twenty years. If you are one of the more than 3 million users of github you are a cloud users

If you think you are in an organisation that has no cloud services you are either badly misinformed or have no users. 

If you don’t respond to your users or customers requirements they no longer just grumble about the stupid IT Department, they go and do something about it.  This leads to the prevalence of Shadow IT in a organisation. 

Individual users or departments now have the ability to access a world of solutions via the Internet and a credit card.  Whilst this appears a viable approach to the user it has a number of risks and issues associated with it such as:

‐ Security and compliance  – if HR purchase a application of the web it may store or transmit data in a insecure fashion or store in in the wrong jurisdiction. 

‐ Integration and access control  ‐ How does this application integrate with existing systems? How do you authenticate?  Does it work with your existing authentication 

3

methods?

‐ Support. The first thing IT may know about the application is when the user calls the Service Desk for assistance.  What happens when the user who bought the software and supports it as a side job leaves?

‐ Procurement.  With no central involvement there may be multiple purchases of the same software, multiple accounts etc.  Again, what happens when the original user who bought and supports it leaves?

With the emergence of IaaS and PaaS you can now build a virtual data centre with a credit card, which takes shadow IT to a completely different level.

To remain relevant you have to deliver quicker, better and more secure services to your users.

3

Cloud Computing is not coming to take your job.  

Computing has gone through many radical changes over the industry's relatively short history.

The move from mainframe to the microcomputer was probably one of the first instances of Shadow IT as users directly adopted PCs  and used them to perform tasks that the mainframe was too expensive or busy to perform. 

Physical server sprawl was replaced by virtual server sprawl with Vmware.

Cloud computing is moving the industry away from organisations building and maintaining individual data centres that are costly, labour intensive and often inefficient in their use of space and resources. Cloud computing is helping to drive efficient use of resources, drive much higher availability and performance than can typically be achieved by a internal IT organisation. There is also evidence that these mega scale data centres are better for the environment than smaller more traditional data centres.

My experience indicates that some IT staff fear cloud ‐ predicting failure and unemployment. These are themes that have occurred many times in the industry. Your job 

4

probably will change, but if you’ve been in IT for a while it is unlikely to be the first or indeed the last time this will happen.

4

There are lots of cloud suppliers.

Some, as previously mentioned have added cloud to existing services hoping to jump on the bandwagon.

There a number of very large cloud providers who do similar things, sometimes in similar locations.

There are good reasons to adopt a multi‐cloud supplier model such as:

‐ Maturity or availability of particular capabilities or services

‐ Location related. The need for instances in particular countries or regions

‐ Not putting all of your eggs in one basket.

You need to be aware that as most of the IaaS providers have a substantial level of proprietary technology or processes in their services, they will be different. They will likely need different designs, skills and tools to deploy.

There are a number of organisations and tools that claim to be able to easily manage the multi‐cloud model, but be careful as they are maturing solutions.  

5

Most importantly, whilst it may be becoming technically possible to move services between cloud providers, I am yet to see a compelling technical or financial reason to flip workloads between providers.  The best approach is to use a process, such as a decision tree to decide which provider to use for a particular workload and then leave it there.

5

Cloud offerings change a lot.

The pace of change by the major cloud player is phenomenal. The assumptions that you had relating to cloud last month may no longer be true. This also means that the smaller providers may fall behind or drop out of the game completely.   You need to make sure you have an exit or contingency plan in this event.

The number of services available in Australia has and continues to increase. This is important as there are a number of compliance regulations that restrict the offshoring of certain data types. 

Swipe the credit card and you’re done?  No way – Not unless you want your cloud expensive, inefficient, insecure and unsupportable. It  requires thought in all the same areas  as if you were building in your own data centre.  

You need to be prepared to change the design as both the cloud service providers capabilities and architecture changes and as you develop a better understanding of how you use the service.

The design we started with a year ago has changed dramatically from a fairly traditional 

6

data centre model to something altogether different and will continue to change.

Don’t get distracted by the shiny things.  Whilst there are many new an interesting platforms and services available from the big players such as AWS. You need to initially focus on getting the basics right – build the skills, the virtual data centre, define the security and support model. 

When you have the basics right then start to look at some of the advanced functions and features. 

6

Coming from a traditional IT environment with a need to understand why things work rather than just that they do a lot of cloud may seem like some strange magic trick.

You will need to accept the fact that now infrastructure is deployable via  code it is now possible to deploy infrastructure in ways and in timeframes that were previously unimaginable.  Load balancers, firewalls and databases on demand without procurement or an engineering involvement with no need to keep it for five years to extract maximum return on investment.

‘I want a load balancer and I want it there'   ‐ Done simple 

7

Once you get past the technical architecture of a cloud service you realise that that technology is almost a minor part of deploying cloud. 

The successful deployment of cloud is far more about People and Process.

Almost everything has to change.

How do you manage, support, track a servers that appears and then disappears in under a hour?  Do you need a change request?  Do you need to log a service request?  Who approves? Many of the methods that were perfectly acceptable for processes with long lead times no longer work.

As I said earlier, cloud is not here to take your job but it will change it, whether you are an engineer or an architect. 

Everything you build in the cloud space can be expressed as code – Infrastructure as Code. 

Your resource skill requirements are different. Less physical hardware engineering skills with screwdrivers and more coders and scripters. 

8

Gartner state only 10% of the roles will be the same after cloud has been . That doesn’t mean you make 90% of the staff redundant. It means the roles and skills need to adapt to the new style of working. 

8

Infrastructure as code provides the ability to quickly develop new architecture and quickly deploy environments.

Speed becomes of the essence, but you do not need to get it right first time. In the IaaS space it is very easy to adjust the configuration of servers and other resources both up and down.  Using the software vendors recommended configurations does not always map onto cloud services, so the ability to adjust becomes important.

The traditional waterfall design process may not be quick enough or flexible enough and the adoption of a bi‐modal, two speed project deployment model may be required adopting Agile and DevOps processes. 

9

Keep those sticky fingers away from the keyboards! 

Infrastructure as code allows everything you deploy to be scripted and automated.

Everything that can be automated should be.  All servers should be treated as commodity and disposable.

In an ideal scenario there should be no reason why administrators should need to go anywhere near the cloud service console particularly for production systems. 

In the Development space a little more flexibility is allowed  to let developers to experiment 

10

Moving to the cloud is not like a Data Centre relocation.  Most existing systems today are sized for peek performance. 

If you simply map current resources (memory, CPU etc.) to cloud resources and lift and shift them it is both inefficient and will likely be very expensive. 

A reasonable approach is to use a decision tree to identify candidates and estimate how much adjustment and change may need to occur. May applications may need to be rightsized or even re‐architected to take advantage of capabilities like horizontal or auto scaling.

Migration of like to like configuration may be OK as long as you do this with an understanding that this will likely be suboptimal and you intend to come back and readdress the issues later.  

11

Remember server sprawl?

Now  you can end up with everything sprawl. Because everything is deployed with code if you provide admins or users the ability deploy things they probably will.

As cloud is potentially infinitely scalable it is quite possible to deploy thousands of servers and run up very large bills.

Be very careful who you give the keys to!

You need to make sure that everything is named tagged so it can be identified and you can provide chargeback or at least show‐back to the users. There is a real bill at the end of the month that has to be paid. Showing users what they are spending (even if it isn’t from their budget) helps in discussion for rightsizing and availability.  

Use quotas and other limits to prevent users from generating more instances of things than they are allowed. 

Use role based access to restrict the functionality of users and admins. For example avoid 

12

having admins who can create and delete objects or data stores.

Make sure you kill of anything that isn’t legitimate and use janitorial tools to clean up unused stuff.

Remember this costs you real money. 

12

One of those may things that needs adjustment is service levels and service classification.

24 x 7 service availability ‐ really? That used to work in the days of servers in internal data centres, there was no cost difference other than maybe electricity. With cloud there needs to be much greater focus put on when services need to be available. If  something is not used out of business hours then can it be switched off at night. 

If availability is classed as 9‐5  business days, but actually has users on it out of hours then the agreed service availability may be wrong and need adjustment.

Maybe services can be scaled back out of hours?

13

Don’t forget the network, particularly the speed of light 

Once you adopt cloud you have to remember that the service might now be some distance away  and there may be latency to content with.

If you rely on Internet access or VPN, how much overhead do you have in your connection?  Is your VPN even compatible with the cloud provider?

At some point there is likely to be a performance/cost crossover between the use of Internet services and a dedicated lease line.

Also remember that some cloud providers charge based on the data ingress and/or egress. If you have applications that are chatty or regularly move large volumes of data this can impact the cost of using cloud services.

14

The procurement model will change and you need to take the finance people on a journey as much as the technical.

Traditional IT procurement is used to buying tangible things  using a CapEx model. Things with a lifespan and defined depreciation. Procurement often has  long lead times, product selection and tenders processes.  

In cloud we are now spending OpEx based on usage. There is a bill that needs paying at the end of each month.  What we spend from one month to the next may vary. In the future as the multi‐provider cloud model matures workloads may move between a number of providers on a regular basis

IaaS and PaaS services have market places where you can buy virtual firewalls, storage arrays and all manner of things that used to take months to procure in the old world.

Vendors have standard contracts that may not be open for discussion. This may cause issues if organisations are used to using their own contracts.

15

Monitor and log everything. 

It is vitally important to understand what is happening in your cloud environment you have automation processes that can deploy any number of instances. 

You need to be vigilant on security and performance, although automation helps to reduce the risk of any misconfiguration or malicious actions.

When you create all these logs you will need to decide where are you going to store and how are you going to manage these logs.

Who gets access to the logs?

16

Cloud may be the answer to lots of thing  but not to everything. 

There are certain things are not yet a good fit for cloud services. 

Legacy applications with large physical infrastructure or unsupported operating system 

In a data driven research organisation the volumes of data required to be transferred between instruments and the storage at extremely low latency makes cloud adoption difficult at this point. 

17