When adopting cloud technologies, most organizations have two things in mind: infrastructure cost and operational speed.

When considering operational speed, it is up to the organization to build, deploy, and operate their software faster. The approaches that are popular in the cloud today, such as microservices, APIs, managed services, and serverless, exist to increase this speed — which designates as developer velocity.

Therefore, if this speed is so crucial and fundamental to the business, teams should aim to boost developer velocity as much as they can. While modern microservices and cutting-edge technologies such as AWS Lambda and Fargate help to increase this speed significantly, inefficiency in monitoring and troubleshooting, sometimes unnoticeable, may bring it back down.

How Engineers Spend Their Time?

One of Epsagon’s customers, Onceitdescribed the time spent by their developers during the day: 60% building, 20% testing, and 20% debugging.

Time spent by developers: building, testing, and debugging

Time spent by developers: building, testing, and debugging

Testing distributed applications is a complicated task on its own, so we should expect it to stay steady as the architecture evolves. But what about debugging? Modern monitoring and troubleshooting tools help to reduce the time spent debugging by 90% to 95%. This not only improves developers’ productivity but, of course, improves customer experience and prevents losses in productivity.

Obviously, we want the building time to be as high as possible. So, what about the building?

As the application’s complexity increases, the developer’s building time is spent building both business applications and code that enables observability. Enabling observability is done today manually, using logging, tracing frameworks, and other tools.

According to the results of an Epsagon survey of companies using modern cloud technologies, engineers spend 30% to 50% of their building time implementing observability tools. That’s a huge drain on productivity and resources that is sadly often overlooked.

If we take the extreme case where 50% of a developer’s time is spent implementing observability into the application, only 30% of the total time is actually spent building applications.

DevOps business building time vs. monitoring and observability activities

Building time split into business vs. other activities

Automating Observability

While some preach about “thinking observability as you build,” at Epsagon we beg to differ: If cloud technologies and modern development methodologies have evolved to enable faster development, then monitoring and troubleshooting tools should keep up.

what is observability in distributed tracing

Distributed applications create an observability challenge

Automating your observability: what does it mean?

As mentioned above, developers should focus on building business applications the vast majority of their building time. That means they should not be spending 50 percent of their time implementing manual-tracing frameworks.

This is achievable by using proper tools that were built for these kinds of applications. Saying to an engineer or architect “it’s too complicated for tools to do, so you have to do it yourself” is not an acceptable answer. As there are standard ways to write software, there are also standard ways to trace, monitor, and troubleshoot.

Requirements from a Monitoring Tool in the Modern Cloud Era

Three things are required:

  1. Extremely fast setup
  2. Extremely low maintenance
  3. Straightforward to work with.

Achieving extremely fast setup and low maintenance hinges on one thing: automation. A monitoring and troubleshooting tool should work for the developers, instead of expecting them to do the “work for the tool.”

How Can Automation Be Achieved?

As opposed to those who claim that applications nowadays are too complex, we are seeing different trends in the market. Engineers use standard frameworks and services, today more than ever before. Adopting a cloud-first approach means that you’re inclined to use more managed services and APIs. Building microservices is done using common container technologies (e.g. Docker) and orchestration services (Kubernetes: managed/self-hosted, Fargate, etc.). Communication between services is done in standard ways, either synchronously or asynchronously.

An Example of a Modern Application

Modern distributed application components

Modern applications are comprised of various distributed components

Let’s take a look at a distributed application. It uses the following standard services:

  • Web access: Nginx and API Gateway. These are the entry points of the application
  • Microservices: Docker containers and AWS Lambda. The Docker can be self-hosted or managed by an orchestration service such as ECS, AKS (on Azure), or other services
  • Asynchronous communication services: Kafka ad SNS
  • Database service: Postgres (an RDS database, for example)
  • External APIs: Stripe, Twilio, PagerDuty — for different purposes.

This is a well-designed, nice-looking application. Every part of the application is standard in the way that it’s a managed service or uses a standard communication API. Tracing this application can be done fully automatically — by instrumenting the SDKs in each of the services according to their runtime.

Is your application using standard services? If not, why not?

Standardization Improves Developer Velocity

Using modern, standard approaches to cloud software development can improve both your building speed and reduce the setup and maintenance of observability — as it will be automated by corresponding modern tools.

To learn more about how automated observability can help you ship better software fast, request a demo of Epsagon.

Read More:

Announcing Epsagon’s Applied Observability for Azure and K8s

The Cost of Monitoring Microservices: Managed Solutions vs. In-house

The Top 5 Kubernetes Metrics You Need to Monitor

How to Effectively Monitor AWS Lambda

Managing Observability in Modern Applications