For years we’ve been told ‘there’s an app for that’. And thus far, I have found that to be mostly true. I have apps for things I never thought I’d need an app for. But when I did and went looking there it was, like magic.
Now, no one goes around saying ‘there’s an application service for that’, but maybe they should. At least in the confines of IT. Because just as there’s often an app for what I need to do, there is often an application service for what a developer needs to do – or address – in production environments.
Take security, for example. It was the number one pain point in production according to developers in a RisingStack survey.
Now, the survey didn’t go into details with respect to what, exactly, about security is a pain point (though I’m sure if asked we’d get a wide variety of responses). What I do know is that 38% of respondents in an app role (developers) in our 2018 State of Application Delivery survey tagged “increasing sophistication of attacks” as their number one security challenge for the next year. 26% said a lack of IT skills in security, and 23% said difficulty in securing applications – particularly web apps – from attack.
If we view the pain point through that lens (and since it’s my blog, I’m going to) then there is an application service for that. Several, in fact. Even if the goal is to virtually patch or prevent an existing vulnerability from being exploited.
And there are a lot of those out there. The thing is that every breach, every unauthorized access, every bit of data that leaks tends to be blamed on a developer – even when the vulnerability was in a third-party library or hidden deep in the packets of a protocol or in a platform used by millions (literally) of other sites on the Internet. But Lori, you’re thinking, the 79% of an application comprised of libraries only accounts for 2% of known vulnerabilities according to careful inspection.
And yet some of the highest profile breaches and data loss have been due to that 2% – vulnerabilities in platforms and common libraries shared by millions of people.
A web application firewall (one of the thirty application services we track in our annual survey) addresses both – and the growing portfolio that attackers use to gain access, drain resources, or steal data. App access control, too, provides a layer of protection for credentials (valuable themselves) as well as the application and its data. Worthy of note is that 75% of all respondents in our annual survey indicated they use App access control to protect applications both on-premises and in the public cloud.
Likewise, performance is not something a developer can always control. There’s the impact of code standards – which err on the side of long term sustainability – on app performance. Sometimes you can’t use the most efficient data structure or syntax. You have to keep in mind that someone else has to maintain and modify that code down the line. Sometimes it’s the impact of variables outside your control – capacity, demand, network conditions, and that customer that refuses to give up on that ten-year old PC running Windows ME.
There’s an application service (several, actually) to address that pain point, too. A veritable plethora of options from TCP optimization to caching to compression to offloading expensive cryptographic processing. All these application services can improve performance and delight users.
A good number of folks already employ just these services to make their apps go faster and safer, addressing both pain points of performance and security.
But developers indicated it isn’t just security or performance problems that give them headaches in production, it’s also deployment – which focuses on how you get those apps and application services executing in production.
This is bigger problem that can’t be solved by a single application service – or even a chain of application services. Solving the deployment pain point requires a more strategic initiative around automation and orchestration and embracing DevOps ideas like infrastructure as code.
It takes a concerted effort to move traditional NetOps to embrace the principles and methodologies of DevOps to codify the processes necessary to deploy the necessary changes in production required to support developers.
That means infrastructure vendors must provide API-enabled infrastructure, and support the ability to operate in a more declarative model that relies on templates and deployment artifacts rather than CLIs.
Of the three pain points developers note, deployment is the most difficult to address because there is no single tool or technology that can solve it. It requires collaboration and a concerted effort to transform IT from a manually driven deployment model to the automated assembly line approach of the future.
Regardless of the ease or difficulty in addresses developers’ pain points, the fact is all three can be addressed by NetOps in production. Whether with a liberal helping of application services or a more dedicated effort to internal digital transformation, NetOps can make moving into production a less painful – and more successful – experience for everyone.