<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Operations on Brave New Geek</title><link>https://bravenewgeek.com/category/operations/</link><description>Recent content in Operations on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 14 Nov 2024 13:47:29 -0700</lastBuildDate><atom:link href="https://bravenewgeek.com/category/operations/index.xml" rel="self" type="application/rss+xml"/><item><title>Platform Engineering as a Service</title><link>https://bravenewgeek.com/platform-engineering-as-a-service/</link><pubDate>Thu, 14 Nov 2024 13:47:29 -0700</pubDate><guid>https://bravenewgeek.com/platform-engineering-as-a-service/</guid><description>&lt;p&gt;Like most industry jargon, “DevOps” means a lot of things to a lot of different people. While many folks view it as specific to certain tooling or practices, such as CI/CD or Infrastructure as Code (IaC), I’ve always viewed it as an organizational model for how software is built and delivered. In particular, my interpretation is that DevOps is about shifting more responsibilities “left” onto developers, moving away from the more traditional “throw it over the wall” approach to IT operations. No doubt this encompasses tooling or practices like CI/CD and IaC, which are responsibilities that developers now shoulder, perhaps with the support of dev tools, productivity, or enablement teams—some companies just call this the “DevOps” team.&lt;/p&gt;</description></item><item><title>Understanding Konfig’s Opinionation</title><link>https://bravenewgeek.com/understanding-konfigs-opinionation/</link><pubDate>Tue, 11 Jun 2024 13:59:57 -0600</pubDate><guid>https://bravenewgeek.com/understanding-konfigs-opinionation/</guid><description>&lt;p&gt;In my &lt;a href="https://bravenewgeek.com/no-assembly-required-the-benefits-of-an-opinionated-platform/"&gt;last post&lt;/a&gt;, I talked about the benefits of an opinionated platform. An opinionated platform allows your engineers to focus on things that matter to your business, such as shipping and improving customer-facing products and services. This is in contrast to engineers spending substantial time on non-differentiating work like platform infrastructure. Rather than infrastructure architecture, developers can focus more on the product architecture. &lt;a href="https://konfigurate.com/?utm_source=bravenewgeek.com&amp;amp;utm_campaign=understanding-opinionation"&gt;Konfig&lt;/a&gt; is an opinionated platform which provides two key value drivers: 1) reducing the investment and total cost of ownership needed to have an enterprise cloud platform and 2) minimizing the time to deliver new software products.&lt;/p&gt;</description></item><item><title>No assembly required: the benefits of an opinionated platform</title><link>https://bravenewgeek.com/no-assembly-required-the-benefits-of-an-opinionated-platform/</link><pubDate>Thu, 23 May 2024 15:28:49 -0600</pubDate><guid>https://bravenewgeek.com/no-assembly-required-the-benefits-of-an-opinionated-platform/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/05/assembly-1024x697.png"&gt;&lt;/p&gt;
&lt;p&gt;When you talk to a doctor about a medical issue they will often present you with all of the options but shy away from providing an unambiguous recommendation. When you talk to a lawyer about a legal matter they frequently do the same. While it’s important to understand your options and their trade-offs or associated risks, when you go to these specialists you are likely seeking the counsel of an experienced and knowledgeable expert in their field who can help you make an informed decision. What most people are probably looking for is the answer to “what would you, someone who knows a lot about this stuff, do if you were in this situation?” After all, many of us are probably capable of finding the options ourselves, but the difficult part is determining what the right course of action is for a particular situation.&lt;/p&gt;</description></item><item><title>How Konfig provides an enterprise platform with GitLab and Google Cloud</title><link>https://bravenewgeek.com/how-konfig-provides-an-enterprise-platform-with-gitlab-and-google-cloud/</link><pubDate>Mon, 29 Apr 2024 14:24:31 -0600</pubDate><guid>https://bravenewgeek.com/how-konfig-provides-an-enterprise-platform-with-gitlab-and-google-cloud/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/04/konfig.png"&gt;&lt;/p&gt;
&lt;p&gt;In a &lt;a href="https://blog.realkinetic.com/security-maintainability-velocity-choose-one-cf9eb9533d71"&gt;previous post&lt;/a&gt;, I explained the fundamental competing priorities that companies have when building software: security and governance, maintainability, and speed to production. These three concerns are all in constant tension with each other. For companies either migrating to the cloud or beginning a modernization effort, addressing them can be a major challenge. When you’re unfamiliar with the cloud, building systems that are both secure and maintainable is difficult because you’re not in a position to make decisions that have long-lasting and significant impact—you just don’t know what you don’t know. One small misstep can result in a major security incident. A bad decision can take years to manifest a problem. As a result, these migration and modernization efforts often stall out as analysis paralysis takes hold.&lt;/p&gt;</description></item><item><title>Security, Maintainability, Velocity: Choose One</title><link>https://bravenewgeek.com/security-maintainability-velocity-choose-one/</link><pubDate>Wed, 17 Apr 2024 11:41:24 -0600</pubDate><guid>https://bravenewgeek.com/security-maintainability-velocity-choose-one/</guid><description>&lt;p&gt;There are three competing priorities that companies have as it relates to software development: security, maintainability, and velocity. I’ll elaborate on what I mean by each of these in just a bit. When I originally started thinking about this, I thought of it in the context of the “good, fast, cheap: choose two” &lt;a href="https://en.wikipedia.org/wiki/Project_management_triangle"&gt;project management triangle&lt;/a&gt;. But after thinking about it for more than a couple minutes, and as I related it to my own experience and observations at other companies, I realized that in practice it’s much worse. For most organizations building software, it’s more like security, maintainability, velocity: choose &lt;em&gt;one&lt;/em&gt;.&lt;/p&gt;</description></item><item><title>Introducing Konfig: GitLab and Google Cloud preconfigured for startups and enterprises</title><link>https://bravenewgeek.com/introducing-konfig-gitlab-and-google-cloud-preconfigured-for-startups-and-enterprises/</link><pubDate>Thu, 04 Apr 2024 14:51:23 -0600</pubDate><guid>https://bravenewgeek.com/introducing-konfig-gitlab-and-google-cloud-preconfigured-for-startups-and-enterprises/</guid><description>&lt;p&gt;&lt;a href="https://realkinetic.com/"&gt;Real Kinetic&lt;/a&gt; helps businesses transform how they build and deliver software in the cloud. This encompasses legacy migrations, app modernization, and greenfield development. We work with companies ranging from startups to Fortune 500s and everything in between. Most recently, we finished helping Panera Bread migrate their e-commerce platform to Google Cloud from on-prem and led their transition to GitLab. In doing this type of work over the years, we’ve noticed a problem organizations consistently hit that causes them to stumble with these cloud transformations. Products like GCP, GitLab, and Terraform are quite flexible and capable, but they are sort of like the piles of Legos below.&lt;/p&gt;</description></item><item><title>Choosing Good SLIs</title><link>https://bravenewgeek.com/choosing-good-slis/</link><pubDate>Mon, 19 Feb 2024 14:11:17 -0700</pubDate><guid>https://bravenewgeek.com/choosing-good-slis/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/02/dashboard-1024x671.jpg"&gt;&lt;/p&gt;
&lt;p&gt;Transitioning from an on-prem environment to a cloud environment involves a lot of major shifts for organizations. One of those shifts is often around how we monitor the overall health of systems. The typical way to measure things like the availability, reliability, and performance of systems is with SLIs or &lt;a href="https://sre.google/sre-book/service-level-objectives/"&gt;Service Level Indicators&lt;/a&gt;. SLIs are a valuable tool both on-prem and in the cloud, but when it comes to the latter, I often see organizations carrying over some operational anti-patterns from their data center environment.&lt;/p&gt;</description></item><item><title>Cloud without Kubernetes</title><link>https://bravenewgeek.com/cloud-without-kubernetes/</link><pubDate>Mon, 12 Feb 2024 11:58:13 -0700</pubDate><guid>https://bravenewgeek.com/cloud-without-kubernetes/</guid><description>&lt;p&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2024/02/Kubernetes-or-Cloud-Run-1024x683.jpeg"&gt;&lt;/p&gt;
&lt;p&gt;I think it’s safe to say Kubernetes has “won” the cloud mindshare game. If you look at the CNCF &lt;a href="https://landscape.cncf.io/"&gt;Cloud Native landscape&lt;/a&gt; (and manage to not go cross eyed), it seems like most of the projects are somehow related to Kubernetes. KubeCon is one of the fastest-growing industry events. Companies we talk to at Real Kinetic who are either preparing for or currently executing migrations to the cloud are centering their strategies around Kubernetes. Those already in the cloud are investing heavily in platform-izing their Kubernetes environment. Kubernetes competitors like Nomad, Pivotal Cloud Foundry, OpenShift, and Rancher have sort of just faded to the background (or simply pivoted to Kubernetes). In many ways, “cloud native” seems to be equated with “Kubernetes”.&lt;/p&gt;</description></item><item><title>SRE Doesn’t Scale</title><link>https://bravenewgeek.com/sre-doesnt-scale/</link><pubDate>Wed, 06 Oct 2021 09:44:55 -0600</pubDate><guid>https://bravenewgeek.com/sre-doesnt-scale/</guid><description>&lt;p&gt;&lt;a href="https://bravenewgeek.com/wp-content/uploads/2021/10/sre-book.jpeg"&gt;&lt;img loading="lazy" src="https://bravenewgeek.com/wp-content/uploads/2021/10/sre-book.jpeg"&gt;&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;We encounter &lt;em&gt;a lot&lt;/em&gt; of organizations talking about or attempting to implement SRE as part of our consulting at Real Kinetic. We’ve even discussed and debated ourselves, ad nauseam, how we can apply it at our own product company, &lt;a href="https://witful.com/"&gt;Witful&lt;/a&gt;. There’s a brief, unassuming section in the &lt;a href="https://sre.google/sre-book/table-of-contents/"&gt;SRE book&lt;/a&gt; tucked away towards the tail end of &lt;a href="https://sre.google/sre-book/evolving-sre-engagement-model/"&gt;chapter 32&lt;/a&gt;, “The Evolving SRE Engagement Model.” Between the SLIs and SLOs, the error budgets, alerting, and strategies for handling change management, it’s probably one of the most overlooked parts of the book. It’s also, in my opinion, one of the most important.&lt;/p&gt;</description></item><item><title>Structuring a Cloud Infrastructure Organization</title><link>https://bravenewgeek.com/structuring-a-cloud-infrastructure-organization/</link><pubDate>Mon, 07 Dec 2020 11:21:46 -0600</pubDate><guid>https://bravenewgeek.com/structuring-a-cloud-infrastructure-organization/</guid><description>&lt;p&gt;Real Kinetic often works with companies just beginning their cloud journey. Many come from a conventional on-prem IT organization, which typically looks like separate development and IT operations groups. One of the main challenges we help these clients with is how to structure their engineering organizations effectively as they make this transition. While we approach this problem holistically, it can generally be looked at as two components: product development and infrastructure. One might wonder if this is still the case with the shift to DevOps and cloud, but as we’ll see, these two groups still play important and distinct roles.&lt;/p&gt;</description></item><item><title>Getting big wins with small teams on tight deadlines</title><link>https://bravenewgeek.com/getting-big-wins-with-small-teams-on-tight-deadlines/</link><pubDate>Mon, 02 Nov 2020 15:52:40 -0600</pubDate><guid>https://bravenewgeek.com/getting-big-wins-with-small-teams-on-tight-deadlines/</guid><description>&lt;p&gt;Part of what we do at Real Kinetic is give companies confidence to ship software in the cloud. Many of our clients are large organizations that have been around for a long time but who don’t always have much experience when it comes to cloud. Others are startups and mid-sized companies who may have some experience, but might just want another set of eyes or are looking to mature some of their practices. Whatever the case, one of the things we frequently talk to our clients about is the value of both serverless and managed services. We have found that these are critical to getting big wins with small teams on tight deadlines in the cloud. Serverless in particular has been key to helping clients get some big wins in ways others didn’t think possible.&lt;/p&gt;</description></item><item><title>Microservice Observability, Part 2: Evolutionary Patterns for Solving Observability Problems</title><link>https://bravenewgeek.com/microservice-observability-part-2-evolutionary-patterns-for-solving-observability-problems/</link><pubDate>Fri, 03 Jan 2020 14:18:10 -0600</pubDate><guid>https://bravenewgeek.com/microservice-observability-part-2-evolutionary-patterns-for-solving-observability-problems/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/"&gt;part one&lt;/a&gt; of this series, I described the difference between monitoring and observability and why the latter starts to become more important when dealing with microservices. Next, we’ll discuss some strategies and patterns for &lt;em&gt;implementing&lt;/em&gt; better observability. Specifically, we’ll look at the idea of an &lt;a href="https://bravenewgeek.com/the-observability-pipeline/"&gt;observability pipeline&lt;/a&gt; and how we can start to iteratively improve observability in our systems.&lt;/p&gt;
&lt;p&gt;To recap, observability can be described simply as the ability to ask questions of your systems without knowing those questions in advance. This requires capturing a variety of signals such as logs, metrics, and traces as well as tools for interpreting those signals like log analysis, SIEM, data warehouses, and time-series databases. A number of challenges surface as a result of this. &lt;a href="https://twitter.com/clintsharp"&gt;Clint Sharp&lt;/a&gt; does a great job &lt;a href="https://cribl.io/blog/the-observability-pipeline/"&gt;discussing&lt;/a&gt; the key problems, which I’ll summarize below along with some of my own observations.&lt;/p&gt;</description></item><item><title>Microservice Observability, Part 1: Disambiguating Observability and Monitoring</title><link>https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/</link><pubDate>Thu, 03 Oct 2019 10:55:23 -0500</pubDate><guid>https://bravenewgeek.com/microservice-observability-part-1-disambiguating-observability-and-monitoring/</guid><description>&lt;p&gt;“Pets versus cattle” has become something of a standard vernacular for describing the shift in how we build systems. It alludes to the elastic and dynamic nature of these (typically, but not necessarily) container-based systems with on-demand scaling and more transparent fault-tolerance. I’ve &lt;a href="https://bravenewgeek.com/the-observability-pipeline/"&gt;talked before about this transition&lt;/a&gt; before and specifically how it relates to monitoring. In particular, with these more dynamic, microservice-based systems, the conversation starts to shift away from traditional &lt;em&gt;monitoring&lt;/em&gt; toward &lt;em&gt;observability&lt;/em&gt;. In this series, I’ll describe that distinction, explain why it matters, and share some concrete tactical items for implementing observability in a microservice environment.&lt;/p&gt;</description></item><item><title>Security by Happenstance</title><link>https://bravenewgeek.com/security-by-happenstance/</link><pubDate>Tue, 26 Mar 2019 11:25:14 -0500</pubDate><guid>https://bravenewgeek.com/security-by-happenstance/</guid><description>&lt;h4 id="key-rotation-auditing-and-securecicd"&gt;Key rotation, auditing, and secure CI/CD&lt;/h4&gt;
&lt;p&gt;Companies often require employees to regularly change their passwords for security purposes. &lt;a href="https://www.pcisecuritystandards.org/document_library?category=pcidss&amp;amp;document=pci_dss"&gt;PCI compliance&lt;/a&gt;, for example, requires that passwords be changed every 90 days. However, NIST, whose guidelines commonly become the foundation for security best practices across countless organizations, &lt;a href="https://www.passwordping.com/surprising-new-password-guidelines-nist/"&gt;recently revised&lt;/a&gt; its recommendations around password security. Its Digital Identity Guidelines (&lt;a href="https://pages.nist.gov/800-63-3/sp800-63b.html"&gt;NIST 800-63-3&lt;/a&gt;) now recommends &lt;em&gt;removing&lt;/em&gt; periodic password-change requirements due to a growing body of research suggesting that frequent password changes actually &lt;a href="https://arstechnica.com/information-technology/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/"&gt;makes security &lt;em&gt;worse&lt;/em&gt;&lt;/a&gt;. This is because these requirements encourage the use of passwords which are more susceptible to cracking (e.g. incrementing a number or altering a single character) or result in people writing their passwords down.&lt;/p&gt;</description></item><item><title>Operations in the World of Developer Enablement</title><link>https://bravenewgeek.com/operations-in-the-world-of-developer-enablement/</link><pubDate>Thu, 24 Jan 2019 11:28:40 -0600</pubDate><guid>https://bravenewgeek.com/operations-in-the-world-of-developer-enablement/</guid><description>&lt;p&gt;&lt;a href="https://blog.realkinetic.com/scaling-devops-and-the-revival-of-operations-d647ba6e2374"&gt;&lt;em&gt;NewOps&lt;/em&gt;&lt;/a&gt; is not a replacement for DevOps, it’s an evolution of it by &lt;a href="https://www.youtube.com/watch?v=JUy3GYkPfto"&gt;looking at Operations through the lens of product&lt;/a&gt;. It’s what I’ve come to call “Developer Enablement” because the goal is to shift the focus of Ops teams from being masters of production to &lt;em&gt;enablers&lt;/em&gt; of production. Through Developer Enablement, teams are enabled—and tasked with the responsibility—to control their own destiny. This extends far beyond just the responsibility of building products. It includes how we build, test, secure, deploy, monitor, and operate systems.&lt;/p&gt;</description></item><item><title>The Observability Pipeline</title><link>https://bravenewgeek.com/the-observability-pipeline/</link><pubDate>Wed, 12 Sep 2018 11:37:24 -0500</pubDate><guid>https://bravenewgeek.com/the-observability-pipeline/</guid><description>&lt;p&gt;The rise of cloud and containers has led to systems that are much more distributed and dynamic in nature. Highly elastic microservice and serverless architectures mean containers spin up on demand and scale to zero when that demand goes away. In this world, servers are very much cattle, not pets. This shift has exposed deficiencies in some of the tools and practices we used in the world of servers-as-pets. It has also led to new tools and services created to help us support our systems.&lt;/p&gt;</description></item><item><title>Scaling DevOps and the Revival of Operations</title><link>https://bravenewgeek.com/scaling-devops-and-the-revival-of-operations/</link><pubDate>Wed, 18 Apr 2018 10:07:42 -0500</pubDate><guid>https://bravenewgeek.com/scaling-devops-and-the-revival-of-operations/</guid><description>&lt;p&gt;Operations is going through a renaissance right now. With the move to cloud, the increasing amount of automation, and the increasing &lt;em&gt;importance&lt;/em&gt; of automation, Ops as we know it is reinventing itself out of necessity. Infrastructure is becoming more and more sophisticated—and commoditized—and practices are just now starting to grow up around that. So while some worry about robots taking our jobs, the reality is more about how automation will help augment us to build better software and focus on higher-value things. It’s not so much about the &lt;em&gt;distant&lt;/em&gt; future—whatever that may hold—so much as it is about the next five to ten years, what Operations looks like in that timeframe, and why I think it has to retool.&lt;/p&gt;</description></item><item><title>The Future of Ops</title><link>https://bravenewgeek.com/the-future-of-ops/</link><pubDate>Wed, 03 May 2017 20:12:57 -0500</pubDate><guid>https://bravenewgeek.com/the-future-of-ops/</guid><description>&lt;p&gt;Traditional Operations isn’t going away, it’s just retooling. The move from on-premise to cloud means Ops, in the classical sense, is largely being outsourced to cloud providers. This is the buzzword-compliant &lt;em&gt;NoOps movement&lt;/em&gt;, of which many call the “successor” to DevOps, though that word has become &lt;a href="https://medium.com/@cindysridharan/what-is-devops-5b0181fdb953"&gt;pretty diluted&lt;/a&gt; these days. What this leaves is a thin but crucial slice between Amazon and the products built by development teams, encompassing infrastructure automation, deployment automation, configuration management, log management, and monitoring and instrumentation.&lt;/p&gt;</description></item></channel></rss>