Observability Takes Too Much Developer Time, So Automate It
Epsagon sponsored this post.
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, Onceit, described the time spent by their developers during the day: 60% building, 20% testing and 20% 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 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, the only 30% of the total time is actually spent building applications.
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.
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 which 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:
- Extremely fast setup
- Extremely low maintenance
- 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 Automation Can 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
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.
We’re hosting a webinar on Tuesday, May 21, 2019, about software modernization using serverless, presented by:
- Mike Deck, principal solutions architect at AWS
- Nikody Keating, cloud architect at Mutual of Enumclaw
- Ran Ribenzaft, CTO at Epsagon.
Feature image via Pixabay.
