<?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>Cloud on Brave New Geek</title><link>https://bravenewgeek.com/tag/cloud/</link><description>Recent content in Cloud on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 09 Oct 2024 16:24:56 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/cloud/index.xml" rel="self" type="application/rss+xml"/><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>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>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>What’s Going on with GKE and Anthos?</title><link>https://bravenewgeek.com/whats-going-on-with-gke-and-anthos/</link><pubDate>Tue, 17 Sep 2019 10:12:52 -0500</pubDate><guid>https://bravenewgeek.com/whats-going-on-with-gke-and-anthos/</guid><description>&lt;h4 id="gcps-slippery-slide-into-enterprise"&gt;GCP’s Slippery Slide into Enterprise&lt;/h4&gt;
&lt;p&gt;When former Oracle exec Thomas Kurian took over for Diane Greene as Google Cloud’s CEO, a lot of people expressed concern about what this meant for the future of GCP. Vendor lock-in is already at the forefront of the minds of many cloud adopters, and Oracle is notorious for &lt;a href="https://www.cnbc.com/2017/04/19/amazon-aws-chief-andy-jassy-on-oracle-customers-are-sick-of-it.html"&gt;locking customers into expensive and prolonged contracts&lt;/a&gt;. However, I thought the move was smart on Google’s part.&lt;/p&gt;</description></item><item><title>Authenticating Stackdriver Uptime Checks for Identity-Aware Proxy</title><link>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</link><pubDate>Tue, 29 Jan 2019 14:46:43 -0600</pubDate><guid>https://bravenewgeek.com/authenticating-stackdriver-uptime-checks-for-identity-aware-proxy/</guid><description>&lt;p&gt;&lt;a href="https://cloud.google.com/stackdriver/"&gt;Google Stackdriver&lt;/a&gt; provides a set of tools for monitoring and managing services running in GCP, AWS, or on-prem infrastructure. One feature Stackdriver has is “uptime checks,” which enable you to verify the availability of your service and track response latencies over time from up to six different geographic locations around the world. While Stackdriver uptime checks are not as feature-rich as other similar products such as &lt;a href="https://www.pingdom.com/"&gt;Pingdom&lt;/a&gt;, they are also completely &lt;em&gt;free&lt;/em&gt;. For GCP users, this provides a great starting point for quickly setting up health checks and alerting for your applications.&lt;/p&gt;</description></item><item><title>API Authentication with GCP Identity-Aware Proxy</title><link>https://bravenewgeek.com/api-authentication-with-gcp-identity-aware-proxy/</link><pubDate>Fri, 25 Jan 2019 11:21:53 -0600</pubDate><guid>https://bravenewgeek.com/api-authentication-with-gcp-identity-aware-proxy/</guid><description>&lt;p&gt;&lt;a href="https://cloud.google.com/iap/"&gt;Cloud Identity-Aware Proxy (Cloud IAP)&lt;/a&gt; is a free service which can be used to implement authentication and authorization for applications running in Google Cloud Platform (GCP). This includes &lt;a href="https://cloud.google.com/appengine/"&gt;Google App Engine&lt;/a&gt; applications as well as workloads running on &lt;a href="https://cloud.google.com/compute/"&gt;Compute Engine (GCE)&lt;/a&gt; VMs and &lt;a href="https://cloud.google.com/kubernetes-engine/"&gt;Google Kubernetes Engine (GKE)&lt;/a&gt; by way of &lt;a href="https://blog.realkinetic.com/http-to-https-using-google-cloud-load-balancer-dda57ac97c"&gt;Google Cloud Load Balancers&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;When enabled, IAP requires users accessing a web application to login using their Google account and ensure they have the appropriate role to access the resource. This can be used to provide secure access to web applications without the need for a VPN. This is part of what Google now calls &lt;a href="https://cloud.google.com/beyondcorp/"&gt;BeyondCorp&lt;/a&gt;, which is an enterprise security model designed to enable employees to work from untrusted networks without a VPN. At Real Kinetic, we frequently bump into companies practicing &lt;a href="https://www.onelogin.com/blog/the-death-star-a-lesson-in-cybersecurity"&gt;Death-Star security&lt;/a&gt;, which is basically relying on a hard outer shell to protect a soft, gooey interior. It’s simple and easy to administer, but it’s also vulnerable. That’s why we always approach security from a perspective of &lt;a href="https://en.wikipedia.org/wiki/Defense_in_depth_(computing)"&gt;&lt;em&gt;defense in depth&lt;/em&gt;&lt;/a&gt;.&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>Multi-Cloud Is a Trap</title><link>https://bravenewgeek.com/multi-cloud-is-a-trap/</link><pubDate>Fri, 14 Sep 2018 11:16:09 -0500</pubDate><guid>https://bravenewgeek.com/multi-cloud-is-a-trap/</guid><description>&lt;p&gt;It comes up in &lt;em&gt;a lot&lt;/em&gt; of conversations with clients. We want to be cloud-agnostic. We need to avoid vendor lock-in. We want to be able to shift workloads seamlessly between cloud providers. Let me say it again: &lt;em&gt;multi-cloud is a trap&lt;/em&gt;. Outside of appeasing a few major retailers who might not be too keen on stuff running in Amazon data centers, I can think of few reasons why multi-cloud should be a priority for organizations of &lt;em&gt;any&lt;/em&gt; scale.&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>GCP and AWS: What’s the Difference?</title><link>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</link><pubDate>Tue, 17 Jul 2018 11:58:21 -0500</pubDate><guid>https://bravenewgeek.com/gcp-and-aws-whats-the-difference/</guid><description>&lt;p&gt;AWS has long been leading the charge when it comes to public cloud providers. I believe this is largely attributed to &lt;a href="https://gist.github.com/chitchcock/1281611"&gt;Bezos’ mandate of “APIs everywhere”&lt;/a&gt; in the early days of Amazon, which in turn allowed them to be one of the first major players in the space. Google, on the other hand, has a very different DNA. In contrast to Amazon’s laser-focused product mindset, their approach to cloud has broadly been to spin out services based on internal systems backing Google’s core business. When put in the context of the very different leadership styles and cultures of the two companies, this actually starts to make a lot of sense. But which approach is better, and what does this mean for those trying to settle on a cloud provider?&lt;/p&gt;</description></item><item><title>There and Back Again: Why PaaS Is Passé (And Why It’s Not)</title><link>https://bravenewgeek.com/there-and-back-again-why-paas-is-passe-and-why-its-not/</link><pubDate>Tue, 06 Feb 2018 16:26:31 -0600</pubDate><guid>https://bravenewgeek.com/there-and-back-again-why-paas-is-passe-and-why-its-not/</guid><description>&lt;p&gt;In 10 years nobody will be talking about Kubernetes. Not because people stopped using it or because it fell out of favor, but because it became utility. Containers, Kubernetes, service meshes—they’ll all be there, the same way VMs, hypervisors, and switches will be. Compute is a commodity, and I don’t care how my workload runs so long as it meets my business’s SLOs and other requirements. Within AWS alone, there are now &lt;em&gt;innumerable&lt;/em&gt; ways to run a compute workload.&lt;/p&gt;</description></item></channel></rss>