Connections: August 2016

Wednesday, August 31, 2016

Gordon's Hafftime Issue #10

This issue talks:
Gartner Catalyst
Big Kubernetes clusters
Docker goings on

Become a subscriber.

After something of a hiatus, my Cloudy Chat podcast is once again publishing. (iTunes feed. It’s also now on Google Play and available directly from my blog.) My regular co-host had moved onto new responsibilities at Red Hat and with a lot of travel and other things going on, I just let podcasting lapse. But I’ve got a new episode out with Red Hat’s Jen Krieger talking distributed teams, another one mostly in the can, and am partway through refreshing some of the standard audio and graphics associated with the podcast. I also expect to experiment with the format a bit going forward so you’ll likely see (well, hear) some approaches that differ from my standard 15-30 minute straight interview.

With this relaunch, I’ve gotten some questions from colleagues asking how I go about recording and editing podcasts. I’ve written on this topic before, but reading back, I see that I’ve made a fair number of changes to how I do things. So time for an update.

Let me note at this point that I use a number of different approaches depending upon the circumstances.

I’ve written about how I record an interview with a remote guest previously and that description still pretty much applies except that I now generally use BlueJeans rather than Google+. But it really doesn’t matter; the process should be pretty much the same for most video conferencing systems.

If I’m on the road, I try to minimize gear and use one of the iRig microphones plugged into my iPhone. If I recorded this way a lot, I might invest in a dedicated recorder. Note though that some of the high quality ones don’t work well as hand-held recorders because they’re overly sensitive to being handled while recording. (The TASCAM that I describe later on has this property; you have to mount it and/or use external microphones.)

For this post, I’m going to describe how I record interviews when I’m in the office and don’t mind bringing in a (small) bag of recording gear. So this describes a case when your co-host(s) or guests are often in the same location as you are. I’ve fiddled with my kit over the past couple years and I’ve settled on this setup as one that is pretty straightforward once you have it down, can give excellent audio quality, and works to create a natural-feeling interview environment.

My hardware is as follows:

TASCAM DR-40 4-Track Portable Digital Recorder ($160 as of this writing)
A pair of microphones with XLR connections. I bought a 3-pack of Behringer Ultravoice Xm1800s Dynamic Microphones ($40 for 3)
Folding desktop microphone stands
XLR cables
Miscellaneous stuff like an SD card, batteries/mini USB for powering the recorder, foam windscreens

Setup the recorder for the external mics. I also use auto levels to try to balance the volume of the microphones but it doesn’t work as well as I would like. But, with my configuration, the mics record on different stereo channels so I can do some manipulation before I blend them. (I also have a USB sound mixing console that I can use to attach more microphones and to directly control their volumes but I’ve found, for most purposes, this adds a lot of complexity without a lot of benefit.)

For editing software, I use Audacity which is Free and Open Source and has far more features than I need or use. It also runs on Linux, Macs, and Windows.

Once I’ve blended the channels, the first thing I usually do when editing is go to Noise Removal under Effect, get a noise profile, and then apply noise removal to the entire recording. I think this capability was introduced in version 2 and, in my experience, does a great job of removing ventilation and other consistent background noises. Of course, the quieter an environment you can find, the better.

After editing in Audacity, I prepare the XML file that’s needed for iTunes and Google Play, splice my standard intro and outro audio onto the beginning and ends of the podcast, and upload the XML and the audio files to AWS. Most of the podcast apps get their feeds from the iTunes API these days, so that’s the one upload that really matters. Even with Google Play, you need to go through the steps to get your podcast into their store, but after that it can draw from the same XML file that iTunes uses. The only separate upload I do is to Soundcloud.

If it sounds kinda fiddly, it is. I’ve written a Python script [1] to take care of the splicing, the XML creation, and the AWS uploading. (Basically, I fill out a form with the title and description, point it at the MP3 file, and it does the rest. The only manual steps I still have to do are uploading to Soundcloud and writing a blog post for the episode; I also typically get my episodes transcribed by CastingWords for inclusion in the post.)

