article

Why you need Service Templates

Demand for faster time-to-market, for new applications and services, is changing the way entire systems are deployed. No longer will organizations tolerate lengthy delays in the release of revenue generating or productivity improving solutions. Consequently, in a time more competitive than previously experienced, the way in which organizations manage infrastructure and services is changing.

The expectation of doing more with less is a familiar reality for most operations staff. With application development and deployment cycles increasing in frequency, often beyond the capacity of the teams responsible for execution, the requirement for automating workloads has never been more crucial.

Human Latency Improving time-to-market requires of organizations to reduce the impact of “human latency” (delays in waiting for operations staff to execute) in the deployment of application dependencies: the application stack, security policies, application delivery services, high-availability functions, etc. The more automated the implementation of these dependencies, the lesser the effect of human latency.

Programmers have been leading this way of thinking for years. They thrive in the prospect of investing a little extra time to script something today so as to never perform that action again. While striving for maximum efficiency is ingrained deeply within them, programmers do have the benefit of coding experience, enabling them whip up a script with ease.

For infrastructure-managing operation staff scripting often isn’t a familiar second language. Becoming proficient with scripting requires experience and frequent exposure to the appropriate languages. Fortunately, modern REST API’s have made automation much simpler and the promise of reduced human latency is now an obtainable goal for all.

Abandon the GUI/CLI Before successfully automating the configuration of devices and technologies one must be able to remotely execute administrative commands. Of a device or technology presenting only a web interface, or command line interface, this process is difficult. Sometimes impossible. The first step of automation is achieved via open, well documented, application programming interfaces (APIs).

For a regular task that may be performed daily, or even weekly, streamlining deployments via an API will:

Execute much faster than on-device via GUI/CLI administration

Reduce exposure to risk through less time at the keyboard

Provide a foundation for a further automated future

Firing commands at a management API will return some quick wins but the greater benefit comes from automating the execution of these commands. As depicted so brilliantly in the diagram below, automation does require a small investment of time up front, which is quickly transformed into reduced operational expense in the future.

Source: http://imgur.com/gallery/Q8kV8

Orchestration of the automated In many cases, the configurations and policies used by organizations are repeatable, requiring only a subset of information specific to each deployment: domain names, IP Addresses, etc. However, introducing an orchestration system that is unfamiliar with the intricacies of each individual device and technology it must touch can result in integration headaches. Whether the chosen orchestration system is acquired or home-grown, it will not understand each and every configuration permeation of the 3rd party, vendor technologies it must deploy. The answer, simplification and abstraction through service templates.

For those unfamiliar with service templates, think of them as being like restaurant menus. Restaurants provide a service in the form of creating culinary delight. Upon arriving at a restaurant, one is presented with a menu for the purpose of describing the available options, but without the many steps involved in each meals creation. For example, if a steak comes with a peppercorn sauce, the customer doesn’t need to know the details of how the sauce is made, or from where the ingredients are obtained, only that it is a peppercorn sauce and it comes with the steak.

The menu provides an abstraction of the process–each step of preparation, cooking, timing, and presentation–from the end result. The alternative, years of schooling and experimenting in how to cook everything for oneself.

Service Templates Take this practice back to the data center–the concept of providing a menu as an abstraction of complexity–and we have service templates. Such an architecture eliminates the need for infrastructure consumers to become experts in every technology. Instead, approved, repeatable policies can be deployed directly by operation staff, or by 3rd party orchestration systems, at the time of application deployment.

Keeping staff trained up on specialist technology is an operationally expensive task, made even more difficult as products evolve and new features are made available. However, presenting capabilities as service templates enables:

The presentation of services for consumption by a broader audience

Simple integration into 3rd party orchestration tools

Reduction of risk through the elimination of manual configuration/implementation

F5 delivers API reference-able, service templates known as iApps. Through the implementation of iApps as part of their data center architecture, F5 customers have been reducing:

time-to-market for revenue generating and productivity improving apps and services

time-to-react in the face of planned and unplanned circumstances

exposure to risk through the reduction of manual intervention

With F5 iApps, application services are deployed faster, more consistently, and at the speed of business.

Great vision here from F5. It will take some time to have service catalogs comprehensively addressing all parts of BIG-IP I suppose (ultimately: no manual configuration necessary). May we get more abstraction of complexity for APM (specifically VPE, customization) in iApps and the API? :-)

This isn't "vision", amolari. We released iApps 4 years ago and customers have been enjoying service template-based automation since.
That said, when it comes to automation there is always the tradeoff of extensive granularity with advanced functions. Are you looking for a method to deploy a common VPE-built policy across many APMs?

I too am interested in APM automation. Specifically what I want to be able to do is have my team build the APM policy with all that entails in our non-production environment and automate pushing it to production with whatever name changes are necessary to reference production resources. (Rather than have them rebuild the APM policy in production.)

Hi amolari, thanks for the follow-up. So, the VPE itself is an abstraction of complexity. Imagine building that out in a conf file?! :) What I am unclear on is what elements you want orchestrated? Is there a common policy you require to deploy multiple times? Or do you have many different policies that you wish to simplify the deployment of? I'm very interested to learn more out the specifics of your deployments.
Thanks,
Nathan

0

About DevCentral

We are a community of 300,000+ technical peers who solve problems together.