Serverless Computing, or simply serverless, is a hot topic in the current software market. More and more companies are shifting their operations from traditional server-oriented architecture to faster, more modular serverless architecture. The “Big Three” cloud vendors (AWS, GCP, and Microsoft Azure) have shown immense interest in offering the best serverless experience possible. But what exactly is serverless? And how does it work if there is no server at all?

In our Configuring OpenTelemetry in Ruby blog post, we showed how to configure OpenTelemetry in a Ruby on Rails backend. In this post, we’ll cover how to configure OpenTelemetry in the front-end JavaScript in order to measure performance of browser and mobile devices and how to configure distributed tracing to work across the frontend and back end telemetry collection. Let’s dive in!

Errors are the necessary evils of software development. They bring to your attention critical information about what’s wrong with your application and what needs fixing before your end-users suffer. Error monitoring tools offer significant help in this cause by aggregating all the errors and issues your applications (and their end users) are struggling with under one roof and providing valuable insights to resolve these and optimize performance.

A monolithic architecture is one of the oldest architectures used for making software and applications for various companies. In layman's terms, Monolith means everything in a single box. Monolithic software is supposed to be self-contained, and its components are interrelated and interdependent. When it comes to monoliths, updating a single component or rolling out a new feature is difficult. Suppose any program component needs an update.

The world is going digital with lightning speed. According to this report by Statista, at the beginning of January 2021, there were 4.66 billion active internet users in the world, which accounts for 59.5 percent of the world's population, and out of this 4.66 billion, around 4.32 billion (92.6%) users have accessed the internet by mobile. All companies regardless of the sector in which they operate, want to use the internet for expanding their business.

The final stage of the popular Software Development Lifecycle after planning, analysis, design, and implementation is maintenance. This is where a full-fledged application running in production is constantly looked after and taken care of. Bugs, bottlenecks, slow database queries, security loopholes, and other issues are discovered and fixed before deploying the updated code. Log records and Application Performance Monitoring (APM) tools play a crucial role in software development maintenance.

Gone are the days where software development was slowed down by the top-down, water-fall approach for getting work done. The rigidity of this methodology made for a longer development lifecycle, and it affected the way software was created and deployed.

In this modern era, most companies want to make customers happy using emerging technologies. This is why they utilize multiple types of tools and new technologies to attract customers in their funnel and finally convert them into leads. However, it has some demerits too.

Before we talk about OpenTelemetry, we should talk about telemetry. Telemetry is: And an instrument is: For the purpose of measuring running computer software and systems, our instruments are virtual instruments. That is to say, code that measures other code. It sounds simple: read a measurement and send it to a remote location. In practice, to make that telemetry data useful in today’s cloud-native and ever more complex environments, there are huge logistical and technical hurdles to overcome.

OpenTelemetry is enabling a revolution in how Observability data is collected and transmitted. See our What Is OpenTelemetry post on why this is an important inflection point in the Observability space. In this post, we’ll walk through how to configure the OpenTelemetry Gems within a Rails app.