[1] It occurs to me that this is probably a good use case for Amazon Lambda but I wrote the original version of the script a few years ago and it generally works fine.

Tuesday, August 30, 2016

Podcast: Distributed teams with Jen Krieger

Increasingly, software teams aren't all working in the same office. Or maybe some are and some aren't. Red Hat's Chief Agile Architect Jen Krieger discusses her experience and offers advice for how to make distributed teams work effectively from appropriate tools, to practices, to behaviors.

MP3 audio (18.21)
OGG audio (18.21)

Transcript

Gordon Haff: Thanks for joining us today. I'm Gordon Haff, technology evangelist with Red Hat. Today, I'm joined by Jen Krieger, who's the Chief Agile Architect at Red Hat. We're going to start off this session talking about these distributed teams.

We're not going to talk about whether teams should be distributed or not and rehash all the debate about individual productivity versus team productivity and so forth. Because frankly, our experience at Red Hat is that distributed teams are the reality. Not every software engineer in the planet can live in Silicon Valley, or indeed wants to live at Silicon Valley.

Jen, introduce yourself please.

Jen Krieger: Hi. Jen Krieger, as Gordon mentioned, Chief Agile Architect at Red Hat. Basically, what that means on a daily basis for me is I just roam the halls here at Red Hat and hope people understand what that word, Agile, means.

I'm talking about distributed teams. It's an interesting topic here at Red Hat mostly because we actually have been distributed since day one, work with our open‑source communities and we can't expect everybody to be in the same room all the time. We're very familiar of this idea of having a distributed working environment.

One of the things that I think about a lot when I'm thinking about the word "Distributed" is, going back to that whole concept of what forms of communication are what we call high bandwidth or the most valuable forms of communication. A lot of people in the Agile space would say something to the tune of, "Face‑to‑face communication is the best way to have a conversation with each other."

Actually, today, Gordon and I are sitting across a table from each other where normally we would get over some form of distributed video conferencing to do a podcast. We're actually uniquely in the same room, which is not standard for us at Red Hat.

What I like to tell people is generally, when you're talking about face‑to‑face communication, video conferencing, email, IRC, all these different methods that you can use to communicate, it doesn't mean that face‑to‑face is the only way to communicate nor does it mean it's the perfect way to communicate.

Some people actually prefer not to have a face‑to‑face communication because there might be language barriers, personality barriers. Maybe it's easier for them to think about what they want to say before they actually are meant to say it.

There are other concerns and other considerations, especially in the world of software engineering today. it's not that it's bad to be distributed, we just have to recognize as an industry what it means. It's the same with face to face communication. That can't be your "Mode one" of communication, if you would. You have to think about the impact that other forms of communication may have on the ability for you to communicate the ideas that you're having.

Gordon: We're going to get to talking about some of the tools and techniques for using those tools and some of the best practices, but one thing I'd like to start off with is we had talked about distributed teams. We talked about non‑distributed teams. The reality is that there's usually going to be some sort of mix of those things, and that mixture can be challenging itself.

Jen: In my experience, I've had several different situations. One of the Agile teams I've had most recently, they were all in the same office. There were six of us, all the cubicles centralized together. We had the glass pulled out between them, so we could have that truly collaborative, truly just face‑to‑face type of environment.

It actually worked really well except there were some challenges, because we didn't necessarily want to be in everybody's face all the time. If you are an engineer, it's really sometimes hard to be in a situation where you're constantly pulled out of what you're trying to think about. We would actually pick a day every week where everybody would be working from home, so that folks could focus on just getting their work done.

I’ve also had situations where I would say 90 percent of all the people on the team are distributed, so they're working in their home offices, or one of them is in one of our main offices. There's not really a challenge of trying to share communication, because everybody has to take that second step to communicate. Everybody is distributed. Fundamentally, no one is in the same location.

The third challenge, or the third type of team that I've worked with, is the team where a couple of people are distributed but the central portion of that team is located in a main office and located very close to one another.

