DEV Community: Alexis Jeanpierre MARTINEZ VARGAS

Simple Observability Practice with Python and Prometheus: How to See Inside Your App Without Touching It

Alexis Jeanpierre MARTINEZ VARGAS — Wed, 02 Jul 2025 21:29:43 +0000

What are Observability Practices?

Observability is the ability of a system to enable a deep understanding of its internal behavior based on the information it emits externally. This includes metrics, logs, and distributed traces. In other words, observability isn't just about monitoring whether an app is "up or down," but about understanding how and why it behaves the way it does.

Imagine your system is like an airplane in flight. You can't open it to see what's going on inside, but you have instruments: altimeter, speedometer, temperature sensors, etc. The same is true of modern software: it's often in production, far from the development environment, and we need those tools to "see inside" without touching anything.

Observability practices are the set of strategies, tools, and conventions that allow us to systematically collect, structure, and analyze that information. These practices typically include:

Code instrumentation to generate metrics (such as the number of requests per second)
Configuring detailed logs with different levels (info, warn, error, etc.)
Distributed tracing across services to follow a request from start to finish

An observable application is one that, in the event of any failure, degradation, or unusual behavior, provides the necessary signals to detect, understand, and resolve the problem, without the need for guesswork or invasive testing.

What is observability for?

Observability isn't just useful in emergencies: it's essential for operating modern software reliably, especially in distributed systems, microservices, and platforms that scale to thousands of users per minute.

Its main functions include:

Detecting errors or unexpected behavior in real time: for example, sudden drops in traffic, latency spikes, or database connection errors.
Measuring the performance of critical functions: identifying which parts of the system consume the most resources, take longer, or execute abnormally frequently.
Generating automatic alerts when something goes wrong: integrating with systems like Grafana, Datadog, or Prometheus AlertManager to react before users notice.
Analyzing trends and usage patterns: allowing you to anticipate bottlenecks, prepare for scalability, or plan infrastructure changes.
Facilitate debugging in production: without the need to replicate scenarios locally or disrupt the system, since observability gives us a clear map of the flow and state of the running system.

What problems does it help solve?

Let's take a concrete example: an order processing microservice in an online store. It works perfectly in development, passes all tests, and is deployed to production. Everything seems fine... until:

The response time becomes slow at certain times.
Some orders aren't processed correctly.
Performance metrics start to fluctuate without explanation.

Without observability, it would be impossible to know what's going on. We'd only see users complaining or some orders not arriving, without knowing where the fault lies.

With good observability practices, we could:

Know how many orders are processed per minute or per hour
Detect how many fail and with what exact frequency
Visualize how long each order takes on average, and when that duration spikes
Correlate events (such as errors or load spikes) with recent changes or external conditions
Have exact traceability between services in a microservices architecture

Simple Practical Example: Observability in Python with Prometheus

We created a small Python service that simulates order processing and exposes custom metrics through Prometheus.

Technologies used:

Language: Python
Metrics: prometheus_client
Automation: GitHub Actions
Container: Docker
Repository: Public GitHub

What does the program do?

Processes orders every second (simulated)

Records custom metrics:

orders_processed_total
orders_failed_total
order_processing_duration_seconds

Exhibition at: http://localhost:8000/metrics

Metrics view in the browser

Full code on GitHub

You can see the full code, structure, Dockerfile, and automation configuration here:
https://github.com/WhiteFall20/Simple_Example_Observability.git

Conclusion

Observability is no longer a luxury or a technical "plus": today, it is a fundamental necessity in the development and operation of modern systems. In times of increasingly distributed architectures, higher user demands, and more costly errors, having visibility into the real state of the system is key to ensuring software quality, scalability, and reliability.
This small project demonstrates that even with basic tools like Python and Prometheus, effective observability practices can be implemented: capturing custom metrics, analyzing them in real time, and automating processes through GitHub Actions. No complex or expensive infrastructure is required to get started.
Furthermore, observability not only helps resolve problems when they occur, but also allows for preventing them, making informed decisions, and learning from system behavior in production. Ultimately, it is a tool for knowledge, continuous improvement, and technological maturity.

Organize Your Code with the Service Layer Pattern: A Simple Python Example

Alexis Jeanpierre MARTINEZ VARGAS — Thu, 10 Apr 2025 19:37:09 +0000

Introducción al Diseño de Software Empresarial

In software development, especially in enterprise applications, it is essential to keep the code clean, organized, and easy to maintain. As projects grow, so does the complexity of the business logic. This is where design patterns play a key role.
One of these patterns, commonly used in architectures such as MVC (Model-View-Controller) or REST APIs, is the Service Layer pattern. Its main objective is to separate business logic from the rest of the system, such as the user interface or database access.

What is the Service Layer Pattern?

The Service Layer pattern centralizes an application's business logic. Instead of distributing business rules across controllers, views, or directly in the model, this logic is organized in an intermediate layer: services.
Imagine you have an ordering application: without a Service Layer, you might have validation logic in the controller, part in the model, and part in the frontend. This becomes difficult to maintain and error-prone. The solution is to encapsulate all the business logic in a service class or module.

Why is it important?

The Service Layer pattern not only helps you have cleaner code, it also provides benefits such as:

Modularity: Clearly separates what part of the system does.
Reusability: The same service can be used in different interfaces (API, console, web, etc.).
Maintainability: If you need to change a business rule, just update the service.
Testability: Having isolated logic makes it easier to write automated tests.
Scalability: Allows you to grow without turning your code into chaos.

Example without Service Layer

Let's look at a typical case where the pattern is not applied and everything is mixed in one place:

This code seems fine for a small project, but what if you now have to:

Validate if the user exists
Check if the product is in stock
Apply a discount based on quantity
Send a confirmation email The controller will quickly become cluttered with business logic, becoming unmanageable.

Refactoring using Service Layer

We apply the pattern and move the business logic to an OrderService class:

Now the controller only coordinates, while OrderService is responsible for applying all the rules necessary to place an order.

Github link for those interested: https://github.com/WhiteFall20/Example_Simple_Service_Layer.git

How does it look in real architectures?

This pattern is very common in frameworks such as:

Spring Boot (Java): @Service classes contain business logic.
Django (Python): Although not enforced, it is a good practice to create a services/ folder.
Ruby on Rails: Many teams create app/services to implement this pattern.
Laravel (PHP): It is recommended to separate logic into service classes.

When to use this pattern?

When your application has rapidly growing business logic.
When the same process is executed from multiple interfaces (API, CLI, etc.).
If your project is very small and doesn't have complex business rules, you may not need it yet.

Conclusion

The Service Layer pattern is a powerful tool for keeping your application organized, clear, and scalable. Although it may initially seem like it's adding more classes or files, it actually prepares you for project growth and improves code quality.
Applying this pattern is a step toward professional software design, especially in enterprise applications. Don't underestimate it!

Avoid Duplicate Code with DRY: A Simple Python Example

Alexis Jeanpierre MARTINEZ VARGAS — Fri, 28 Mar 2025 20:56:51 +0000

Have you ever copied and pasted the same code into multiple parts of your project?
This is a big problem because it hinders maintenance and increases errors. This is where the DRY (Don't Repeat Yourself) principle comes into play, helping us write cleaner, more reusable, and maintainable code. In this article, we'll see how to avoid code duplication with a simple Python/Java example.

Introduction to Software Design Principles

Software design is a fundamental discipline in software engineering that focuses on planning and creating efficient, maintainable, and scalable systems.
Software design principles are guidelines that help developers make informed decisions during the development process, ensuring that the software is robust and easy to maintain.
One of the most important principles in software design is the DRY principle (Don't Repeat Yourself). This principle states that code duplication should be avoided whenever possible. The central idea is that each piece of information or logic should have a unique representation in the system.
This not only reduces the amount of code that must be written and maintained, but also minimizes the risk of errors and consistency issues.

What is the DRY principle?

The DRY principle was coined by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. Its central idea is that code repetition is a sign of poor design.

When the same code is repeated in multiple places, any changes or fixes must be applied to all of those places, increasing the likelihood of errors and making software maintenance more complicated.

Why is it important in software development?

Implementing the DRY principle involves identifying and abstracting common patterns in code, encapsulating them into reusable functions, classes, or modules.

This not only improves code clarity and readability but also facilitates collaboration between developers and the evolution of software over time.

Key Benefits:

- Reduced redundancy: Less duplicated code means less work and fewer opportunities for errors.

- Ease of maintenance: Changes are made in a single place, simplifying software updates and fixes.

- Improved readability: Cleaner, more organized code is easier to understand and follow.

For these reasons, the DRY principle is considered an essential practice in coding and has been chosen as the primary focus for this article.

Brief example of what happens if we don't apply DRY

# Repeated code in multiple functions
def calculate_rectangle_area(width, height):
    area = width * height
    print(f"The area of the rectangle is {area}")

def calculate_square_area(side):
    area = side * side
    print(f"The area of the square is {area}")

def calculate_triangle_area(base, height):
    area = 0.5 * base * height
    print(f"The area of the triangle is {area}")

# Function calls
calculate_rectangle_area(5, 10)
calculate_square_area(7)
calculate_triangle_area(6, 8)

Problem

In this example, each function calculates the area of a geometric figure and then prints the result. Although the formulas are different, the calculation pattern and printing of the result are repeated in each function.

This violates the DRY principle because we are repeating the printing logic in each function.

# General function to print the area
def print_area(shape, area):
    print(f"The area of the {shape} is {area}")

# Specific functions to calculate the area
def calculate_rectangle_area(width, height):
    area = width * height
    print_area("rectangle", area)

def calculate_square_area(side):
    area = side * side
    print_area("square", area)

def calculate_triangle_area(base, height):
    area = 0.5 * base * height
    print_area("triangle", area)

# Function calls
calculate_rectangle_area(5, 10)
calculate_square_area(7)
calculate_triangle_area(6, 8)

Explanation of the change

In the improved version, we have extracted the printing logic into a separate function called print_area. Now, each calculation-specific function calls print_area to print the result.
This eliminates code duplication and makes the code easier to maintain. If we need to change the way the area is printed in the future, we will only need to modify the print_area function instead of changing each function individually.

Result of applying good practices

Reduced redundancy: We eliminated unnecessary code, which reduces the amount of code that needs to be maintained.

Ease of maintenance: Any changes to the printing logic are made in a single place.

Improved readability: The code becomes clearer and more organized, making it easier to understand and maintain.

For anyone interested github link: https://github.com/WhiteFall20/Example-DYR-Alexis-.git

Conclusion

The DRY principle is one of the best practices in software development. Its application helps us reduce errors, improve code organization, and facilitate long-term maintenance
However, it is important to keep in mind that it cannot always be applied in all contexts. There are projects that follow specific standards depending on the company or where, for time reasons, refactoring is left for later maintenance.
Despite this, the DRY principle remains a fundamental pillar in software development, and it is always good to remember and apply it whenever possible.

Acknowledgments

I would like to thank my parents and family for supporting me in my career in Systems Engineering. I also want to thank everyone who reads this article, as this is my first time posting on Dev.to. I hope you find it useful and that it helps you improve your code.