Orchestrate Your Infrastructure

The digital society has emerged.

Today’s always-connected world and the applications we interact with are changing the way we live. People are mobile, our devices are mobile, and by all accounts, everything that is a noun – a person, place or thing – will soon be connected and generating data... and all that traffic is destined for an application – that could also be portable - located somewhere in a data center.

But not all data traffic is created equally and critical information might need some action that requires automation of the deployment process. At the same time, organizations can’t afford to manually make policy adjustments every time something needs attention. Automated coordination between applications, data and infrastructure from provisioning to applying policies and services which are in-line with business needs must be in place.

This is Orchestration.

Humans have always differentiated ourselves from all other creatures by our ability to reason. Today, we’re building reason into systems to make some of these decisions for us. Software that incorporates, ‘What’s the purpose?’ ‘What’s the reason why?’

Purpose-driven networking – programmability - means not just recognizing this is Thing 1 or Thing 2 and route requests to the appropriate service, but recognizing what Thing 1 or Thing 2 is trying to do and delivering in such a way as to meet expectations with respect to its performance.

The underlying infrastructure/architecture also needs to understand the purpose or reason for the data traffic adjustment and enable the scale and speed of deployments necessary for business success.

There is a ton of communication between us, our devices and the things around us, along with the applications that support us. It takes an agile and programmable infrastructure which is able to intercept, evaluate and interpret each request with an eye toward user, device, location and, now, purpose.

Orchestration is the glue that holds together all the quick networking decisions, ensures the provisioning of policies go where they need to go and provides the intelligence for the architecture to make automatic decisions and adjustments based on policy.

There could be many good reasons to automatically adjust the system and the F5 proxy architecture can augment application delivery functionality in tune with many other frameworks.

Because everyone has a unique environment, we’ve built custom integrations for a variety of 3rd party solutions including Cisco APIC, Amazon EC2, VMware NSX, and OpenStack. It begins when an administrator creates a custom integration based on Application Templates.

These templates can contain any configuration for a BIG-IP – from firewalls to local traffic management or anything else. Many configurations are seamless but with Cisco APIC, the configuration is then turned into a custom plug-in. The device package can then be uploaded directly to Cisco APIC, where application developers can deploy their targeted configuration correctly without using lots of knobs, but only the knobs they need to configure their application.

The application developer only has to specify a couple of parameters because when the administrator created the templates, they pre-configured everything the application developer needs in order to correctly deploy their application. This is different from other vendor’s integrations, which simply expose a large series of configuration clicks that then users have to get correct…and they’re easy to get wrong.

At this point, iWorkflow translates this small set of parameters into the complete configuration needed by the BIG-IP. And it deploys it on the BIG-IP. The BIG-IP is now completely configured for your application.

But we’re not done yet.

This is a dynamic integration since environments are always changing. When new application servers are added, or removed from your network, APIC will notice this, inform the BIG-IP, and BIG-IP’s configuration will update to reflect the new application servers and the associated application services. Now that the BIG-IP is aware of these application servers, it will immediately start directing traffic to those servers allowing your application to expand.

Likewise, when application servers are removed, the BIG-IP’s configuration will immediately be updated and will stop passing traffic to those application servers, allowing you to take a maintenance window or decrease the capacity provided to your application.

And while this all happening, the iWorkflow is collecting application level statistics, to provide a complete view of your infrastructure and reporting them upstream to the Cisco APIC in this example.

That’s it, we’re done right?!?!

WRONG!! What about security? What happens when you’re under attack?!?

As you know, it is critically important that the security services dynamically follow the application also, no matter where it lives or how it got there. And in some cases, an old application needs a new home.

The idea is that you start with the (figurative) castle protecting the queen's treasure – The Data - and we drop in the different service pieces to keep the application secure, available and resilient. The wall and moat around the castle represent BIG-IP AFM perimeter protection; there’s a satellite dish for signaling to Silverline DDoS Service; BIG-IP APM's draw bridge to thwart unauthorized access. The whole point is that F5 can add these services around all your 'castled' applications to protect them from threats. This is especially true for ‘older’ applications that may have issues adding security services. F5 can be deployed with the latest security services to protect your entire environment.

Orchestration gives organizations the automated provisioning processes of application policies in our hybrid, dynamic, mobile and risky world. And check out Nathan Pearce's great iWorkflow Series!

ps