Modern Security- & Load-Testing with VSTS when bound to on-premises
In many enterprises Azure is the strategic public cloud. But it still can have technical or organizational blockers which prevent you from fully profiting from the public cloud. Embracing modern DevOps practices to optimize and simplify the process of creating end user value is much harder if you build on top of legacy processes and hardware. Based on a real life scenario I'm describing in this post how you can use cloud technology to practice at least a bit of DevOps even if your organization is still not ready yet for public cloud.
The scenario
We are talking about a massive eCommerce web application (built with ASP.Net Core) that faces the extra challenge of not being able to leverage public cloud technologies. The development team for this eCommerce platform consists of 30 developers which contribute from two locations (onsite & nearshore). They are sharing an on-prem TFS 2018 with other dev-teams but have their dedicated build server. The application itself runs on Windows behind an IIS webserver.
Beside using latest ASP.Net Core technology this is pretty much the classical way how application are getting developed and deployed. The application is ready to be containerized, but external dependencies do not allow a deployment to a Docker-hosted environment at the moment.
How VSTS & Azure still enable DevOps
As the platform will have a massive user load it is absolutely crucial to test the application under load on a regular base starting already early in the development process. But the initiative of getting a dedicated on-prem environment with (1st) the load-generator agents and (2nd) the application itself to run the load against would probably have died due to complexity on an early stage.
To unlock this situation we have chosen a fully cloud based solution. As a prerequisite all relevant interfaces of the application have been mocked (https://en.wikipedia.org/wiki/Mock_object). Then the application gets deployed to an Azure VM (automated though TFS Release Management) and the cloud-based load-test from VSTS simulate user-load for the application running on the Azure VM. In addition to this Application Insights (https://azure.microsoft.com/en-us/services/application-insights/) is activated only on the application instance running on this Azure VM what provides us dozens of additional metrics while the application is under load.
Continuously more and more important is security testing and especially considering the OWASP (https://www.owasp.org) threats. Executing scans with the ZAP (Zed Attack Proxy, https://github.com/zaproxy/zaproxy/wiki/Downloads) again requires hardware for this proxy-software as well as for triggering the requests.
Extending the scenario from above with a second Azure VM which hosts the proxy and a VSTS build definition which makes use of the test task coming with this VSTS extension (https://marketplace.visualstudio.com/items?itemName=kasunkodagoda.owasp-zap-scan) is our easy and efficient solution to run OWASP security tests on a regular base.
What if…
With this solution cloud based security- and load-tests are possible although no data (not even source code) is stored in the public cloud. But without any boundaries in leveraging public cloud (VSTS & Azure) the ALM (Application Lifecycle Management) process could still be much more efficient:
- Containerizing the application and running it as micro-services on a managed infrastructure (e.g. AKS, /en-us/azure/aks/) would give you full flexibility in terms of scalability and provisioning additional environments by reducing the operational effort to rare minimum.
- The execution of the mentioned Security- & Load-Tests could be orchestrated as part of the existing build-, test- and release-pipeline
- When working on VSTS you automatically profit from the newest features and get rid of upgrading TFS once or twice a year.