We continue our hiring advice series in this episode. It’s a really powerful thing to have people who have established careers, think about what would have made a difference, think about what is important when we work with and mentor inexperienced and junior people who are building a career.
This episode is full of thoughtful advice on how to build subject matter expertise, and the ephemeral qualities that make somebody a good leader or a good worker, or what we were calling an executive function.
If you are building your career, or helping mentor people who are building a career, you will get a lot out of this.
What are the challenges of interconnectedness and transparency, specifically concerning Kubernetes and cloud native applications?
We have a fascinating discussion sparked by the question of how exposed we are. What happens when something we don’t know is connected is open and exposed as hackable? What happens when it closes, and we didn’t know?
We talked about how this is inherent in the architecture of cloud native applications and what you can do about it.
This discussion should get you thinking about how to architect not just your applications, but the platforms that you need to connect together to make them work.
How do you build GitOps, infrastructure and systems relying on events and monitoring, when you need to revert to a polling loop, or augment a polling loop with an event system?
Today, we drill into concrete technical details about events and monitoring. We also suggest practical functional advice on how Git Ops works, how systems work, and how you can build a resilient system.
Stick around for a bonus at the end of the discussion, where we talk a little bit about complexity!
In the July 26th DevOps Lunch and Learn episode, Rob Hirschfeld delves into the intricacies of monitoring and events, highlighting the importance of eventing systems for scalability. The discussion explores the intersection between building a resilient standalone system using polling and enhancing responsiveness through eventing to create a comprehensive and adaptable solution. The key takeaway emphasizes the need for systems that can effectively integrate both polling and eventing to ensure durability and improved performance. For a detailed exploration of these concepts, tune in to the full podcast on monitoring and eventing from July 26th at the2030.cloud.
How do we handle distributing identity? DID stands for distributed identifiers, and today we talk about Web3 as well as distributing identity.
Distributing identity is not just about people and personal identity, but also about things and how we identify and track different things in a distributed way without a centralized infrastructure. That’s fundamental to what Web3 is talking about.
How do we break down the centralization that we have been building over the last 15 years of what Web3 people call Web2, and look at ways to do it in a decentralized way where the trust is between the parties involved? Where it’s set up in a way that you don’t have to have a centralized trust authority.
We spend a lot of time talking about this, what the spec is, what it means, and looking at it in a broader context.
In the July 21st episode, Rob Hirschfeld explores the world of decentralized identifiers (DIDs), a crucial technology emerging from W3C specifications for web three. The conversation underscores the significance of laying the groundwork for web3 protocols and establishing bridges between current and future technologies. While the disruptive impact of web3 remains uncertain, the episode emphasizes the importance of widely adopting, testing, and integrating these new specifications into present-day technologies to shape the next generation of digital frameworks. For a deeper dive into the discussion on decentralized identifiers, tune in to the full podcast at the2030.cloud.
Human factors make governance as code a challenge – today we discuss why looking at things like audit and how we determine what has happened and respond to it in an automated way, may be a great first step to adding controls into a system.
We talk about a lot of human factors of what makes it hard to create a governance system, or what creates a biased system or an unevenly governed system.
We spent the first couple minutes of this podcast talking about our agenda, and those conversations spell out a lot of interesting topics that we will discuss. So hang in for those first couple of minutes, and then we will get straight to the governance.
How do we use chaos monkeys in real life, and practically? This happens all the time when we have failures. The Rogers failure that took out the internet and cell phone use in Canada last week was the start of our discussion.
Predicting how things are going to go out is a common theme for chaos monkeys, and really comes back to how we test infrastructure. Should we be putting it under stress in planned ways like Chaos Monkey, in order to ensure that our increasingly internet and power dependent society is prepared for the inevitable outages?
We have a really fascinating discussion about what it would take to make this type of practice real, including alternatives that people can look at today.
How do we manage complexity? Today we discuss sources of complexity and explore design rules. We also talk about how you think about the systems that you’re building in ways that allow them to handle complexity gracefully.
The simple answer is to have people who are good at thinking about complex systems. Part of that is experience in looking at complex systems, seeing how they operate and being ready to deal with that type of thing like training pilots.
How we get to that insight is really significant, and it impacts how you build teams and systems. In addition to how you build systems that defend themselves that are naturally complex, but have the right defense mechanisms to make them more stable over the long term.
In the June 28th episode, Rob Hirschfeld delves into the topic of complexity, emphasizing the inevitability of complex systems in real-world scenarios. The discussion highlights the importance of training individuals to navigate and manage complex systems effectively, suggesting that exposure and interaction with complexity are critical learning experiences. The key takeaway underscores the need for proactive training to equip individuals with the skills to handle and defend complex systems, ultimately preventing the creation of increasingly fragile structures. For a comprehensive exploration of the human element in dealing with complexity, listen to the entire podcast at the2030.cloud and join the ongoing discussions.
What makes people interested in new tech versus the stable, boring, things that keep the lights on work?
It feels to me as if we’re in the phase of development where we start saying, I need to make sure this all works. I’ve followed all the cool stuff, now I need to make sure everything’s working and get my ROI out.
This conversation questions that assumption, talks about why we care, what we’re really trying to accomplish, and digs into what is boring and what is sexy? And what makes them different.
We continue our Governance as Code discussions in today’s episode.
We started by very broadly looking at Governance as Code generally, but quickly drilled down into Infrastructure as Code meets Governance as Code focused discussion. Understanding that intersection is critical to building something that is both automated and governable.
The topic explored how we audit controls for systems. We also need to make sure that when we build infrastructure, it’s following our policies. The challenge here is making sure that what we’ve automated is conforming to our governance.
How do you manage complexity? Something we talk about a lot in Cloud2030 is how challenging it is to understand complexity, measure it and cope with it.
Richard Cooke wrote a paper called “How Complex Systems Fail,” (how.complexsystems.fail) and in it he talks about complex systems having strong defense mechanisms against failure. That’s what we talked about today. How do we build defense mechanisms for complex systems, not by making them simpler, but by exercising them and testing them?
We discuss the importance of testing, validation, and layer of abstraction and testing the layers in this conversation. If you deal with complex systems, this discussion will be fascinating and actionable.
In the May 24th DevOps lunch and learn, Rob Hirschfeld delves into the concept of making complex systems defensible by exercising and testing them thoroughly. Emphasizing the importance of shared automation and collaborative efforts within communities, he cites examples like Kubernetes and OpenStack as complex systems made more defensible through widespread testing and shared code. While complexity cannot be eliminated, actively exercising systems enhances their defensibility. Join the ongoing discussions and explore the intricacies of complexity management at the2030.cloud.
