Open Source Spotlight: F5 Infrastructure as Code and Multi-Cloud Manageability
You might have noted that a significant drum beat under the multi-cloud mantra is manageability. That’s because the task of scaling, securing, and delivering apps to users requires a certain set of services – load balancers, compute, storage, app security. And though cloud may (it does) make the process of provisioning those services much easier, it does so to the detriment of operations. Sadly, it moves the complexity somewhere else.
If you’re the one provisioning those services, that’s all cool. But if you’re the one who’s got to configure, tweak, and manage services, it’s not so cool.
Because complexity makes management harder. No two clouds are the same (in terms of APIs and services) and that often means two completely separate operational models that folks now have to deal with.
So manageability is a big part of making multi-cloud successful.
One of the ways organizations can do that is to adopt those constructs that simplify deployments. These are increasingly in the form of some kind of template: OpenStack HEAT, AWS Cloud Formation, and Azure ARM spring to mind. These templates codify the bulk of a BIG-IP deployment in terms of the specific configuration that needs to be in place in order to spin up the real value of a BIG-IP – its services.
Templates are one of the best examples of infrastructure as code (IAC). This is because they can be treated exactly like code artifacts. They can be versioned, branched, merged, retrieved, cloned, and ultimately deployed.
This model matches well with the DevOps-oriented view of cloud and management through APIs and scripting languages. After all, if DevOps can extend its influence into NetOps, and in turn they can rapidly deploy services using an IAC approach, everyone’s happy. It’s just what the doctor ordered considering the lack of such services from NetOps significantly influences the decisions of DevOps to go around IT when it comes to cloud.
Supporting multi-cloud manageability is exactly what We (the corporate We now) envisioned when we began developing templates for OpenStack, AWS, and Azure. Enabling an IAC approach to provide greater agility and speed is why those templates are freely available through github.
Because our lab deployments are not your deployments and they aren’t that other guy’s (in the row behind you, reading over your shoulder) either. Deployments share a common set of characteristics, but all apps have specific needs that can’t be met with the same commodified service configuration. Round robin load balancing might be good enough for stateless, microservices based apps but it can be terribly inefficient (not to mention expensive) for other application architectures – particularly in cloud environments. You need the freedom to adapt and optimize app performance and ensure the security of data and the safety of user interactions.
You need to be able to pull, clone, and commit those artifacts to your own repositories so you can reap the benefits of a NetOps approach that includes IAC to deploy as much of your service base as possible, across as many of your cloud environs as possible.
So pull, clone, commit, and deploy on your schedule – whether that’s three times a day or three times a quarter. It’s open source, and it’s always an open for access.