POPULARITY
20 episodes with rackn
6 episodes with rackn
4 episodes with rackn
2 episodes with rackn
2 episodes with rackn
3 episodes with rackn
2 episodes with rackn
2 episodes with rackn
We step back in this episode of our Tech Ops series and talk about cloud self managed infrastructure and how you balance the competing concerns. We started from a report that RackN had commissioned talking about on premises Kubernetes, and mixing that into your IT infrastructure. Can you have a cloud broker? Can you do multi cloud, some sort of tried and true topics for cloud consideration, but through a new filter and through this repatriation idea of mixing and matching your IT Infrastructure? Transcript: https://otter.ai/u/FKGuQpV-5bQFVASAYDhNQJtuoKM?utm_source=copy_url Resources: https://store.repebble.com/ https://rackn.com/2025/03/18/ready-for-kubernetes-on-bare-metal/ https://www.reuters.com/technology/cybersecurity/google-agrees-buy-cybersecurity-startup-wiz-32-bln-ft-reports-2025-03-18/ https://gabrielsimmer.com/blog/kubernetes-plus-oneplus
Today we dive into RackN high availability technology and what we did to build consensus based raft HA capabilities directly into Digital Rebar. This is one of those episodes where we are talking specifically and only about Digital Rebar, so it is a vendored conversation from that perspective. If you are building HA systems, or are interested in how HA systems work, this is a great session to learn firsthand from our experience! Transcript: https://otter.ai/u/9lA9djczp5GkJbj12k0EzFUXw4g?utm_source=copy_url
In this episode, we continue our TechOps series, diving deep into the topic of container management. As containers become increasingly mainstream, the need to effectively manage and orchestrate these lightweight, purpose-built environments is crucial. We'll explore the distinctions between container management and orchestration, discussing the different tools, techniques and trade-offs involved. We'll also hear insights from the RackN team on how they've approached container lifecycle management within their own infrastructure management platform, Digital Rebar. This is a rich discussion that touches on everything from Kubernetes to system design trade-offs. So let's jump in and learn how to wrangle those containers!
Is high availability always a good thing? Today our discussion takes an operations perspective. We look at places where you were over or under committing high availability, where you were confusing disaster recovery for high availability, and perhaps even securing the wrong service or looking at it the wrong way. We cover all of these scenarios with practical, hands-on examples that I know you will get a lot out of. This is good prep for talking about HA clusters, because the idea of coordinating and monitoring systems is core to HA and HA clusters. In our journey with RackN, a lot of customers who thought they needed very aggressive HA systems, once they are confronted with the overhead of maintaining an HA system, have to ask if you really need it. We started with an active/passive HA implementation using third party monitoring to monitor for when the system failed and spin up the second system, creating a live streaming back up to the failover system. Transcript: https://otter.ai/u/vOVZadHvRTFCZGqcI2DC3nQzDgY?utm_source=copy_url
#234: The shift to cloud computing has greatly increased the popularity of infrastructure as code. But think about it. Cloud is nothing more than an abstraction on top of bare metal servers. Why can't we just as easily manage our bare metal servers as code as well? In this episode, we speak with Rob Hirschfeld, founder and CEO at RackN, about the challenges and opportunities of managing bare metal servers as code. Rob's contact information: Twitter: https://twitter.com/zehicle LinkedIn: https://www.linkedin.com/in/rhirschfeld/ Website: https://robhirschfeld.com/ YouTube channel: https://youtube.com/devopsparadox Books and Courses: Catalog, Patterns, And Blueprints https://www.devopstoolkitseries.com/posts/catalog/ Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/
If you follow cloud2030 discussions or any of my podcasting over the last decade, Edge is a very interesting topic to me. Today's episode is a short update on the state of the edge from a very specific position. In this discussion, I walk through with Josh why edge has been hard for us to nail down from a technology perspective. This is something of special interest to RackN as we keep honing and refining our IT edge infrastructure technology set. Transcript: https://otter.ai/u/OtzOtPvoyiAKZdxJjmE4q9HpSfo?utm_source=copy_url Photo by Khoa Võ: https://www.pexels.com/photo/unrecognizable-man-sitting-on-rooftop-edge-against-cloudy-sundown-sky-5780744/
MLOps Coffee Sessions #164 with Rob Hirschfeld, Open Source and Fast Decision Making. This episode is brought to you by. // Abstract Rob Hirschfeld, the CEO and co-founder of Rack N, discusses his extensive experience in the DevOps movement. He shares his notable achievement of coining the term "the cloud" and obtaining patents for infrastructure management and API provision. Rob highlights the stagnant progress in operations and the persistent challenges in security and access controls within the industry. The absence of standardization in areas such as Kubernetes and single sign-on complicates the development of robust solutions. To address these issues, Rob underscores the significance of open-source practices, automation, and version control in achieving operational independence and resilience in infrastructure management. // Bio Rob is the CEO and Co-founder of RackN, an Austin-based start-up that develops software to help automate data centers, which they call Digital Rebar. This platform helps connect all the different pieces and tools that people use to manage infrastructure into workflow pipelines through seamless multi-component automation across the different pieces and parts needed to bring up IT systems, platforms, and applications. Rob has a background in Scale Computing, Mechanical and Systems Engineering, and specializes in large-scale complex systems that are integrated with the physical environment. He has founded companies and been in the cloud and infrastructure space for nearly 25 years and has done everything from building the first Clouds using ESXi betas to serving four terms on the OpenStack Foundation Board. Rob was trained as an Industrial Engineer and holds degrees from Duke University and Louisiana State University. // MLOps Jobs board https://mlops.pallet.xyz/jobs // MLOps Swag/Merch https://mlops-community.myshopify.com/ // Related Links https://rackn.com/ https://robhirschfeld.com/about/ --------------- ✌️Connect With Us ✌️ ------------- Join our slack community: https://go.mlops.community/slack Follow us on Twitter: @mlopscommunity Sign up for the next meetup: https://go.mlops.community/register Catch all episodes, blogs, newsletters, and more: https://mlops.community/ Connect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/ Connect with Rob on LinkedIn: https://www.linkedin.com/in/rhirschfeld/ Timestamps: [00:00] Rob's preferred coffee [00:17] Rob Hirschfeld's background [01:42] Takeaways [02:36] Please like, share, and subscribe to this channel! [03:09] Creation of Cloud [08:38] Changes in Cloud after 25 Years [10:54] Pros and cons of microservices [13:06] Secure Access Provisioning [15:46] Parallelism with ads [18:08] Redfish protocol [20:21] Impact of using open source vs using a SAS provider [26:15] Automation [32:39] Embrace Operational Flexibility [35:08] Automating infrastructure inefficiently [41:26] Legacy code and resiliency [43:39] Collection of metadata [45:50] RackN [51:23] Granular Cloud Preferences [54:35] Reframing of perceived complexity [57:32] Generative DevOps [58:50] Wrap up
People should be automating as much as they can, but they don't have a lot of ground rules, benefits, or even KPIs that they can use to start knowing if they're automating well. Want to know more? Listen to Rob Hirschfeld, CEO and Founder of RackN, as he discusses how CTOs should rely on automation infrastructure. Show NotesConnect With: Rob Hirschfeld: Website // LinkedIn // TwitterThe CTO Podcast: Website // Speaker ApplicationEtienne de Bruin: Website // LinkedIn // TwitterSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
When you're building something that needs to run people's production data centers, or people start depending on your product, they don't want it to be an MVP; they want that DevOps discipline of building CI and CD systems, testing, security checks, and all those pieces. Want to know more? Listen to Rob Hirschfeld, CEO and Founder of RackN, as he discusses the role of DevOps in building startups. Show NotesConnect With: Rob Hirschfeld: Website // LinkedIn // TwitterThe CTO Podcast: Website // Speaker ApplicationEtienne de Bruin: Website // LinkedIn // TwitterSee Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
https://youtu.be/pTY2RIuxNDs Rob Hirschfeld is the Founder and CEO of The RackN Digital Rebar platform that helps organizations scale their automation efforts. We discuss ways to turn customers into raving fans, the fastest way to build trust in your business, and the pros and cons of open-source software. --- Groom Customer Champions with Rob Hirschfeld Our guest on the show is Rob Hirschfeld, who is the founder and CEO of RackN, a digital rebar platform that helps organizations scale their automation efforts. Rob, welcome to the show. Thank you. I'm excited to be here. Well, I'm very curious about you and your business here. So we're going to dive right in. So tell me a little bit about your journey. How did you end up founding a company that does Digital rebar of all things? Oh, my entrepreneurial journey for RackN started over 20 years ago when I was doing standard IT work and I was consulting. And at the time, I just kept having the same issue over and over again, which is an operations issue. I could write software. It took me as much time to deploy, install, get everything working as it took to write the software. And I found that incredibly frustrating. And that led me to starting my first startup, which was a cloud, one of the very first cloud companies. My co-founder and I actually patented cloud back in 2001. So it's a rare distinction. I'd never made any money on it. We were way too early. It's always a challenge of being an entrepreneur. And, you know, a lot of ways what RackN does with Digital Rebar is exactly the same part of that journey. It's asking that same question of “Why is it so hard for us to do the backend stuff, the, you know, running the infrastructure, making things work, you know, having that automation not take as much time as it takes.” It's been a frustration of mine going all the way back. And, you know, RackN is my latest foray into trying to solve that problem as a product. Well, you know, as I was getting ready for this interview, I was looking into your product and into your website, it says digital rebar. Let me Google that to see what this is exactly. And all the, you know, all the information I kept coming in was all about reinforced concrete and metal rods that are used in reinforced concrete. And the only info source that came up was your website about it. So I guess you coined that thing as well, right? It's definitely nice to have a product name that is unique in the industry. So Rebar, so for people who don't know, Rebar is the steel that people put into concrete to make it more durable and ductile. It's a core. It's actually the absolute core requirement for buildings, skyscrapers and buildings and bridges. And, you know, digital rebar for us as a name accomplish two things. One is, it is actually a good description of what RackN provides, which is the foundational pieces for building infrastructure and all the things that you build cloud applications, IT businesses around, which is really our focus. But it's also an homage back to the original name of the product, which was Crowbar. And so when we started this journey, we started with an open source project that we named Crowbar, being the first tool that you use in— there's a Half-Life video game— and the first you start with a crowbar and no other tool. And so the idea was that you would use a crowbar to get your infrastructure built. And when that name— when it was time to sunset that name, the team wanted something that people in the know, wink and nod, would understand that was a reference back. And so Rebar accomplished both purposes. It turned out to be quite a good name for us. Okay, well, definitely interesting and we're gonna get into this a little bit more. I have more questions, but before we go there, let's talk about the framework that you're bringing on this show. And I think we call it the build an internal champion framework or build internal champions framework.
As we've known for some time, top developer talent is scarce and continues to see a rise in demand. As a result, tech leaders are increasingly focused on developer productivity and the developer experience, looking for strategies to improve both. One potential solution is platform engineering. Rob Hirschfeld is the CEO and Founder of RackN, a leader in physical and hybrid DevOps software. He has been in the cloud and infrastructure space for 20 years and has executive experience at both start-ups and big companies. He has a background in Scale Computing, Mechanical and Systems Engineering, and is an advocate for applying lean and agile processes to software delivery. In this episode, Rob dives into platform engineering, explaining how it can support developers and operations teams, improve productivity and enhance the developer experience. He stresses the importance of collaboration between internal teams and thinking critically about how to define productivity. He also outlines the challenges that he is seeing in automation reliability and automation half-life.Key Quotes:“What's happening is, it's not that hard to write code. It's getting even easier with some of the new things that we have, but it's incredibly hard to take that code on a journey all the way into production and to keep it running in production. And that understanding, learning all those pieces having to do with all the work that has to go into building that infrastructure and making that work, that ends up being a tremendous hurdle for developers.”“If you're looking at productivity as, I delivered a whole bunch of code. It doesn't make any difference. What you actually need to be doing is delivering the right code at the right time.”“The way I see platform engineering is, it's a service-oriented operations infrastructure that consolidates the operations experiences across multiple disparate development teams. There's people out there who talk about it being an internal product. If you get too focused on a product definition of platform engineering, you miss what we're really doing, which is creating a service oriented approach. Meaning, it's an operations team that is looking at the developers as customers and figuring out how to better serve those internal teams as a shared resource.”“What we see everywhere in the industry is there is a reliability crisis in automation. Meaning most people don't believe their automation is very reliable….They're basing it on, when you run your automation, how often does it work? What we find is that a lot of people have under 80 percent automation success.”Time stamps:1:00 Development team's biggest challenges2:46 Journey from ideation to production4:46 Impact of improving the developer experience 11:48 Definition of platform engineering 13:06 Platform engineering case studies18:51 Why developers and operations teams need to collaborate 24:30 How platform engineering impacts security27:17 Importance of transparency and stakeholder buy-in31:59 Automation reliability problems35:00 Will generative AI improve automation?
!!WARNING: DEEP SYSADMIN CUTS AHEAD!! Back in the early 2000s, if you were a sysadmin that had to set up desktops or servers, you probably used Norton Ghost to create images. When virtualization became big, that process moved to creating VM templates. But there was still often a lot of manual intervention in these tasks - password setting, BIOS updates, vCenter installations and more. As the IT world moves more and more towards automating software tasks, what about automating infrastructure provisioning? Sure, there's cloud, but what if you're still on-prem? This week, Rob Hirschfeld of RackN joins us to discuss how RackN helps automate the previously un-automate-able.
In this episode, we talked with Rob Hirschfeld, CEO and founder of RackN. RackN connects the tools people use to manage infrastructure to workflow pipelines through seamless automation across IT systems, platforms, and applications. In this episode, we discussed the challenges of operating on-premise data centers and the need to automate processes as companies adopt edge computing. We also explored the development during the past 25 years of data center evolution, what has improved, and where we still need progress. Key Questions: ● What are the challenges nowadays for cloud infrastructure? ● How have IoT and data centers evolved over the past 25 years? ● How do companies adapt to edge computing?
Rob Hirschfeld is the Founder and CEO of The RackN Digital Rebar platform that helps organizations scale their automation efforts. We discuss ways to turn customers into raving fans, the fastest way to build trust in your business, and the pros and cons of open-source software. Time Stamps [00:30] Rob's entrepreneurial journey [02:06] Understanding the meaning of the "Digital Rebar" [04:15] The Build an Internal Champion framework [07:06] The foundation of RackN's sales function [08:36] How to generate interest for a new product in the market [11:05] Ways to leverage the power of trends in marketing a business [13:00] Pros and cons of open-source software [16:40] Why you need to have repeatable standards for how things work [21:38] The easiest way to build trust in your business [22:33] Things that make an automation platform scalable [27:08] The experience curve and ways to improve your productivity [29:05] Parting thoughts Links and Resources Steve and Greg Cleary's Book: Pinnacle: Five Principles that Take Your Business to the Top of the Mountain Work with Steve - Stevepreda.com Rob's LinkedIn RackN.com Connect with Rob via email: IamRob@rackn.com Rob's website - Robhirschfeld.com
How do we improve the time to decision for CIOs? Today we talk about general business practice and how we can help. Technical innovators and architects create value for the teams that they support. This can either be from an automation perspective, which is what RackN does, or from a data perspective, which Tyler describes in the podcast today. These are real challenges. When we flip the script and talk about the miscommunication between how CIOs see business challenges and translate business challenges into technical delivery, however, we get into a fascinating set of discussions where Joanne brings up some key challenges for 2023. We also discuss mapping those from CIOs into implementation, followed by ultimately trying to find ways that people can make fast, valuable decisions that feel right. This conversation is rooted in important conceptual executive level thinking. We'll include the list of points that Joanne talks about below as well as in the show notes, and I highly recommend you check those out. Joanne Friedman's Key Challenges for 2023 1. Tackle inflation and margin pressure 2. Migrate supply chain disruption 3. Make sustainability a pillar 4. Calibrate talent management strategy 5, Streamline procurement and sourcing 6. Strengthen digital thread 7. Prioritize innovation initiatives We try to name these key challenges, but in a lot of cases we are talking about the list or the graphic. You'll need to refer to the show notes in order to see the complete one. Transcript: https://otter.ai/u/sFESW3yziGOolNbiyt1TlY_IA-M?utm_source=copy_url Image: https://www.pexels.com/photo/man-holding-clapper-board-1117132/
Today we talk about backstage.io, and we have that conversation centered around a demo done by one of the RackN and interns, Zander Franks. Check out the demo video here: https://youtu.be/cAQQOmKz4OI Zander has been exploring with the backstage to Digital Rebar integration, and the conversation that results explains backstage in some fundamental ways and also what it takes to build good developer portals. You will find in this episode both the broader information about how to do integrations where you have a developer portal as a front end and the key insights about how backstage works. To get the most out of the backstage pieces, you will definitely want to see the video on Youtube. Take time to enjoy this whole podcast, both in video and audio format. Transcript: https://otter.ai/u/xWx-q_ZvK4oX1sDJS09F1BsaZZI Image:https://www.pexels.com/photo/wood-fashion-man-people-5650782/
Rob Hirschfeld is CEO of RackN and in this episode we go through the pros and cons of Terraform and how to leverage it for use in Multiple clouds! Resources: Infrastructure as Code at Enterprise Scale > https://youtu.be/bmPCSsAMayw Building templates from scratch > https://youtu.be/EfJ0d9pr16k Digital Rebar playlist > https://www.youtube.com/playlist?list=PLXPBeIrpXjfigvrXEQIJxXmFdTHqobooH https://fosstodon.org/@zehicle@hachyderm.io https://twitter.com/zehicle
Rob Hirschfeld (@zehicle Founder & CEO @rackngo) talks about how Platform Engineering has evolved from DevOps and SRE and how it aligns to Cloud Platforms. SHOW: 682CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwCHECK OUT OUR NEW PODCAST - "CLOUDCAST BASICS"SHOW SPONSORS:Eaton HomepageEaton and Tripp Lite have joined forces to bring more sanity to IT pros days, every day. Visit www.eaton.com/audio to learn more!Datadog Application Monitoring: Modern Application Performance MonitoringGet started monitoring service dependencies to eliminate latency and errors and enhance your users app experience with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.SHOW NOTES:RackN websiteWhat is Platform Engineering? - GartnerPlatform Engineering: What is it and Who Does it? - NewstackSpotify BackstageTopic 1 - Welcome back to the show, it was great to see you in person at events recently. What have you been focusing on the last couple of years?Topic 2 - There's been a lot of discussion about Platform Engineering over the last 6+ months. You've been around this space for a while. We're trying to understand if PE is different from DevOps or SRE or Cloud Platform in the past, or an evolution. Is PE just a common platform maintained with reusable tools, regardless of the infrastructure? Topic 3 - I've heard people say that Cloud Platform and Platform Engineering are colleagues. where one owns/operates the platform, and the other is the “product manager” to the application teams. Is this realistic? Topic 4 - What does “good” look like for Platform Engineering? Is the goal a frictionless developer experience? Are developer consistency and efficiency valid goals? Are there KPIs or Metrics that “good” teams are striving towards? Topic 5 - Any interesting technologies that you're seeing that make Platform Engineering easier, or more manageable? Topic 6 - Any team dynamics that you're seeing that make Platform Engineering easier, or more manageable? FEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet
What is the architectural balance between learning curve, architecture, building things that can scale while acknowledging overhead, and the attitude of just get it done? Don't make my tools complex and let me be very productive quickly. If it doesn't scale, then we see this as an ongoing challenge. Two engineers from RackN led today's discussion in which we really talked about the balance that we try to achieve at RackN as we design our product, with the understanding that, ultimately, scale really does matter. If users have trouble understanding how the product works, at first, that learning curve can push people away, so that they never actually get into the product. That's where finding the right balance is absolutely essential to success. Transcript: https://otter.ai/u/DAfKcHVBAiOY5EuReW1krDYsqso Image: https://www.pexels.com/photo/anonymous-woman-showing-sketch-of-trendy-stylish-outfit-7148032/
In this episode of On-Premise IT Podcast, presented by RackN, Stephen Foskett sits with Calvin Hendryx-Parker, Keith Townsend, and CEO Rob Hirschfeld to discuss collaboration and automation. © Gestalt IT, LLC for Gestalt IT: It's Too Hard to Collaborate in Automation
In this episode of On-Premise IT Podcast, presented by RackN, Stephen Foskett sits with Calvin Hendryx-Parker, Keith Townsend, and CEO Rob Hirschfeld to discuss collaboration and automation. © Gestalt IT, LLC for Gestalt IT: It's Too Hard to Collaborate in Automation
Guest: Rob Hirschfeld Guest Title: CEO & Co-Founder at RackN Topic: Automating Infrastructure Pipelines Language: English Abstract In modern applications, Infrastructure automation is an important piece in the puzzle. Manual infrastructure management and security tasks in the volume required for modern application will probably lead to mistakes, misconfigurations and non compliance platforms. In this episode we spoke with Rob Hirschfeld, CEO and Co-Founder at RackN, about Infrastructure as code and how organizations should automate their infrastructure pipeline.
Rob Hirschfeld is the founder and CEO of RackN, providing secure workflows and modular life-cycle automation for bare metal, edge, and cloud. Rob is a proponent of collaboration in the open source software industry. In this episode, he joins Ben Rometsch to share his insight and ideas from an infrastructure perspective on what needs solving and the potential outcomes.
Software Engineering Radio - The Podcast for Professional Software Developers
Rob Hirschfeld CEO of RackN discusses Bare Metal as a Service. Host Brijesh Ammanath spoke with Hirschfeld about all things bare metal. Hirschfeld starts with the basics before doing a deep dive into bare metal configuring, provisioning, common failures..
In this episode of the Definitely, Maybe Agile podcast, Dave and Peter have a special guest, Rob Hirschfeld, co-founder, and CEO of RackN, a collaborative platform for teams automating infrastructure as code. This time we'll have a slightly longer episode than normal as we dive into different aspects of complexity. This isn't one you'll want to miss. We had a lot of fun recording it and really liked the end result. We hope you do too.This week takeaways:Stop trying to eliminate complexity and figure out how to manage it.Build systems focused on system effectiveness.Complexity problems are collaboration problems.We love to hear feedback. If you have questions, want to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com.
RackN Digital Rebar standardizes the full lifecycle management of your infrastructure, mitigating risk and taming automation helping you innovate faster. Rob Hirschfeld founder RackN, an Austin-based start-up that develops software to help automate data centres joins me on Tech Talks Daily. Rob has been in the cloud and infrastructure space for nearly 15 years and has done everything from working with early ESX betas to serving four terms on the OpenStack Foundation Board. Rob believes that the technology of running data centers and applications on cloud is just part of the bigger story. We discuss why Rob believes developers often develop infrastructure incorrectly and why he is a strong advocate for lean/agile processes. We also talk about the increasing focus on automation, the impact of open-source software, and its emphasis on agility and fast decision-making.
Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company. Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. RackN's Website (https://rackn.com/); Digial Rebar (https://rackn.com/rebar/) Follow Rob on Twitter (https://twitter.com/zehicle) or LinkedIn (https://www.linkedin.com/in/rhirschfeld/). Visit his website at robhirschfeld.com (https://robhirschfeld.com/). Follow RackN on Twitter (https://twitter.com/rackngo), LinkedIn (https://www.linkedin.com/company/rackn/), or YouTube (https://www.youtube.com/channel/UCr3bBtP-pMsDQ5c0IDjt_LQ). Follow thoughtbot on Twitter (https://twitter.com/thoughtbot), or LinkedIn (https://www.linkedin.com/company/150727/). Become a Sponsor (https://thoughtbot.com/sponsorship) of Giant Robots! Transcript: CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show ROB: Chad, it is a pleasure to be here. Looking forward to the conversation. CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is. ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company. But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level. CHAD: So, how agnostic to the actual bare metal are you? ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective. And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices. TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it. CHAD: What kind of companies are your primary customers? ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system. CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves? ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating. Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud. And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want. CHAD: Cool. So, how long have you been working on RackN? When did you found it? ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory. And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern. There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing. But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either. And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work. And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way. CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new? ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar. But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey. CHAD: Now, did you bootstrap, or did you take investment? ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was. CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought? ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers. Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work. And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix? CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right? ROB: You'd like to hope so. [laughs] CHAD: Okay. [laughs] In my experience, that's the culture of the space. ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached. And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard. I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault. And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason. CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers? ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers. But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation. But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience. And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted. And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked. Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically. And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done. And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective. CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long? ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers' data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders. And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products. And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half. And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them. But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard. CHAD: At the time, everything you were doing was open source. ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege. CHAD: So, how did you adjust to that reality? ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still. And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different. So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter. There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that. And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together. CHAD: Was that a difficult decision to make? Was it controversial? ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that. For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it. But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple. And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing. CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change? ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought. I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance. And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification. There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination. CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking. ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened. We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it." CHAD: [chuckles] ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software." CHAD: Exactly. [laughs] ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?" And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge. As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..." We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great." CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do. ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot. We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that. ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle. Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it. CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs. ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that. But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local. CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time? ROB: [laughs] No, of course not. CHAD: I figured that was the answer. ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything. So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case. CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently? ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process. And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system. And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing. CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability. ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive. And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion. CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think. ROB: Yes. CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different. ROB: [laughs] CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way. ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that. But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on. CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum. In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way. ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through? CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use. ROB: Yeah, that ability to split and feature flag is a huge deal. CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing? ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain. The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that. Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build. And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that. From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes. But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors. But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for. CHAD: And so it's actually being delivered by the API that's saying that. ROB: Correct. CHAD: That's cool. ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change. CHAD: Now, are these GraphQL APIs? ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that. CHAD: [laughs] It's a whole nother episode for that. ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations. CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline. ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there's this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process. Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs. The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey. They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows. And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes. And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern. CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you? ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that. I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that. CHAD: Awesome. And you can subscribe to the show and find notes and transcripts for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.
Rob Hirschfeld is CEO and co-founder of RackN, leaders in physical and hybrid DevOps software. He has been in the cloud and infrastructure space for nearly 15 years This is a special episode with Rob returning as the guest for his 4th podcast and for the commemorative 200th episode! We discuss how to unlock the power of multi-cloud automation, the challenge of human ops, and how we are finally reaching an "overnight success" of true bare-metal provisioning and multi-cloud automation and operations. Follow Rob on Twitter here: https://twitter.com/zehicle Check out the awesome work by RackN here: https://rackn.com Subscribe and listen to the 2030.cloud podcast here: https://soundcloud.com/user-410091210 This episode is brought to you by Veeam Software and the 4-Step Guide to Delivering Extraordinary Software Demos that Win Deals and Diabolical Coffee plus the great folks over at Fiverr! Want to ensure real privacy online? Check out ExpressVPN and keep your online life protected.
Cloud isn't just cloud. It's multi, hybrid, edge, and everything in between. The complexity can be mind-numbing. In this podcast, David Linthicum talks with RackN's Rob Hirschfeld about how companies can use infrastructure pipelines to better standardize and manage their infrastructure ecosystems—which can significantly reduce complexity. Rob's take is that automation is key, but it has to be standardized. Of course, infrastructure as code plays a critical role.
How the Change to CentOS Affects the Community This past year, Red Hat made some changes to how CentOS is developed and released. With CentOS's strong following, the change came as a big surprise to the community, the user base, and enterprise companies. To that, Rob Hirschfeld, CEO and Co-founder of RackN (https://tinyurl.com/458kbjpd), had this to say: "If CentOS was designed originally to be an alternative for Red Hat Enterprise Linux (RHEL), it was supposed to be an enterprise-grade Linux based on Red Hat bits." According to Hirschfeld, that led to a degree of commercial tension between the enterprise version (Red Hat Enterprise Linux) and CentOS. But how did this impact the end-users? Hirschfeld makes it clear the impact was and is significant. At RackN, Hirschfeld says, "We heard immediately from customers, asking questions about how they were going to sustain their versions of deployed operating systems." Hirschfeld offered up some specifics on what happens when the previous version of an operating system (in this case CentOS 8) isn't maintained. He says, "When somebody has a patch, or a change, or an upgrade, or they're writing software that relies on that version, which is very common, then they do not have a way to get patches or fixes for the operating system, they have to literally forward port anything they've built on that operating system to the latest version." Hirschfeld also adds that this type of forced migration is very bad, unattractive, not desirable, or not even commercially feasible. As far as competitors are concerned, Hirschfeld mentions both Rocky Linux and AlmaLinux, both of which are forks of CentOS and whose developers have committed to maintaining versions over time. He adds, "It's also worth noting that there are a lot of Linux distributions, like SUSE, Ubuntu, and Debian, which should be considered as an alternative." However, Hirschfeld says of their clients, "We do see people waiting to look at these alternatives. Some of them are just saying, I'm going to switch to a distro where I don't have to deal with vendors like Red Hat." Hirschfeld ends the discussion with talks of migration and says, "I think the jury's still out on whether or not we end up with as dominant a distribution as we have seen with CentOS. And that ultimately, I think, will cause further fragmentation in the Linux industries."
RackN has announced the release of RackN Digital Rebar v4.6, which introduces a load of new features including continuous provisioning automation with self-contained high availability and multi-platform universal workflow. In this episode of Let’s Talk, RackN CEO and Co-Founder Rob Hirschfeld joined us to tell us more about what’s new in v4.6 and also where does it fit in the broader bare metal story.
The RackN team goes behind the scenes describing the many ways that we've worked with customers to automated VMware deployments from the bare metal up.
Interactive and balanced discussion about how and when minimal viable product (MVP) strategy works. Includes story telling about RackN and Digital Rebar journey.
We sat down with Rob Hirschfeld, CEO of RackN to analyze today’s news that Google is planning to ‘donate’ Istio to a foundation. What does it mean for the project and the community? Which foundation will Google pick? Will it be another CNCF project or will it become an anchor project for a new Linux Foundation project?
The RackN teams provides an in-depth overview of how DHCP and PXE boot work along with highlights in their remote booting on a Raspberry Pi
Happy 100th podcast!! Rob Hirschfeld is the founder and CEO of RackN. Rob has been along for many podcasts with Eric and is also a premiere podcaster himself at the L8ist Sh9y Podcast. This show introduces the freshly minted Edge Lab which is finally a way to do bare-metal provisioning for an edge scenario with the magic (and science) of Digital Rebar, K3s, and most importantly, this is a reference build to help you experiment with PxE booting and much more. Check out the Edge Lab at https://edgelab.digital Check out Digital Rebar at https://rebar.digital If you want to participate in the Edge Lab but cannot afford to purchase the gear, please reach out on Twitter to @DiscoPosse and we are working on grant programs and discount opportunities to help those folks who are underrepresented in technology and who can benefit from access to these resources.
This week we discuss all the news from VMware's annual VMworld conference, held this week in San Francisco, with special guest RackN founder/and CEO Rob Hirschfeld. RackN is provider of next generation infrastructure automation software for provisioning bare metal, VMs, clouds, and edges. At the event, VMware announced it's going all-in on Kubernetes. There were hints the company was going in that direction with its acquisition of Heptio in November, a company founded by Joe Beda and Craig McLuckie, who were among Kubernetes' founders. At the show, the company announced that vSphere with Kubernetes in a new alpha offering called Project Pacific. Hirschfeld opined that, with this Kubernetes support, VMware is playing defense, given that operations teams using the vSphere platform might be getting requests from their developer counterparts for Kubernetes support.
This week we discuss all the news from VMware's annual VMworld conference, held this week in San Francisco, with special guest RackN founder/and CEO Rob Hirschfeld. RackN is provider of next generation infrastructure automation software for provisioning bare metal, VMs, clouds, and edges. At the event, VMware announced it's going all-in on Kubernetes. There were hints the company was going in that direction with its acquisition of Heptio in November, a company founded by Joe Beda and Craig McLuckie, who were among Kubernetes' founders. At the show, the company announced that vSphere with Kubernetes in a new alpha offering called Project Pacific. Hirschfeld opined that, with this Kubernetes support, VMware is playing defense, given that operations teams using the vSphere platform might be getting requests from their developer counterparts for Kubernetes support.
Rob Hirschfeld talks about the new open source Digital Rebar 4 release with its new features and flipped open source release changes.
How is the open source Kubernetes container orchestration engine actually used out in the wild? Does it drive large clusters for service providers to run multi-tenant apps? Or are its clusters small, fit for managing the lifecycle of a single app? Rob Hirschfeld, CEO of bare metal infrastructure management company RackN, did his own informal Twitter survey to find some answers, and got a wealth of answers, which he summarized in a blog post for The New Stack. On this episode of the The New Stack Context, a weekly wrap-up podcast of news and views in the cloud native computing community, we talk with Hirschfeld about his survey, and what the future may hold for Kubernetes. "As Kubernetes emerges as the de facto management platform, we are still figuring out what that means. The challenge is that it exists in a gray zone between a specialized application platform and general purpose infrastructure abstraction. I wanted to understand if one set of use-cases was more common," he wrote. In the second half of the show, we talk with our Oakland technology news correspondent T.C. Currie about her recent podcast interview with Zack Butcher, a founding engineer at Tetrate.
As more open source projects become commercially driven (rightly so) there is a challenge among open source community folks as to when it is right to use open core, open source, or the dreaded fork. Rob Hirschfeld joins us for a great discussion that started on the news of AWS launching Open DIstro for Elasticsearch and we take on some challenging topics around open source, monetization, and commercialization of open platforms and products. Rob refers to a great Gitlab talk which discusses open source business models which is also a must-watch here: https://www.youtube.com/watch?v=G6ZupYzr_Zg
Join host Mike Kavis and guest Rob Hirschfeld, founder and CEO of RackN, as they discuss Edge computing—taking a deep dive into how edge computing works, applications of Edge technologies for business issues, how it’s changing the IT infrastructure and how it’s complementing the cloud computing landscape. They also take a look at the future of Edge computing and how it will revolutionize both IT and industry.
Rob Hirschfeld is the Founder and CEO of RackN. Rob has a background in Scale Computing, Mechanical and Systems Engineering and specializes in large scale complex systems that are integrated with the physical environment. He is able to break long range technical vision into meaningful tactical steps. Rob has executive experience at both start-ups and big companies where he is a strong advocate for Lean/Agile processes.
Rob Hirschfeld, CEO/Co-Founder of RackN and Greg Althaus, CTO/Co-Founder of RackN have a short discussion of the issue faced by DevOps and Operations teams finding time to investigate new technologies that could improve their day to day capabilities. In this discussion, time is more important than money.
In this podcast, I talk with Rob Hirschfeld, founder of RackN, on composable infrastructure, Kubernetes, OpenStack and more --- Support this podcast: https://anchor.fm/modernenterprise/support
Joining us this week is Eric Wright, Director Technical Marketing/Evangelist at Turbonomic and podcaster/evangelist at Discoposse.com. Highlights " RANT on Cloud Terminology w/ new terms "DevOpsishFullStackishness" & "Woke IT" " Open Source communities, vendors, and value of users " Edge Computing - Definition, Turbonomic Role in Cloud/Edge " Edge and Cloud are Hybrid - Embrace multiple paradigms including legacy " Discussion of Go language and RackN usage
Aaron and Brian talk with Rob Hirschfeld (@zehicle, CEO @rackngo; Kubernetes Cluster Ops Co-Chair) about the consistency, continuum and confusion between the concepts of DevOps and Site Reliability Engineering (SRE). Show Links: Google SRE Book DevOps vs. SRE DevOps vs. SRE (Rob on Datanauts) Love DevOps? Wait until you meet SRE? Open Source PXE "L8istSh9y" - Rob's Edge & Automation Podcast [PODCAST] @PodCTL - Containers | Kubernetes - RSS Feed, iTunes, Google Play, Stitcher, TuneIn and all your favorite podcast players [A CLOUD GURU] Get The Cloudcast Alexa Skill [A CLOUD GURU] A Cloud Guru Membership - Start your free trial. Unlimited access to the best cloud training and new series to keep you up-to-date on all things AWS. [A CLOUD GURU] FREE access to AWS Certification Exam Prep Guide - At A Cloud Guru, the #1 question received from students is "I want to pass the AWS cert exam, so where do I start?" This course is your answer. [FREE] eBook from O'Reilly Show Notes Topic 1 - What is the State of DevOps today? On one hand, there’s Gene Kim’s DevOps Reports (all is great), on another hand is DevOps Days which has become about Empathy, and somewhere in between are companies struggling with all of this silo-busting and automation and constant change. So where are we? Topic 2 - The DevOps community seemed to want to reject all sort of labels and titles (DevOps engineer, DevOps certified, etc.) and how there is this “SRE” (Site Reliability Engineering) concept. Is this just a new name for DevOps? Topic 3 - Like NetFlix had microservices, so everybody needed microservices - Google has SRE, so now everyone needs SRE? How does SRE fit into a non-Google company? Topic 4 - Many Infra/Ops-centric people have been trying to learn automation and some basic programming (e.g. Python, Powershell/Scripting). SREs are often described as programmers that live in the Ops world. Can these current Infra/Ops people evolve to SRE? Topic 5 - Do you find that DevOps or SRE apply more (or less) to using certain types of technologies vs. other technologies? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet and @ServerlessCast
In this week’s L8ist Sh9y Podcast, we bring on the Digital Rebar team at RackN to discuss several issues they have working on over the past few months: * Patch Rest APIs and CLI : Scaling Challenges Require Patch * Swagger API History and Changes : No CLI Generation * Integrations to Existing Tools up the Stack
Rob Hirschfeld is the founder and CEO at RackN, an Austin-based startup which makes software to automate data centers and managing servers well. Hirschfeld has 15 years of experience in the cloud and infrastructure industry. He has served four terms on the OpenStack Foundation Board and previously worked as an executive at Dell. He’s also a serial entrepreneur. Hirschfeld founded RackN in October of 2014, the company has received some angel investment, earns money and is currently raising money. He founded ProTier in 1999, which Surgient founded in 2004. He also founded Zehicle and has worked for several other technology companies and startups. RackN graduated from the TechRanch Venture Forth program led by Kevin Koym. That helped the company launch, Hirschfeld said. Today, the company is active in the meetup scene and Capital Factory, he said. Andrea Kalmans with Lontra Ventures, is an advisor to the company too, he said.
Rob Hirschfeld, CEO/Co-Founder of RackN speaks with Mark Thiele, Chief Strategy and CIO of Apcera on a variety of cloud and DevOps related topics including Mark’s recent blog post, Why Adoption of Public Cloud Likely Won’t Exceed 17 Percent of Total IT Demand by 2022.
Rob Hirschfeld, Co-Founder/CEO of RackN announces the availability of the RackN beta program. This solution allows operators to leverage the open source Digital Rebar Provision tool for physical hardware and cloud provisioning in the data center.
Rob Hirschfeld, Co-Founder/CEO of RackN discusses the challenges of DevOps from the CIO and Operator viewpoint and how it is critical for each group to better understand the issues they each face. Only then can a true DevOps experience be had.
Rob Hirschfeld, Co-Founder/CEO of RackN announces the availability of Digital Rebar Provision 3.1 providing fast, secure, open physical provisioning in the datacenter. Learn more at http://rebar.digital.
Stephen Spector, HPE Cloud Evangelist talks with Rob Hirschfeld, Co-Founder and CEO RackN about the installation process for Kubernetes using Kubespray, Ansbile, and Digital Rebar Provisioning. Additional commentary on the overviews of Kubernetes, Containers, and Installation in this podcast.
Stephen Spector, HPE Cloud Evangelist talks with Greg Althaus, CTO and Co-Founder of RackN about how the Digital Rebar Provisioning solution provides bare metal server support for the HashiCorp Terraform Solution.
Rob Hirschfeld, CEO and Co-Founder, RackN talks with Stephen Spector, HPE Cloud Evangelist about the recent uptake in Ansible news as well as how Digital Rebar Provision assists Ansible users.
This fun chat expands on what we started talking about in episode 42 (http://podcast.discoposse.com/e/ep-42-spiraling-ops-debt-sre-solutions-and-rackn-chat-with-rob-hirschfeld-zehicle/) as we dive into the challenges and potential solutions for thinking and acting with the SRE approach. Big thansk to Rob Hirschfeld from @RackN for sharing his thoughts and experiences from the field on this very exciting subject.
Brian talks with Rob Hirschfeld (@zehicle, Founder/CEO of @RackN) about the concepts of SRE (Site Reliability Engineering), the challenges of maintaining infrastructure software, emerging tools and the next-generation of operations. Show Links: Get a free eBook from O'Reilly media or use promo code PC20CLOUD for a discount - 40% off Print Books and 50% off eBooks and videos [DISCOUNT] Start Serverless Skills Bundle (4 courses) - (only $49 instead of $79) [FREE] Alexa Development for Absolute Beginners Sign up for a Datadog account and get a FREE t-shirt RackN website RackN and SRE Google SRE Book Show Notes: Topic 1 - Welcome back to the show. Let’s start by talking about the concept of SRE (Site Reliability Engineering). Give us the basics and maybe explain how it differs from what people define in DevOps. Topic 2 - Application development has been moving faster for quite a while (agile development, etc.). But now infrastructure/operations teams have to deal with faster software - especially around updates (e.g. Kubernetes releases every 3 months). How are companies managing this? Topic 3 - Given that this pace of operations change may not slow down, how do you think about the challenge in terms of process/operations versus technology/tools? Topic 4 - What are some of the steps that companies take to better prepare for this type of operational model? Tools, process, skills, etc. Topic 5 - Do you see SRE as being a progression for existing infrastructure/operations people, or is this more focused on sysadmins or developers that want to get away from building applications? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet
In this podcast, Rob Hirschfeld, Founder and CEO, RackN discusses the latest trends in IT management at scale including DevOps and the emergence of Site Reliability Engineering (SRE). SRE is a response to the limitations of DevOps faced by Google providing an answer to the significant challenges of operating global Hybrid IT infrastructure that continues to grow at a rapid rate. For more information on RackN visit www.rackn.com
If you only read one blog this week, this is the one you should start with: https://robhirschfeld.com/2017/01/17/spiraling-ops-debt-the-sre-coding-imperative/ We chat with Rob Hirschfeld (@zehicle) on the subject of spiraling operations debt and the SRE coding imperative, plus how he and the RackN team are helping to solve some of those challenges.
Our guest on the podcast this week is Rob Hirschfeld, Founder and CEO at RackN. We discuss the differences between Docker Swarm and Kubernetes as well as the debate about how many companies use containers the right way. We also look at hybrid and how it can be easy to lift a container from Amazon and move it to Google, but there will still be key differences in networking and storage between the two that make the shift more complex. Last, we talk about the pros and cons of going all in on one vendor.
In this episode, we chat with Rob Hirschfeld (@zehicle) about the evolution of OpenStack, interoperability, abstractions and APIs, and more. We also talk a little about RackN and we even find out the origin of the Twitter handle Zehicle. Episode was recorded while at the OpenStack Summit in Austin which gave a perfect background for us to really dig into where the evolution of OpenStack and the big tent approach has brought us, and what may be next in the open cloud ecosystem.
Our guest on the podcast this week is Rob Hirschfeld, Founder and CEO at RackN. We discuss hybrid devops and why the hybrid cloud is here to stay. We talk about the importance of abstraction layers in allowing each team to use whichever vendor works best for them while continuing to be supportable. We debate the security of containers versus private cloud and how the discussion is changing with the emergence of new companies that monitor security overall and will not run a container with a vulnerability.
Brian talks with Rob Hirschfeld (@zehicle, Founder/CEO of RackN) about the evolution of OpenStack, Containers, his company RackN and Digital Rebar, and how Microservices and DevOps go hand-in-hand. Show Links: This show sponsored by Intel Cloud For All The Cloudcast is an O'Reilly Media Partner, Request a free eBook or use code PCBW for a discount on all books RackN Homepage Digital Rebar Homepage (GitHub) Rob’s Blog How We Changed Digital Rebar’s Architecture, But Not Its Code, in Six Easy Steps Topic 1 - It’s been a long time since you were last on the show (Eps.16), back when you were at Dell in 2011. A lot has changed since then. What have you been up to? Topic 2 - You been heavily involved in OpenStack since the earliest days, serving in board roles, contributing role, working on architectures. You’ve also been critical of several areas around operations. What’s the state of OpenStack from your perspective? Topic 3 - Let’s talk about Digital Rebar and the challenges involved in using resources in different environments - bare metal, containers, VMs, various clouds. Topic 4 - You recently wrote a great article in The New Stack about how you migrated Digital Rebar to a microservices architecture. Give us the lessons learned in that migration process. Topic 5 - Given all the tools and frameworks and platforms available to developers and operations today, why is it so important to align application architectures (microservices) with modularity of the tools and frameworks? Can monoliths and microservices exist across DevOps
© 2020-2025 Ivy Podcast Discovery LLC
