Resources

Years ago, end-to-end software development involved dividing tasks based on where they fell in the system life cycle. One team wrote the code. Then another team deployed it to production. And yet another team monitored and maintained the service. This led to a lot of friction, needless handoffs, and bottlenecks.

Engineering initiatives are a necessity when it comes to ensuring security, reliability, and keeping the lights on within an organization. These can include actions such as upgrading library versions, migrating everyone to a new metrics provider, or upgrading a framework.

When starting a new job, have you ever asked yourself: How much time should I spend learning about the code? The product? The process? Was I expected to know Technology/Framework/Design Pattern X?Is my ticket taking too long?

You can use OpsLevel’s Git Integrations to run code-level checks against your services, to bring ownership to your repos, and more. While the best way of integrating your repositories with OpsLevel is importing everything, we realize however that some repositories are more important than others. (cough 6-month-old hackday project cough.) Oftentimes these repositories aren’t ready to be archived or deleted, but also don’t need the full OpsLevel experience. Wouldn’t it benice if they almost didn’t exist at all in OpsLevel?

Let’s get DevOps to mean Service Ownership again. We broke DevOps. And it’s preventing us from building. When the first cloud providers emerged in the mid-2000s, they unlocked a new superpower: the ability to near-instantly provision hardware. Service-oriented architecture and microservices developed as a new architectural pattern. As a result, DevOps emerged as a practice to organize engineering teams around those new services - combining development and operations responsibilities onto the same team.

Having strong ownership of your microservices and other running systems is an important pre-requisite to building a DevOps culture. But focusing solely on ownership of services running in production can leave some gaps. There’s a lot of code living outside of any service’s codebase: libraries, internal tools, templates, terraform code, and a lot more. All of these repositories need ownership too.

Over the last few months at OpsLevel, we’ve changed how we tell interview candidates we’re not moving forward. Instead of a templated response, we now provide specific and actionable feedback for each candidate about where they fell short in our interview process and how they can improve. The results have been spectacular.

OpsLevel contains a ton of information about your technical services and systems, but it doesn’t contain all of the information about your business. Fortunately the data in OpsLevel isn’t trapped there! In addition to our existing GraphQL API, we now support extracting all of your OpsLevel data into your ETL pipeline and data warehouse.

We all know that naming things is one of the two hardest problems in computer science (along with cache invalidation and off-by-one errors.) Naming your microservices is extra hard, as they’re almost like children: they’re practically these living, breathing things that you birth into the world and do your best to make sure they’re set up for success in life (i.e. in production.) Ok, perhaps people don’t agonize over the names of their microservices as much as the names of their children, but it’s still a big enough decision.

Last summer, our team gathered in the woodland heart of Parry Sound, Ontario for the inaugural OpsLevel HackDay. For 24 hours, participants were given total creative freedom while being tasked with creating a demo-able, team-based project. Skills were sharpened, bonds were strengthened, and marshmallows were roasted - it was a blast.

Pranav Krishnan is a Computer Science student at the University of Waterloo. I first started working at OpsLevel in May 2019 and it was my first ever co-op experience. I was extremely nervous, with no clue what to expect. Fast forward almost a year later and I find myself struggling with the idea of leaving this company behind.

OpsLevel is a great place to work. I love the product, the values…the snacks, but most importantly, the people. Our team isn’t large, but our size makes us extremely tightly knit. We eat lunch together, play lunchtime foosball, chat about things like kids and mortgage rates, and play after work video games (mostly Rocket League) almost every day.

A microservice catalog is only as good as the data it contains. OpsLevel is making it easier than ever to keep your service list up-to-date with its new Service Suggestions feature. With Service Suggestions, we automatically discover new services when they get deployed and help you add them to OpsLevel. For services that are already in OpsLevel, we can also help you easily attach those deployment streams to the right service.

OpsLevel helps keep your services consistent and healthy through the use of various pre-built checks. But what if you want to write your own checks from scratch? You can now do that with OpsLevel custom checks. Our custom checks API opens up endless possibilities, allowing you to do things such as integrating with your deployment pipeline or container orchestrator, writing your own check scripts, and more.

Don’t you hate remembering all of your passwords? With OpsLevel’s Single Sign-On integration all of your microservice data is seconds away without the need for another long and secure password.

OpsLevel is intended to be your source of truth for microservice and ownership information. Today, we’re very excited to announce that we’ve taken a leap forward towards that vision with the launch of our GraphQL API.

Services and repositories come in many shapes and sizes. You can fully extend OpsLevel’s data model to fit your needs by tagging your services and repositories with key/value pairs. With our Tags feature, OpsLevel can track additional or custom attributes, as well as allow you to search and filter by these attributes.

OpsLevel is your one-stop shop for understanding the microservices you have running in your architecture. A key component to understanding your microservices is to actually see what code is running in production, and when/how that changes.