They all have their different types of challenges and different ways to address them, but I would say the one situation that is harder to deal with is that third situation, where I'd say maybe half your team is all in one place and half of the team is distributed, so some people are getting the benefit of that face‑to‑face interaction and the hallway conversation, and half the team is not.

Gordon: Let's talk about that third situation, because I think that's very common, maybe it's even the most common today, in the open source world, very distributed teams are often a norm.

That's maybe not quite a norm at a lot of other organizations but I've certainly seen that myself, whether we're talking software development or something else where decisions get made informally around the water cooler or over pizzas, over beer, whatever, and two or three guys or gals who are in London, in Hawaii, in wherever they're working from, they find out after the fact, "That's right, we've made that decision over lunch last week. Sorry. We'll try and remember to tell you next time."

What are some of the best practices that you've found for dealing with that kind of environment specifically?

Jen: The best situation that I can recall in my own career is, I would say it's about 12, 13 years ago now. I was the sole distributed team member of a team trying Scrum for the first time. Everybody else was in our Miami office and they were all, on a daily basis, participating in live and active vocal conversation.

I was their Scrum master, sitting in my remote office in Raleigh, North Carolina, trying to somehow manage impediments and manage the team from a very remote place. There was no technology at the time, at least at that office that we could rely on because the company didn't have Slack. It was nothing back then.

Maybe we could've signed up for WebEx but it was too expensive. We didn't really have anything other than a phone. Get that. I was a remote team member, being a Scrum master, and all I had was the phone. A lot of times, what would happen is they would have team meetings and they would forget to call me, because the phone exchange didn't allow direct call in, if they didn't call me, I just didn't go to the meetings.

I became very familiar with the angst of being that remote team member and came up with a long list of things. It wasn't that long. it was top three things that I needed that team to do, which is not forget that I was up there.

We played fun games, we printed out a picture of me. We put it on the conference machine so they would bring it around the meetings so they will remember that I was to be called on the phone. Simple things like that. Now that we have all this technology out there, there are a lot of other things that e can do to integrate that team into a central office.

One of the best things I've seen a team do is have one of those gigantic monitors in the center of a team area and actually having a running live feed of folks to actually join in video conference. Whenever they are thinking to say hi to people, they can just dial in and their face shows up on the monitor.

It's a little awkward if you're in a large office where lots of people walk through all the time. If you are in a small situation where you can actually dial in, you can see people sitting around. It's fun to see that.

The other thing that is really important is, those water cooler conversations are not going to stop happening. They are always going to happen. That's human nature to have a conversation with somebody. If you are sitting right next to them, to not have the conversation is a little weird. You're going to wind up having a conversation.

The things to understand though is that when you are making decisions, the first thing I always like to tell people is, "Who you actually bring to the decision making room is actually a pretty important topic." If you are going to randomly make decisions in the hallway without all the people who need to be in that decision, it's probably not going to be a very good way for you to actually get consensus or drive change to your organization.

If you're going to make a pretty impactful decision, you probably should make sure that you have all the decision makers in the room when you're doing that. Yes, it does slow the decision making down, but in some cases it probably is a good idea.

Example, you're making an architectural decision about your product line. Something needs to change. You're going to switch one technology in for another technology. Is it appropriate for you to have that decision made over a water cooler or should you bring in the extended team who is going to be impacted by this decision to get their feedback on that.

Option number two is probably better than option number one, but it also doesn't mean that every single decision has to be in that central decision making body. I would also say that there are probably some decisions that aren't going to really matter like, "What time do you have your stand‑up meeting?” If you guys want to make a decision and simply say something to the tune of, "Five out of six team members think we want to change it to this time, is it OK with you sixth team member? Would you mind if we do that?"

Trying to delay that conversation until everybody is on the phone may not make sense. It's a matter of determining the decision that need to be made or the question you're asking and how critical is the question, how much impact is it going to have? What's the risk level of the decision you make? Is it really risky? If so, you probably want to talk to more people to reduce the risk of what you might be deciding to do.

