Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.
The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.
Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.
Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.
The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.
By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.
The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.
One of the things that tends to hold back adoption of DevOps are all the low-level events that need to be correlated by an engineer to generate anything that approaches actionable intelligence (AI). To eliminate that requirement, Loom Systems created a Loom AIops platform to automate many of the tasks that normally would need to be performed by a DevOps engineer.
Loom Systems has upgraded the Loom AIops platform by adding Distributed Entity Tracing, which makes it easier to analyze events across a range of interdependent applications and associated middleware. In addition, Loom has created Correlations View, which simplifies identifying how alerts being generated are related to one another.
Finally, the latest version of AIops adds support for the OpenStack cloud management framework, in addition to sporting a revamped set of dashboards that are easier to navigate.
Dror Mann, vice president of product for Loom Systems, says one of the reasons that DevOps is not widely implemented is that today it requires IT staffs to accumulate and correlate massive amounts of low-level event data to create anything approaching actionable intelligence. Loom AIops is designed to automate the low-level tasks relating to DevOps to enable the IT staff to focus more of their time and effort on fixing issues and reducing the time required to release and update applications.
Loom AIops, says Mann, accomplishes that goal by first streaming all the application log data into its platform, followed by all the log data generated by any dependencies that application might have. Loom AIops then applies machine learning algorithms in real time to identify the root cause of an issue. Armed with that information, it becomes a lot easier to reduce the mean time to resolution (MTR), which then provides the IT organization with the time needed to address more complex management challenges, he says.
Mann notes the single biggest challenge IT organizations encounter with DevOps is that it requires them to change their modus operandi. By automating many of the lower-level DevOps tasks, there’s more time available for IT organizations to think through the cultural changes required to successfully implemented integrated DevOps processes.
Most IT professionals will view the application of AI to IT operations with a combination of skepticism and trepidation. It will be difficult initially for many IT professionals to trust the analysis being generated by AI software. Once they do begin to trust that analysis, there naturally will be some concerns over to what degree an AI program can eliminate the need for a DevOps engineer altogether. But, Mann notes, there are many complex tasks that never get addressed because most DevOps engineers spend an inordinate amount of time and effort trying to correlate the right data.
At this juncture, usage of AI within the context of DevOps is now all but inevitable. The challenge now is not figuring out the line between where humans add higher orders of value compared to machines that are generally going to be limited to identifying patterns. The advantage a machine has it that once it learns something, it doesn’t forget it, take days off or switch jobs. However, being able to identify a pattern is not nearly the same as being able to apply reasoning to what the sum total of those patterns really means for the business.
The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.
Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:
Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.
IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.
Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.
There’s no shortage of variants of Node.js in the world, but NodeSource is making a DevOps-related case for why IT organizations should standardize on its runtime implementation.
NodeSource released version 2.3 of N|Solid, which adds support for event loop delay notifications that pinpoint precisely where an issue that needs to be addressed has occurred with an application, based on the Node.js variant of JavaScript.
Pravin Halady, product manager for NodeSource, says N|Solid uniquely provides a runtime implementation of Node.js that provides that capability. Coupled with tools to monitor applications based on N|Solid, additional visualization tools and configurable webhooks-based integration to create alerts that can be shared via collaboration platforms such as Slack, N|Solid is the only Node.js runtime specifically optimized for enterprise IT environments, Halady says.
He notes one of the thornier issues organizations that embrace Node.js face is that any long-term synchronous activity blocking the event loop can prevent other incoming requests from reaching the server. Before too long, the application hangs or simply crashes. By providing insights into when an event loop delay is occurring in real time, Halady says IT organizations don’t have to waste time trying to reproduce the problem. The result is a much faster time to resolution of Node.js application issues.
DevOps teams can find themselves dealing with those types of issues at a much higher level of frequency once developers employ Node.js. As adoption of the most widely employed variant of JavaScript increases, IT organizations are managing more applications than ever. In fact, a recent survey published by the Node.js Foundation finds that three out four respondents plan to increase their usage of Node.js over the next 12 months. The primary reasons cited for that additional usage are increased developer productivity (68 percent); improved developer satisfaction (65 percent); reduced development costs (58 percent); and increased application performance (50 percent). Nearly half the respondents (47 percent) working in enterprise IT organizations say they been using Node.js for more than three years. Over half the developers (58 percent), in contrast, report having more than 10 years of experience working with Node.js.
IT organizations generally have very little visibility into what’s occurring inside Node.js applications, which makes it difficult to apply DevOps processes. In fact, most DevOps processes in place today are wrapped around applications written in more mature languages such as Java. Developers employing JavaScript tend to not be as well-versed in the role programmers ideally play within the context of an integrated set of DevOps processes.
In the absence of those processes, having the tools needed to debug an application in real time becomes more important to an IT operations teams that needs to inform a developer about the root cause of a specific issue. Otherwise, the developer ends up running one test after another in the hopes of replicating the problem. Unfortunately, the probability of accomplishing that goal inside most organizations is often relatively low. Because of that issue alone, an event loop delay notification made in real time is likely to pay for itself in a matter of hours.
The inclusion of IT security into DevOps processes, also known as DevSecOps, appears to be occurring at an accelerated rate. A new survey of 300 enterprise IT organizations published this week by DigCert, a provider of identity management and encryption software, finds that almost half (49 percent) of the respondents says they have completed DevSecOps, while another 49 percent say they are already working on it.
In terms of overall impact, however, only 22 percent say they are doing well in terms of achieving and maintaining higher levels of security.
In addition, those that have achieved DevSecOps say it took them anywhere from 12 to 14 months to make the transition. Those that have not completed the transition are estimating it will take them seven to 11 months. Based on the experience of the organizations that have completed the transition, there would appear to be a natural tendency to underestimate how much the cultural difference between developers and IT security teams can negatively impact integration objectives.
Jason Sabin, chief security officer (CSO) for DigiCert, says that while many organizations may have brought IT security professionals into the process, an increase in the overall security of applications being built requires more time and patience, says Sabin.
DigiCert recommends IT organizations identify an IT security champion within a DevOps process and automate the implementation of IT security controls as much as possible. Those moves can help lower developer cultural resistance to having to spend time on what often are considered mundane programming issues.
It’s worth noting that most IT security professionals don’t have much in the way of programming skills. They can secure an application using any number of platforms that have a management console. But understanding how to employ APIs to help plug security holes before an application gets deployed is beyond the capabilities of most IT security professionals. IT security professionals can make developers aware of issues, but in general there’s not much they can do to fix the application itself.
Also, IT security professionals typically don’t understand the amount of coding that might be required to fix an issue, and they are not always able to access the true risk associated with a specific vulnerability. All vulnerabilities tend to be treated as equal threats regardless of number of instances a vulnerability has been exploited.
The good news is a full 88 percent of respondents saying it is somewhat to extremely important to integrate security into DevOps. Failure to do so will lead to issues such as increased costs (78 percent), slower application delivery (73 percent) and increased security risks (71 percent). Awareness of these issues should eventually lead to the development and deployment of more secure applications.
The issue, of course, is that not every development team is equally along the DevSecOps maturity code. Because of that issue, it unfortunately may be years before the preponderance of applications running in a production environment are able to defend themselves from even the most rudimentary cybersecurity attacks.
In this DevOps Chat we speak with Damon Edwards, co-founder and chief product officer of Rundeck. What I like to say about them is, Rundeck putting the Ops in DevOps. But Damon needs no introduction to those who have any familiarity with DevOps. He is one of the early leaders of the DevOps community and continues to evangelize DevOps around the world. In fact, he is speaking at our DevSecOps event at RSA APJ in Singapore July 25, which you can find here.
It has always been a hope of me personally to have Damon as a guest on DevOps Chat. Besides being a great interview, Damon and Rundeck are a great story of an open-source project growing organically, spawning a great commercial business. This is harder than you think and Damon tells us a bit about it in this interview.
As usual, the streaming audio is immediately below and the transcript is below that. Enjoy!
Audio
Transcript
Alan Shimel: Hey, everyone, this is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. We’ve got a really, really special guest for this DevOps Chat, it’s one of my heroes in the DevOps movement from when I first started researching what DevOps was and it’s about. I’m thrilled to have him appear on our DevOps Chat today, none other than Damon Edwards. Damon, welcome.
Damon Edwards: Thank you, Alan. Thank you for having me and thank you for those kind words, I’m excited to be here.
Shimel: Thank you. So Damon, I’m going to guess a lot of people in our audience have heard of Damon Edwards, instrumental in putting together DevOps Days, especially DevOps Days at Silicon Valley kind of drove that for a number of years. You had several different companies, both open sources and consulting, and probably maybe even more than all that, Damon, you have appeared—I don’t even know if you keep count any more—at how many different DevOps Days events or other DevOps related events where you’ve spoken at. I mean, do you know? Have you kept track?
Edwards: I don’t know, [Laughs]. I know it’s less than John Willis, because he reminds me of that on our podcast, but DevOps Café, I’m going to give a cross plug for that. We just had you on, Alan, as a guest, and you were fantastic. Yeah, I kind of lucked into just sort of right place/right time. We were really interested in how do you move fast—we called it Dev2Ops ourselves internally, our consulting business we used to call DTO Solutions that we have. And it was really all about how do you help organizations move faster? For a long time, scale was the problem. Hey, how do you deploy, hook into a thousand servers, right? A thousand servers used to be a big deal. And then it suddenly came to be that, hey, we can deploy anything to anything, that’s not really—deployment scale is not really the problem, speed is the problem. That organizations can’t move fast enough, that the pipeline is jammed, that the organization is kind of stuck in cement. And the organizations that are able to free themselves and decouple themselves and move in this new and fast way had a strategic advantage, were really kicking the butts of the big traditional companies that were kind of locked in place.
So we really started asking ourselves, why is that? Our customers started asking us, why is that? And that really got us into lean and all those things. And at the same time, John Allspaw gave his big talk at Velocity, I saw that, you know, fell in with John Willis and Thatcher Dubois and the rest of the crowd and the DevOps movement was born. And we kind of became known as the folks who are great at taking the design patterns that you see on stage at the big high flyers and translating them to the big enterprises out there. So that was DTO Solutions.
Then along the way we had a side project called Rundeck that was an open source tool, I’ll get to that in a second, but it really just took off. And after awhile, enough people called us about Rundeck, we really got excited about it, and there are two reasons why we decided to jump with both feet into Rundeck. The first being that I feel like operations is a DevOps frontier that’s not truly explored yet. I think in a lot of big organizations the dev side, they’ve got dev talking better to QA, they’ve got the build pipeline going, the little dev test cycles are going a lot faster. Maybe deployment’s happening a lot faster. But these DevOps principles haven’t really entered into full operations mode yet. A lot of big operations organizations just haven’t been able to transform themselves, and we saw DevOps, especially we saw Rundeck as a tool being used just to do that. So as a way to, number one, I think we were always product guys at heart, we wanted to see where we could take it. But number two, I really feel it’s helping push the DevOps movement to a new place.
Shimel: Yeah, I agree with you. And Damon, just again, adding a little color, you actually have a video up somewhere, it’s kind of a brief history of DevOps. For any of our listeners who really want to know kind of how DevOps got started, Damon has a great video on that that I’d highly recommend. But let’s jump into Rundeck. Damon, as you mentioned, it was a side project to what you were doing with DTO. It was open source, wasn’t it?
Edwards: Yeah, Rundeck’s core is it’s an open source product, an open source community. I Think last time we did some sort of estimate. There’s around like 25,000 different open source users out there. So it kind of became this silent—for us, we woke up one day and said, wow, a lot of people are really using Rundeck, and they were calling us saying, “Hey, we really want to do more with Rundeck,” and that led to the formation of what’s now Rundeck Inc.
And if you want to talk about what Rundeck actually is, fundamentally, from a technology perspective, it’s an orchestration and scheduling platform. Right now a lot of orchestration happens within different silos, so there’s container orchestration, there’s configuration management orchestration, all kinds of different things like that. There’s enterprise job schedulers. But we noticed that as folks are transforming their operations organizations there was this layer that needs to span all of those different silos of tools, all the different islands of automation that they have, all the different systems that they have. They want to create procedures, operational procedures that span all of those different silos. And they want a place where they can define those procedures using whatever scripting language that they want. They want to be able to define the work flow, they want to be able to set security around it, that’s huge, because what a lot of people are doing in those procedures is not just helping their operations teams be more efficient and effective but they’re starting to open up more of a self-service model. Self-service operations is the big design pattern that I think is really driving us forward.
Which is, all these people that need to do operational things throughout my organization, and as I start to transform my organization, how do I safely let them do things that could be deployment but it’s often remediation activity, diagnosing things, just doing operational things that I need to do, how do I let an ops team define those and be in charge of those and say who can do what, when and where, but allow other people to participate? And by participate, I mean two things. One is give them the button or the API to hit themselves to do the operational things that they need to get done, but also give them a mechanism to which those different teams, often in different business units, can define those operational procedures for the things they’re creating themselves, then have a standard mechanism to hand it off to operations where ops and security can vet them and then that ops and security vetting process can then turn around and give access to those other teams. So it’s like how do we let the operations decouple, let more people participate in operations, and do it all in a safe, sane and secure and audited and logged way? That’s where Rundeck shines.
Shimel: Got it. I mean, Damon, you opened a bunch of different things in here I want you to kind of flesh out a bit. So number one is this whole idea of ops, right? My personal opinion is for too long with DevOps there was a very developer-centric focus of DevOps, and really, at the end of the day, ops is where it’s at for a lot of different reasons, especially in the world we’re living in. And you’re clearly working in there. But we’re not looking to recreate silos, right? There’s a place for the development team, right? They interact within Rundeck, if you will, with the ops folks, right? This isn’t for ops only kind of thing.
Edwards: Right, right. If you look at organizations today, again it kind of goes back to our statement before about how scale is no longer the problem but organizational speed was the problem that caused the DevOps movement. And if you look at what’s going on with operations it’s a very similar thing. It’s not scale of the infrastructure as much as it’s complexity and scale of the organization that causes the problems. So in a lot of large enterprises, most every large enterprise, you have this central place called operations. Just kind of put the teams out of the way at this point, just think about the action of running all these things. You have all these different streams of activity that come into this central place, and that has to all hang together to form this enterprise. That is operations. That is the business. That’s where all the money is made. All these streams of development activity that come into that, essentially they’re part suppliers, so the next version, the next cogs in the machine that has to run, but it all has to hang together or we aren’t making any money, unless you actually sell software, which very few companies do these days, your running the service is the business. So operations is very important. But in that same vein, that operations, because things are so tightly coupled and it all falls to this one often central team, that becomes a huge bottleneck and a big problem, and it really ends up stunting or blocking the DevOps. That decoupling transformation that these organizations want to go to, they get blocked by the sort of calcification of the classic operations domain.
And so we see these high flying organizations, what they’re doing now, the high performers, what they’re doing is a frame of how to uncap and decouple all of that operational activity. And in doing so, they’ve kind of realized there are three key pieces to what you’re working with. There’s the ability to—who defines the procedures? Who defines the procedures for the things that they’re going to be running. The second is, who can push the button for those procedures, button meaning through a GUI or through an API. And then third, who has the secondary or the operational, the management control of that action?
Traditionally that all kind of fell to one group or one team and they’re grossly outnumbered by the rest of the organization and that became the big ops bottleneck. Their whole mindset was all about let’s protect ourselves from being overrun. Let’s protect ourselves because people are pushing things at us that they don’t really know how it’s all going to hang together, they don’t have that responsibility for defining things. So ops was in a very, very tough position and doing their best. We see these organizations doing a bit of a Tom Sawyer paint my fence or a jujitsu move by saying, hey, let’s redefine who does what where. Let’s allow that definition. Let’s allow those teams. They created these things, let’s allow them to participate in the definition of these operational procedures. And then let’s also, once it comes back to us, let’s let them push that button as well—for some things, not everything—maybe just certain non-destructive things, or maybe certain teams can deploy but certain teams we don’t want to deploy because it’s a different type of system or different security requirement. And you can move those things around and ultimately you can keep that third piece, the management and the compliance and the audit security control, with that traditional operations organization, or traditional operations skillset or management skillset who wants to control those things.
So in this self-service design pattern it’s about dividing those three things up—the definition of the automation, the execution of the automation, and the management security compliance control over it—and allowing those to be moved to the parts of the organization where it makes the most sense for the flow of the business, speed, taking advantage of the labor that you have. It’s that mindset that these operations organizations are using to transform their organizations. When we saw that happening we were like, wow, that’s something really cool, and we jumped in with Rundeck Inc. with both feet.
Shimel: Absolutely. Let’s talk a little bit about Rundeck Inc. as you called it. So Damon, was it about nine months, maybe more, maybe a year ago now, you and your—I’m drawing a blank, I apologize –
Edwards: Alex Honor.
Shimel: Right, Alex Honor, you and Alex have been doing Rundeck for as long as I know you. But about nine months or a year ago you brought in sort of a professional CEO, someone who I’ve known for years, a tremendous person based out in the Valley, Stephanie Fohn, as your CEO. And it really went from being Rundeck’s a side project of DTO Solutions, to Rundeck Inc.
Edwards: Yeah, we jumped in full feet. We luckily landed Stephanie, it was a big coup for us. I think she described our situation “an embarrassment of riches,” and I wasn’t sure if she was emphasizing on the embarrass or the riches part. We started what’s now Rundeck Inc. as kind of an experiment to see, hey, what’s going to happen? It was Alex, myself, Greg Schuler, as lead developer of Rundeck. Alex is the founder of the Rundeck project. We had a small team going, we had some engineers scattered about, and things were working. But next thing we looked up and we had a whole bunch of large enterprises that were paying us for the early version of Rundeck Pro, which is sort of an enterprise enhanced version. There’s all kinds of features and extra plugins that really matter if you’re doing this stuff at scale. The open source is really defined for if you’re just a team and you need to define buttons and push buttons, then the open source is fully featured and there for you. Rundeck Pro is really about kind of adding things around and on top of it that the boss cares about, that big organizations care about.
So we looked up and things were doing well. Stephanie came in and said, hey, we’ve really got something here and I want to be a part of it. So it was a big score for us. She is very well known on the security side of the house, a number of great successes there. She’s kind of found that operations and security is a very similar mindset, very similar set of people, and she’s really taken to it. Yeah, it’s been great, she’s brought in even more professional people.
Shimel: It’s grown up to a company.
Edwards: Yeah, we’ve got over 50 enterprise customers so far and we’re growing fast, so it’s a pretty cool, pretty fun ride.
Shimel: Damon, your role now in Rundeck Inc., if we can call it that, is you are CTO and obviously cofounder, but CTO and evangelist, but your hands are still getting dirty talking to customers and helping.
Edwards: Yeah, I’d say that’s mostly what I’m doing. Actually, Alex is the CTO, I’m the, I guess, Chief Product Officer, or head of product, these names that, you know, it’s a typical start-up, right? I focus a lot on the evangelism, a lot on the product side, a lot on helping customers figure out, A, well, figure out what they’re doing with Rundeck, and then also, B, help them figure out what they want out of Rundeck and driving that forward. So I’m still intimately involved with the DevOps community and out on the road doing that because I believe this is the next frontier, this is where you have to go. Straighten out your deployment pipeline and getting automated testing in there is a great thing, but if you’re any organization of any scale, this is the next major issue. You need to transfer operations otherwise you’re not really meeting the full DevOps vision. And the companies that are, have a distinct advantage over you.
Shimel: You know, Damon, to me, DevOps is still very much like right out of the goal, where you solve one bottleneck only to find the next bottleneck. And that’s what we do is we keep knocking them down. And as you knock one down, another one further down the road shows itself. And I think that’s what we’re seeing in DevOps, is as we knock down bottlenecks in the CICD arena and configuration management arena, ops becomes where the next series of bottlenecks are, and that’s what obviously Rundeck is hitting in there.
I wanted to talk a little bit, Damon, about a particular subset of this, and that’s DevSecOps. I think you almost inadvertently maybe backed in to the wonderful world of as we call it now cyber security or InfoSec or whatever you want to call it. Inherent in that ops mission is the idea of deploying securely and keeping a secure infrastructure up and securing your apps. And this is something that Rundeck is spending more and more time, more and more resources, more and more of the focus that I’ve seen anyway is involved around this DevSecOps mission. Comment on that?
Edwards: Yeah, I’d say it’s sort of the intersection of security and operations. Really security, operations and governance. That if you think about what’s going on now—especially, well, two big trends. There’s the digital transformation trend, which is really just saying all of my systems need to be interconnected now for a consistent customer experience, that’s something the business wants. And then there’s all these new server lists, containers, the new API world where everything’s an API. So now we’ve got to define these procedures that span all of these different systems that used to be stand-alone stovepipes. And, everything’s turning into an API, so I’ve got to have a way to secure that, I’ve got to have a way to figure out who’s who and who can do what. So we kind of fell into that in terms of people use Rundeck as that tool, to say, hey, I’ve got my Chef automation over there, I’ve got some Kubernetes stuff over there, I’ve got some legacy stuff over there, I’ve just got a bunch of scripts I need to run over there, I’ve got these different Amazon services I need to hit, Akamai and these kinds of things. So they’ve got all these different things, buttons they need to push, and they each have their own logins, each of their own sort of way of managed security policies.
So they look at Rundeck and say, hey, this is a place where we can enforce policy, or enforce this authentication and enforce the security controls. By defining these Rundeck jobs, it becomes a nice abstraction for that to say they can just call all this stuff, it’s real easy to string it together, and then I can define who can do what and where, and I’ve got the full access. In a lot of ways we call it like the key card and the camera. You can define who can do what through Rundeck, sort of the key card in your office building. But then there’s also a bunch of cameras, right? Not that we don’t trust you but we have to prove that you didn’t do anything bad with your keycard. So the kind of keycard and camera metaphor, we talk about that internally, but we should probably talk about that more externally. It’s something that we see a lot of people implementing with Rundeck in this new world. It’s a way to satisfy the security and governance demands but also do the new ops stuff.
Shimel: Damon, we’re a little overtime already but I wanted to just quickly mention that you’re going to be appearing at RSA APJ, which is the largest info sec or cyber sec related show in the Asia Pacific region. We’re putting on a full—we meaning Sonatype, DevOps Connect and a few others—are putting on, Rundeck is a sponsor, is putting on a DevSecOps day there, and you and John Willis are headlining, and for any of our listeners who are in Singapore or around Singapore, that’s on July 25. And on July 26 I think we’re going to try to do a mega meetup group, several meetups, different meetup groups within Singapore. Also at RSA APJ, and you and John will be presenting there as well.
Edwards: Yes, we will. You guys do a very good event. We’ve done the one here in San Francisco, excited to do the one in Singapore. Singapore is actually a great DevOps community out there with all the banking and finance and whatnot. It’s good work being done there. And the event’s great. It’s not just for security, it’s really looking at the end-to-end pipeline I’d say. It’s more like how do you bring these enterprise concerns into the DevOps story. And I don’t want people to think it’s just, hey, if I’m not in security, I don’t need to go to this. I think it’s really good for anybody who works in the enterprise and wants to think about the nuts and bolts of how do we get this stuff done so we can move fast and be secure or sure in what we do.
Shimel: Absolutely. And you mentioned RSA, Damon, actually I’ll have some news about that hopefully within the next week—RSA San Francisco next year is April in San Francisco and I think we’ll be doing a DevSecOps day there as well. I think you presented, we’ve done three or four of these, I think you’ve presented at all of them, actually.
Edwards: I’m a supporter. I’m a supporter of the Alan Show.
Shimel: Well, you know what, to me it’s about bringing these two tribes together. It was something that Gene Kim and Josh Corman tried to do and I’ve tried to help, and Mark Miller and the Sonatype folks. And Damon, you know what, it’s paying off because I spend a lot more time in security just because of my background, and I’m hearing from—I’m not getting the pushback I used to get from people about DevOps any more. They get it. Or they’re starting to get it. God hopes. Anyway, Damon Edwards, we’re way past our time, but that’s okay, it was worth every minute. Thank you for being this episode’s guest on DevOps Chat. We will see you in Singapore. You know what though? For people who want information about Rundeck, where can they get more information?
Edwards: Rundeck.com. There’s a free trial of Pro. You can always use the open source. We’re on IRC, we’re available, so we’re around. Feel free to reach out to us and we love talking about this stuff.
Shimel: Cool. Damon Edwards, co-founder, chief product officer of Rundeck Inc., and also DevOps evangelist extraordinaire. Thanks for appearing on DevOps Chat and we’ll speak to you soon.
Edwards: Thank you, Alan.
Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat, and we’ll see you soon on the next chat.
Those of us working in DevOps make a good living. According to Glassdoor, the national average salary for a DevOps engineer in the United States is $100,000. Are we worth it? Of course we are; DevOps is hard work. The value we add to an organization more than justifies the salaries we can command. Nobody is giving us the money. We have to earn it every day.
Considering that high school teachers earn on average $48,000, a restaurant manager averages $46,000—about the same as a paralegal—and a forklift driver makes $26,000, DevOps engineers are doing A-OK.
That’s the good news. The bad news is that our average salary, combined with our commercial isolation from others, puts us in a bubble. I am the first to admit that I live in that bubble. I don’t interact with a lot of paralegals, restaurant managers and forklift drivers in my day-to-day work. Most of my interactions are with people who do what I do and live the lifestyle I live. It’s nice to live in the bubble; I’ve done countless all-nighters to be here. But I am very aware that it’s a place that few people live. Keep in mind, the average income in the United States is $51,272.
Here are some other DevOps Chats you may want to listen to:
It takes a lot to get into our bubble. You need to be really smart and you need to be well-educated. Most programmers have a college degree. Yes, there are few of us that are part of the 70 percent of the population that does not have a college degree, but those people are rare. And, for as long we keep delivering and learning the new stuff that comes down the pike, we’ll be living in the bubble for the foreseeable future.
However, for those outside our bubble, it’s going to be a different story. As the evolving landscape reveals, those who do predictable, repetitive work are going to be automated away. And, most of the jobs that do remain are going to be on the lower end of the income scale.
So, what’s to become of those outside the bubble? How will they survive?
One solution that has been bantered about is Universal Basic Income (UBI). UBI is income that you get by virtue of being a citizen of state. There are no strings attached. Every month a deposit appears in your checking account and you are free to do with it as you wish. If your refrigerator is empty, you buy food. Should you earn a good salary, you can give the money to a favored charity or buy your kid a new video game. As I said, it’s no strings attached. The intention is to provide financial security to the citizenry without means testing.
Other governments are trying or have tried out UBI. Finland has a limited experimental program that pays €560 ($630) a month to participants. Cyprus pays out €480 a month ($546) to qualifying citizens. Canada had an experimental program back in 1974 that ran for four years in Dauphin, Manitoba. The program was called Mincome. It dispersed $1,200 a year to people living below the poverty line.
UBI has it supporters. Former U.S. president Richard Nixon supported it for a while. Milton Friedman supported it via the negative income tax. And tech leaders including Mark Zuckerberg and Elon Musk, men who have a keen understanding of the impact of automation on human employment, are proponents.
I am a supporter, too, if for no other reason that I believe in the promise of technology—that we will automate our way to a life in which we are free to do the work that brings meaning and purpose rather than going through the motions of existence, laboring away to put bread on the table.
But, for as much as I think UBI is valuable, there is a part of me that finds the notion to be a farce. It’s not so much because I think people will take the money and go down to a riverboat casino to gamble away their monthly allocations while the kids go hungry, but rather because the dollar amounts being considered for allocation are a joke.
Let’s do the math.
The table that follows illustrates how much income is required to support a family of two adults and one child on state-by-state basis. This data is provided using the MIT Living Wage Calculator by way of Mental Floss.
Table 1: A listing of minimum income by select states
State
Minimum Income per Year
Per Month
West Virginia
$45K
$3.75K
Iowa
$49K
$4.09K
Montana
$49K
$4.08K
Tennessee
$47K
$3.91K
Alaska
$54K
$4.50K
The states I choose—West Virginia, Iowa, Montana, Tennessee and Alaska—don’t contain any big cities on the order of New York, Los Angeles, Houston or Chicago. Let’s just say they’re states not subject to a large amount of urban impact. These are states that I can image might find UBI a useful program, particularly as industries—manufacturing, agriculture and energy—become more automated and the employed workforce experiences more displacement due to automation.
As you can see in Table 1, according the the MIT Living Wage Calculator, it will cost a family of two adults and one child residing in any of these states about $4,000 a month to live at a comfortable minimum.
Let’s apply some UBI numbers. As mentioned above, in 2014 the Alaska Permanent Fund distributed $1,884 a year to each permanent resident in the state. That comes out to a monthly allocation of $157. Compare that $157 a month to the $2,250 each working adult in the Alaska household has to earn to achieve a modest standard of living. That $157 is 7 percent of the amount needed. It’s a joke. The reality is that the allocation from the Alaska Permanent Fund will buy about a week’s worth of groceries, if that.
On the other hand, there is Cyprus. As mentioned above, that country is paying out $546 per person in guaranteed income, which is an OK allotment given that the rent on a three-room apartment is about $500 a month and a McDonald’s Combo Meal goes for around $7. Multiply the per-person allocation of $546 by two adults and you have a situation where life is sustainable. But then again, the population of Cyprus is 1.2 million people, a little more than the size of the population of Montana. Still, the Cyrus UBI amount is a viable number. But, what about here in the United States? If we were to implement UBI, what is the dollar amount each person is to be given?
Let’s go back to Table 1. For the residents in those states listed to enjoy a standard of financial security on the order of Cyprus—one in which no matter what, you will have your basic needs met—it seems that we will need to come up with a UBI allocation of about $20,000 a year per adult. Of course, this is assuming that the person does absolutely nothing in the way of earning money beyond the UBI allocation. However, as was reported in the study of the Mincome Project in Dauphin, Canada, once UBI kicked in, only two segments of the workforce worked less—new mothers and teenagers.
Granted, this is very limited study of a very small sample of people from over 40 years ago. But, still the inference may be valid. Also, as we’ve found from people in retirement or forced unemployment, after a period of welcome inactivity, at some point we need something to do. Thus, there is a good chance that those on UBI will want to earn money beyond the allotment. Given that we can project that most people on UBI will want to engage in income-producing work, if such work is available, then maybe that $20,000 a year number is excessive. Maybe a reasonable dollar amount for UBI is between $12,000-$15,000 per year, per person. That number could work in less-expensive areas of the country.
How would we pay for it all? Honestly, at this point, I don’t know. Maybe the same way we paid to put a man on the moon? To quote the old saying, “Where there is a will, there’s a way.”
Sadly though, no matter what the allocation number is and no matter what the consequences of not doing UBI may be, the will to do UBI currently is limited to a bill before the Hawaiian Legislature. The general will is not there for a variety of reasons: politics, moral distaste manifested as a fear of Netflix-induced sloth in the general population, or just plain greed. The notion of having enough money show up in a citizen’s checking account to ensure a modicum of financial security has limited appeal.
I can accept such reluctance. UBI is far afield from where we are culturally or where we have been historically. But, what I cannot accept is formulating a UBI program that is dumb; one in which we create stories that say financial security can be had for $157 a month. UBI allocation needs to be proposed in real, livable numbers. Otherwise, the risk we run is that when we can somehow sell the idea to a willing buyer, should UBI fail due the stupidity of not allocating enough money per recipient, we will be hard-pressed to get a second chance to do it right.
The notion that the impact of automation on human employment will be severe is a tough one for many to accept. While it is true that history shows that advances in technology have led to new forms of employment for those displaced, history does not accommodate thinking machines. Thinking machines are new to the landscape.
Just as automobiles replaced horses, maybe thinking machines will replace humans. Horses did not find new forms of employment when the automobile came along. Rather, their number diminished to levels required for their remaining purpose: providing entertainment. Such an analogy might sound harsh. After all, a human life is worth more than its commercial value. If this is the case, then unless humanity can implement ideas such as UBI as a way to sustain life independent of commerce, the alternative might very well be about the bubble—a place where those on the inside live well, in secure isolation from the less fortunate ones suffering on the outside.
In the technology world, we are in a time of incredible disruption and innovation. Many years ago, my friend and “DevOps Handbook” co-author John Willis predicted that a decade from now, academics will call this period the “Cambrian explosion” — it was an incredibly vibrant 25-million year period that resulted in an incredible diversification of cellular life forms, including the appearance of complex, multi-cellular organisms, setting the stage for the diversity of life we see today.
Similarly, over the last decade, we’ve seen an explosion of incredible innovation and disruption in almost every area of technology: cloud computing, containers, virtualization; Agile, iterative development, continuous integration and deployment, and automated configuration management.
One can be forgiven if all this change is overwhelming; I think we’ve all had moments in our careers where we think, “I’m not sure if I I’m up to learning how to tackle this next big thing.” Even someone who loves learning can become cynical, or maybe just fatigued by change.
But most of us, maybe with some calm reflection, will recognize that there’s never been a more fun time to be in technology. And many of these new techniques and practices lead to massively better ways of working, where after an initial learning curve, we’d never go back to the old way. I believe this actually calls for excitement! And, I’m not alone.
We recently hosted a live chat with multiple leaders in technology who’ve spoken at past DevOps Enterprise Summit events. As we are in full prep mode for the next event in San Francisco this November, we asked our esteemed panel to share about their career journeys in tech and their passion for learning and change. It was a great pleasure to be able to pick the brains of Dominica DeGrandis from LeanKit, Dr. Nicole Forsgren from DORA, Erica Morrison from CSG International, Terri Potts from Raytheon and Robin Yeman from Lockheed Martin. During the course of the discussion, each person shared how they got their start in tech and many of the lessons they have learned over the past 20 years in the industry. It was echoed throughout the discussion that while things are rapidly evolving, it’s an exciting time filled with continuous opportunities to learn, plenty of room for growth and time to experiment with new tools and processes. For the full video replay and transcript of the discussion, please see below.
Also, don’t forget to register for the 2017 DevOps Enterprise Summit San Francisco to hear more from leaders in tech and get a glimpse into their organization’s journey into DevOps. Early Bird pricing discounts are available until July 31!
Gene Kim: Hello everybody, welcome to this episode of the DevOps Enterprise Summit live chat. We are assembled here today with a group of people I’ve known for years, and people who I genuinely admire. They’re all experts and leaders in the DevOps Enterprise community who are helping shape much of the practices that are going to almost certainly be commonplace in technology organizations over the next decade. Over the last 20 years I’ve been studying high-performing technology organizations, and more recently it’s led to studying transformational leaders and trying to understand how they became transformational leaders. What I find fascinating is there’s evidence to suggest that these are traits that you are not necessarily born with, but instead they’re actually learned.
Over the next hour, my goal is to learn about these leaders on this panel, their careers and experiences that shaped who they are today. My desired outcome is that we’ll all learn something that we can integrate into our own respective journeys. As you’ll surely find out over the next hour, these are all great people. As a reminder, the upcoming DevOps Enterprise San Francisco event is taking place on Nov. 13-15, and for more information visit events.itrevolution.com. And just a reminder, Early Bird pricing ends on July 31st.
Let’s go quickly around the panel, and everyone, if you could just introduce yourselves, name, company role, when did you present DevOps Enterprise and what did you speak on, and free to speak to share any professional accomplishment that you’re most proud of. Dominica, let’s start with you.
Dominica DeGrandis: All right. Well, I was a build engineer, spent 20 years bringing visibility to what version of what file was on what server in what environment. Currently, I am the Director of Training and Coaching at LeanKit. I’ve spoken at DevOps Enterprise Summit for four years in a row now, mostly speaking about experience reports and metrics and making things visible. And I guess, my most professional accomplishment, I think it would have to be finding my courage to get up in front of a group of people, and explain or present data, and demonstrate how to get leadership buy-in with metrics.
Kim: Awesome, thank you. Erica Morrison.
Erica Morrison: Hi, everyone. I’m the Director of Software Development and Operations at CSG International in Omaha. We’ve spoken the past couple years at DevOps Enterprise Summit chronicling our journey through the DevOps space, and we’ll continue to tell that journey. Something that I’m most proud of, probably the things that have brought the most challenges in my career have actually been in the DevOps space. We’ve undergone a fairly major transformation this past year, brought a number of teams through that, but one team in particular who have made substantial improvements as far as stability and automation. That’s been really something that’s been fun to be a part of.
Kim: By the way, following your experience reports has been my favorites among every year at DevOps Enterprise, fantastic. Robin.
Robin Yeman: Hey, I’m Robin Yeman, a Lockheed Martin fellow. I’ve been working in engineering about 23 years in the defense industry on everything from submarines to satellites, and everything in between. I think my biggest accomplishment is really being able to see the change. When I first started doing Agile in DevOps, you really couldn’t see it, but now I start getting contracts and RFPs from the customer repeating verbatim what I told them before. It’s cool to see that the influence is there. It might not be as fast as I’d like it, but it’s there.
Kim: That’s awesome, and then you spoke last two years of DevOps Enterprise San Francisco and London.
Yeman: You’re right. Yeah, the last two years on transforming large legacy organizations way back. A combination between Suzette Johnson from Northrop Grumman and myself from Lockheed Martin, because we both had very similar journeys.
Kim: Awesome. Thank you, Robin. Nicole.
Nicole Forsgren: Yes. Hello, I’m Nicole Forsgren, CEO and chief scientist at DevOps Research and Assessment, otherwise known as DORA. I spent years doing software development, enterprise storage at IBM, and then I went and got my Ph.D. that might be my professional accomplishment that I’m most proud of is that I’ve been studying and researching what’s basically known as DevOps for the last 10 years, and then applying it and bringing what I found to the industry and in my work with Gene and Jez Humble, and the team at Puppet on the State of DevOps Report. We all lived through that 2000 dot-com bust, and we saw many companies fail and I don’t want to see that again. Really helping to make an influence in the industry and make things a little bit better is an accomplishment for me.
Kim: Awesome, thank you Nicole, and you spoke in I think every year at DevOps Enterprise. Fantastic. Terri Potts.
Terri Potts: Hi, I’m Terri Potts. I’m from Raytheon Company, and I’m the Technical Director of the Software Development Organization. Like Robin, we are focused on doing mostly defense- and Intel community-related contracts. I started in the software development business actually in the Air Force and spent 11 years there, moving through the ranks and came to Raytheon, and moved on to be an architect after doing development for several years and have been a champion for technology transformation since the early 2000s.
I’ve spoken a few times at DevOps Enterprise Summit. Once about our legacy transformation since we have been around for long, and a lot of our code is quite old. Last year, I spoke about how you build up your staff of people that can support your DevOps transformation because it’s hard to just go out and hire those, some ideas around how to go do that.
Kim: Awesome, thank you much Terri. And by the way, I remember meeting you at the IBM Interconnect Conference in 2014, and you were actually one of the first announced speakers at DevOps Enterprise, very grateful for that.
First, let me just state an assumption I have that there’s actually never been a more fun time and exciting time to be in technology even though things are rapidly changing. Actually the pace of change is what’s causing much fear for many professionals about our livelihoods, our vocations, but I genuinely believe that the best times are ahead of us not behind us. Do you believe that? And if so, why? Erica could we start with you?
Morrison: Sure. I think about when I came out of college with a computer science degree, and I was focused on writing one language and writing that language well, and now we’ve got the proliferation of numerous different technologies, different languages. Like you said, the pace is moving much quicker. We actually hosted a hackathon here. We’ve done two of them for college students and just a number of different technologies that they use was absolutely mind-blowing to me, but I find it extremely interesting to continue to evolve for all these different things. It’s not just this one little dedicated space anymore, it’s constantly learning these new things which I love to do. Its new challenges everyday which keeps work interesting for us, makes work about being lifelong learners. I love that continuing to learn throughout our career, and it’s just focusing on learning different things now.
Kim: Awesome. Robin, how about you?
Yeman: I absolutely agree. I’d really think it’s the most exciting time. Just like Erica was saying, the college kids are coming in with 15, 20 different languages, they’re bringing all kinds of new technologies, they’re bringing gamification. They’ve really brought some different leadership styles. It’s very exciting. I know that some of our engineers get nervous, but if you just grab on and join the ride its fun.
Forsgren: Honestly, that’s one thing I love about technology. I mean, it kept me engaged, it kept me excited. Back when I was doing a bunch of development work, there was always something new to work on. As you said though, there’s always that other piece. There’s always the other side of it. We’re working in systems with growing complexity and that does make it really, really difficult, and that’s something that we’re seeing when we work with companies with DORA, in our assessment. You have to make sure that you can focus, but you need to know what your constraint is, particularly when we’re working on technology transformations. We need to make sure we can focus on the most important thing. We need to make sure that we can limit our whip, we can focus on our constraints, we can identify what the most important thing is that we don’t have sprawl and just contribute to technical debt. But, I think that’s what makes our work challenging and exciting and meaningful.
Potts: I love change, and that’s why my career has taken me where it has because the more different things you get into I think the more rounded you are, and the more you’re able to adapt new technologies. And the way I see it today is all the technology changes especially with the automation that many of us are going through that transformation, and I have always seen that as drudgery. If you’re working in some factory, let’s automate all the drudgery out, and then that gives us time on our teams to explore more around analytics or machine learning. That’s exciting for me.
Kim: Yes, you make it sound exciting. Dominica, you’re smiling.
DeGrandis: Well, I’m just thinking back at my first job out of school after I got my computer science degree. It was more configuration management back then, that was getting everything on the mag tape from IBM and putting that in a library, physical library somewhere safe in order to deploy it into production. But I think for me, it’s just the amount of opportunity there is now. There is this massive amount of opportunity for everyone whether they have a degree in computer science or not to go out there with all the sharing. The ability to share and learn now is much greater than it has been previously.
Kim: That is true. I mean, there’s never been a better time to be a learner. There’s no cost to entry it seems these days.
DeGrandis: Absolutely.
Kim: I suspect that this isn’t the first time that you’ve seen this dramatic change in the industry in your career. I’d love it if you could tell us about that time and how it affected your thinking about how you viewed your skills, your career, and where it took you. Robin, would you mind starting?
Yeman: Sure. When I first started we had a lot of ToR trend and ADA going on, and I was worried about the next generation of ADA, and whether they would even be able to keep up. So, just like that Dominica and the rest of the folks have said, I spent a lot of time at night trying to study, make sure I could stay on top of it because I was working with these amazing engineers and I just didn’t want to fall behind. I do the same thing now.
Kim: And by the way, I mean in a scale of 1 to 10 what level of fear did you feel? One is like it’s just another book no fear, 10 is existential fear of, “I might not be able to finish the book and therefore my career is over.”
Yeman: I work with some engineers—they’re smart that I was terrified. I’d say way up at 8 or 9 out of 10 because some people just get it quick and I have to work at it—I’m just not a natural. I was terrified.
Kim: by the way, it reminds me of learning Clojure very recently. It’s my first script language and I think I had to do 40 hours of reading before I could write a single line of code. It was just, it was very challenging, but very rewarding but all very intimidating. Nicole, how about you?
Forsgren: My first job in tech was when I was still in college, and it was on a mainframe. I was coming out of my associates in like ’99, and that was the big Y2K, everyone’s panicked, and it really fundamentally shaped what I thought about tech in many ways. Everyone was panicked, there was this big dot-com bust, and I alluded to this earlier, “Survival isn’t mandatory, companies can fail.”
That’s one piece where it really shaped what I do is that I don’t want to see companies fail. I’m sure you all have talked to me at conferences, and suddenly I just dig in, and I’m passionate. I have this drive to make sure we know we can find ways to help companies not fail, but it fundamentally affected me in a different way in that in the late ’90s, there was almost a tactical way to address the problem and it was teach everyone fundamental things. People look at me, they’re like, “How do you do mainframes?” It was mainframe, COBOL, Fortran and that was all we were teaching many students because we desperately had a very tactical need to make sure that when we hit 2000, the world didn’t end, technologically.
And then I did a bunch of consulting, and then I got a Ph.D., and then I was a professor. We’ve almost taken this other stance of we only want to or we’re very purposeful now, and I think it’s led to complexity sometimes in technology, but we want to make sure that we understand the purpose behind what we’re doing. We want to make sure that we have flexibility, we’re strategic, and we aren’t just tactical.
So, we designed the State of DevOps reports. They’re vendor and tool agnostic. We tell you about the principles that are important, the architectural designs that are important, the principles behind using version control are important. We aren’t going to tell you to use Git or Subversion, we’re going to tell you to use Subversion control. That’s the other thing that’s really impacted my career is that I need to make sure that if I walk into a situation I can tell someone from a conceptual level what’s really fundamentally important to improve their technology practice, and it won’t be tied to only a specific technology because that can end up being limiting. If you only tell someone teach someone a language, but not the fundamentals behind that language, it won’t work.
Kim: Principles are timeless and those things are not. Awesome, Terri.
Potts: When I think about this, the thing that comes to mind for me is probably about 20 years ago when systems software architecture started becoming a first-class citizen, at least at Raytheon. I remember seeing the first book, and one of my mentors saying, “Hey, I’m going to have a study group on software architecture do you want to join?” And I wanted to join and started seeing it as a way to grow my career, and be able to influence bigger parts of the system, and try to make things more maintainable, and really make good decisions going forward instead of just sort of stumbling into things. I wouldn’t say I was afraid, but I was really curious, and certainly felt like it was something that I needed to keep up with and did a lot of studying on my own outside of the office with study group, learning everything I can from them.
Kim: Sounds very interesting. In this case, it was like a mentor who actually sort of directed you down a certain direction. There seems to be a pattern of having great mentors. Fantastic, Dominica.
DeGrandis: When it comes to dramatic change, I have to say hands down 2005 or 2006. I was working at Corbis at the time managing environments, and we went from building out maintaining 25 servers to building out maintaining 250 servers over a period of 9 to 12 months. It was just impossible to manually build out servers. We had to start automating, and developers were like, “Builds take too long.” They wanted to put their own changes in their own dev integrated environment, and they took it seriously. They said, “Okay, then you get to own that dev environment like you build it, you maintain it. Then, I’ll just go build out maintain QA and staging inner prod.” That was huge dramatic change I think, and just being able to adapt to that and quickly was the biggest lesson for me there.
Kim: And specifically, was it dramatic because it was such a different way of doing things or it was dramatic because the role change and responsibilities for you, or what made it dramatic?
DeGrandis: Because for the previous six years we have had this process where we just dole out responsibilities, who’s doing what and how we’re doing it, and now that was turned on its head because we had to deliver faster, we had to deliver better quality, we had to get these environments up and running, and everything just exponentially grew with the number of servers and the number of environments. The way that I had been working for the last six years which had been fairly successful was completely different. That’s the second law of thermodynamics, everything is always in constant change and motion.
Kim: I love it. This is the famous story that’s in David Jay Anderson’s book, and in your upcoming book, Dominica. Fantastic, and Erica your dramatic changes in a certain point of your career.
Morrison: In addition to the ones that have been mentioned, there’s a couple that come to mind for me. First of all, the introduction of Agile. I started my career very waterfall. I probably wrote code for three to six months before I even chucked it in to the point that other people were using it which now is obviously mind-blowing to us, but that’s how we did software development back then. That’s been a major upheaval in pretty much all of our processes is around how we do software development.
I think overall, all these items point to the fact that software is constantly evolving, it’s not a static thing. When the next thing comes out we’re used to this evolution of change. It’s something that as developers, we just accept it, and look to learn the next best thing and how we get to evolve and continue to get better.
Kim: And physically what’s different or dramatic about the Agile transformation from your perspective?
Morrison: Pretty much everything about it, just the concept of batching work up into small little pieces. I’ve participated in helping roll out Agile with other teams, and it’s somewhat mind-blowing to these teams that you can take this big amount of work and you can even slice it up into one week or one day increments, and chuck that in and have this daily accountability with my team members. That test is now my responsibility and how am I going to automate that because as a developer, we want to automate that test as much as possible. It’s just much more of this integrated, fast-paced, all of us owning all the work and focusing on flow through the system.
Kim: I do remember that it was around 2005, we had just started our first experiments on Agile and even finishing something in a week was mind-blowing. That’s how long it took us to fill out the PRD forms usually. I love these amazing stories that you’re sharing. If you could compare yourself now to the person you were 20 years ago, what were the most important and significant differences between yourself now and yourself then? What skills did you have to develop? Nicole, let’s start with you.
Forsgren: Twenty years ago, as you think back, there’s no Facebook, there’s no Twitter, there was barely email. It existed, but not really. I mean, definitely all the technical skills, but for me learning how to be a leader and how to interact with people, and how to exert influence in a soft power sort of away.
Again, going back and talking to people that I knew 20 years ago there was learning how to do things in more of a nuanced sort of way, which you need to do when you’re managing large projects. For me, it’s been a soft skills thing. I always joke that technology is easy and people are hard, even as complex as technology can be. That was probably my biggest piece of learning.
Kim: In many parts what we work on, they’re all volunteer projects. And even the softer skills are necessary when everyone’s volunteering their time. Great, Terri.
Potts: Twenty years ago I was finishing up my last year in the Air Force and doing some leadership things, but much more as an individual contributor. I have a good view of what it was like to be on the Air Force side managing big contracts, and testing systems and operations. But since then I think that there have been a few things that I really had to develop. One was my network, the group of people that I learned from, and that has definitely grown in the last four years outside of Raytheon. I had a pretty good network within Raytheon, but once I met Gene and started participating in DevOps Enterprise Summits and the Forum, I just love how that career or that network has grown from there.
I’ve also always been interested in really staying with modern technologies and finding ways to make our teams more efficient, I think that’s always going to be something that’s changing. You always have to stay on top of what the latest thing is that’s helping your teams be more efficient. And the Agile transformation too because definitely we were waterfall all the way in the Air Force, and for the first several years that I was at Raytheon.
Kim: That’s interesting you mentioned network. One my favorite quotes is, “You’re only as smart as the average of the top five people you hang out with.” But I think what is interesting is when you can actually bring that network to help other people with their problems. It becomes a really powerful asset and the ideas of everyone.
DeGrandis: Well, I think 20 years ago, I assumed that everybody else knew what they were doing, and that if they were doing the right thing and I intended to feel like I didn’t know what I would. I didn’t know what was up, I didn’t know what I was doing. I was just inundated with trying to learn quickly. And now I recognize that most people really don’t know what they’re doing. Nobody has all the answers and it’s absolutely okay to ask questions, and that in order to have your voice heard and become the voice of reason, how important metrics have been in order to present them in a way that others can understand.
Forsgren: Plus one on metrics. I will cheerlead for metrics all day long.
DeGrandis: I used to rant we don’t have automated testing, smoke tests take too long, and it just has got me nowhere. Now being able to present data calmly and confidently, to be the voice of reason in the organization is one of the greatest learning changes over the last 20 years. That and learning much more about Flow and Lean and Kanban and different methods out there—it’s why I wrote my book, Making Work Visible to help others see how to become the voice of reason. I think that’s super important one.
Kim: Awesome, we have a calm voice of reason. Excellent, Erica.
Morrison: I’ll echo the comments made about people and relationships, and, I think in college we don’t get an understanding that there’s nontechnical problems in addition to the technical ones. Really, we all look at the world differently and we’re going to have to understand that everyone that we work with isn’t going to have the exact same perception as us, and we need to partner together and get these diverse viewpoints, build these relationships, build these networks. That’s something that I probably didn’t get proper appreciation until maybe the midway through my career journey far. And I just wish someone had told me that earlier in my journey.
And then, I think appreciation for the ecosystem that we operate in I talked about that when I first came out of school as a computer science graduate. I was focused on my view of the world and the code I was writing, and I thought the big picture was understanding what the rest of the developers on my team were working on not understanding how do we deploy this code, how do we maintain it, what’s the infrastructure that we’re running on, how does our customer use this code. All those different sorts of things, which I we work on now to get that bigger picture for people, but that appreciation that that bigger picture makes you good at your specific piece of that. And then just that need to continuously improve yourself. It’s not about just being good with what you’re doing right now, it’s about looking at what’s next, how can I continue to evolve myself and improve myself that I can help move our company along.
Dominica: Well said Erica. Hear, hear!
Gene: I can resonate with all elements of that, but just to share a story. I was talking to a younger developer, he must been like around 25 hanging out with a bunch of ops people and I asked him, “Well, what are you doing here hanging out with a bunch of ops people?” He said something that I thought was hilarious, maybe not the most politically correct, but I couldn’t fault his curiosity. He said, “I just want to know where my code goes. To me it’s like I flushed it down the toilet and I just I’ve been doing it for two years, I just wonder where it goes.” Which I thought was unfortunate imagery, but man he was like, “Well I’m the minority of developers actually caring about the system as a whole.” Obviously, that made an impression on me.
One of the things that, if you go back to the topic of change, one of the things I hear a lot these days is how people in our profession often feel very uncertain about their own future, and specifically about how to maintain their own relevance. I’m thinking a person I met that I was actually able to interview on my blog, and yeah, he’s my age and despite having an MBA, despite having a Master’s in engineering management, despite being an expert in the theory of constraints, despite being an operations lead at Boeing, he wrote asking for career advice saying, “What do I do to make sure that I’m as relevant in five years as I am five years ago?” Specifically, what advice would you give someone who’s in operations and feeling like if they don’t take drastic measures they won’t be as relevant, and what actions would you recommend? Terri, why don’t we start with you?
Terri: I was thinking about this question, much of it depends on where he wants to take his career you have to know where you want to go, in order to put together a plan for how to get there. Given all of his degrees, and what he’s doing, it doesn’t seem like he really wants to go off and start re-architecting software or it didn’t sound to me like he would necessarily need to get a whole computer science degree. But if he wants to really understand how the automation works maybe he takes a few classes in Python or Ruby or one of the scripting languages to help with that, and get involved with that. But it seemed like it would be pretty drastic to go out because there’s lots of opportunities to lead transformations and he’s got those leadership skills apparently. I would say, “Look for the opportunities that really fit with your personality and your skills rather than going back to school for the answer.”
Gene: Indeed, and by the way, I just realized, sorry Robin! I didn’t forget your answer—could you say what advice would you give yourself 20 years ago, and what skills are most important? Then we’ll get back to our friend Pat Birkeland. Sorry, Pat.
Robin: Just like the others, I would say people and people skills. I was really type A and really driven building my code, and I thought the harder I work the more impact I would make, but as I got older I learned really the more that I build people around me the bigger impact I make. Being able to build those co-workers or people that work for me actually magnify that tenfold, and it just didn’t occur to me at that time. I would really focus on what you share. We tend to get rewarded for what we know, but if we rewarded people for what they share, you’d be amazed at what can happen.
Gene: Thanks Robin, and one of the things that I found impactful about your presentation even just in this last London event was you shared the story about how you had created this very informal community of people just sharing, and you met weekly or monthly, and 15 years later you’re still meeting, and then you’ve all sort of ascended together. Am I misremembering that story?
Robin: No, no, we’re actually still meeting and we’re building people. I think both me and Suzette [Johnson] are in the same boat because at the same time we were we were looking for others that would help us because we’ve started Agile pretty early in our careers, and we really needed any information. There just wasn’t a lot of like-minded groups to get together and build each other.
Gene: Awesome, and I guess if I were to sort of speculate that all are sort of very curious, all ambitious, all good at networking, and what a great collection people to learn from and collaborate with.
Gene: Awesome, thank you Robin. Let’s go back to this non-fictitious Pat Birkeland, he was generous in writing up some of his thoughts and experiences. Terri, your advice was the answer is not to go back to school, but maybe more crystal clear about where he wants to go in his own career and find opportunities. I love that. Dominica, your thoughts on Pat Birkeland.
Dominica: First of all, I could definitely relate because I had the same thoughts myself earlier, “Man, I should go back and get my Master’s. I need to. I just need another degree, make more letters at the end.” But really can’t do that because of working full time with little children at home. It’s just really hard. I didn’t have a nanny. I think that what somebody can do immediately is to learn the business better. Maybe just brought it again by a bit from the business perspective and see what the business challenges and risks are. And then, figure out how to reduce some of that risk maybe by making things a little bit more predictable to you. That’s going to be such a huge growth experience to go around, and maybe visit some of the other parts of the value stream and go look at the whole value stream, and see where things are stocking. And you got making that fall in faster.
Gene: That’s such an interesting piece of advice. And by the way, it reminds me, one of the things I was always envious, if I had to do my career over again, I would have loved to spend a couple years at a big four audit firm just because I was envious my friends who could actually see the big value statement, procure-to-pay, order the cash. It was something I was envious about, just even the language they spoke in. That totally resonates with me, Dominica. Erica.
Erica: One thing that I’ve told a number of our operations personnel that I’ve had this similar conversation with is “Good people will always find a way to be successful.” I’ll hire good people any day, and they’ll acquire those new skills. When it comes to being nervous about the situation I think as long as people are eager and willing to learn new things, they’re going to be successful. And then we as companies need to set them up for success. So they’re just personally able to talk with their manager and see if they have specific areas where they see that there’s opportunities for improvement. And then like Terri said, find your passion and invest in that particular area.
Gene: There’s no shortage of problems to be solved, I think is what you’re suggesting, Erica?
Erica: Exactly.
Gene: Yeah, that’s actually great. Pat, I hope you’re listening. I’ll have this transcribed for you. Robin.
Robin: The first thing I did when after the DevOps Enterprise Summit in London is to come back and tell everybody about Nicole’s research which stated that, “Transformational leaders really improve the likelihood of your success.” We’re short on those, I would think being able to build those folks around them and really drive, help the technical folks get things across to understand the value stream as Dominica said. I think there’s plenty of work to be done there, and that would be amazingly helpful.
Gene: That was great. In fact, I mean I do love the literature that says these transformational leadership traits are learned behaviors not that the old school was like these are things you’re born with. The great man theory, that you had to be born that way, otherwise you’re just, yeah, you’re just not wired that way. I think that’s exciting. Nicole, on Pat Birkeland.
Nicole: Yes, I would start by asking in an ideal world right, what would Pat be doing in six months, and in a year? And then, work backwards. What’s your ideal job? What do you want to be doing? And then what skills do you need? Because again you take a look at what he’s been doing, look at his credentials. He’s got an MBA, he’s a theory of constraints expert, and he has a master’s in engineering management. It sounds like he’s setup to be doing incredible things right now in leading a technology transformation. If he wants to be doing that, he might need to brush up on one or two specifics of a new technology in order to like really be able to speak to the developers or the operations staff on a few of his teams, but he might be there.
And it’s funny I say that especially as I was listening to what Dominica said she wanted a master’s so she could add letters. Some people walk up to me and they’ll say, “I want a Ph.D.” because I have a Ph.D., and I’m like why? And they look at me like like I want to be the only one at the Ph.D. I’m like, “No, like why do you want a Ph.D.? Don’t get a Ph.D. just for fun.” A Ph.D. is a research degree. If, for example, if Pat says I want to be doing research in six months or a year it’s going to take more than a year, then get a Ph.D., but if you want a Ph.D. because or if you want to degree because you want someone to know you have a degree that’s not the reason to get a degree. But if the job that you want in six months or a year is to be writing code, okay, then yeah then you’re going to need to either get a degree or do some Coursera or some Udemy or something. But if what you want to be doing in six months or a year is leading transformations, you’ve got it, you’re set.
Gene: There’s many easy ways to learn these days and Ph.D. is just one of them. By the way, if I could just go back to this and this more for me, but I remember a point in my career this must have must been, must be about 2005. And, I hear all these talk about “It’s easy to learn things, yeah, rah, rah. Change is good.” I remember when Microsoft changed their database interface – it would change from ODBC to ado.net, and the reaction I had was like, “This is crap. I do not want to learn another way to access database. This is horrible.” I had no appetite for that. I mean, sure you might have had encountered people who had that reaction, what advice would you give me in 2005? I’ll take any advice from anybody, otherwise I’ll call on.
Dominica: I’ve had friends, developers, who have been extremely frustrated at the continual change in the learning. But if they feel like they learned something really good, and then it just all changes again, and how frustrating that was for them, and it made them want to go be a business analyst. But, I think that is just the nature the demand. That’s the reality that we live in, and that there’s a need, we have to learn and adapt and changes are always there.
Terri: Right, I’ve had interesting reactions from people in our organization who seem to think that learning something new is going to threaten their job right like if you move to automated test then, perhaps they won’t have a job anymore. It’s always surprising to me when people don’t want to learn because learning is sort of what keeps me motivated and excited. Although sometimes, you feel maybe it’s a step too far beyond what your current skills are. But, yeah, there’s lots of, there’s lots of ways to do that these days and to figure out. And worse, if worst comes to worst get a few of your colleagues or friends that are in a similar boat, and you all want to learn about the same thing and you go through a course or a book together and maybe a group effort might make it a little more interesting, less intimidating.
Gene: It always helps to have a buddy is what I learned. Any other advice for Gene 2005 who is enraged by ado.net?
Robin: I would just say that it’s constantly changing, and that if you’re if you’re enraged by it you’re just going to be unhappy all the time. It’s almost like it’s just a given. You might as well try to learn to like it or pretend you do.
Gene: Awesome, Robin.
Dominica: Do you think though that there’s one thing that hasn’t been talked about yet, is this sense of fear that people have. They were really good at something and they knew this technology and they were at the top of their game, everybody went to them to ask advice on this one thing and now that’s changing. That’s scary for a lot of people like “Wow, just a year ago, I was awesome at this and now everything’s changed and what the heck do I do now? I mean look at some project managers now with the whole coming out of waterfall and PMI and Gantt charts. And now all that’s being shifted upside down and where are they going to go now?” I think addressing that fear of what people used to be really good at and now that’s gone is real.
Terri: Those are really good points Dominica.
Gene: And by the way, I had no illusions that I was good at ODBC. I mean, I was barely competent. I felt like their people are just randomly shuffling chairs just to force people to upgrade from Windows 95 or whatever it was just, I saw no value in it. Yeah, but I loved that it is a fact of life and something genuinely miraculous. It’s like, who would want to go back to the old way?
We did a webinar. It was on the topic of how to get your DevOps Enterprise submission accepted to the conference, and one of the people who was on that panel was Margo Cronin. She was an Enterprise Architect at Zurich Insurance and she’s now at AWS, but we actually accepted her through the CFP process. It was fantastic to see her perspectives and the advice that she gave, but one of the things that she said really made an impression on me. She said, “Have confidence that you have an interesting story to tell.” I think she even said, “Just because you’re not the lead developer or using the new cutting-edge technologies that’s not necessarily as interesting as someone who’s helping drive behavior change and transformation in large organizations.” Do you agree with her? And if so, what advice would you expound to anyone who has a story to share, but maybe are hesitant to. Let me call on you Dominica. And Dominica this is great because you’re on the programming committee.
Dominica: I hear this a lot! People don’t feel like they have a story to share, but everybody does. It’s a different perspective that they can bring and there’s a lot of similar nuances that we all go through, but I think to hear, especially somebody that we haven’t heard from before, a new fresh perspective and their challenges always makes for an interesting story.
Gene: Maybe you can shed a little light outcomes of the process right now. We’re looking at every one of these submissions and we are looking for interesting stories.
Dominica: Yeah, how many submissions did we have for San Francisco?
Gene: It’s over 250 almost 300.
Dominica: Yeah, going through all of those is a challenge and one thing that I really look for is original, real wording of people telling a real story and not shying away from using their own language. I don’t think people feel should feel that they have to conform to using the book-written perfect language in a submission. Just say whatever—what’s the problem, why it matters, what they did about it. The real story that’s what I want to hear what worked, what didn’t work, what was some of the failures, and where they are right now, and where they hope to go.
Gene: Great. Yeah, the lull of deliberation. In fact, one of the things that maybe most people might not know is just the level of the intensity of some of these debates of who we accept in the conference. I mean is that something that gets very, very heated. I’m not sure it was actually hung up and out of the meetings, but sometimes very close. Erica, how about you?
Erica: So, yes I actually had a conversation with a co-worker of mine after we attended a local DevOps meetup here, and she said, “I would love to at some point work towards a goal of presenting at this [event].” And she actually comes from a non-technical background and she has participated in a lot of the same things that I have in our DevOps journey and I said, “You know, I think it would be interesting to hear the same story told through your eyes, and I think it would be a different story than my version of it, and just the different things that stick out to you and were amazing to you.” I really encouraged her and I said, “I’d like to hear this story.” Even just the two of us telling that same journey, different perspectives on that are very, very interesting.
Gene: And are you referring to the portion of the presentation you gave last year, which was when a dev manager takes over ops?
Erica: Yes, yup.
Gene: I would love to hear that story. In fact, three of your colleagues actually did submit through the CFP. I’m eager to see where that goes. Thank you for any encouragement that you gave them. Thanks Erica. Robin.
Robin: Just like Erica, I think everybody has a story to tell, and through another person’s eyes it’s a whole different perspective. Sometimes the things that we do every day seems commonplace. That happens to me all the time, but then, when you tell somebody else they’re like, “Wow, I didn’t even know that existed or how would you even do that.” I think, again, just having confidence in yourself and realizing you actually have something unique to sell other people is what you need to do.
Gene: Interesting, thanks. Nicole.
Nicole: Yes, sometimes when I think about what might be a good topic to talk about when I go to conferences, I think about things that I do pretty commonplace or things that are pretty easy and think about what used to not be super easy, right? If it’s a process that I’ve done or a process or what we’re working through right now, and then what that journey has looked like. Right? Because if I can do it now, and it’s pretty easy, and it’s almost habit or reflex, when was it not a habit and reflex. And then, how did I get here? What were the steps that I got here? Did we have a checklist? What were the crazy hurdles? Because if it’s easy for me now and it probably wasn’t easy for me at some point, I had to learn to get there. That’s probably going to be useful or at least interesting to someone.
And then, write that up. And then, that’s the story, but then writing it up I think is another piece. And like Dominica said, I’m on a budget program committee, write it up that when I’m reading 300 submissions or a 1,000 submissions it stands out to me and it’s interesting I can tell you’re going to have some personality onstage and let the audience know what they’ll get out of it. That’s when they read it in the brochure, they know like which talks to go to. What takeaways am I going to get from this? Am I going to have a few tips and tricks? Am I going to know what to avoid? Am I going to know where to start? Those are some tips in terms of like writing submissions. And sometimes I forget when I write my own submissions, so none of us are perfect.
Gene: Awesome.
Nicole: Keep trying. I mean, I still get CFPs rejected. We all do.
Gene: No, it’s so true. Terri Potts.
Terri: Yeah, I do this a lot with people in my organization because moving up the career chain at Raytheon often requires you if you want to stay technical to start presenting. First maybe internally within Raytheon and then externally.
Nicole: I love that.
Terri: Yeah, so a lot of times people think, “Wow, what I do? That’s boring.” I try to just have a conversation with them to get them to tell me some of the things that they’ve done recently. And some of the things I really like to hear about is, “Okay, you started using Puppet or you started using Chef, did that just go perfectly the first time?” “Well, no we tried this and that didn’t work. Then we did this.” I’m like, other people would love to hear that they don’t make those same mistakes. So write something up to say these are things that we found that work really well and these are things that we found that didn’t work so well, so don’t repeat those mistakes.”
Gene: That’s great. As a professional conference goer, I mean I love one of my favorite variances like the internal technology conferences because this is a hope of the shared context that’s already shared. There’s a mercenary reason why you want to help people within your own organization that isn’t present in a more industry-wide conference. I mean I just really I got to attend the one at Capital One and at Nationwide Insurance. I just, they really stand out in my memories. Just incredibly unique experiences and so great for internal technologists to be able to show off the amazing things they’ve done.
All right, we’re almost out of time, one last question. I think a theme that’s come up over and over again is we’re lifelong learners. Learning is part of the game, in this game that we’re playing. Learning is definitely part of it whether we like it or not. Hopefully, we’d like it far more than we don’t. What are your top resources for learning? Maybe answer two ways—of all time and maybe right now here in the moment. Erica, let’s start with you.
Erica: Sure. Of all time, once upon a time I had like my C++ book that I referenced all the time before I really even used Google, so there was those sorts of things. But, much more recently, I rely heavily on Twitter, and a lot of the things that I see on Twitter and on leaders in the DevOps space, and what are they reading, what are the things that they’re tweeting about. There’s obviously books like The DevOps Handbook. And The Phoenix Project and I try read probably about one book at a time, but then I like to just see what’s going on space. Yeah, I’ll see whether there’s a conference going on and I’ll go look for that conference and what’s going on with that conference and the slides that are coming out of that, and that helps me stay current. And then just rely on co-workers as well. They’ll send out emails and different articles that they’ve read.
Gene: That’s awesome. By the way, one of the things I just want to punctuate is several of you mentioned, it always helps to learn with co-workers. I mean I remember teaching myself JavaScript in React, and it was incredibly gratifying, but it was horrible beyond words because there were like 40 tools I had to learn what they were and I didn’t care. Just that it always helps to have a buddy in learning things. I love that pattern. Thank you, Erica. Robin, top resource for learning.
Robin: So, I again I follow Twitter just like our counterparts here. I am a big fan of LinkedIn, I read LinkedIn and read the latest things there. I have a membership to Safari Books. They always have the latest technology books which I just love. And I read the blogs. It’s interesting because you get many different perspectives on the different blogs you hear and what Mike Cohen thinks is cool and Ken Schrader, and then you turn around and hear David Anderson. Maybe they don’t all play nice in the sandbox, but it’s interesting to hear what they have to say.
Gene: Twitter, it is interesting and we always used to dismiss it as a toy, but more and more I find it interesting just to some of the most interesting reading comes from what other than what my friends are reading. Interesting Robin. Nicole.
Nicole: For my overall best learning it’s probably my Ph.D. because it taught me how to do a lot of critical thinking, statistical thinking, pulling things apart, how to design, and critically pull apart research and think about things in a really concrete, consistent, detailed way. And then overall in today, Twitter, news sites. I try to make sure I keep it as well-rounded as possible. New York Times, Wall Street Journal, Al Jazeera, and I try to keep up on what my friends are reading, but then I also try to occasionally do a random search to get exposure to things that my friends aren’t reading.
Gene: Great. Thank you, Nicole. Terri.
Terri: Let’s see, far all time, I mean I’ve kept a membership for IEEE and ACM for years just trying to keep track of what’s going on, but now things are a lot more electronic. Some of the things I do regularly is I try to listen to most of the Software Engineering Daily podcast episodes.
Gene: Oh, great.
Terri: And all the SE-org podcasts, which they’ve had a tremendous amount of podcasts that I found really, really useful. And of course, I do go to a few conferences every year, so I’ve learned a lot at DevOps Enterprise Summit, and this year I presented at the SEI’s Architecture and Technology User Network Conference, and it was really, really good to see the amount of architecture work going on around figuring out how to transform legacy systems and architect for automation in this assembly.
Gene: That’s great. And by the way, I echo your endorsement of the Software Engineering podcast as they have great people in there.
Nicole: Yeah, and I’ll plus on IEEE and ACM. ACM Queue has been really fantastic.
Gene: Yes, and then last is Dominica.
Dominica: Yeah, I’ve learned much from watching TedTalks. That’s one of the greatest sources of learning for me for years now. I mean Hans Rosling, “Let my dataset change your mindset”—in 20 minutes what you can learn from that. Or David McCandless in “The beauty of data visualization”—just phenomenal. And then the DevOps Enterprise Summit videos over the last four or five years, from the tech side great, great learning resources straight up on YouTube, easy to get to.
Gene: Awesome, yeah, because there’s a YouTube channel you can just subscribe to it, and then you’ll be notified whatever there’s a new one. In fact I was going through them last night. Awesome, well, hey thank you much. I so much appreciate your time and you sharing all of your experiences. This is a topic that is near and dear to my heart, and I think we were actually going to be writing this up that people can actually access it in written form and the summary of it.
I look forward to seeing you all soon, one way or another. At the very latest at DevOps Enterprise in San Francisco. I hope you’ve learned as much as I have today.
Thank you to all the panelists who are doing amazing work in all your respective organizations, and you will be able to see them too Nov. 13-15 at DevOps Enterprise in San Francisco. It’s at the Hilton Union Square location and look for updates on the website at events.itrevolution.com. In fact, we’ll be announcing more speakers in the next week or two as we start processing the CFP submissions. And just a reminder, last reminder early bird ticket pricing ends on July 31 be sure to register soon for a 20 percent discount!
With that, thank you much Erica Morrison, Robin Yeman, Nicole Forsgren, Terri Potts, and Dominica DeGrandis. See you next time, all.
The rise of machine- and deep-learning algorithms is about to create some interesting data-gravity challenges for IT operations teams. Over most of the last decade IT operations teams have been caught up in a public- versus private-cloud computing debate that has mostly been species. The truth is that most organizations wind up employing both. But as IT organizations are just now getting used to that multi-cloud reality, the rise of machine- and deep-learning algorithms to create a new generation of advanced artificial intelligence (AI) applications are about to add some significant nuances to managing the DevOps pipeline.
New applications tend to be built and deployed where they can access the most relevant data. Most of the data employed by the average enterprise resides on-premises today. But it’s clear that the data being created in various types of cloud services is growing at a faster rate, thereby altering data gravity forces across the enterprise.
To get the most value out of that, developers are now building a new generation of advanced applications that employ machine- and deep-learning algorithms. In most cases those algorithms are being deployed wherever data happens to reside. For example, Salesforce just announced at its Salesforce TRAILHEADX 2017 conference that it is making available additional APIs to the Salesforce Einstein Platform Services for building custom applications that can now be infused with sentiment analysis, the ability to detect objects and understand customer intent.
Michael Machado, director of product management for Salesforce Einstein, says that the success of any AI initiative will come down to both the amount and quality of the data being accessed. As a CRM application consisting of a mix of structured and unstructured data concerning customers, Salesforce represents an attractive platform for building AI applications. In fact, to facilitate the building of applications, Salesforce also is making it simpler for developers to collaborate across multiple alliances in addition to providing access to DevOps tools from Atlassian and Github.
But CRM applications are only one element of the typical application portfolio. The more data that any set of algorithms can be applied against, the faster the application learns and the more accurate it becomes. As developers build the next generation of applications, they are going to want to be able to access as much data as possible. For many IT organizations, that will mean the applications will be hybrid almost by definition—attempting to centralize all their data will prove to be impractical as well as prohibitively expensive. Constructing application pipelines spanning multiple data sources, however, requires a very mature set of DevOps processes.
Arguably, the rise of these next-generation applications might finally force the DevOps issue inside most organizations. Most have been able to manage application development on various cloud platforms in isolation. Going forward, that may no longer be practical, as developers seek to incorporate more data sources within their application environment. The challenge IT operations teams will need to wrestle with is providing timely access to that data in way that doesn’t ultimately compromise their performance.
It has been about 18 months since my last post. Toward the end of 2015 I started digging deeper into cybernetics and systems analysis, which led me to construct a model and write a paper. I haven’t posted it before now because it isn’t perfect. The funny thing is, I know it will never be perfect but I still have a list of edits to make. I always will.
I would describe the paper as a form of hermeneutical phenomenology. The TL;DR on the model: it provides a basis to qualify systems for further analysis. Writing is a mechanism for me to study the model, but as my investigation varies so does my interpretation of what the paper should say. At the moment I’d like to add some observations around four-color mapping, thresholds and compactness. It’s a more rigorous argument than what I said about the continuum hypothesis, but I may leave that bit in anyway.
Ultimately, the paper is my interpretation of the work I’ve studied. More than read my paper, I’d encourage anyone to review the sources themselves. It goes without saying that I couldn’t have written it in the first place if I weren’t standing on the shoulders of the giants that came before me.
Self-Inflicted Othering
I strongly identify as a technologist and a mathematician, but I would be neither of those things if it weren’t for the broader scientific community. Where I keep seeing people get stuck is celebrating our individual differences along with what we have in common. Humans have a tendency to form tribes and wage war. While I’m always glad to see the sense of belonging communities provide for their members, it’s the tendency to direct hostility toward other groups we should resist. J. Paul Reed wrote a post about this last year. We all have circles we run in where our faces are more familiar than others and it’s easy to get “othered” when we step outside of those environments.
I meet a lot of really smart people at tech conferences who haven’t taken any trig or calculus. If I’m at a math conference I typically get a lot of beginner tech questions from people who are a different kind of brilliant. One conclusion from my paper is the operating environment is the ultimate constraint on a system. We can be local experts on whatever experience we have that’s not the focus of the event. We should also be able to find people that can teach us more about the event’s main topic while we’re there. If you find your experience in a field is making it difficult to learn, try spending more time with newer community members. Their challenges and experiences stand a good chance of providing a fresh perspective.
We Rise
This past week I spoke at We RISE Women in Tech Conference, which was hosted by Women Who Code Atlanta. I’ve been among the organizers for devopsdays Atlanta for the past two years and have been making an effort to engage the local community more.
I spent most of my time at We RISE on the tools track. G. Ann Campbell gave a great talk on code quality called, “Refactoring with Cognitive Complexity: The New Option for Measuring Understandability.” I’ve used sonarqube for years and have been studying complexity science as part of my cybernetics journey. I felt like I was the target audience for her talk. I really liked Meera Subbarao’s talk, “Know Your Enemy, and Yourself: Demystifying Threat Modeling,” too. I enjoy any talk with maps and Sun Tzu quotes, but the highlights of Meera’s talk were the personal stories she shared about trust and failsafe experiments. Experimental methods are playing an increasingly important sociotechnical role in security as our systems become more complex and adaptive. I’m currently convinced all sociotechnical systems are cybernetic as a byproduct of their complexity and all cybernetic systems are sociotechnical at a coarse enough scale.
Other Kinds of Othering
It’s that kind of talk that got me grouped in with the “complexerati.” The first time I heard the word I knew they were talking about me (among others) and it wasn’t intended as a compliment. Nevertheless, I couldn’t deny it is who I am. I’ve also been called an insight junkie and street academic and I can’t deny those, either. I can get hooked on a phenomena and dig until I’m completely exhausted. I also never finished my undergraduate degree, which leaves me to perform my research in the street, like a busker. I’m not sure busting my chops over the part of my degree I’m missing is constructive feedback, but we can’t expect everyone to be nice to us all the time, either.
I know we can catch people on a bad day so I try to be forgiving when someone gets a bit brisk with me. The complexerati comment led to some helpful advice after a diplomatic conversation. If I’m going to use language that’s specific but unconventional, I should make an effort to translate as I go along. People are comfortable with expanding their vocabulary but we shouldn’t introduce too much new material at once. What I said about cybernetics and sociotechnical systems translates into plainer English as, “any system with people in it is self-steering and any self-steering system will have people in it if we zoom out far enough.” The language isn’t quite as precise but it’s still accurate. Negative feedback can be helpful but we have to keep it constructive.fours
Diplomatic Relations
Churchill said, “Diplomacy is the art of telling people to go to hell in such a way that they ask for directions.” Communication is vital to trust and learning. Our human tendency to zoom in and steer toward our own familiar shores keeps us divided. This is an excerpt of my last post from December of 2015. It would seem my position has not changed.
Instead of focusing on processes we should focus on enabling people to improve themselves. We improve when we learn and we learn when we communicate. If your culture does not foster communication can if foster learning? If you’re not open and honest with yourself, how does that effect your environment?
I could go into more detail about my intentions for next year and may do so at a later date, but my plans are of no use to you as we are different people. I would encourage you to gain awareness of your own situation by challenging the assumptions that have bounded your operation.
We can stay true to ourselves and our own identities while interacting with other communities. We’re members of some and just allies of others. It’s important to respect those boundaries and understand when our experience is welcomed and appreciated, when it’s time to listen and learn, and when it’s just not the time or place for us and we need to move onto something else for a while.
We RISE was about technology and culture, which I believe are at the heart of what I’ve been studying for the past few years. The talks about DevOps and security couldn’t have been more relevant to my work. I felt some of the advice I heard in the keynotes from Jen Bonnett, Safia Abdalla and Estelle Weyl that was specifically targeted toward women was probably good advice for anyone, including me. Both Melanie Crissey and Sandra Persing shared their takeaways from the conference here and here, respectfully. Their posts should help shed some light on how I fit in and what I took away from this women’s tech conference more convincingly than I’ll be able to explain.
I felt very welcomed and included at We RISE. Erica Stanley, Alicia Carr and Beth Laing threw a terrific event. We’re lucky to have them and Women Who Code as members of our Atlanta tech community.
A Group Effort
I think this slide I tweeted from Ashley Sun’s talk is the best I can do at summing it up. Ashley gave an awesome talk, during which she showed us how she’s using neo4j for cloud monitoring that gave developers in her organization the ability to manage more of their own infrastructure.
Ashley shared Kelsey’s tweet in an effort to convince us that just because this solution was a good fit for her organization, it didn’t necessarily mean it would work for anyone else. Adrian Cockcroft had made the point that not everyone can be Netflix. Adrian used to work for them, so he might be a little biased. When Kelsey Hightower quoted him, it provided some external validation to the idea. Kelsey works for Google and they aren’t trying to be Netflix, either. They’re too busy being Google.
Greg Poirier pointed out that not everyone can be Kelsey Hightower in his talk at devopsdays Silicon Valley a while back. I felt the point Adrian had about Netflix applies to us as individuals, too. Copying Kelsey’s results won’t give us the experience of walking Kelsey’s path. Some experience with Kubernetes may help you on your own journey, but it will never make you Kelsey Hightower. The same applies for Ashley Sun, Adrian Cockcroft and anyone who’s still reading this. We all have some experience others can learn from because we’re each on our own path. As things change over time and our memories fade, not all of what we remember remains how it was today. This is how the perspective of a novice can give fresh eyes to someone with more experience.
One Step at a Time
This is why Taiichi Ohno was unconcerned when people came from the United States and wanted to study TPS. By the time they had implemented what they had observed, the process at Toyota would have already adapted into something different (if you’d like to read more about it you should check out this book). The game we’re in has no finish line we can cross. The only successful move we can make is to try to support each other as individuals and communities as we’re able, sharing what we have in common.
