Everyone is shifting their workloads to the cloud, but one challenge remains: Workloads need to be automated. Whether they’re employing a cloud-native, cloud server, or hybrid model—IT operations teams need to know what, when, and now also where to automate. Speaking at the recent 2022 Automation Virtual Summit, Dave Kellermanns, Global Advisor for Automation, Broadcom Software explored some lessons learned and best practices for cloud automation. Read on to see some of the highlights.
#1. Do you want to automate the cloud infrastructure, the workload in the cloud, or a combination of both? Each cloud and data center has different ways to automate.
#2. You also need to decide whether to use one cloud provider or many. Staying with one makes life easier (the standardization story), but if costs rise or the service level degrades, you are locked into that provider.
#3. What elements will be SaaS? SaaS means you won’t have access to the servers, although most SaaS providers feature extended APIs to support automation.
#4. How do you get to the cloud? Is it a bi-directional connection—in other words are you executing from a data center into the cloud? Or is it cloud-to-cloud? This helps you decide what firewalls or tunnels you’ll need to “request” work from other applications.
#5. Consider how you will monitor your network experience. Where are the potential latency issues and what should you do if they occur?
#6. Consider an abstraction layer to avoid lock-in. If your cloud provider is likely to change, we recommended that you separate the automation of the cloud infrastructure from the automation of the cloud workload. This way, you can switch cloud providers more easily.
#7. Where will your code execute? Do you want to do SDK or API calls from your data center or within the cloud? It’s good practice to set up a server with a lot of memory to run “utility agents” such as REST or SOAP.
#8. Some cloud providers dictate maintenance windows for their applications. You need to automate around these windows and decide what can be skipped, what can be scheduled around these windows, and what needs to be negotiated.
#9. Individual cloud SDKs and APIs only provide visibility into a slice of the business flow. This gets complicated when you’re relying on multiple cloud providers, SaaS applications, and on-premises applications. Our advice is to invest in an orchestration layer that offers end-to-end visualization, from on-premises and SaaS applications to the cloud.
#10. If you only see individual slices of the business flow, how can you manage SLAs? The orchestration layer can help you here. It sees the complete picture and can manage run-times and SLAs—informing you what’s on your critical path and when SLAs are likely to be affected.
#11. If you use multiple cloud providers, each will alert you differently when problems occur. That adds complexity, risk, and potentially cost. You can add a SaaS solution like ServiceNow to harmonize the data. Or you can use your orchestration layer to receive individual alerts and then open, monitor, and close standardized tickets.
#12. How much needs to be exposed to the outside? A general rule is to minimize connections to the outside, thereby reducing the attack surface. You can also use encryption to secure communication.
#13. Automating from a central location minimizes the need for connections. Users can orchestrate, automate, and monitor from one location or a single jump server in the cloud.
#14. Never use the default ports. A little more configuration effort in the short run pays off when hackers are looking for the “usual” ports.
#15. Manage your access rights. If you rely on SaaS, plan where you will trigger that automation from. Everything for a SaaS solution approach should be installed where you have access, either a cloud server or on-premises, so you can troubleshoot issues.
#16. Do you need every server up 24x7 or can you orchestrate your cloud to start/stop servers as required, reducing cost?
#17. Automate the backups for your cloud servers and applications.
#18. When executing workloads in containers, you can either use the container control and features like load balancing or you can try to package an agent into the container. In general, an agent within a container does not offer significant benefits, unless it’s designed mostly for file movement or file watching and then moves the file before the container shuts down.
Want to learn more? You can catch all the presentations from the 2022 Automation Virtual Summit.