Gordon: Maybe related to that, one of the things that I've often found challenging in my career when I've been dealing with folks who are maybe not right next to me, maybe just in another building in the same location, there are a lot of decisions and a lot of useful conversations just to flesh out thinking, that maybe don't fall into the formal decision making bucket, but they're just part of the day to day interaction.

I find a lot of time, when people are remote from each other, it's harder to have those conversations because you feel like, "It's not really worth bothering that person with a phone call to talk about this half‑formed thought I have." What are some ideas you have about dealing with that kind of thing?

Jen: It's interesting because a lot of Red Hat doesn't have...maybe they do, but my observation is, a lot of the engineers I work with don't fall into bad habits because they generally use IRC to communicate.

I watch this every morning, when I get into work, people say, "Good morning." Some folks chat about what they did the previous evening. There is a connection that people make during the day. They have general conversation during the day that helps with that cross‑communication.

The interesting part about that is to layer that team dynamic on there where you've got most of the folks located to one office and a few people distributed, I would imagine that a lot of the conversation and the general chit chat happens around cubicles, happens around whatever space that team occupies and rarely, if ever makes it back to IRC, or whatever communication channel you choose to use, whether it be email or maybe Skype, whatever you're using.

It's important for teams to understand, especially if you're committed to doing something together as a team, that you have a social responsibility to the folks that you're actually interacting with. It's not just, get on your team meeting and immediately start talking about work but it's asking somebody about their day, or finding out what they did over the weekend, or trying to make some sort of social connection so that it's easier for you to have casual conversation.

In your own case, you might feel like you can't reach out to somebody and share that half‑baked idea because you don't know them too well. If it was somebody that you knew, you wouldn't hesitate to pick up the phone and have that conversation with them.

Gordon: When was an industry analyst for a number of years, one of the things I found was that I can certainly connect with people over the phone and have good personal connection with them, but it was much easier if I had actually met that person in real life and had dinner with them, had some beers with them or whatnot.

This comes back to, there is some value in these high‑bandwidth, in‑person communications because often, once you've established those things face to face, that's probably an argument. For example, having a commitment to things like team off‑sites, if you are possibly in a position to afford them.

Jen: Companies probably make out a little bit by having distributed work force, especially if they're not paying for co‑working space or Internet or a phone, they're putting that burden on their employees, they probably are making a little bit of money by not having to pay for office space or maybe not making money but having it reduced overhead for having to pay for something...a gigantic office building in downtown Raleigh.

The critical point is that it's not as easy to just say, "If I am not paying for a desk, that means I have X dollars free to do whatever else with that I need to," because there actually is the bottom line impact to the way that people are able to work together. Often, because it's not a quantifiable one, as in I can't establish that if I don't get Team A in the same room at least once a year, I can say for sure that they'll have a decrease 10 percent of production. I can't say things like that.

I can't quantify that to a finance person and say, "If you give me $5,000 so that they can all travel to a team bonding exercise or whatever you want to call it, I can ensure that they will have a steady line production for the rest of the year." I can't say stuff like that.

Anecdotal evidence indicates to me that it actually is a critical and important part of everything that we do as an industry. One of the things that I have had happen recently is that I did work with a team that was very distributed. They were from all over the world. They were not really brand new together.

They were having a little bit of trouble actually working well together and coming up with just a general backlog. Everybody was new to whatever it was going on on that space. We brought everybody together so that they can meet each other, have food together. People bond while eating. It's just a thing. It's a universal thing, whether it be beer in the Czech Republic or Italian food in Little Italy in New York City, people bond over eating and drinking. It's just a thing that we do as humans.

By giving them the opportunity to do that bonding, they just worked better together afterwards. That face‑to‑face interaction, it's critical for me, especially being a distributed employee to have that bond with people on a regular basis.

Gordon: I still remember a few years ago. It must have been a LinuxCon, it was one of the Linux Foundation Events. There was a kernel panel talking about how the development process worked with Linux, kernel and the like.

