Must haves before you call your application production ready

As developers, we want to create an application that our users would love using. To achieve this we keep thinking of new ideas and adding new features to our app. We loose track of how a small chat app has grown into a huge social networking app. That is why, as soon as we realize that we have put in a lot of time and effort for the pilot — with the first chance we ship this app to production. But in this hustle, we forget asking ourselves a very important question.

Is my application production ready?

Surely this question is very subjective, and the answer varies from developer to developer & organization to organization. Some would even argue that I’ve tested my application end to end — from all user flows to the last button click to ensure its expected outcome. But is that all you need? No! I know this would hurt but, there is one critical aspect still missing. You have ensured that the application is working for you at say 12.30 PM from xyz city. This does not guarantee that the application will work for every user coming from any part of the world at any given time. Now how do you achieve this? Here are 6 simple must-haves that will help you achieve this, without which your application is still not production ready.

Deployment tool — How do I release a new feature?

I can see that smirk on your face. Yes, you sure can manually log into the production server and run a simple git pull, npm install and other commands needed for deployment with every new release. But don’t forget

Developers too are humans

We sometimes forget stuff, confuse the terminal windows, become lazy and assume stuff. But when your application is visible to the world, you cannot risk your application with these human errors. It is of utmost importance that your application is up and running at all times — even at the time when you are deploying new features. This can be achieved only if we remove the manual part from it. To do this use a deployment tool that suits the application’s need and allows you to gracefully handle deployments. This would also save a lot of time in the long run. Some tools that will help you achieve this are Shipit, Capistrano, etc

Web Server — Do I have an IT team to manage the web server?

This is an important choice and needs a good amount of research. Choosing the web server depends on multiple factors like a programming language, framework, traffic, etc. So instead of telling you which web server is the right one, I’ll tell you which server could be a wrong choice.

• 
  

  **Single threaded**Single threaded servers are a big no in the production environment for obvious reason, that your application has to serve multiple requests at the same time.

• 
  

  High maintenance serverChoose a server that doesn’t have to be maintained. By low maintenance I mean the one that can be quickly up and running with minimum config changes. Basically, the one has sensible defaults already set in place.

• 
  

  **Recoverability**Let’s be true to ourselves and accept a fact that any application can crash. Because every application these days relies on some external plugins, APIs, tools, infra that is not owned and maintained by us. So we should be prepared for that. Even if any of the dependent services fail for a millisecond, our app server will be able to recover the application as soon as the dependent service is back online.

Some good and common examples handling the above issues are — apache and nginx.

Monitoring — What’s my API response time?

Monitoring is nothing but keeping a watch on your application 24 by 7, for all the 365days of the year for its performance and availability. This gives you a customer’s eye view of your application, which in turn will avoid the chances of making assumptions about application stability. Monitoring has many many benefits but here are a few key benefits:

• Gives you end-to-end visibility of the user experience.
• Helps you take a data-driven decision about when you need to optimize your code.
• Helps you make the right infrastructural choices for your application.

Some performance monitoring tools worth exploring are Newrelic & Appdynamics.

Logging — Can I debug an issue with my logs?

I’m sure your framework logs something or the other to a log file, all frameworks these days do. But is that enough? Check the below pointers before making up your mind for a yes.

• 
  

  FilteringUsers want to feel safe when they are using your application. Maybe you are the only person having access to the log files, but you never know how soon your application will scale. So filtering all logs that have sensitive information like tokens, passwords or anything that is private and sensitive will make sure you have taken the first step for user safety.

• 
  

  Centralised loggingThis is often ignored by the aspect of logging. Yes, you can do without having this, but just like monitoring this would prove to be a valuable insight as your application grows in size to multiple instances. Two elegant solutions for this are Graylog and Logstash.

Alerting — Is my application really down?

This is the most important point from the list. You as an application developer should always be alerted if your application is not behaving as expected. You can choose any option to get an alert, maybe via notification, email, SMS or by a phone call. The criteria of when you should be alerted can be configured inside the monitoring tool itself. Few examples when you should be alerted can be:-

• API response time greater than expected
• The error rate in the application (greater than 20% for eg)
• Application not responsive (downtime)
• Cron/workers failing

There are many opensource & paid tools available in the market for alerting. Two of the popular ones are pagerduty and pingdom.

Tracking — are users loving the new like button?

If your application is not tracking user behavior, then you are left with no choice but to make all decisions based on assumptions. And many applications fail solely because these assumptions go wrong. Without proper tracking of user behavior, there is no way to know if features that you are deploying are actually being used by users. Tracking can be of many types,eg: user clicks, interactions, views, time spent, bounce etc. There are many interesting tools available in the market for this. Some of the simple ones that you can start with are google analytics and mixpanel.

I do agree that these steps take some time to implement. But once these are implemented, you can see results with every new feature that’s released. It will from time to time help you in making every architectural, security and business decision with ease. You will realize how every minute spent in making your application production ready was worth it.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!