6. You distribute temporary passwords/SSH keys to your admins
in order to access instances and update software packages
Remember the old days, say, pre-Sarbanes-Oxley, when pretty much everyone
had access to the servers? Then things changed, and people had to request
temporary authorization to log into the servers to make changes (patches,
fixes, etc.), and those changes were monitored via PowerBroker, or an equiva-
lent. If you still follow the same approach on the cloud, you have not embraced
automation and cloud concepts to their full extent. Patching the servers should
not involve logging in, but rather updating your server definition template and
relaunching the server. As a matter of fact, in a well-architected cloud environ-
ment, there should be very few occasions requiring humans to log into
servers.
7. You say "multi-cloud" within two seconds after someone
asks you about your cloud strategy
Multi-cloud itself is not a bad idea or strategy, but you have to understand what
it really means to you. The multi-cloud term has been somewhat overused and
seems to be a knee-jerk reaction to concerns about cloud or vendor lock-in. In
addition, people have a misconception that they will be able to move workloads
between on-premises, Azure and AWS at will, with ease and with no opera-
tional overhead. The reality is quite different. It takes time to get good at one
cloud. It will take even more time to get good at several. You should definitely
have a multi-cloud strategy, but it should be based on the business objectives
you are trying to achieve. For example, you might want to run certain work-
loads in Google because of its capabilities; in Azure because of proximity to
your corporate offices; or in AWS because of the breadth of offerings. But most
certainly do not select multiple clouds because you are afraid AWS will raise
the rates on you. After all, when you bought Oracle to power your workloads,
you did not also purchase Sybase just in case Oracle changed its licensing
agreements.
8. You want to know when it is a good time in the cloud to
take servers down to patch them
The good old Patch Tuesdays simply do not work in the cloud. If you really need
to ask that, you are not ready for the cloud. Your infrastructure should be
designed to be self-healing and to withstand failure, so if a server dies another
one launches automatically based on the template defined. This way, patching
servers is as simple as updating the server template definition and relaunching
the new one. Once the server passes the necessary tests in an automated fash-
ion, it can be safely put into use.
FALL 2018 | THE DOPPLER | 13