One of the kernel developers, one of the core maintainers, I don't remember which one it was, but he made a comment about one of the reasons that Linux kernel development has historically worked as well as it has, is that fortunately a lot of people involved...certainly, there's a lot of individual contributors as well but a lot of the core people involved... work for pretty well resourced companies, IBM, Red Hat, Intel, Hewlett Packard, and so forth.

That provides the opportunity and the budget, frankly, that people can get together in Linux Plumbers events, LinuxCons and the like. From their experience, this has been a very important part of Linux kernel development historically even though on a day to day basis, Linux kernel developers are all over the world.

Jen: They cite the social interaction they're having as their ability to long‑term work well together.

Gordon: Absolutely.

Let's switch gears a little bit and talk a little more about some of the benefits you see with specific tools. You raised a great point about IRC and Slack...call them messaging but in a sense, they're almost ambient distributed conversation.

To add to your point, when I had this feeling in my product management days that I had to go around and have in‑person conversations because things weren't important enough to bother some of them with an email or with a telephone call. One thing just those kind of tools provide is they do allow for this asynchronous, non‑interrupting type of conversation to take place.

Jen: It's interesting too because a lot of people think that they need to read everything that comes across IRC. I choose to read when I am available. If I've got a gigantic back load of things that I've not read yet, I just say, "Forget it," and start wherever I am at that given moment.

It is ambient conversation. It's not conversation that should be...if we're talking also too about that decision making, IRC is probably not a great place to do decision making because unless you're paying attention in the moment, it's likely that you won't even notice that a decision was made, or if you're trying to make a decision at IRC and somebody makes a decision, make sure it gets logged somewhere else so that you can actually go back and look at it later.

Slack is better for that because if you've got Enterprise Slack, you can watch and you can read the entire history. You can see some of that stuff. I know there are ways in IRC that you can also do that. Obviously, I've got a proxy set up so I can see the entire backlog. Again, it's like the social existence around those messaging systems where it's not necessary or mandatory for you to read everything. It is really just general chatter.

It's like whatever you would be experiencing while you're in the office, you'll just listen to people talking. I was just sitting over in the breakout room and I could see people just having random conversations, I could hear them doing it. I didn't necessarily need to listen for content. I just knew that they were having a conversation.

It's a way to pass information back and forth pretty quickly but it's also a way to feel maybe a little bit bonded to the people that you're working with even though you're not participating in that given moment.

Gordon: We've talked about documenting decisions and we need to make certain decisions, make sure everybody in the team knows. What are some of the practices that you use for documenting decisions that everyone has participated in?

Jen: The easiest way to say that is that if you are working at a product line and you have some sort of roadmap of what you're trying to develop for the year or maybe even a given release. The easiest way to track those decisions is to associate the decisions directly with the work that you're actually doing.

In the space of Scrum and Agile, we call them user stories. We tag them back to problem statements in which we're trying to solve something for our customers. They go through this, not massive process, but a pretty well‑defined process of how we get from problem statement to actual user story where our team is going to do something, but if you are making a decision about, "I'm going to use technology A versus B to solve this problem," and you decide to go with technology B, the easiest place to put that decision is on that user story.

Long‑term, it's harder to capture that information for product line. If you make decision, we're going to go with technology B, how does your customer know? 10 years from now, how do you remember that you actually made that decision? The best way to do that is just to document your product.

I don't really know any better way to do it. Maybe you could have a system to track decisions and you can go back and you can say, "On October 1st made a decision and this is what the outcome was,"

I don't really know how that's valuable if it's not tangentially related to the product that you're working on. Say you're doing a CICD system and you choose Jenkins as your technology, I don't think it matters who made the decision or when you made the decision but rather, was it implemented, is it in the product line, can you document how to use it or what the implementation details are? Those are the things that matter.

Tracking when the decision was made and who made it feels maybe a little bit like you're feeling untrustworthy about who made the decision or why was the decision made. Associating back to the actual work that you're doing is probably the best place for you to be.

