5 Application Performance issues that slow-down your service

5 Application Performance issues that slow-down your service

By |2018-12-13T09:59:51+00:00September 26th, 2018|Categories: Best practice, Engineering, How-to, Know how, Technology, Trends|Tags: , , , , , , |

The 21st century is powered by on-line apps and with the rise of the “Service as a Service” applications, availability is paramount. If a decade ago, usage of such business applications was a privilege of the few, in the recent years: it’s a requirement of the many. With various business models evolving, we can no longer state that custom apps or business digitization services are a luxury – they’ve became as crucial as electricity or water provisioning for an office.

Their utility-like demand, draws countless opportunities; however, service providers face more and more application performance challenges that can lead to service delivery latency or worse: a total outage. Since we’re a custom web software provider, we’ll focus on the main culprits we’ve identified during hundreds of code audit sessions we perform internally and for our trustful partners.

Excessive Resource Usage – one of the main factor that could cripple your cash-flow

Most of the time, service providers respond to increased demand with an equivalent increase of their server resources. While this is a measure that can decreases your application latency it is definitely a misguided application performance management process.

For instance, one of our partners found out that by simply reducing their resources on weekends (when demand fell below 80%) they were saving about 60 EUR per hour in operational costs. Understanding that a constant tune-down/tune-up process, each and every week, involve way too many risks in matters of service availability – they’ve decided to revise their app and find the main cause of their resource usage.

After a meticulous review, it turned-up that 80% of the resources were swallowed by multiple batch-processing operations triggered by their end users. Following on their findings, they’ve replaced their processing approach by making use of data streaming within those resource-hungry operations. In the end, their overall application resource usage dropped with 37% leaving more cash for eventual service development.

Limited scalability will definitely leave you behind competitors

Technology evolves faster that you can plan for and most service providers are faced with the challenge of keeping the pace with their end-user’s demand. This challenge is valid for all kinds of service providers (at least based on our records).

In most of the cases, it’s related to maintaining a monolith system that is in most of the cases way to expensive to scale and way to rigid to allow change. The resolution here would be a complete redesign of your current infrastructure that focuses on a Function as a Service model, leaving you with little or no framework-related dependencies.

Legacy frameworks that cripple your service evolution

In beating their competition to market, adapting to demand is paramount for an online service provider. Doing so could be way too complicated and sometimes quite expensive especially if the app has been released 3 or 4 years ago.

Not to mention the risks you encounter every time you supply new features on an outdated code-base… Running on a monolith, outdated framework is like building a Jenga tower – you never know which brick might fall when you’re changing something.

Let’s agree “if ain’t broken – don’t fix it”, however, when you run a rigid and outdated system there’s less value for your end users and fewer expansion possibilities. In this case, you’re faced with a business decision that only you can take: maintain the outdated framework and stay behind your competitors or switch to a fresh approach (like microservice usage) to stay ahead. Whatever your decision would be, the costs will balance-out, but the competitive advantage might take a serious hit.

A radical business process shift could be the end of your business

If market conditions change, effective decisions regards your provisioning and pivoting at the right time might save your business. This would be next to impossible if you’re not running a malleable infrastructure.

Of course, deploying an app within a serverless infrastructure, based on microservices and focused on a FaaS model might be expensive in the first instance – but life saving if you should ever pivot. In addition to the outage-management, time-to-market and scalability benefits delivered by a modern infrastructure, pivoting within such an environment could save you 10 times your investment.

It will simply allow you to maintain your current system, aid new features on the fly or even change delivery paradigms with less or even no infrastructure hassle – leaving more time to focus on what you’re building: function by function, service by service.

The worst-case scenario: a badly written code that could kill your business model

It is a well known fact: outsourcing can save a load of money you can put to good use. An even a better option (from the financial perspective) would seem to be making use of a freelancer or a group of freelancers.

While there are success stories, the epic fails frequent than you’d imagine. Over 60% of our refactoring jobs are based on poorly written code, architecture mistakes and poor quality control/quality assurance processes powered by one or more freelancers. If you’re a service provider that cannot afford an in-house IT provisioning team – be careful with your choices: If it’s too good to be true – it probably is.

Of course, the list would not stop here – we’ve just outlined the ones EBS dealt with in the past year. Since you are the one running the business, there might be some aspects of interest we’ve not covered. If you’re looking to extend this conversation, our team is here to hear: just drop us a line and we’ll be happy to check, identify and resonate issues that matter.

About the Author:

Adobe CS Geek, Illustrator fan and font-face gambler playing around with words, colors and wire-frames @ EBS-Integrator