Why Shift-Right is Essential for SaaS Applications

SaaS DevOps Needs to Include Post Deployment Monitoring

To many IT software teams, the mantra currently fashionable for team practice is “shift-left.” That refers to moving certain activities, such as code integration, build, and testing, earlier in the software development and delivery process. By shifting them to the left, the team knows more about code quality and performance earlier, allowing for corrective action and making them nimbler in response.

There is a lot of value in shifting these and other IT software activities earlier in the lifecycle. However, while shifting left makes sense from the standpoint of application development, monitoring, testing, evaluation, and remediation also benefit significantly when the team shifts right, past deployment and into active production.

The DevOps movement has brought a great deal of validity to this concept. Multi-functional teams worked together to manage software from conception to delivery and beyond, ensuring that the application is supported by the same team that developed it. And because of continuous integration and continuous deployment strategies, the code base is rarely fully tested before it becomes the production version.

Monitoring is Common for SaaS Applications

The shift-right idea is rapidly moving into the mainstream, with software teams devoting resources to what happens after an application is deployed. Until recently, that application became the primary responsibility of the IT group charged with keeping servers and software running. Only when there were obvious defects or need for enhancements did the development team once again get involved.

Instead, today’s DevOps teams own the application through development and into production. Cloud deployment, a hallmark of DevOps, makes it even more difficult because the cloud application environment is very different from a hosted one. The performance and behavior of the deployed application can be very different from what they might expect, based on architecture and development practices.

That means they need to look carefully at applications in production, in order to first baseline performance, and then evaluate and correct performance trends over time, as necessary. Let’s look at why both of these steps are needed.
Baselining enables the enterprise to determine initial performance based on real user interaction. It provides a set of evaluations that can be used to understand how the application performs under initial circumstances. While initial performance may not be ideal, it provides a starting point to determine both improvements and degradation.

At the same time, using tools like Exoprise CloudReady, you can get a performance average from everyone who is using CloudReady to monitor the application. This is called data from the crowd, and is essential in providing a comparison between your enterprise’s performance and how everyone else is doing.

That comparison provides you with essential information on how your performance compares against the crowd, and gives you the ability to compare and, if there is a significant decrement from the crowd, to determine where the problem is. By combining your own performance data with data from the crowd, you can both understand your performance characteristics, and determine where any deficiencies arise.

Shift-right using monitoring, trend analysis, and alarms is essential with cloud-based applications. The practice lets enterprises find problems with applications and get them addressed before they become problems for the users. And it’s not just for the developers of an application – it’s for all the teams responsible for the delivery of the app. Delivery, operations and performance of core SaaS applications like Office 365, Salesforce, Box or others can be affected by:

• Group Policy
• Single Sign-On infrastructure
• Proxies, VPNs, MPLS and other network changes
• Integrations with on-premises and other cloud properties
• Electronic Data Interchange procedures

Any of these dependent systems can affect the operations of your live and running SaaS applications.  So if you aren’t yet monitoring your SaaS application in production, it’s time to do so. You will get the information you haven’t been able to get in deployment, and can feed that back to your diagnosis and resolution.