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 realise 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 answer varies from developer to developer & organisation to organisation. 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
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 allow 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 good amount of research. Choosing the web server depends on multiple factors like 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 production environment for obvious reason, that your application has to serve multiple requests at the same time.
- High maintenance server
Choose 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.
Lets 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 are not owned and maintained by us. So we should be prepared for that. Even if any of the dependent service fails for a millisecond, our app server will be able to recover the application as soon as the dependent service is back online.
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.
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.
Users want to feel safe when they are using your application. May be 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 first step for user safety.
- Centralised logging
This is often ignored 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 a 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 phone call. The criteria of when you should be alerted can be configured inside the monitoring tool itself. Few example when you should be alerted can be:-
- API response time greater than expected
- Error rate in application (greater than 20% for eg)
- Application not responsive (downtime)
- Cron/workers failing
Tracking — are users loving the new like button?
If your application is not tracking user behaviour, 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 behaviour there is no way to know if features that you are deploying are actually being used by users. Tracking can be of many type, eg: user clicks, interactions, views, time spent, bounce etc. There are many interesting tools available in 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 thats 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!