The essence of software development

I have already written here, that when we start coding the most important thing that we should keep in mind is maintainability. Even with other methods than scrum, like waterfall or “perfect planning”, it’s really hard to know beforehand exactly how to develop your system/application. So, if you want to deliver a good software and a great experience to your customers, you should invest time and energy building a high flexible system.

To build a flexible software doesn’t mean to code a software with a lot of layers of abstraction, but a software able to evolve when needed. There’re a lot of good articles about evolutionary architecture out there, I’m not going to detail it. However, it’s important to know that the second most important thing in programming right after having a good test suite is monitoring. A well coded software has a very good and reliable test suite to be able to evolve faster and with a reduced risk. Furthermore, it should have a structured monitoring system so it can grow without concerns about performance.

How to monitor your system

There are two ways to monitor your application:

Pushing: in this mechanism the application is responsible for sending its metrics to the monitoring server. So, the workload inside your application will grow as much as the amount of metrics that you want to have on it. Two famous monitoring systems that use this method are appdynamics and newrelic.

Pulling: on the other hand, the pulling mechanism is responsible only for exposing an endpoint with its metrics and the heavy lifting of extracting and generating metrics is done by the monitoring server itself. The most famous monitoring server using this method is Prometheus.

There’s no right or wrong in this case, if you don’t want to monitor a lot of different aspects of your application, it is alright using a pushing mechanism. However, if you have a lot of metrics and you want to see them frequently, sending them to the server could be too expansive. In the former case, it could be better using a pulling mechanism and prevents your application from the whole workload.

What you should monitor

Three main points should be monitored:

Environment: It doesn’t matter if you are using kubernetes or a bare metal machine, you should monitor your CPU, RAM and disk usage.

Application: Memory usage, response time, endpoints and health check.

Business flow: this is the most controversial monitoring aspect. Some purists say that you shouldn’t mix business and technical metrics in the same monitoring server; however, if you put your business metrics in a prometheus, for example, you will be able to create alerts, graphs and a lot of visualizations with much less effort.

At the end of the day, we all know that we are going to code software with strict deadlines and with a lot of uncertainties, as a consequence we have to be open to evolve fast and reduce our chance of error. Let’s test and monitor, shall we?

• architecture
• monitoring
• development