The Evolution of Application Development

The evolution of application development has gone through many stages, and each has had its challenges.

It started with monolithic code, which was difficult to regression-test, and was essentially snowflake construction that required longer development cycles. We then moved to dedicated/embedded modules written within applications that made testing easier and created the beginnings of reusability. We subsequently advanced best practices to module portability/reusability, which opened the door for both proprietary and open-source module code reuse.

These made the development of similar applications much easier with reusability, but also introduced unknown and un-patchable vulnerabilities due to un-managed code. Each of these was, to some degree, a natural evolution. Each was essentially an incremental improvement over its predecessor, but overall led to significant gains in productivity.

The current movement to containers and microservices is fundamentally different in its offer for ease of deployment, creating the ability for continuous integrations and continuous development (CICD) and improved application performance.

Simultaneously, it brings some intrinsic risks.

[You may also like: 4 Emerging Challenges in Securing Modern Applications]

First, the Benefits

The creation of cloud computing gave CICD its reason for existence. Cloud users demanded quick feature parity with on-premises applications and rapid feature delivery in agile development models rather than interval-based large releases. These needs drove new application delivery methodologies, like containers, microservices, and serverless application deployment, which created greater risk.

Recent research conducted between Radware and Enterprise Management Associates identified a very interesting set of benefits and problems.

Over 45% of respondents said their organizations have migrated/deployed one-third or more of their applications in a container/microservices architecture, with another 45% indicating they are currently testing the waters on how to deploy in a container or microservices architecture or have a plan to begin migration within the next 12 months. That is a breakneck pace for changing application architecture!

[You may also like: Application Security in the Microservices Era]

Why is adoption so fast? 68% of organizations that deployed in the container/microservices architectures say they have seen an increase in security effectiveness, and 61% identified an increase in operational efficiency.

And Now, the Risks

However, it’s not all good news. Fifty-two percent of respondents said their operational costs increased, and 57% said they believe their application risk profile increased.

The questions to answer are why these negative increases occurred and whether they can be reduced. The answer is yes to both.

Operational costs increased due to retooling and education.
The same things happened with major programming technique shifts that happened
previously and as tools for CICD have been deployed. As more developers become
well-versed, education cost spikes should decrease. Similarly, once
organizations select a single or primary tool for container management and the
same for microservices management, those costs will stabilize.

[You may also like: Are Your DevOps Your Biggest Security Risks?]

Decreasing an application’s risk profile will most likely take a little longer, but should also mirror previous trends in application deployment.

Delivering and securing containers and microservices is relatively new. Both application developers and information security personnel are not wholly sure how to best protect them. The standards and best practices are still evolving. Vulnerabilities for ten-year-old software are still being found, so we should not expect these new methodologies to be 100% secure overnight. Prepare, evolve, and apply the necessary resources for due diligence.

Though there may be a few hiccups, all will normalize to a strong, steady state. The benefits are too great for anything but a major, unfixable vulnerability to halt the momentum.