Cloud adoption changes the way we deploy applications, the way we work, and the way that IT fulfills our responsibility of “stopping of everything breaking.” Automated deployments, templated services, and self-service tools are part of the new reality of working in a cloud-age IT organization.
Which is why it’s a good job that most IT professionals are natural continuous learners. Because not only are there new tools and techniques to learn, there are whole new ways of working to deal with too.
As an operations team transitions from ‘button pushers’ to ‘button creators,’ you are going to have to learn the both skills to create those buttons, and the knowledge to know what kind of buttons to create.
Enough waffle: let’s talk about the kind of buttons you need to create. The short answer is that in the world of automation and self-service you need to create a declarative interface for your customers to specify what service they need, without the knowledge of the steps required to create it. This enables a developer (or other requestor) to create a representation of what the end state of the infrastructure should be, and rely on the tools and integrations you build to deliver it. Behind this simple(?) goal lies considerable complexity and also the real value that network operations brings to a cloud environment as they transform and adapt to become network automation specialists rather than implementers. Because behind a declarative interface – whether that is a GUI, an API endpoint, or a system the ingests a text file and builds a fully functioning infrastructure from it, there is a lot of imperative work going on in the background. Just as behind the request for a “large decaf soy-milk latte with caramel drizzle” there are a lot of steps (and probably just a little head shaking form your barista in the former case) behind a line in a text file to include WAF protection for an application, and there are number of API calls and implementation steps which need to be done in the right sequence with success – checking along the way to deliver a configuration that is effectively protecting an application.
If this sounds like a job better suited to a programmer, you’d be both right and wrong. Right because there will be some programming scripting and API-fu skills required. Wrong because the domain knowledge of the network operations team is, despite what many might think, critical to delivering quality applications at scale. The knowledge and experience of creating supportable, maintainable infrastructure is far too important to be lost in the transformation to an automated deployment model.
So how to create the interfaces? Some of that is going to depend on your organization’s automation strategy as a whole. There is no point building an automation system built around a tool that doesn’t align with the way the rest of the application stack is being deployed, or the cloud platforms in use. Plan to learn the deployment tool of your organization – or if that’s not decided, then become at least familiar enough to make some recommendations. Learning some of the core automation concepts and exploring the API capabilities of your infrastructure is also essential groundwork.
Even if full automation is still a future project, what you can do now is work on creating standardized templates of your most common deployments or operations – tackling the 80% of activity. Work out what the parameters are, what might vary from deployment to deployment and what should stay fixed. Things like SSL cipher suites are usually fixed and standard, for example, whereas the SSL certificates used will often vary. Building these templates out will start to create the building blocks of your automation implementation. If there are vendor tools to enable the automation of your components, or software libraries to integrate them into automation tools, then getting evaluation versions and testing them is also a great start.
As well as automated deployments, you might need to start planning automated lifecycle management of your infrastructure, along with capacity planning and workload management. All of these need to be at least a consideration for automation.
So even if you are at the start of your private cloud and automation journey, there are plenty of steps you can take now to ensure a successful conclusion. For most of us, automation is coming, and coming soon, and the time to get ready is now.
About the Author
Related Blog Posts
The everywhere attack surface: EDR in the network is no longer optional
All endpoints can become an attacker’s entry point. That’s why your network needs true endpoint detection and response (EDR), delivered by F5 and CrowdStrike.
F5 NGINX Gateway Fabric is a certified solution for Red Hat OpenShift
F5 collaborates with Red Hat to deliver a solution that combines the high-performance app delivery of F5 NGINX with Red Hat OpenShift’s enterprise Kubernetes capabilities.
F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
Volterra and the Power of the Distributed Cloud (Video)
How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.