Gordon: Continuing on the theme of tools, one of the things that's been percolating for a long time in business is video conferencing. It would be fair to say that historically a heck of a lot of money has been wasted for not much effect. How do you feel about the current generation of tools and what their value is in terms of teams working together?

Jen: I don't know anybody who doesn't complain about video conferencing. I was legitimately just at Agile 2016 and listened to some hallway conversations about people complaining about video conferencing. I just took a casual poll where, what are we using? All the big names came up.

Everybody goes through this 5‑ to 10‑minute pre‑conference...there's Internet memes about this. Pre‑conference, who's on the phone? Dialed in, interrupting. All these things have happened.

There are definitely improvement from what I had when I was working and that sole employee, remote, because I had nothing. It's 2016, it should be far better than it is. It just doesn't seem to be any better in the last five years than it was when I first joined Red Hat, really. It just seems to be not going anywhere.

Gordon: We can all agree that some of the messaging tools, for example, are really quite good now. Without starting a traditional Internet versus software as a service knockdown, you'll find certainly Slack or potentially other tools in that general bane. It has legitimately moved to promote collaboration forward.

I can remember having conversations with Novell maybe 10 years ago when they were doing a lot of work on collaboration. Wouldn't it be nice to be able to do the equivalent of standing up at whiteboard in a room with a bunch of people sitting there and have that kind of interactive, very rich visual experience? The fact is, it's still pretty bad.

Jen: That's actually a pretty interesting conversation because I've been looking for whiteboarding programs for a while. Just so that we're all clear, especially for folks listening to this podcast who might be creating a for‑pay tool that's really fantastic, I'm looking for free things, things that my Linux users will feel comfortable using.

The space here is not that broad. There are some really great things out there but they're not necessarily perfect. They're still worlds away to go.

I was actually talking to one of my friends a couple of months ago about...I guess they were using these smart whiteboards that they purchased for one of the school systems. I was asking her how it was going. She said it was a complete disaster because no one knows how to use it and so they were immediately broken. They've got these $25000 whiteboards that no one knows how to use.

It was a complete waste of money and time because they don't understand the technology. You can get these really fancy things that unless you really know what you're doing, you don't know what to do. That's sad, right?

Gordon: Yeah. I'd hate to admit this but probably 20 years ago, having things that take pictures of a whiteboard or that you could use different colors and write and it would supposedly put this onto a computer screen, none of that stuff really worked. I'm sure we spent at least a few tens of thousands of dollars in this stuff at a former employer that never really worked. The really sad thing is, I'm not sure we're an awful lot better today.

Jen: No. A lot of the video conferencing stuff is always going to be challenged by networking and bandwidth caps. Unless you are somebody who wants to pay a significant amount of money for your home office Internet connection, you're going to be challenged by that. That's not something that I think...technology obviously will make that better as time goes on. Right now, given the state of things in general, it's a goal that's far out in the future to be able to stream video back and forth like that, and not have problems.

Gordon: I've heard some of the very high end Cisco systems. You have a special room and you have someone directing the cameras. It can be very good. Of course, at that point, pretty much everybody says, "Let's just fly together to a nice place." [laughs] To get there.

Jen: I have a lot of friends who work at Cisco and they claim that these systems are fantastic. I believe them.

Tuesday, August 23, 2016

Video: Getting started with DevOps

At Red Hat Summit, Dylan Silva and I co-presented on getting started with DevOps. We focused on two scenarios. I discussed using OpenShift to create a complete DevOps environment and workflow. Dylan covered using Ansible to quickly and easily automate tasks that are getting in the way of developer and ops productivity.

Series of posts about modernizing virtualization

Screen Shot 2016 08 23 at 1 29 04 PM

In a recent series of posts on the Red Hat blog, I took a look at virtualization modernization with a particular emphasis on incrementally building off of existing virtualization investments and on the management of, often heterogeneous, virtualized environments.

The first post set the stage for the series, noting that:

