I have spent the last two years 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 - Fundamental changes to the way organisations operate - Different skill sets - A great deal of patience

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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