KubeCon + CloudNativeCon North America 2022 kicks off next week (October 24-28 in Detroit), so we’ve been thinking a lot about how service catalogs can help you get the most out of your Kubernetes clusters!

Google has had an outsized impact on the world, from its unrivaled search engine to its expansion into a range of customer-focused services. It would be difficult to make an impact of this magnitude without also leading the way in the software development industry. One of its biggest contributions to the community is a set of principles known as site reliability engineering or SRE.

A microservices catalog is only useful if you are confident that anything stored in it is fully accurate and that the information will not become outdated. How can you be certain that your catalog stays up-to-date in the future? Should you look for an asset in the catalog and, despite finding it there, also double-check GitHub? The service catalog is supposed to be your single source of truth. The purpose is defeated if you have to look for what you need in multiple different places.

The process of writing code resembles the practice of normal writing - your first draft isn’t the final one. The code you write has to undergo testing, debugging, and reviews before it can be integrated into the final product and shipped off to users. Without these checks, the code would be filled with bugs and errors that may prevent it from functioning properly or cause security flare-ups.

With Datadog’s Dash conference right around the corner, we at Cortex have been thinking a lot about best practices for observability. To get the most out of an application performance monitoring (APM) vendor like Datadog, you want to make sure monitoring and observability are built into launch and production readiness checklists.

Despite there being significant differences in the roles, DevOps and Site Reliability Engineering are often lumped together because many people assume they do similar work. Although both attempt to reduce the issues arising from software development processes, their goals, skill sets, and approaches are actually quite different. DevOps engineers focus on the development pipeline, and their goal is to enable better development processes and workflows.

Cortex’s Resource Catalog allows engineers to track all of their infrastructure components — from databases to Kafta topics — in a single place. The Resource Catalog demystifies infrastructure, giving developers clear insights into exactly how their service architecture works. Using the Resource Catalog, it’s easy to find information about which infrastructure assets are running and how all the distinct components connect.

Knowing how productive your development team is is essential to planning your software delivery timeline and releasing high-quality software to the end-user. However, there exist several misconceptions about what developer productivity is and how it can be increased. Developer productivity is not a single metric you can measure, like the number of pull requests each developer in the team is making in a given development time.

Microservice architectures have become extremely popular in recent years, and for good reason. When managed properly, they improve scalability, encourage faster development and deployment, and reduce data and domain coupling. Companies of all sizes, from small startups to large enterprises, have migrated their monolithic applications over to microservice and service-oriented architectures. Making the move from monolith to microservices is a big shift, though.

Is microservice quality a focus for your team this year? Perhaps you’re looking to improve your service performance. Maybe you feel like your organization needs better ways to enforce best practices or ensure that service quality doesn’t degrade over time. Let’s take a look at these three areas and share some concrete recommendations for strengthening your services and creating a long-term culture of quality.