Financial Services Software App Challenges: Speed and Stability

 ● 04th Aug 2021

4 min read

As the general population becomes more app-savvy and less patient, app performance has become a major issue for any company needing to keep the customer’s attention. 

Need statistical proof?

47% of consumers expect a page to load in two seconds or less, and 40% will abandon a website that takes more than three seconds to load.

Three seconds is of course an eternity in the age of 5G and IoT. A LOT can happen in those three seconds. The problem is that for a lot of companies, not ENOUGH is happening in those three seconds because the application is getting stalled by things that should have been discovered in pre-production. 

Let’s briefly examine why speed and stability are such a challenge for financial services applications and what DevOps teams can do to make sure their apps perform to modern-day standards. 

Why Continuity is Key

As covered in our previous finserv app challenge blog on downtime, a lot of DevOps issues that ultimately translate into application issues come down to not testing early or often enough. 

To really get good at speed and stability, DevOps teams need to have all of the “continuous” stuff in order, including their:

  1. Continuous integration
  2. Continuous delivery
  3. Continuous testing
  4. Continuous reliability
  5. Continuous monitoring

All of those things have to be there. Otherwise, they are setting themselves up for the typical application issues that lead to performance problems. 

DevOps teams need to be running continuous integration and continuous testing suites in a consistent manner all the way up to production. They shouldn’t be waiting for production to discover these issues. 

Ultimately what this means is operational discipline. DevOps teams need to shift left to ensure all the monitoring and testing is done pre-production. 

The Importance of Upstream Communication

A typical software development lifecycle involves four or five or “handoffs”. The devs hand it off to QA, QA hands it off to performance guys, the performance guys hand it off to staging, then security, then UAT, and so on, until it arrives at IT ops. 

The problem is, the IT ops people don’t communicate the same way developers do. 

Think of this hand-off cycle as the game “rumors”, where someone whispers into someone else’s ear, that person whispers the same thing into another person’s ear, and so on, through five or six people, until the last person says what the phrase is. Rarely is it identical to the original phrase. 

The same thing happens with these handoffs. 

So the question becomes:

How can your developers get information into the hands of people upstream as quickly and accurately as possible? You need to be informing the systems that need to be dealt with down the line. If defects arise in pre-prod, all teams need to know. 

How can you get information back and fixes forward so that there’s agile development, agile deployment, and agile resolution throughout the software development lifecycle?

Good logging—not just lots of logging but the right kind of logging—helps with this. So does avoiding a bad signal-to-noise ratio. Any boy-who-cried-wolf scenario will eventually get people to stop listening. Focus on the things that need to be paid attention to so that when an alarm goes off, your teams know that it matters. 

That said, spending too much time on logs or placing too much importance on logs can cause issues as well. 

For more on that, and for the full conversation around speed and stability issues for finserv apps: click here to listen to the full conversation. 

Related Panel Discussion: 4 BIG Software App Challenges For FinServ

This past May, Bob Kemper, VP of Worldwide Engineering at OverOps, and Anders Wallgren, VP of Technology Strategy at CloudBees took part in a panel discussion on the 4 BIG Software App Challenges For FinServ. In part 3, the two discuss  the challenges of speed and stability.

Troubleshooting Apache Spark Applications with OverOps OverOps’ ability to detect precisely why something broke and to see variable state is invaluable in a distributed compute environment.
Troubleshooting Apache Spark Applications with OverOps

Next Article

The Fastest Way to Why.

Eliminate the detective work of searching logs for the Cause of critical issues. Resolve issues in minutes.
Learn More