Exploring Kubernetes API using Wireshark part 1: Creating, Listing and Deleting Pods
Related Articles: Exploring Kubernetes API using Wireshark part 2: Namespaces Exploring Kubernetes API using Wireshark part 3: Python Client API Quick Intro This article answers the following question: What happens when we create, list and delete pods under the hood? More specifically on the wire. I used these 3 commands: I'll show you on Wireshark the communication between kubectl client and master node (API) for each of the above commands. I used a proxy so we don't have to worry about TLS layer and focus on HTTP only. Creating NGINX pod pcap:creating_pod.pcap (use http filter on Wireshark) Here's our YAML file: Here's how we create this pod: Here's what we see on Wireshark: Behind the scenes, kubectl command sent an HTTP POST with our YAML file converted to JSON but notice the same thing was sent (kind, apiVersion, metadata, spec): You can even expand it if you want to but I didn't to keep it short. Then, Kubernetes master (API) responds with HTTP 201 Created to confirm our pod has been created: Notice that master node replies with similar data with the additional status column because after pod is created it's supposed to have a status too. Listing Pods pcap:listing_pods.pcap (use http filter on Wireshark) When we list pods, kubectl just sends a HTTP GET request instead of POST because we don't need to submit any data apart from headers: This is the full GET request: And here's the HTTP 200 OK with JSON file that contains all information about all pods from default's namespace: I just wanted to emphasise that when you list a pod the resource type that comes back isPodListand when we created our pod it was justPod. Remember? The other thing I'd like to point out is that all of your pods' information should be listed underitems. Allkubectldoes is to display some of the API's info in a humanly readable way. Deleting NGINX pod pcap:deleting_pod.pcap (use http filter on Wireshark) Behind the scenes, we're just sending an HTTP DELETE to Kubernetes master: Also notice that the pod's name is also included in the URI: /api/v1/namespaces/default/pods/nginx← this is pods' name HTTP DELETEjust likeHTTP GETis pretty straightforward: Our master node replies with HTTP 200 OK as well as some json file with all the info about the pod, including about it's termination: It's also good to emphasise here that when our pod is deleted, master node returns JSON file with all information available about the pod. I highlighted some interesting info. For example, resource type is now just Pod (not PodList when we're just listing our pods).Orchestrated Infrastructure Security - Advanced WAF
The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. Introduction This article is part of a series on implementing Orchestrated Infrastructure Security. It includes High Availability, Central Management with BIG-IQ, Application Visibility with Beacon and the protection of critical assets using F5 Advanced WAF and Protocol Inspection (IPS) with AFM.It is assumed that SSL Orchestrator is already deployed, and basic network connectivity is working. If you need help setting up SSL Orchestrator for the first time, refer to the Dev/Central article series Implementing SSL Orchestrator here. This article focuses on configuring F5 Advanced WAF deployed as a Layer 2 solution. It covers the configuration of Advanced WAF protection on an F5 BIG-IP running version 16.0.0. Configuration files of BIG-IP deployed as Advanced WAF can be downloaded from here from GitLab. Please forgive me for using SSL and TLS interchangeably in this article. This article is divided into the following high level sections: Advanced WAF Network Configuration Attach Virtual Servers to an Advanced WAF Policy Advanced WAF: Network Configuration The BIG-IP will be deployed with VLAN Groups.This combines 2 interfaces to act as an L2 bridge where data flows into one interface and is passed out the other interface. Vwire configuration will be covered later. From the F5 Configuration Utility go to Network > VLANs.Click Create on the right. Give it a name, ingress1 in this example.Set the Interface to 2.1.Set Tagging to Untagged then click Add. Note: In this example interface 2.1 will receive decrypted traffic from sslo1 Interface 2.1 (untagged) should be visible like in the image below.Click Repeat at the bottom to create another VLAN. Give it a name, egress1 in this example.Set the Interface to 2.2.Set Tagging to Untagged then click Add. Note: In this example interface 2.2 will send decrypted traffic back to sslo1 Interface 2.2 (untagged) should be visible like in the image below.Click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure VLANs for the two interfaces connected to sslo2.These VLANs should be named in a way that you can differentiate them from the others.Example: ingress2 and egress2 It should look something like this when done: Note: In this example Interface 2.3 and 2.4 are physically connected to sslo2. Click VLAN Groups then Create on the right. Give it a name, vlg1 in this example.Move ingress1 and egress1 from Available to Members.Set the Transparency Mode to Transparent.Check the box to Bridge All Traffic then click Finished. Note: This guide assumes you are setting up a redundant pair of SSL Orchestrators.Therefore, you should repeat these steps to configure a VLAN Group for the two interfaces connected to sslo2.This VLAN Group should be named in a way that you can differentiate it from the other, example: vlg1 and vlg2.It should look like the image below: For full Layer 2 transparency the following CLI option needs to be enabled: (tmos)# modify sys db connection.vgl2transparent value enable Attach Virtual Servers to an Advanced WAF Policy You can skip this step if you already have an Advanced WAF policy created and attached to one or more virtual servers.If not, we’ll cover it briefly.In this example we configured Comprehensive Protection which includes Bot Mitigation, Layer 7 DoS and Application Security. Give it a name, App_Protect1 in this example then click Save & Next. Select the Enforcement Mode and Policy Type.Click Save & Next. Configure the desired Bot Defense options.Click Save & Next on the lower right. Configure the desired DoS Profile Properties.Click Save & Next. Assign the policy to your application server(s) by moving them to Selected.Click Save & Next. Click Finish/Deploy when done. Summary In this article you learned how to configure BIG-IP in layer 2 transparency mode using VLAN groups.We also covered how to create an Advanced WAF policy and attach it to your Virtual Servers. Next Steps Click Next to proceed to the next article in the series.
F5 Services in a CI/CD pipeline
Speedup the delivery of new services (time to market), decrease OPEX are examples of why customers are investing in automation and orchestration. This has an impact on all the layersinvolved in the delivery of a service, infrastructure included. As a solution architect working at F5, i spend a fair amount of time with customers to discuss how wecan handle F5 services lifecycle with Automation and orchestration tools. Customers want to make sure that any technologythey acquire can be orchestrated and won't be an inhibitor to their projects. In the video below, I will show you how you can tieF5 services to the lifecycle of an application. For this demo, I used the F5 automation toolchain. The F5 automation toolchain allows our customer to deploy easily and quicky F5 application services via a declarative API interface. AS3 (Application Services 3) is the extension i used to deploy the service on top of our F5 platform running as software (Virtual Machine). Everything related to this demo is available here. It contains enough scripts/information for anyone to reproduce this demo and learn more about how to consume F5 services in a CI/CD pipeline. You can find more information here regarding the F5 automation toolchain: * Overview * Whitepaper * Technical documentation * Download the F5 automation toolchainManage Infrastructure and Services Lifecycle with Terraform and Ansible + Demo
Working as a Solution Architect for F5, Ioften need to have access to a lab environment. 'Traditionally', the method to implement a lab was to leverage tools like Vagrant,VMWare,or others. A lab environment on a laptop is limited by its computing capacities (CPU/Memory/disk/...).Today we are often asked to show how we can integrate our solutions with many different tools(Orchestration solutions, Version Control systems, CI Servers, containerized environments, ...). Except if your laptop is a powerful one, it's difficult to build such an environment and have itrun smoothly. If the lab requirements are too demanding for my laptop, Iwould access one of our lab facility to do my work. Thisapproach itself is fine but bring some challenges: If you travel like Ido, latency can become a hindrance and be frustrating. Lab facilities leverage "shared resources". Which means you may face issues due toconflicting IP addresses, switch misconfiguration, maintenance operations, ... Some resources may already be reserved/used by another fellow colleague and not be available. You may also face other constraints making both deployment models difficult: Need to share access to the lab. Not easy when it runs on your laptop or in a private cloud that is not always opened to the outside world. People may need to be able to replicate your lab in their own environment. Stability/time needed for maintenance: Using a lab over and over will make it messy. You usually At some point, you'll reach a stage where you want to create a "new" environment that is clean and "trustworthy" (until you played too much with it again) I'm sure i've missed other constraints but you get the idea: maintaining a lab and using it in a collaborativemanner is challenging. Luckily, it's easier today to achieve those objectices: Leverage Public Cloud! Public Cloud gives you access to "unlimited" computing services over Internet that can be automated/orchestrated. With Public Cloud, you have access to an API allowing you to spin up a new environment with all therelevant tools deployed. This way, you may go straight into work (after enjoying a nice cup of coffee/tea while yourinfrastructure is being deployed! ).Once your work is done, you can destroy this environment and save money. When you'll need a lab again, you'll be able to spin a new/clean environment in a matter of minutes and be confident that it's a "healthy lab" When working on Automation/Orchestration of Public cloud environments, I see two dominant tools: Terraform andAnsible. https://www.terraform.io Terraform is an open source command line tool that can be used to provision an infrastructure on dozensof different platforms and services (AWS, Azure, ...).One of the strength of Terraform is that it is declarative: You specify the expected "state" of yourinfrastructure and Terraform will take care of all the underlying complexities (Does it need to be provisioned? Should I update the settings of a component? Which components should be created first? Do we need to deleteresources that are not required anymore, ... ).Terraform will store the "state" of your infrastructure and configuration to be more efficient in its work. https://www.ansible.com Ansible is a provisioning and configuration management tool. It is designed to automate application deployments.One of the strength of Ansible is that it doesn't require any "agents" to run on the targetted systems. Ansibleworks by leveraging "Modules". Those modules are consumed to define the "state" of the targetted systems. They areusually executed over SSH (by default). So how to leverage those tools to have a lab available on-demand? In the following demo, we will: Leverage Terraform to manage the lifecycle of a new AWS environment: manage a dedicated VPC with external/internal subnets, Ubuntu instances, F5 solution) In addition to deploying our infrastructure, it will generate the relevant files for Ansible (inventory file to know theIPs of our systems, ansible variable files to know how to configure the F5 solution with AS3) Use Ansible to manage the configuration of our systems: update our ubuntu instances, install NGINX Web serviceon our Ubuntu instances, deploy a standard F5 configuration to load balance our web application with AS3 Here is a summary for the demo: Demo time! By leveraging tools like Terraform or Ansible (you can achieve the same results with other tools), it is easy to handle thelifecycle of an infrastructure and the services running on top of it. This is what people IaC (Infrastructure as Code) Useful links:- If you want to learn more about the setup of this demo, it is posted on Github: here- F5 provides a list of templates to automate deployment in public cloud. It's available here: AWS Templates, Azure Templates, GCP Templates- F5 Application Services 3 (AS3) documentation/examples: here- If you want to learn more about our API and how to automate/orchestrate F5 solutions (free training): F5 A&O Training
BIG-IQ Grows UP [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. Today F5 is announcing a new F5® BIG-IQ™ 4.5. This release includes a new BIG-IQ component – BIG-IQ ADC. Why is 4.5 a big deal? This release introduces a critical new BIG-IQ component, BIG-IQ ADC. With ADC management, BIG-IQ can finally control basic local traffic management (LTM) policies for all your BIG-IP devices from a single pane of glass. Better still, BIG-IQ’s ADC function has been designed with the concept of “roles” deeply ingrained. In practice, this means that BIG-IQ offers application teams a “self-serve portal” through which they can manage load balancing of just the objects they are “authorized” to access and update. Their changes can be staged so that they don’t go live until the network team has approved the changes. We will post follow up blogs that dive into the new functions in more detail. In truth, there are a few caveats around this release. Namely, BIG-IQ requires our customer’s to be using BIG-IP 11.4.1 or above. Many functions require 11.5 or above. Customers with older TMOS version still require F5’s legacy central management solution, Enterprise Manager. BIG-IQ still can’t do some of the functions Enterprise Manager provides, such as iHealth integration and advanced analytics. And BIG-IQ can’t yet manage some advanced LTM options. Never-the-less, this release will an essential component of many F5 deployments. And since BIG-IQ is a rapidly growing platform, the feature gaps will be filled before you know it. Better still, we have big plans for adding additional components to the BIG-IQ framework over the coming year. In short, it’s time to take a long hard look at BIG-IQ. What else is new? There are hundreds of new or modified features in this release. Let me list a few of the highlights by component: 1. BIG-IQ ADC - Role-based central Management of ADC functions across the network · Centralized basic management of LTM configurations · Monitoring of LTM objects · Provide high availability and clustering support of BIG-IP devices and application centric manageability services · Pool member management (enable/disable) · Centralized iRules Management (though not editing) · Role-based management · Staging and manual of deployments 2. BIG-IQ Cloud - Enhanced Connectivity and Partner Integration · Expand orchestration and management of cloud platforms via 3rd party developers · Connector for VMware NSX and (early access) connector for Cisco ACI · Improve customer experience via work flows and integrations · Improve tenant isolation on device and deployment 3. BIG-IQ Device - Manage physical and virtual BIG-IP devices from a single pane of glass · Support for VE volume licensing · Management of basic device configuration & templates · UCS backup scheduling · Enhanced upgrade advisor checks 4. BIG-IQ Security - Centralizes security policy deployment, administration, and management · Centralized feature support for BIG-IP AFM · Centralized policy support for BIG-IP ASM · Consolidated DDoS and logging profiles for AFM/ASM · Enhanced visibility and notifications · API documentation for ASM · UI enhancements for AFM policy management My next blog will include a video demonstrating the new BIG-IQ ADC component and showing how it enhances collaboration between the networking and application teams with fine grained RBAC.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! psCreation iApp application service via iControlREST
Hi, Is it possible to create an iApp application service with iControlREST? I'm pretty sure it is, although when I looked through the iControlREST API I didn't see anything mentioning iApp. If it's possible, can someone give me a sample URL which would do it? Regards, Barney
To Err is Human
#devops Automating incomplete or ineffective processes will only enable you to make mistakes faster – and more often. Most folks probably remember the play on "to err is human…" proverb when computers first began to take over, well, everything. The saying was only partially tongue-in-cheek, because as we've long since learned the reality is that computers allow us to make mistakes faster and more often and with greater reach. One of the statistics used to justify a devops initiative is the rate at which human error contributes to a variety of operational badness: downtime, performance, and deployment life-cycle time. Human error is a non-trivial cause of downtime and other operational interruptions. A recent Paragon Software survey found that human error was cited as a cause of downtime by 13.2% of respondents. Other surveys have indicated rates much higher. Gartner analysts Ronni J. Colville and George Spafford in "Configuration Management for Virtual and Cloud Infrastructures" predict as much as 80% of outages through 2015 impacting mission-critical services will be caused by "people and process" issues. Regardless of the actual rates at which human error causes downtime or other operational disruptions, reality is that it is a factor. One of the ways in which we hope to remediate the problem is through automation and devops. While certainly an appropriate course of action, adopters need to exercise caution when embarking on such an initiative, lest they codify incomplete or inefficient processes that simply promulgate errors faster and more often. DISCOVER, REMEDIATE, REFINE, DEPLOY Something that all too often seems to be falling by the wayside is the relationship between agile development and agile operations. Agile isn't just about fast(er) development cycles, it's about employing a rapid, iterative process to the development cycle. Similarly, operations must remember that it is unlikely they will "get it right" the first time and, following agile methodology, are not expected to. Process iteration assists in discovering errors, missing steps, and other potential sources of misconfiguration that are ultimately the source of outages or operational disruption. An organization that has experienced outages due to human error are practically assured that they will codify those errors into automation frameworks if they do not take the time to iteratively execute on those processes to find out where errors or missing steps may lie. It is process that drives continuous delivery in development and process that must drive continuous delivery in devops. Process that must be perfected first through practice, through the application of iterative models of development on devops automation and orchestration. What may appear as a tedious repetition is also an opportunity to refine the process. To discover and eliminate inefficiencies that streamline the deployment process and enable faster time to market. Inefficiencies that are generally only discovered when someone takes the time to clearly document all steps in the process – from beginning (build) to end (production). Cross-functional responsibilities are often the source of such inefficiencies, because of the overlap between development, operations, and administration. The outage of Microsoft’s cloud service for some customers in Western Europe on 26 July happened because the company’s engineers had expanded capacity of one compute cluster but forgot to make all the necessary configuration adjustments in the network infrastructure. -- Microsoft: error during capacity expansion led to Azure cloud outage Applying an agile methodology to the process of defining and refining devops processes around continuous delivery automation enables discovery of the errors and missing steps and duplicated tasks that bog down or disrupt the entire chain of deployment tasks. We all know that automation is a boon for operations, particularly in organizations employing virtualization and cloud computing to enable elasticity and improved provisioning. But what we need to remember is that if that automation simply encodes poor processes or errors, then automation just enables to make mistakes a whole lot faster. Take care to pay attention to process and to test early, test often. How to Prevent Cascading Error From Causing Outage Storm In Your Cloud Environment? DOWNTIME, OUTAGES AND FAILURES - UNDERSTANDING THEIR TRUE COSTS Devops Proverb: Process Practice Makes Perfect 1024 Words: The Devops Butterfly Effect Devops is a Verb BMC DevOps Leadership Series
The 2015 problem - Human Latency
What is human latency? No, I’m not referring to how quick you can pull a table cloth - something my mother insisted I stop trying, and failing miserably at, at a young age. In technology circles, human latency refers to the delays incurred when waiting for people to complete a task. I don’t believe (I hope not) that the term was coined to suggest that certain employees are slow to meet expectations, but more to do with the fact that people have finite bandwidth and, therefore, when the workload exceeds what they can deliver businesses will experience delays. This is ‘human latency’. Putting something in a request queue (the business) waiting for something to be done (human latency). Human latency can be the result of many things: Workload exceeding the capabilities of a delivery team. Procedural delays (policy) caused by anything form budget constraint, key decision makers being unavailable, possibly even interdepartmental disputes over prioritization. Knowledge limitations of engineers working beyond their comfort zone. Why are we suddenly so interested? In more recent times, the speed of business has increased significantly. Far, have IT departments progressed, from the days of sitting around in sun-loungers (I jest), to todays more competitive, information-consumer driven priorities. Driven largely by competition and the ‘immediate gratification’ generation, expectations on the delivery of ‘everything now’ have never been so prevalent. What effect will this have? Have you seen Terminator 3: Rise of the Machines? In case you haven’t, it’s the one about the robots deciding to eradicate the human race from planet earth. Turns out the robots realized that we, their creators, were the weakness in evolution. I’m hoping that said movie has socialized the importance that we (humans) stop before anything gets quite so bad <CR><LF>. However, back to the title of this section, it’s the human latency problem that is driving technology integration and intelligent orchestration. Not this integration (man inserts RFID chip into hand), and not this (musicy thingy) kind of orchestration. Five years ago (that’s 2009, to the future alien race), I was talking with a customer who told me of a most excellent policy within their team. “NEVER do something more than 3 times without committing effort towards the automation of that task.” Unfortunately, my suggestions toward building a shrine in honor of this customer were laughed off, but can you deny the genius behind this policy? In their environment, one was ‘busy’ and unavailable for other assignments should they be reviewing a historical task for the purpose of never performing it again. BRILLIANT!!! What can we learn? For a long time, cloud computing was heralded as the solution to IT’s bottleneck. “Move workloads to the cloud so that IT can focus on strategic projects”, they yelled from the rooftops (via twitter). Cloud-based technology didn’t solve problems, it merely moved them elsewhere, or created new ones. With IaaS we have the same service delivery problems as private data centers, just on someone else’s hypervisor, and with a utility licensing model. With SaaS, its great that someone else is handling feature requests and execution, but with SaaS also came access problems: increased password fatigue and a reduced security integrity. And no, I didn’t forget PaaS. PaaS just brought confusion as it primarily solved problems for coders and, while I think PaaS is AWESOME, there’s still an education phase for this one. A new hope (coincidentally, Star Wars, Episode IV) While pushing better business, the efficiency (automation/orchestration) drive is definitely creating headaches – how many different/conflicting SDN pitches did you hear in 2014? New terms like SDN create for new stories, but lets keep the focus on reducing human latency. The best people I’ve ever worked with are those who have focused, primarily, on removing themselves from policy validation (safely) to ensure rapid execution. But there’s always a line…. all your base are belong to us!iApp + iControl
#iapp #iControl #orchestration In the past few years there has been a lot of talk about dynamic data centers, automation, orchestration, etc. iApp has a very large benefit in these environments that might not be completely obvious. Last week I met with a customer who was responsible hosting managed applications and support services for their enterprise customers. To implement configuration they built a provisioning system to automate infrastructure and application services based on the user’s inputs. That included scripting each step individually to configure the ADC. Remember that iApp templates can reduce configuration steps up to 90%? Well they are also iControl enabled. That means that whether a template is configured via the UI or API the complexity and time to deploy is equally reduced. Also since an iApp service is just another object, deploying one can be done in a single call regardless how complicated the application may be. So with iApp templates they no longer have to script hundreds of calls to build a single application implementation. They can make one call and pass only the required data unique to the customer and the iApp will complete the rest of the configuration on the device. That certainly reduces the complexity and cost to orchestrate our device and simplify automation.
