The O'Reilly Radar Podcast: Alois Reitbauer on performance hacking, DevOps applications, and fostering a culture of respect.
Subscribe to the O’Reilly Radar Podcast to track the technologies and people that will shape our world in the years to come.
In this week’s episode of the Radar Podcast, O’Reilly’s Courtney Nash chats with Alois Reitbauer, chief evangelist at Ruxit, about how DevOps is deeply woven into the Ruxit culture. Reitbauer also talks about how the term “performance hacking” came about at Ruxit, why Chaos Monkey should be applied to systems of people, and why trust across — and between — all departments in an organization is essential.
DevOps beyond DevOps
Performance hacking is a term that emerged at Ruxit about a year ago as the company prepared for the beta launch, Reitbauer said, when they realized as the company scaled up, they needed to bring everyone from all their teams together. “The idea of performance hacking, then,” he noted, “was really, how can we scale up this collaboration between the DevOps teams, the product development teams, and our go-to-market growth hacking teams while we grow as an organization.” The ultimate aim was to figure out how to continue to act like a three-person, one-room startup as the company scaled to a couple hundred people.
One of the approaches embraced at Ruxit is to apply some of the DevOps best practices to their growth hacking and product development strategies. As an example, Reitbauer offered up the idea of Chaos Monkey, as applied not to AWS instances, but to the organization as a whole. The way it works, he explained, is to send a member of a team — any team — away on short notice (or no notice) and see what breaks. Reitbauer said that they’d actually done this and outlined what they learned from the exercise:
We have done it, and it also came up as part of our regular organizational practices. Like, when we had our first very strong conference season — we sent people to different shows all over the place; we picked people from the team who had to go somewhere. And even if people knew they were going to be out of the office in a couple of weeks, they still started to behave as if they would be around all the time, that they wouldn’t be leaving the office. Then, suddenly they were on a plane. They had no time to do their everyday work, and suddenly they realized where they really needed help. So, you don’t even have to make it a total surprise. You just have to plan how to get people out of their regular working behavior to do something else. Then we were able to figure out, ‘We really need somebody else to be able to jump in here or to help somebody out over there.’ It might be a regular holiday or just not daily routine.
Explore the declarative, idempotent, and stateless Puppet DSL.
Before we begin to explore practical best practices with Puppet, it’s valuable to understand the reasoning behind these recommendations.
Puppet can be somewhat alien to technologists who have a background in automation scripting. Where most of our scripts are procedural, Puppet is declarative. While a declarative language has many major advantages for configuration management, it does impose some interesting restrictions on the approaches we use to solve common problems.
Although Puppet’s design philosophy may not be the most exciting topic to begin this book, it drives many of the practices in the coming chapters. Understanding that philosophy will help contextualize many of the recommendations covered.
What to expect at OSCON 2015.
Twenty years ago, open source was a cause. Ten years ago, it was the underdog. Today, it sits upon the Iron Throne ruling all it surveys. Software engineers now use open source frameworks, languages, and tools in almost all projects.
When I was putting together the program for OSCON with the other program chairs, it occurred to me that by covering “just” open source, we weren’t really leaving out all that much of the software landscape. It seems open source has indeed won, but let’s not gloat; let’s make things even better. Open source has made many great changes to software possible, but the spirit of the founding community goes well beyond code. Read more…
Outsourcing your DNS is not a magic bullet.
There is frequently a tendency toward letting one’s guard down when it comes to threats to your IT systems. Absent an immediate “hair-on-fire” situation, we may relax and assume all is well. Yet malicious activity such as hacking, phishing, malware, and DDoS attacks never stop accelerating in terms of frequency and intensity.
So it’s important to have a “Plan B” DNS solution in place and ready before a crisis hits. That way, even if you’re taken off guard, you still have a backup plan and can respond appropriately.
DNS is one of those things nobody really thinks about, until it stops working. The first time easyDNS went off the air on April 15, 2003, it induced a type of existential crisis in me. That summer, after meditating intensely on the situation, I came away with the conclusion that the centralized managed DNS model, as we understood it then, was doomed.
My response at the time was a proposal to pivot to a DNS appliance with decentralized deployments, but centralized monitoring and management. That concept was promptly shot down my co-founders and we’ve kept on with the centralized, hosted DNS model to this day.
The core problem is this: there are many reasons to elect to outsource your DNS to a managed DNS provider. Those reasons include:
Using Docker Machine to create a Swarm cluster across cloud providers.
You understand how to create a Swarm cluster manually (see Recipe 7.3), but you would like to create one with nodes in multiple public Cloud Providers and keep the UX experience of the local Docker CLI.
Use Docker Machine to start Docker hosts in several Cloud providers and bootstrap them automatically to create a swarm cluster.
The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.
In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.
Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:
“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”