The compliance death curve is something I’ve been working on as an evolving concept that tries to explain how companies fight compliance governance and standardization efforts, something that is critical to platform team and infrastructure operations.
Today we try to decompose some of the mathematics that I’ve been using into more universal, more easily understood components. We built a compliance flywheel that I found really fascinating which you can see an example of that work in our podcast description.
It could also be helpful to check out my previously recorded compliance death curve talk that has been released.
TechOps series episode 3 covers how to automate against API’s. We discuss exactly the ways in which you can use API’s effectively, and ways you can run into trouble. We also discuss how we should be consuming API’s, both as a consumer but also in times when we have produced API’s. Many ideas discussed were pulled from learning how people consume our API’s and what we can do to help make them better and safer.
Enjoy this broader TechOps series where we are diving in deep in tips and techniques that improve your journey as an Automator.
What would our systems look like if we didn’t have Kubernetes?
We started this discussion with platform engineering and its associated challenges. In talking about platforms, we covered ways in which people can consume infrastructure more effectively. That segwayed directly into ways in which Kubernetes could be changed under the covers, used for virtualization use for non traditional containerized automation.
This episode is a pretty thorough review of alternatives to Kubernetes, and the ways in which Kubernetes misses the mark.
Today we look at what it takes to have much more collaborative building of automation, templates and shared components that are necessary to really drive platform engineering, and not just between teams at the same company.
We make components for infrastructure automation that bridges the industry because they can be shared much more broadly, similar to the way we share modules in coding languages. We dug into what it takes to make that type of environment work in automation, and what are the prerequisites of the environment?
What are the human and management factors that go into building great platform engineering? And what are the efforts of control having too much control or too much flexibility, not enough collaboration, not creating space for innovation, and changing inside what’s inside these platform engineering efforts?
Today, we discuss centralized versus decentralized platform engineering, or as came up in the conversation about platform engineering, it’s the opposite of Java Enterprise, version and platform.
As you’re doing this type of work interacting with platform teams should influence how you design and authorize the effort to make that work. What type of slack you need to put in the system and what type of authority needs to be given to the platform engineering team.
In the Cloud 2030 Podcast episode on March 14th, Rob Hirschfeld discusses the importance of adopting a system-wide view in platform engineering, emphasizing the need to identify over-optimization in certain areas like developer productivity while underestimating other critical aspects such as operations, security, or compliance. Hirschfeld advocates for a holistic approach to platform engineering, focusing on optimizing the entire system, streamlining teams, and making strategic trade-offs rather than just emphasizing technology or developer productivity. He suggests that this mindset can lead to improved efficiency, productivity, and return on investment for platform teams, highlighting the significance of considering the broader organizational context. Hirschfeld encourages listeners to explore the March 14 episode for a deeper understanding of these concepts, available on the 2030.cloud platform.
Our mini episode today is a short discussion of API delineation and abstractions for platform engineering.
This was a short intro discussion, and it is especially interesting because platform is a major topic we will be exploring in the coming year. We highlight the challenges of finding the right abstraction points as well as building front end and back end automation.
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: 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.
In the Cloud 2030 Podcast episode from January 10th, Rob Hirschfeld discusses the backstage integration, emphasizing the importance of understanding the dynamics involved in building an integration between a developer self-service portal and the systems responsible for a robust deployment experience. Hirschfeld underscores the critical point that while developer interfaces are crucial in platform engineering, they should not be expected to replace production tools like orchestrators, observability platforms, and infrastructure automation components. The episode features a demonstration and code exploration, providing valuable insights into the complexities and considerations of such integrations. For those interested in similar discussions, the Cloud 2030 community welcomes participation at the2030.cloud.
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.
Platform engineering is a topic that seems to be generating a lot of interest going into 2023. It’s sure to be one of those things that enterprises spend a lot of time arguing about and telling each other that they’re doing it wrong.
In this podcast, we dissect why platform engineering seems to be so controversial, and what we can do to help make it more understandable.
We break it down into DevOps components, team components, Dev components, operations components, and ultimately talk about long term trajectories of how all this stuff is going.
In the December 13th DevOps Lunch and Learn on the Cloud 2030 podcast, Rob Hirschfeld explores the concept of platform engineering emerging from enterprises grappling with the challenges of enabling developers while rationalizing operations. The discussion introduces the idea of operational entropy or infrastructure entropy, emphasizing how platform engineering teams can effectively manage the constant changes, security vulnerabilities, and evolving environments, relieving developers of this burden. By shifting entropy management to a shared and collaborative task, platform engineering teams have the potential to enhance how they function, offering opportunities for improvement across the industry. For those intrigued by these discussions, the full episode is available at the2030.cloud, inviting participation in ongoing conversations.
