Platform engineering makes observability straightforward.

Preamble

What is platform engineering?

Platform engineering is about building a platform that supports your teams.

In contrast to site reliability engineers, platform engineers are not in charge of how production systems work. Instead, they provide DevOps and development teams with solutions that are already set up. This makes it easier for them to write and deploy code quickly, consistently, and in line with organizational standards. Platform engineers provide answers for common and significant parts like:

• Installation and configuration of a Kubernetes cluster
• database creation
• Authentication and access control
• Security and vulnerability management
• Observability

Building “paved roads” took a lot of work from platform engineers. For driving, a paved road with directional signs is required to get you where you’re going. Teams can follow a paved path that shows them how to create and deploy software in a clear, standard way. You don’t have to set up new tools, start an old process, or worry about deploying your software consistently. Instead, that road is constructed for you by the platform engineering team.

The typical step along this path is for DevOps teams to browse a database of solutions and add them to their CI/CD pipeline using an internal developer platform. Even though some APIs have a user interface (UI), they are usually chosen because they are easier to automate. The platform engineering teams’ main goal is to make things easier for the teams they work with without giving up their independence.

Observability is an essential part of platform engineering

The main goals of DevOps are to increase the number of releases, improve the quality of releases, and make operations more efficient. DevOps teams need timely feedback on performance, mistakes, and user engagement to accomplish that. Those pieces of information must come from different places and often cover different versions of the same product. Distributed tracing is one of the tools you need, especially if you’re using microservices. To better understand the effects of changes and the underlying causes of errors and outages, all of that data must be correlated with releases.

A platform engineer’s job is to assist DevOps teams in carrying out this work. This requires setting up and configuring observability tools, which pave the way for DevOps teams to get where they need to go without any problems.

Therefore, platform engineers must incorporate observability into every environment from the start. When it comes to provisioning, all stakeholders need to be able to easily get access to observability data. Data from different sources, like logs and events, needs to be combined and linked so that problems can be fixed quickly. Without that paved road, your teams are likely to end up with a patchwork of solutions and siloed data, or worse, no solutions at all. This makes it very hard to work together to solve problems when they come up.

Above all, platform engineers need to find ways to reduce the amount of mental work and tools they have to use. As much as possible, the tools should be easy to use and deploy in all of your environments in the same way.

Observability criteria for platform engineers

A good observability solution from the standpoint of platform engineering should be:

• Quick and simple to implement: This procedure should be standardized and additional implementations may be required across various teams.
• Easy to customize: Where possible, your observability solution should offer options for automation and be adaptable to different teams, environments, products, and services.
• Scalable: As your applications grow, the solution should continue to be robust. Because of this, on-premise solutions are less desirable, and custom and open source implementations that might not scale as well should also be considered.

You should also think about the features an observability solution provides. When possible, platform engineers should focus on unified solutions that are easier to standardize across teams and limit the number of tools they use. Exactly what features you need will depend on your use case, but the following are strongly recommended:

• Alert notifications: The solution should intelligently push issue notifications to the appropriate individuals without adding additional work due to alert storms. Correlation between data from various sources is necessary, as is easy navigation. In order to be fully integrated into existing workflows, the solution should ideally be able to provide alerts in a wide range of tools, including Slack, email, and PagerDuty.
• Log management: In order to facilitate searches across various services and environments, the solution should, ideally, have centralized log access. Because of this, no developer will ever again need to have direct access to any production environments. The first place to look when debugging is frequently the logs.
• Application metrics are tracked in real-time by application performance monitoring (APM). Golden signals like throughput, latency, and errors at various levels, including the browser, application logic, infrastructure, and network, are typically included in this.
• Distributed traces: Even when a request travels through numerous services, traces assist you in understanding end-to-end performance. This is crucial for identifying the root of errors and identifying system bottlenecks.
• Monitoring Kubernetes: If you’re using Kubernetes to orchestrate containers, you’ll need to keep an eye on the status of clusters and the pods within clusters in relation to the health of your underlying hosts and the applications that are running on them.
• Real user and synthetic monitoring are both important for web and mobile developers to be aware of in order to enhance user experience. Web developers can get information on Google Web Vitals and page popularity from a good observability solution. The causes of crashes and how users interact with mobile apps are two things that mobile developers will want to be aware of. Both web and mobile developers need to be able to see the many factors that affect performance, including the device, OS, network, and geographic location. To monitor how actual users interact with your application, use real user monitoring (RUM). In the interim, you can use a headless browser to test the functionality and dependability of your user-facing services using synthetic monitoring.
• Infrastructure and network monitoring: Your observability solution should also be able to monitor both your underlying infrastructure and network, allowing operations and network engineers to better collaborate and identify issues.

Once platform engineers have a clear idea of what is needed, they can start building an internal developer platform. They will want to make sure that some standards are followed when it comes to security and following the rules of the organization and outside regulators. For the SRE team’s benefit, they will need to set some rules about naming and tagging. There isn’t much need to be overly directive aside from that. Even though alerts and dashboards that are already set up will be helpful, DevOps teams will also need to be able to change and tweak them as needed. Developers might also want to create custom events or add custom attributes to their transactions. The observability solution should be able to be changed in this way because of how it is scripted and because of the policies and guidelines.

Steps to implementing observability in your platform

Aim for 100% observability

Platform engineers should ideally add monitoring as soon as new services, applications, and pipelines are made to make sure that everything can be seen. Here are a few instances:

• Before collecting monitoring data, take data security into account. Could query strings in logs or databases contain sensitive information? Should all users have the same data at their disposal?
• Include host monitoring for crucial metrics like CPU and memory utilization when configuring a database. Essential statistics like the condition of table spaces, buffers and caches, the number of connections and locks, and more, can be tracked for the database service. Depending on the database, the specifics will change.
• Automatically record information about the status of nodes, pods, containers, and logs when configuring a Kubernetes cluster.
• Build APM into the application server before deploying any applications. assemble application logs and logs from the application server. Reading How to monitor application performance with APM and APM vs. observability will teach you more about application performance monitoring.
• Include other services like RabbitMQ, Kafka, and web servers like NGINX that applications use.
• See What are SLOs, SLIs, and SLAs for more information on how to quantify and track the effects of observability.

Automate everything

After adding observability to your CI/CD chain, the next step is to set up alerts and dashboards automatically. The DevOps team should begin by using some standard alerts based on golden signals before customizing them. Also, some generic dashboards that use tags or naming conventions to collect metrics based on typical KPIs will give an application or team a head start. Provide a REST API or GraphQL deployment option for these alerts and dashboards.

A crucial component of platform engineering is observability.

About Enteros

​Enteros offers a patented database performance management SaaS platform. It automate finding the root causes of complex database scalability and performance problems that affect business across a growing number of cloud, RDBMS, NoSQL, and machine learning database platforms.​​​