Some readers might be thinking that virtualization is yesterday’s news. But it continues to play a major role within just about every enterprise IT infrastructure whether measured by the number of applications it touches, the expense of supporting it, or the number of administrators needed to manage it. At the same time, it’s often not used efficiently. At Directions 2016, IDC Group Vice President for Enterprise Infrastructure, Al Gillen, noted that virtual machine (VM) density is stalling out at about 10 VMs per server and between 30 to 50 percent server utilization. This leaves ample room for improved efficiencies and financial value.

The second post focused on getting things done faster such as by introducing self-service (with Red Hat CloudForms or with Red Hat Enterprise Virtualization itself), automating (e.g., with Ansible), and by simplifying integration.

The third in the series looked at saving time and money—always high on the concerns of IT operations folks. Efficient management is a big piece of this given that, in many cases, the server sprawl that virtualization was often introduced to address simply became “VM sprawl,” a similar problem at even higher scale.

The virtualization platform itself can also save money. For example, performance features in Red Hat Enterprise Virtualization (RHEV) such as KSM memory overcommitment (which allows users to define more memory in their VMs than is present in a physical host) and SR-IOV for the virtual machine network (which increases network throughput while decreasing latency and CPU overhead for near bare-metal performance) enable high VM densities. As of March 31, 2016 Red Hat held the x86 2-socket world record for SPECvirt_sc2013, the standard benchmark used to evaluate performance of datacenter servers used in virtualized server consolidation.

Finally, I discussed how security features and compliance relate to modernizing virtualization. Again, management plays a big role. Red Hat CloudForms provides robust mechanisms for cloud infrastructure with automation, advanced virtualization management controls, private or hybrid cloud management capabilities, and operational visibility. This includes aggregate logging capabilities that let you segregate, log, and allocate resources by user, group, location, or other attributes. Among other benefits, this helps you to find systems that are out of compliance so that you can take quick remedial action.

This complements the foundation provided by Red Hat Enterprise Linux and RHEV. For example, the RHEV security model takes takes advantage of the SELinux and sVirt capabilities in Linux--including mandatory access control (MAC) for enhanced VM and hypervisor security.

(For a broader picture of security and compliance at Red Hat, take a look at the whitepaper that I wrote earlier this year.)

Monday, August 22, 2016

Internet-of-Things (IoT) at Gartner Catalyst

1 kRiM0T4e7iHbREUGouUtOw

I was out at Gartner Catalyst in San Diego last week and I’ve been trying to mentally sort through what might serve as interesting observations from the event. It covers a broad range of topics relevant to technical professionals, so it’s been a bit hard for me to distill the sampling of sessions that I attended into a single storyline. However, an unrelated piece on IoT that I read this morning—and the graphic that graces this page—got me thinking about some themes both specific to IoT and applicable to emerging technologies more broadly.

Accelerating pace

At one level, the fact that IoT was prominently on display in a keynote, as well as in a variety of breakouts, is certainly not surprising. There was plenty on containers and container orchestration too. Gartner VP Eric Knipp even highlighted open source as a “cool forever” technology. Well, duh, you may be thinking. Do any of the cool kids not talk non-stop about topics such as these?

Here’s the thing though. How shall I put this nicely? The cool kids tended not to go to Gartner conferences or be Gartner clients historically, Indeed, for many shades of cool, that’s still the case. This isn’t predominantly a startup hub place.

Many of those conservative banks and manufacturing companies and logistics vendors now care about the latest technologies as well. They have to; digital transformation is a thing and the cost of doing nothing is higher than ever. They may adopt new IT approaches slower and more methodically than the Silicon Valley company setting VC dollars on fire. But they’re at least interested in learning about projects, products, and tech that may have not have even existed a couple of years ago. It’s a big change from the days when a lot of these folks weren’t especially interested in anything that wasn’t already in production at a hundred of other sites in their industry.

IoT: The Bad

