The 12 Factor App methodology has been a go-to guide for people building Microservices for many years. In it’s time, it presented a step change in how we think about building applications that were built to scale, and be agnostic of their hosting. As applications, and hosting, have evolved, some of these factors need to evolve, specifically, factor 11 “logs” (which I’d also argue should be a lot higher up in the ordering).
What is the 12 Factor App Methodology?
12 Factor App is a methodology for the building of applications in a way that allows them to be independent, easily scalable, and ultimately composable to create a system that works together. It was defined by the teams at Heroku in around 2011, and has held up very well over the last decade due to the principals being well thought-through and agnostic of implementation details.
What is Factor 11?
Factor 11 refers to “Treat logs as Event Streams”, and more specifically “A twelve-factor app never concerns itself with routing or storage of its output stream”.
The intent here is very clear. Don’t make operators of your service (whether that’s you or another team) think about anything other than a stream of data. Being really clear, the thing that we’re avoiding is having to mount a disk for logs to be written to so they can be tailed and aggregated. You should strive for standardisation, so that all services have the same output.
These are great goals, and the intent is still valid. However, this factor does go into implementation details of using stdout to push logs, and this is where I think we’ve evolved as an industry.
What is OpenTelemetry?
OpenTelemetry was founded as a means to bring together different mechanisms that engineers were using to output telemetry signals from their systems. One of those being logs, the others being Traces and Metrics. The idea was to provide a unified way of thinking about telemetry across languages and frameworks, then to provide a consistent, standardised, format for forwarding that data out of the application. They created something called the “OpenTelemetry Line Protocol” which is a protocol and set of standards of how to output Logs, Traces, and Metrics from your application so that backend observability platforms can take them and provide visibility and insights.
You’ll notice that there are similar goals here, and therefore I believe that OpenTelemetry supersedes Factor 11 in a good way.
What about stdout?
The idea around using stdout and essentially “logging to the console” was to provide a consist transport for the data in such a way that external aggregation systems could gather it. Unfortunately, this requires conversion and writing of data in text format, which is not always the most efficient way. In addition, as we promote Structured Logging as an industry, we’re essentially Serializing information, just to deserialize it later.
Within OpenTelemetry, there are now better, more efficient ways to send this information such as gRPC and HttpProtoBuf. Then, due to the documentation/standardisation of Environments across languages, operator can forward that wherever they want without changing the code.
Conclusion
12 Factor App Methodology is still valid today if you look at the intent. When looking at the logging portion, think about this as a wider concept of “telemetry” and consider whether stdout is, in fact, the right way to transmit the data.
MartinDotNet 
Leave a Reply