The Doppler Quarterly Fall 2018 | Page 15

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