Scenario from the keynote. Car window gets broken by a thief. The police are automatically summoned. The owner’s insurance company is informed. Repair quotes and automatically generated and a repair is quickly scheduled in time for that evening’s anniversary dinner plans.

Heartwarming. Efficient. A marvel of modern networked communications.

Skip over for the moment all the automagical seamless interaction of communication systems, document formats, and workflows designed to “just work.” At the risk of being a luddite, this degree of autonomous interaction with and between third-parties sets off my creep-meter.

Perhaps I’m overreacting in this specific scenario. But I think it’s hard to argue with the fact that we’re being bombarded with more and more IoT examples in which it seems that someone stopped at the “can it be done stage” without much if any thought given to the “should it be done" question. Whether because it’s creepy. Or even just solves a problem that no one has.

IoT: The Good

Yet, the same keynote also featured an IoT use case from Duke Power that was exemplary on a couple of fronts.

For one thing, it was a joint presentation featuring leaders from both information technology (IT) and operational technology (OT) within the company. Driving cooperation between IT and OT was a key theme both in this session and woven throughout the conference as a whole. Reporting from the event, Craig Powers writes:

“At Duke, OT and IT have been apart for many years—we barely touched,” says Shawn Lackey, director of strategy and architecture at Duke Energy. “OT was mainly analog; IT was moving towards digital—we needed to start bringing the two together.”

Lackey was speaking Monday during the opening keynote of industry analyst firm Gartner’s Catalyst Conference in San Diego.
But connecting OT and IT wasn’t necessarily easy, just ask Lackey’s colleague Jason Handley, director of smart grid technology and operations at Duke, who also spoke during the Gartner Catalyst keynote.

“I did not want to talk to IT to begin with,” Handley jokes. “But my attitude has changed. Legacy operations for OT were based on protection and control and nothing else is going to trump that—but now we need to move digital data, and that is only happening by partnering with the IT folks.”

It’s also just a good example of building toward an integrated system that meets genuine business and customer needs. The video goes into more detail but the basic idea is that, using real-time sensor and metering information, the grid will be able to quickly route around certain types of physical damage.

IoT: The Ugly

The keynote didn’t have much to say about IoT security but breakouts dove into considerable detail. For example, Gartner’s Erik Wahlstrom covered “Securing Digital Access in IoT Solutions” while his colleague Erik T. Heidt spoke on “Securing IoT from Edge to Platform and Beyond."

A couple of common themes were lifecycle management and dealing with the diversity of edge devices.

For example, Wahlstrom noted that “sneaker net” is still a common way to provision identity in IoT; the problem is that when things are done this way, there’s no automatic way to provide updates and otherwise manage the device over time.

There is a lot of work going on with IoT security and identity management, including the development of new standards. For example, Enrollment over Secure Transport (EST), is "a new standard (RFC7030) designed to improve the lifecycle management of digital certificates, a key element for secure communications.” However, standards have to cover many different areas—this presentation by James Fedders of Intel gives a sense of just how many—as well as many different classes of edge device: small/smaller, connected always/sometimes, plugged in/low power, etc. For example, the aforementioned EST requires HTTP to work and therefore isn’t a fit for the most contained edge devices.

I’d sum up the security (using the term broadly) conversation is that there’s a general recognition that it’s important. And work is going on. But there’s a huge amount left to be done and, if security is valued in principle, I see far less evidence that it’s universally valued in practice.

[1] Graphic by http://anandmanisankar.com/posts/IoT-internet-of-things-good-bad-ugly/

Video: Lessons learned on the DevOps front

At Red Hat Summit in June, Katrinka McCallum and Jay Ferrandini shared their experiences and lessons learned in the process of rolling out DevOps in the Product and Technologies organization. They call it their banana/pickle story, a reference to the pre-DevOps challenge of delivering to users the banana that they asked for instead of the pickle that they didn't want.

This was one of the highest-rated sessions in the IT Strategy track and Summit and is a must watch if you're interested in case studies about how real organizations are implementing DevOps, the challenges they face, and the benefits they gain.