October 6, 2022

Robotic Notes

All technology News

O11y Guide – Your First Steps in Cloud Native Observability – Java Code Geeks

4 min read

While I’ve been evolving the stories I tell from a developer audience to an architecture audience for some time now, one thing that caught my attention was the complexity of native cloud environments. The more complex the solution architecture, the greater the need for simple ways to share how successful organizations operate at cloud scale.

Along with the journey to cloud-native architectures, a very different problem has emerged that manifests itself in cloud-native environments. I’ve outlined this problem in a series on cloud data, and it’s about more than just your data storage from the early days of the architecture.

This look at cloud data revealed a very interesting and somewhat hidden world of cloud-native observability, where the data generated supporting sections of your cloud-native architecture can often exceed your ongoing production costs.

This series starts with the basics, from developers to native cloud monitoring, the players involved, and outlines the technical vs. business story being sold to you around cloud native monitoring tools.

Let’s dive right in, shall we?

The main introduction starts from the point that developers are in a non-cloud world and then had to make a transition to a cloud development world. What does this mean for them and what are some of the challenges they have to deal with?

It’s important to understand that coming from the old world of developers, writing code for services and applications before the cloud, the idea of ​​monitoring my code as it made its way to production was often very limited.

It was usually some kind of continuous integration and continuous deployment (CI/CD) toolchain that provided me with some insights into performance, failed tests, and deployment success. Bug tracking often doesn’t require dashboards other than CI/CD alerting to any issues. This warning would throw me back into my dev environment’s debugging tools, trying to decipher logged errors, failed test results, and using a lot of breakpoints as I stepped through my code.

Most of this will be in the purview of the operations department when the code reaches production. They had their own tools, with log parsing, dashboards, and monitoring favorites like Nagios.

Then came the world of cloud native development.

Cloud native development o11y

There has slowly been a shift where as a developer you no longer work on your own machine or in hosted environments from your own data center. Everything is in the cloud or a cloud-like environment, which changes all business expectations.

Agile development shortens the path to production with automation that forces us to move at the speed of your next code change. It also created a new landscape where operations shifted left closer to the developer and we all became DevOps teams.

New features are no longer released several times a year, but several times a day or even hourly. This led to the need for better tools to handle the vast array of components being created in our cloud native world. Applications use hundreds if not thousands of microservices and it becomes very difficult to maintain visibility across these architectures.

This, friends, is the word we have come across in the homeworld of the cloud to represent the observation of everything; the rise of natural observability in the cloud. Observability, or o11y for short, is way bigger than anything that’s happened in our developer world to date. Not only do you want to monitor the availability of your applications and services, you also want to detect trends in advance that could cause your customer’s experience to degrade or break.

In the beginning, there was a lot of talk about the three of them pillars of monitoring to try to address the challenges of native cloud o11y; metric, trackingand troop. The problem is that business is more interested in focusing on three phases; necessity of i know as quickly as possible solving the problem, as you can quickly triage the problem, correcting it (fixing) and finally getting to I understand basically what happened to prevent future events.

Next is who is on the field

After a brief summary of the path that developers and operations have taken from the old world to the new native world of the cloud, this article touches on the difference between the technical approach (pillars) and the business approach (phases) to cloudy native o11y.

With that in mind, the next time in this series is to look at who the players are in this native cloud o11y field.

Source link