BLOG

App Services as Code

Lori MacVittie Miniatur
Lori MacVittie
Published May 31, 2016

App services, those often misunderstood layer 4-7 (TCP up to HTTP) services that provide for the scale, security, and performance of applications when delivered over networks (which means, basically, all of them today) are an integral part of the software deployment pipeline that ultimately gets apps into production and the hands of the users (corporate and consumer) that need them.

soad16 app svcs 1

Whether it’s load balancing, web application security, or performance-related caching and image optimization, a majority of organizations (60%) use more than 10 different “network” services that sit between the user and that Very Important Application.

Because these services are essentially sandwiched between the network and the app, they are dependent on both. Which means they have specific configurations required to fit properly into the network architecture as well as the application architecture. They can’t just be “dropped in” and voila, off they go. Many of them, too, require specific tailoring to really provide value to the app. A web application firewall, for example, can provide basic protocol (TCP and HTTP) security for any app without much tweaking necessary. But to validate specific input and verify output requires a bit more work. It’s worth it, but it does take time and effort.

Which is where we run into problems. See, moving apps through production is pretty frustrating these days. While agile and DevOps is churning out apps and microservices and deploying with increasing frequency, in production it’s still slower going. The speed bump in the time to get to market that is production (because of the complexity inherent in network and app services) isn’t helping business achieve the agility it needs and it’s certainly not lowering the operational costs per application critical to scaling both IT and the business as it delivers apps more frequently.

That’s why a DevOps approach to deploying network and app services is so critical today. The ability to rapidly roll out consistent, repeatable, and predictable app services that provide for the availability, security, and performance of applications is necessary. And it’s necessary not only to speed up the process, but to keep the costs down and enable the other IT ops teams (network, infrastructure, security) to scale cost effectively and efficiently.

 

what are app services

One of the ways to do that is by treating app services as code. That means taking advantage of templates for common services that can provide standardization by encapsulating core security and delivery policies, and using APIs to both deploy and tweak those policies to meet the unique requirements of a given application. By enabling services to be treated like code, the production pipeline can be streamlined to automatically pull from repositories the appropriate service template at the right time and deploy it lickety-split.

This approach addresses one of the biggest challenges in production deployments of applications in traditional data centers: the disparity between the production network architecture and that of dev/test and QA. Because many network and app services are still deployed on custom hardware platforms, they are rarely duplicated in other environments. That means provisioning and configuration cannot occur except in the production environment. But with the advent of programmability options such as templates and the availability of virtual platforms, such services can be created, tested, tweaked, and validated as portable templates that can move from virtual to physical to cloud platforms with alacrity. These templates become the “code”. It is stored, versioned, and revised as architectural artifacts that can be easily integrated into a more automated deployment process which speeds up deliver of the application to its users. This approach further encourages collaboration and sharing as the services can be shifted left, enabling ops and app dev to help craft the policies that are best suited for each application or service and ensuring compatibility sooner, rather than incompatibility later.

This is one of the core premises upon which not only DevOps operates, but SDN and SDDC, too. There are variety of platforms and frameworks that currently support treating app services as code, such as OpenStackCisco ACI, and VMware NSX. We (that’s the corporate We) support it, as well, not only offering templates like iApps and APIs like iControl but now an orchestration-enabling platform, iWorkflow, as well.

This is the future of infrastructure, to be as agile and deployable as code whether it actually ends up on custom hardware, virtual images, or somewhere in the cloud.

You can learn more about our latest software, iWorkflow, and how it enables a software-defined approach to provisioning and deploying app services on DevCentral at https://devcentral.f5.com/iWorkflow