The widespread adoption of Agile methodologies in recent years has allowed organizations to significantly increase their ability to push out more high quality software. Previous development practices revolved heavily around centralized applications and infrequent updates that were shipped maybe once a quarter or even once a year.
Mean time to repair (MTTR) is an essential metric that represents the average time it takes to repair and restore a component or system to functionality. It is a primary measurement of the maintainability of an organization’s systems, equipment, applications and infrastructure, as well as its efficiency in fixing that equipment when an IT incident occurs. Key challenges with MTTR arise from just trying to figure out that there is actually a problem.
The modern technology landscape is ever-changing, with an increasing focus on methodologies and practices. Recently we’re seeing a clash between two of the newer and most popular players: DevOps vs DevSecOps. With new methodologies come new mindsets, approaches, and a change in how organizations run. What’s key for you to know, however, is, are they different? If so, how are they different? And, perhaps most importantly, what does this mean for you and your development team?
11 Tips for Avoiding Cloud Vendor Lock-In Cloud vendor lock-in. In cloud computing, software or computing infrastructure is commonly outsourced to cloud vendors. When the cost and effort of switching to a new vendor is too high, you can become “locked in” to a single cloud vendor. Once a vendor’s software is incorporated into your business, it’s easy to become dependent upon that software and the knowledge needed to operate it.
Metricbeat, an Elastic Beat based on the libbeat framework from Elastic, is a lightweight shipper that you can install on your servers to periodically collect metrics from the operating system and from services running on the server. Everything from CPU to memory, Redis to NGINX, etc… Metricbeat takes the metrics and statistics that it collects and ships them to the output that you specify, such as Elasticsearch or Logstash.
Observability and Monitoring are viewed by many as interchangeable terms. This is not the case. While they are interlinked, they are not interchangeable. There are actually very clear and defined differences between them. Monitoring is asking your system questions about its current state. Usually these are performance related, and there are many open source monitoring tools available. Many of those available are also specialized.
A key decision that must be made in a product’s lifecycle is SaaS vs Hosted. Should we be only employing the use of hosted solutions, or are we going to utilize SaaS offerings? Hosted solutions are services from providers like AWS and Azure, that take away the operational burden from some well-known pieces of tech, like Kafka or Grafana. SaaS solutions on the other hand are platforms like Coralogix, that offer proprietary value. They each offer benefits and drawbacks. Let’s get into it.
As our customers scale and utilize Coralogix for more teams and use cases, we decided to make their lives easier and allow them to set up their Coralogix account using declarative, infrastructure-as-code techniques. In addition to setting up Log Parsing Rules and Alerts through the Coralogix user interface and REST API, Coralogix users are now able to use modern, cloud-native infrastructure provisioning platforms.
Maintaining product focus is the best way to guarantee a successful business. As the late great Steve Jobs put it: “if you keep an eye on the profits, you’re going to skimp on the product… but if you focus on making really great products, the profits will follow.” There are a wide variety of statistics available on how much time developers actually spend writing code, anywhere from 25% to 32%.
