devopsy.kinsta.cloud

Category: Features

  • DevOps Video Chat: DevOps Testing with Ryan Lloyd of SmartBear

    DevOps Video Chat: DevOps Testing with Ryan Lloyd of SmartBear

    The testing landscape in DevOps is a big one, with lots of established players feeding the machine. SmartBear is one of those companies. The force behind Swagger, SoapUI and others is perhaps not as well-known as its brethren in the DevOps testing space, but it cuts a wide swath. And, with its recent acquisition of Zephyr, it’s about to get wider.

    In this DevOps Chat, we speak via video with Ryan Lloyd, VP of Products at SmartBear, about the Zephyr acquisition and the DevOps testing and test management space in general. As usual, the streaming video is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, Container Journal, Security Boulevard, and we’re here for a great interview, hopefully, with Ryan Lloyd, VP of products for testing and development at SmartBear. Ryan, welcome.

    Ryan Lloyd: Thank you. Great to be here.

    Shimel: Great to have you here. So, Ryan, before we jump into today’s news that we wanna discuss, I wanted to just quickly kinda do a level-set. SmartBear is a company I think most people have probably heard of it, but they may not be 100 percent sure of the full breadth of the SmartBear portfolio. So why don’t we talk a little bit about who is SmartBear and what are the kind of products and services you guys offer?

    Lloyd: Yeah, absolutely. So SmartBear software is a company with a lot of history and if you don’t recognize the company brand, it’s very likely that you recognize one or more of our product brands, so we are the company behind some of the key product brands like Swagger, SoapUI, CrossBrowserTesting, TestComplete, so quite a diverse portfolio of products focused on helping our customers who’re building software. Help them build tests and monitor their software applications.

    Shimel: Great. So, Ryan, big news out today is SmartBear had made another acquisition. You guys have acquired Zephyr. Is that correct?

    Lloyd: That’s right. Yeah, we’ve announced our intent to acquire Zephyr, a company in a similar market space as us.

    Shimel: So it’s a similar market space, but let’s get specific. What does Zephyr do?

    Lloyd: Great. So Zephyr is a collection of tools for testing and specifically focused on the area of test management, managing the process of testing.

    Shimel: Great. And you mentioned an intent to inquire – acquire, so I guess that means it hasn’t yet closed, but you’re both private companies and I would imagine it closes fairly quickly.

    Lloyd: That’s right. We expect in the next 30 days, subject to the usual regulatory approvals.

    Shimel: Yep. Fantastic. So, you know, Ryan, one of the things I read in the background around this one was that one of the big pluses here is Zephyr’s presence within the Atlassian, the Atlassian ecosystem, and SmartBear actually is already a big player in that Atlassian ecosystem. Well, aren’t they?

    Lloyd: Yeah, so we have a couple of products that have plug-ins to the Atlassian ecosystem. I mean, the reality is 60, 70 percent of our customers are using Atlassian’s tools. They’re pretty dominant in the area of software teams, for managing some part of the software development process, so it’s a very strategic and important ecosystem for SmartBear as a company. And, certainly, Zephyr improves our ability to reach that ecosystem of users and make sure that they’re aware of all of the tools and capabilities that SmartBear can offer.

    Shimel: Yep. And, Ryan, you know, 60 to 70 percent use Atlassian. I’m gonna imagine the overwhelming majority are using Jira and then maybe Jira Plus.

    Lloyd: Jira –

    Shimel: Correct?

    Lloyd: Certainly, Jira is probably the most prevalent. Confluence gets tagged on with Jira quite a lot. And then BitBucket, actually, is also becoming quite popular as well. BitBucket, GitHub, GitLab – they’re sort of three of the same, in terms of enterprise solutions for developers.

    Shimel: Got it. So I don’t wanna turn this into being about Atlassian and their products, but, obviously, they do have a big ecosystem. There are a lot of third parties, such as SmartBear and Zephyr, who move a lot of services and product via that marketplace. But let’s talk a little bit similar, but where’s the overlap? Or is there any overlap between what Zephyr and SmartBear’s offerings are about?

    Lloyd: Yeah, so SmartBear offers a broad portfolio of products and, certainly, a couple of the products we have, pre-acquisition, were in this test-management space. What Zephyr brings to the table, though, is a solution that is natively built around Jira and delivered through the marketplace. So what that means, to be delivered through the marketplace, is it’s a native Jira solution that Jira administrators and customers can install directly from within their Jira instance. So it provides a very seamless extension of their workflows, within Jira, to handle some of these test-management scenarios, which we think is really important to teams that are trying to consolidate their processes and have a unified approach to that.

    Shimel: Excellent. I guess one of the issues – and, with your title and your responsibilities around VP of products for test-and-dev, just in a number, how many products are there in test-and-dev now, within SmartBear and then if we add the Zephyr suite to the mix?

    Lloyd: Yeah, so we had five products in that portfolio. Today, Zephyr brings three additional products into that portfolio, so we’re now up to eight products in our test and development business, as well as a range of products in our other business unit, around API.

    Shimel: You know what? That’s a lot of products to be managing, huh?

    Lloyd: It is. I mean, SmartBear has grown a lot over the years, through both acquisition of companies and building new organic products and bringing them to market. It’s pretty exciting time for us. We’re, pre-acquisition, at about 450 employees globally, so it’s an exciting time to be part of this company.

    Shimel: Absolutely is, man. So, you know, another not necessarily unique but another kind of factor you have to play into the SmartBear – and I don’t know about Zephyr as much – is that some of your solutions have open source kind of versions out there that you guys help manage the open source communities around these, as well as the commercial versions of the products themselves. Correct?

    Lloyd: Yeah, that’s right. I mean, core to our business is really a couple of philosophies. One is we wanna be open and interoperable with all the tools that are part of the ecosystems that software teams are using. And so, in some cases, that means commercial opportunities to partner with companies like Atlassian; in other cases, it means we want to be a part of an existing open-source ecosystem or help build up and nurture an open-source ecosystem. So, certainly, when we brought SoapUI and Swagger into our product portfolios, that was all about really taking that existing organic ecosystem, where developers and testers are going through tools, and helping build and nurture and develop that ecosystem.

    Shimel: Excellent. So what kind of special challenges – you specifically, right? You own the products; you’re VP of products here. What challenges does that pose for you, having these open source kinda versions and tools and communities. I mean, you don’t wanna burn them, right? Because, ultimately, you kinda bite the hand that feeds you. So let’s talk about that. What does that – how does that manifest itself with you?

    Lloyd: Yeah, certainly. I think there’s a brand and a culture that exists around open-source products and I guess it’s our responsibility, as stewards of those brands, to really continue to nurture that community. And that means we’ve gotta make balanced decisions about where we choose to add features to the open source products, versus where we commercialize some of those features, so there’s a constant balance there and kind of evaluating and making sure we’re engaging with the community.

    And then, more broadly, beyond just our open-source products, I think one of the biggest challenges in the software tools space and market is the interoperability that’s required between tools these days. You know, developers and testers, they’re demanding practitioners. They want their tools to work together and there’s a huge diversity of tools out there in the market. So, as a product manager, that’s what keeps me up at night, is making sure all these tools are compatible and working to support these complex workflows.

    Shimel: Absolutely. I mean, one way of looking at it is, if there wasn’t such a big market, there wouldn’t be all these tools.

    Lloyd: That’s true.

    Shimel: Another way of looking at it is also that it presents a tremendous opportunity for consolidation and for one or a few products to emerge as true market leaders. And then you’ll see it kinda – you know, you’ll see the amount of products in the market kinda consolidate. You know the old saying, “If you’re not – you’re either leading, following, or get out of the way,” right? If you’re not top-three, you gotta ask yourself, “Do you wanna stay in that market?” But, you know, when we talk about the testing market – and, in DevOps, we talk about continuous testing – it certainly is a huge, huge market here.

    Lloyd: Yes, it is. And it’s one that’s continually evolving and shaping, right? So there’s traditional test tools that have been around for a decade or more, and then there’s sort of emerging products that are coming to market. And I think it’s how all these work together and evolve to support the change in workflows and, yeah, even just organizational changes within environments.

    Shimel: Yep. So another area of the testing space, Ryan, that I’m interested in personally is security and security testing. And it’s really funny when I – you know, 20 years ago, when I was into security, when I first got into security, info-sec, QA was here and security was there and never the twain shall meet, right? But now we’re starting to see security become synonymous with quality – that’s the “Q” in QA.

    Lloyd: Yeah.

    Shimel: And so security testing and other kinds of testings are starting to merge. What do you guys see with that at SmartBear?

    Lloyd: Yeah, I think what’s driving a lot of that is the Agile workflows that teams are adopting, so, as they increase the pace of trying to deliver and release software, they’re being forced to evaluate quality and security earlier in the life cycle and more from the context of the development team, rather than having a separate, isolated team that deals with that downstream or after the fact.

    Shimel: Correct.

    Lloyd: So I think that’s the driver, so definitely a lot of demand for your Agile workflows to support testing by design and security by design. From our perspective, I think that opens up some unique opportunities for adjacencies and areas that SmartBear can continue to expand to in the future.

    Shimel: Yeah. I mean, so, you know, what you’re describing is almost the classic “shift left.” Right? As we start shifting testing, security and security testing, left early into the development life cycle. But it’s also the reality of it’s been called the “modern software factory.” Right? It’s an assembly line and is a production line, for software, and where traditional QA, traditional testing, security testing, where they fit into that life cycle has shifted left.

    But also is – you know, where we used to think, oh, QA was going away and security people were gonna give up control of security. Not the case. They’ve become more important, right? But also highly automated where they can be and clearly defined as part of this factory, if you will.

    Lloyd: Yeah, it’s really just about reshaping the responsibilities and improving the collaboration across the whole unit or team that’s now responsible for delivering iterations of software.

    Shimel: So, Ryan, then – so that begs the question then, “What does that mean for you as a product manager?” Right? Where you used to sell to a QA engineer or security testing sold to a security person, but now your audience includes the guys using Jira and BitBucket and a bunch of other tools. It’s not just Atlassian, obviously. So you have new customers to serve and to service. Now how do –

    Lloyd: Yeah, that’s absolutely right. Yeah, so, over the last several years, we’ve been focusing on how to modernize our portfolio to support those sort of emerging needs, both the process change that’s going on with our customers and the persona change that’s happening in many instances. So the acquisition of Swagger is a great example of us providing tools that help developers earlier in the life cycle, so, where we had SoapUI to help with API testing from a QA perspective, Swagger aims to solve some of that further upstream by enabling more collaboration around the definition of those APIs to begin with. And, oh, by the way, making sure that interoperates with SoapUI, so you get leverage out of that API definition to generate some of those tests, automate it, and it triggers sort of a seamless workflow and thread.

    And so we’re continuing down this path of modernizing our portfolio. We acquired CrossBrowserTesting about two years ago, to help companies address some of the modern types of applications that they’re looking to test, integrated more deeply with Selenium, which has become hugely popular in sort of the developer organizations, to drive automated Web and mobile testing. And then, with Hiptest and Zephyr, again, it’s furthering our relevance for those software teams that are on that journey.

    Shimel: Excellent. Ryan, last kind of issue I – or not issue – it’s not an issue at all – but the last area I wanted to talk to you about was so you’ve got five. There’s three more coming in. And that’s just test-and-dev; you have an AP kind of silo as well within SmartBear. How do you – I mean, I’ve been in the boat not quite as many as you, but, when you have so many different products and then a company name, how do you brand? Right? Do you continue branding the individual products? Do you throw SmartBear in front of all of them, but some of ’em already have names that may be, in fact, bigger than SmartBear, as you said in the beginning? Again, as a product manager, you have to think about that a bit. You know, what’s the right answer there, if there is –

    Lloyd: Yeah, so I think SmartBear is going through a bit of a transformation, in that regard. You know, as I said and as you pointed out, we’ve had very strong product brands up to this point. We wanna continue to nurture those product brands, so no intent for those to go away because we love the high-velocity, try-buy model we have around our products, where developers and the practitioners can find the right tool for the job and get started.

    But we’ve gone through an exercise on how we can integrate our products in the right way, so like the Swagger, SoapUI example I provided, to create those sort of interesting workflows. And we’re building up the SmartBear Academy, our SmartBear community, our big user conference, to help elevate the SmartBear brand and create more awareness of the portfolio of products we have – how they work together, how they fit into the ecosystem. And I think we’re just at the start of that journey right now. We’ll see a lot more, as we launch into the year next year, around what we’re doing from a brand perspective to galvanize the company and all of the great products we have.

    Shimel: Excellent. Well, Ryan, we’re about out of time, but, first of all, congratulations on the Zephyr announcement and anticipated acquisition here. It’ll make for some good times. And continued success with SmartBear and everything you guys have going on.

    Lloyd: I appreciate it. All right. Great talking to you, Alan.

    Shimel: All right. Ryan Lloyd, VP products, test and development, for SmartBear, on SmartBear’s acquisition of Zephyr, here on DevOps.com. And we’ll talk to you soon, everyone. Have a great day.

    — Alan Shimel

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie

  • Want a Successful Software Build? Just Say No

    Want a Successful Software Build? Just Say No

    It is a truth which should be universally acknowledged that the most important skill for a customer-facing job in what we laughingly call “information technology” is a cast-iron ability to say no—and make it stick.

    Empty suit

    The misguided desire to please other humans by attempting to deliver on their every request has sunk more projects than any units mismatch or catastrophic misconfiguration—even more than the justly feared Friday afternoon deployment.

    The key to success is an agreed definition of what success is, and how we will all know and measure whether we have achieved it. Let’s take the car as an example.

    French Cars Have Always Been Weird

    These days, we would consider a car to be woefully unfinished if it were lacking upholstered seating for at least four adults, a roof and windows to keep the elements out and some form of in-car entertainment—an FM radio as a bare minimum, probably a CD slot or USB socket as well. This is on top of seat belts, airbags, anti-lock brakes that are probably power-assisted and more lights and safety features than you can shake a stick at.

    Nicolas Cugnot did not bother with any of these features. His design didn’t even have four wheels. It not only didn’t have an airbag in the steering wheel, it didn’t even have a steering wheel. It was controlled with a ridiculous tiller arrangement that unsurprisingly completely failed to catch on. And yet, his vehicle was a success by the stated criteria of the project: It made it much easier for the French army to haul ammunition around.

    Nicolas Cugnot's steam dray from 1769
    Nicolas Cugnot’s steam dray from 1769

    Admittedly, he was also lucky enough to be constrained by the technology available to him. Even Louis XIV might have balked at adding a four-piece chamber ensemble to provide an appropriate musical soundtrack for the driver. But the key point is this: Monsieur Cugnot stuck to his brief, and concentrated all his efforts on the features necessary to achieve it.

    Bringing Apple Into It

    In somewhat more recent times, we have Steve Jobs (emphasis mine):

    People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

    One reason why Steve Jobs is so famous is that he actually said those thousand nos—often loudly, rudely and profanely. Steve stands out in IT because most technologists have an irrepressible instinct when faced with a question to start to speculate about it, bikeshed possible solutions, build a quick minimum viable prototype and, before you know it, you are armpit-deep in feeping creatures, all of which you are now somehow responsible to nurture and feed. Not being a technologist himself but more of an ideas person, Steve was perhaps better able to take a step back and focus on the end goal.

    Let’s Get Concrete

    Now, this should not be taken as a license to adopt all of Steve Jobs’ methods (Lesson One: Be a complete arsehole to absolutely everyone in your life), if for no other reason that even Steve got fired for it, and from the company he founded at that. When someone comes to you with a request for just one leeeeetle feature, you and I probably can’t get away with screaming “NO!” and slamming the door in the requester’s face. The polite and career-prolonging way to deal with the problem is to ask, “Why?”

    Ideally, in the process of explaining the rationale for whatever the request is, some other solution to the problem will be identified. A good way to improve the odds of this happening is to involve other people in the discussion. Extending the audience in this way creates opportunities for someone to interject helpfully with something along the lines of, “but Carol, we have a perfectly good hammer over there; why are you trying to use a screwdriver to batter a nail in?”

    Peter Falk as Columbo

    Sometimes, you may need to adopt an iterative approach, which sounds impressive, but simply means waiting until the end of the first explanation, nodding thoughtfully, and then asking, “Yes, but why?” Among people who watch more television than me, this is known as the Columbo approach: “Help me understand, what is it you are trying to do here?” and just keep doggedly repeating the question. Eventually enlightenment will arrive—or the requester will get tired and go away, which is also a perfectly valid win condition.

    This method will also help with the tricky situation where the most important question is the one which is not being asked. There is often an implicit question behind that one, where the solution is not to give a glib answer, but to think critically about the proposed or effective solution and ask the questions yourself: “Why are we trying to solve for this?” Or, “What is this thing you are proposing actually meant to do?” And finally, “What was the original problem, anyway?”

    People have a tendency to focus on the issue that is right in front of them, even when the real problem is in an upstream step of the process. They observe or experience something about X as the identified problem, and so default to solving for X directly without considering the broader landscape. This leads to convoluted, inefficient and often high-friction solutions—Rube Goldberg/Heath Robinson machines (delete as appropriate to whichever side of the Atlantic you are on), where a simple connecting pipe is all that is required. An artillery piece will make holes in the ground, but there are a couple of collateral impacts you may want to consider—and maybe offer a spade instead.

    Man standing in front of giant crater
    All I needed was somewhere to plant some flowers!

    Unfortunately even the Columbo Method is not entirely guaranteed to work, because on some rare occasions the underlying request is actually valid and cannot be summarily dismissed. This is when you bring out the big guns and start ranking the urgency of what was already agreed as the scope of the project (a nail hammered into the wall sturdily enough to support that lovely picture) as opposed to what is being requested (a fully motorized picture rail, capable of supporting up to 10 paintings on the scale of Guernica and turning them to optimize lighting conditions throughout the day while also keeping them out of direct sunlight). Nobody is saying that the second option would not be nice, but it certainly won’t be done in time for supper.

    And that, children, is how you say No. Go forth, and do ye likewise, and may all your projects be huge successes. And, most importantly, not require me to come in and clean up after you.

    — Dominic Wellington

  • DevOps Video Chat: DevOps Transformation with Tasktop’s Carmen DeArdo

    DevOps Video Chat: DevOps Transformation with Tasktop’s Carmen DeArdo

    Carmen DeArdo is well-known in the DevOps space mostly because of his work at Nationwide, where he was DevOps leader and technology director. In August of last year, Carmen moved to Tasktop, where he works with other DevOps luminaries Mik Kersten and Dominica DeGrandis, helping organizations along their transformational journeys.

    In this DevOps Video Chat, we speak with Carmen about his move to Tasktop and the culture shifts that are almost universal in embracing DevOps.

    The video is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel, DevOps.com, and welcome to a DevOps Video Chat. Today’s guest on our DevOps Video Chat is well-known DevOps personality, Carmen DeArdo, as well as huge Pittsburgh Steelers fan. Carmen, welcome to DevOps Video Chat.

    Carmen DeArdo: Thank you, Alan. Great to be here. Glad to be talking to you.

    Shimel: Absolutely. So, Carmen, to paraphrase a religious question, this one’s a little different than all other chats we’ve done before, in that we’ve always spoken to Carmen from Nationwide Insurance DevOps team, where you really pioneered a lot of DevOps – not only at Nationwide but set the tone and the course for a lot of DevOps journeys throughout the industry. But now you come to us as Carmen DeArdo as part of Tasktop.

    DeArdo: As you said, I always enjoyed, within the DevOps community, talking to other companies. You know, we talked a lot at conferences, where I was a reference customer for some other customer – companies, like IBM, and I was just really intrigued by Mik’s book, which I know we’ll be talking about, and some of the concepts that Tasktop was getting involved with because we were a customer. And I really liked their vision and now I’m here on the Tasktop roster, so to speak, working with customers to help them go through the kind of journey that we went through at Nationwide and also to bring in some of the concept of Mik’s book, which I think can take it beyond, to the next level of what we were doing at Nationwide.

    Shimel: That’s fantastic, Carmen, and I – first of all, I wish you a lot of luck in the new position, new sort of career path, and I’m sure you’ll do great because you’re just a great person with this. Well, you mention Mik’s book and I happen to have a copy of it here. It’s called Project to Product. It’s by Mik Kersten. And, not to brag, but I happen to have a signed-by-the-author copy of it, you know?

    And I will tell you, Carmen, I was fascinated with some of the concepts in the book and I’ve discussed some of these concepts with people, as part of my DevOps.com communication, and it really is – this concept of moving from a project-centric IT environment, right, to a product-centric is really – I mean, it’s fundamental, in a lot of ways, right?

    DeArdo: Yeah, it is. So I think, you know, we were at DOES London and that’s where they galley copies of the book came out, so the official copy, I think, the coming out party, officially, I think is gonna be in the Vegas conference, and then the book will be available shortly after that to everybody. But – through IT Revolution, but it is a fundamental change and it was something even that Mik and I had been talking about and we had been trying to work through at Nationwide because, before I worked at Nationwide, I worked at Bell Labs for quite a while. And one of the things that struck me when I came to Nationwide was we went – at Bell Labs, we already had this concept of kinda like products, right, because you had your switches, you had your network control points, you had – so work really came to the team. And so we were always working on the next set, for example, way back when I worked on Advanced 800 features, and so we had a team that stayed together and the work came to us and we were very focused on our product, that 800 service concept and then the systems that we build.

    So I came to Nationwide, what struck me was almost all the work was done through projects and these projects seemed to have a life cycle, a lot of ’em, that got funded as part of the funding for that year. They started up. You brought all these people to the team. You went through the “norming and forming and storming” kind of parts of the project. And then, once they were done, the project dispersed and the people went. And what you would do – it was very difficult to do – was, if a project touched five or six systems, you would start to allocate – you know, we were using Clarity – two people, three people, a half a person, a quarter person, whatever you thought you needed from those systems.

    And so it was a very fragmented kind of experience because the project was temporal; the systems people were all separated and spread out among these projects. Sometimes, a person might be working on a half-dozen projects at the same time. And, you know, you were constantly forming in these teams and so one of the ideas of the product focus is you have a set of people that are focused on that product. They’re gonna live, eat, drink around that product. And it may be more than one team – we’d like to say it’s a two-pizza team that can solve the world’s problems, but we know, sometimes, it’s gonna be more than one team – but still their focus is on the product and now the whole idea of bringing them a continuous flow of work, you’re bringing it to this established product teams.

    And the other thing that came up with projects a lot was there was this tension between doing the feature work versus the defects and the risk items and some of the technical debt because project managers were very focused on “You have a budget. You have a set of scope. You’re supposed to deliver that.” So who wants to pay if there’s a vulnerability in a Struts library or making the next thing faster, right? Technical debt is always about – is really about investing to make the next thing go faster, so, if you don’t really have a long-lived relationship with what you’re working on, you tend, just because of the nature of business –

    Shimel: You make short-term decisions.

    DeArdo: Make short-term decisions. Right.

    Shimel: Yeah. I mean, you know, Carmen, that was one of the things I realized in talking to people, about shifting from a project focus to a product focus, and, to me, it was almost – I learned a lesson. I helped take a company public back in the dot-com days – ’99, 2000 – and the difference in how we managed the company as a pre-public, as a private company, to a public company just blew me away. Right? All of a sudden, we were managing in three-month cycles, right? ‘Cause we were managing quarter to quarter ’cause we had to just, you know, go to the street and tell them our results. And you start making decisions that ultimately led to the failure of the company, frankly, because we were making very, very short-term decisions that were maybe good for the short term but not for the long term.

    DeArdo: Right. And you know I’m a – you know, we talk about Deming a lot and Deming warned about things like that, right, about the short-term thinking and lack of systems thinking, but you’re right. It drives you that way because the market’s saying, “Well, what’s your next earnings per share? What’s your next report gonna be?” So it does take more – it’s a different way of thinking about things and, really, you’re more in it for the long haul. Now that’s not to say you can’t do things well in the short term because absolutely you can. You can apply all the DevOps practices we’ve talked about. You can run your experiments or ideas of what you think is gonna get value. You can get that feedback much more quickly.

    So you can still apply all the things that we’ve talked about and everything, over the last five, six years, but now you’re doing it for the benefit of that product and you can start to tie the business in with how the value’s actually flowing, right? Because, a lot of times, you don’t – a business doesn’t wanna go up and show ’em an Agile team board, with a bunch of different stories, if they can’t relate it to “What’s the value of what I’m getting through this value stream? Right? Where is my value? What’s going on with what I’m trying to do?”

    And, with that product focus, it kinda tears down that wall and opens up that black box of IT and says, “Okay, all the way from the idea through deployment, we’re gonna make this work visible and we can see it and we can make decisions and priority calls based on how we’re gonna deploy our resources. And it’s across the features, the risks, the defects, and the investment in debt items so that we can continue to make this product good, not just now but in the future.”

    So it seems subtle, but, actually, it’s a very different way of thinking and it even gets back into how things are funded. So I think, in the past, with Agile and DevOps, we stayed away from that left-hand side of the value stream, closer to the customer – we’re kind of in our comfort zone – but now it forces you to engage the business and really have them come along to the journey with you. So that’s another change, I think, in how this applies, versus some of the things we’ve done up to this point.

    Shimel: Good. Now – I mean, Carmen, I think you’re so right on with that, though, in that it sounds subtle, but yet it’s so fundamentally different. And I guess one of my biggest fears around it is people are so resistant to change.

    DeArdo: Right.

    Shimel: And, thought – you know, maybe that it sounds subtle will help sneak it in, right, as a Trojan horse or whatever, but to tell people that they’re gonna have to shift the way they think about this, about the way they go about doing IT in products, knee jerk is “No, we’re not.” Right? It’s –

    DeArdo: Right.

    Shimel: And that makes it hard.

    DeArdo: It makes it hard. And that’s an excellent point, Alan, and I think we’ve been talking about this since I joined, which it’s almost two months now, about the fact that, just like – when I was at Nationwide and gave some of the talks with Cindy and Jim, we talked about the journey. We even had that mountain which showed you climbing to the summit. This is a journey, right? And, if you start out with what you just said and saying, “Okay, you can’t even get started until you do all these things and they involve your business,” you’re right. You’re gonna lose folks right there because “Wait. I gotta change my organization. I gotta change how we do funding. I gotta change this.”

    So the way you have to present it and the way I think we’re looking at is we’re taking the customer on a journey. And that journey starts, really, with – and I  used to talk about this with you – thinking horizontally. Right? So, when you think of a value stream, a value stream starts and ends with the customer. And if you start to get people to think horizontally and the concept across that value stream and the artifacts that flow from your PPM, your portfolio planning, through your build cycle, through your deploy, and the fact that, in order to get flow, your tools have to be connected, which is where Tasktop essentially was started, was around this concept of connecting your tools, making your tools talk, synchronizing artifacts from tools so, when a defect is created in quality center, it can flow into the backlog of your Agile team. When an instance’s created in ITSM, it can become a defect; it can flow.

    So it’s really starting with this concept of “Let’s start with getting the tools talking. Let’s get your artifacts flowing.” And even – and this may sound heresy – even if those artifacts initially are really focused on the work of an initiative or a team or even a project, dare I say, you can still start to utilize the concepts in Mik’s book around the flow framework and see things like lead time, flow time, the flow efficiency, flow velocity. You can still see those things as part of this journey.

    Now I think, ultimately, yes, you need to turn the boat more to get that product focus, to get some of the things – advantages we just talked about, but you can start this journey, I think, from wherever you are, as a enterprise, and just take those incremental steps in order to get to the point where then you’re ready to experiment with one product. Right? And then you just wanna start with one product. Pick one product, get one business owner that is interested in this.

    And then, from that, you even call it maybe an “experiment,” get some results, and then that’s what starts to change the culture. Right? It’s not gonna be me talking or giving talks; it’s gonna be – you know, I used to joke about this at Nationwide, right? When I would go around to different areas and talk, that didn’t have near the impact of getting one team to actually do something and get results ’cause then that opened people’s eyes and said, “Okay, that is possible. It’s possible right here, right now, and I wanna create my own story.” So you’re absolutely right. It needs to be structured in a way that allows companies’ teams to go on that journey; otherwise, the impact of the change is gonna be too much and you’re not really gonna get any traction.

    Shimel: I agree. You know, Carmen, that was one of the first lessons I learned in business a long, long time ago, which is nothing succeeds like success.

    DeArdo: [Chuckles]

    Shimel: No one wants to jump on a sinking ship; everyone wants to be with the winner. And if you could show that you’re winning somehow, that you’re succeeding, you have upside, everything kinda flows from there. Right? People wanna be associated with that and they’re willing to tolerate and even embrace change, in some –

    DeArdo: Yeah. Absolutely. And, you know, and some of the – you know, you can’t just decide you’re gonna wake up today and change culture, right? I mean, you have to do things through what you’re talking about, right? Creating those experiences, those successes, those stories. Stories are very powerful. That’s what ultimately will change the culture, right? Sharing credit. Right?

    If it looks like – you know, at Nationwide, if it looked like, “Well, this is Carmen’s show,” that’s not gonna get anywhere. It has to be everybody’s show. It has to be Jim’s show and Jane’s show and Donna’s show and everybody’s show, where they’re now showing how they can be successful. That then really has the impact of changing the culture and showing people that, yeah, this is possible because that team on the fifth floor’s doing this, right? It’s not in this book. It’s not in this conference. It’s that team. It’s that team on the fifth floor and why can’t we do it?

    Shimel: Agreed. Agreed. So, Carmen, you mentioned you’ve been at Tasktop now two months. We spoke a bunch about the book, Project to Product, by Tasktop CEO, Mik, but the Tasktop people have really amassed a great Murderers’ Row lineup there. They’ve got you; they’ve got Mik. And I can’t –

    DeArdo: Dominica.

    Shimel: Dominica DeGrandis, of course. You know, that’s a lot of brainpower. Lot of brainpower over there. What else are you working on?

    DeArdo: Well, I mean, it’s obviously a pleasure. There’s a lot of – it’s a great company, it’s a great culture, and Dominica beat me over here by a few months, but to be able to collaborate with folks like Dominica and Mik and then just the whole community, right? Because they were folks that were already in the great community that has been built, that Gene’s built, other folks like yourself have helped build this whole community. I mean, yeah, it’s a pleasure. It’s an honor to be able to talk about these ideas. I mean, Dominica’s concepts of flow and visibility naturally just relate to what we’re talking about.

    I thought it was interesting, in the London talk, the London conference, I mean, you go to all these conferences and you can sorta see, over year to year, how things are going and what topics now are becoming more in the mainstream. And there’re a number of talks this year where flow was either in the title or key concept. Jonathan Smart talked about it; Fin had a talk about flow. So flow is kinda where it’s at, I think, now, as people are seeing, “If I’m gonna accelerate my delivery, become more responsive, I gotta understand flow and, as my ex-boss, Tom Payter, would say, where things aren’t flowing.”

    And so, with Dominica’s great work that she’s done with making work visible and concepts of flow, her book, Mik’s book now, I mean, yeah, it’s a great opportunity to be involved with just a great company, great culture, and great folks, to see how we can help other companies succeed in the marketplace.

    Shimel: I think it also speaks to the coming maturity of the DevOps marketplace, where we’re seeing sort of leaders kinda come together, community leaders come together and combining in ways that it’s sorta synthesis, right? _____ synthesis and I think it’ll lead to yet another wave of innovation, another wave of thinking about these things.

    DeArdo: Yeah, I agree. I mean, I think people like Gene have done a great job of bringing people – creating forums for people to come together and the community, as you know and as you contribute to, is very open about sharing ideas. Right? So, for example, I would use – Topo Pal, we both know at Capital One – I would use his example all the time at Nationwide, when people would say, “Well, we can’t do this. We’re not a unicorn. We’re a regulated industry.” I’d go, “Well, let’s see what Capital One has to say about this,” right? They’re a bank. They had a great presentation with auditing, where I think Jennifer Brady was the auditor that came up on stage with Topo and gave a talk.

    So it’s just such a great community where people are willing to share and – you’re right – that allows everybody to get better and the whole community is kinda propelling each other forward. So it’s really been a great blessing, honor to be involved, getting to know all these folks and getting to do this kind of work.

    Shimel: Absolutely. Well, Carmen, we’re about out of time, but I wanna wish you luck at Tasktop. I think they’re really, really lucky to have you. I’m sure we’ll run into you somewhere on the DevOps conference circuit and we’ll catch up in person. But congratulations on the move to Tasktop. You’ll make us proud, Carmen. Keep innovating. Keep leading. And thanks for being our guest today.

    DeArdo: Well, I appreciate the kind words, Alan. It’s always great talking to you and I look forward to keep the conversation going. Thank you very much.

    Shimel: All right. Carmen DeArdo – you know, Carmen, I forgot to ask, what’s your title at Tasktop?

    DeArdo: My title is senior value stream management strategist.

    Shimel: Carmen DeArdo, senior value stream management strategist at Tasktop, our guest today on DevOps Video Chat. Thanks, everyone. Have a great day.

    — Alan Shimel

  • VR Development Guide: Choosing the Right Engine

    VR Development Guide: Choosing the Right Engine

    Creating virtual 3D worlds has been a dream of programmers for many decades. Virtual reality, once a faraway fiction, is becoming a reality. Failures such as Nintendo’s infamous Virtual Boy are now a distant memory, and major successes including PSVR and Google Cardboard have become the norm for the emerging technology. In fact, Statista projects incredible growth for virtual reality, estimating that the market will expand to $40 billion by 2020.

    Creating Your Own VR Apps is Possible

    Creating your own virtual reality applications is more possible now than ever. The cost to participate in virtual reality, for both consumers and developers, has lowered dramatically in recent years, and a plethora of tools is now available for new development teams to enter the fray.

    One of the most important elements to your virtual reality development process is the engine you use to build with. Unless you have unlimited time and unlimited resources, it’s in your best interest to use a commercial engine rather than create one yourself.

    Developing VR Apps with Premium Engines

    Akin to other development environments, there are many free-to-use and open source engines at your disposal. You’ll have plenty of options to choose from, but you’ll need to educate yourself about these tools to ensure you’re making the best project in regard to your specifications.

    The Unreal Engine and Unity have been used for myriad 3D video games and virtual reality applications. They have been classic choices for video game development and even for mobile app development.

    The Unreal Engine is free to use and allows development teams to create their own interactive applications at no cost. Once your application is developed, however, you’ll have to share a small percentage of your profits with the Unreal team.

    How to Build VR Apps Without Coding

    Interestingly, you can code your entire application with simple logic alone through the use of their Blueprint Visual Scripting functionality. With Blueprints, you can design programmatic actions, methods and computer behavior without writing a single line of code.

    This design feature isn’t available on any other major engine. If you have a design-heavy team, filled with more analytical designers and artists than programmers, you may want to consider using the Unreal Engine.

    Why Unity is a Developer Favorite

    Unity, a similar engine yet underpowered when compared to Unreal, allows developers to use their engine for a small upfront fee, but you won’t have to pay out any royalties once you’ve purchased the program. To use Unity, you’ll need to have a team with strong C# skills.

    If you don’t have a strong background in C# and don’t have the funds to bring on a more experienced C# programmer, you should strongly consider using the Unreal Engine. If your team has the programming ability and design ability, Unity can be a great and relatively low-cost option that sacrifices little in terms of quality.

    There are Great Open Source Options, Too

    If you’re looking for the lowest cost possible, you’ll want to investigate completely free engines. Video game engines such as Godot may be serviceable, but virtual reality compatibility is not completely assured. You’ll have to devote more time and resources into editing the engine your needs.

    Completely open source virtual reality-ready engines are also available for use. Apertus VR is one such example. It’s a set of embeddable libraries that can easily be inserted into existing projects. OSVR is another virtual reality framework that can help you begin developing your own virtual reality games. Both OSVR and Apertus VR are fairly new creations, however, and you may experience bugs and other issues you would not encounter with Unity or Unreal.

    Conclusion

    Developing virtual reality applications is incredibly hard work, but with a bit of persistence and with some help from experienced developers, you should be able to get the hang of the virtual reality development process.

    While you can’t control a great deal of what happens within the development process itself, you should make absolutely sure that your framework is well laid out.

    Selecting an engine or virtual reality framework that works for your team is a decision that requires a great deal of time and effort. Take your time weighing the pros and cons of the tools available to you. Moving forward will mean you’re committing yourself and your team to a specific engine. That sort of decision has a lot of weight in the development process.

    — Anthony Coggine

  • DevOps Chat: Crowdsourced Continuous Testing with Rainforest’s Derek Choy

    DevOps Chat: Crowdsourced Continuous Testing with Rainforest’s Derek Choy

    Scaling your testing is the scourge of many software teams. While test automation and continuous testing have made great strides, it still is difficult to automate every QA test. Also, engineering resources who can script these tests are difficult to find. Enter Rainforest.

    Rainforest has a unique crowdsourcing solution to continuous testing. It combines crowdsourcing talent with automation to deliver a high level of quality assurance on a continuous basis.

    In this DevOps Chat, we speak with CIO Derek Choy as he explains to us why Rainforest in some ways can be the Uber of QA. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. Today’s DevOps Chat features a first-time guest on DevOps Chat. He’s Derek Choy, CEO at Rainforest, or Rainforest QA, as some may know them. Derek, welcome.

    Derek Choy: Thank you. Just a little correction: I’m CIO at Rainforest.

    Shimel: What did I call you?

    Choy: Responsible for primarily the technical side of the functions here.

    Shimel: Did I call you “CEO”?

    Choy: I think you did, but I just want to make a little correction there.

    Shimel: You know, it’s 2019; that’s my prediction.

    [Laughter]

    Choy: I don’t know that I would support that prediction, but thank you. [Laughs]

    Shimel: Well, I _____ – CIO’s enough. But, anyway, Derek, thanks. Yes, it’s Derek Choy, CIO at Rainforest. So, Derek, you know what? I didn’t make the mistake on purpose; it was an honest mistake. Good. That leads us – why don’t we talk a little bit about Rainforest for our audience who may not be familiar?

    Choy: Absolutely. So Rainforest is a testing platform. What we do is we help our customers with their software testing. You know, as you know, we’re moving – a lot of companies are moving towards a rapid development cycle, CI/CD, frequent releases and stuff. Testing becomes much of a challenge for a lot of our customers because now they not only have to do testing, but they have to do it fast. They have to have accurate results and stuff.

    So Rainforest is actually a crowd-based testing platform that allows our customers to simply input test cases in plain English, so no Selenium or any sort of programming language, and then we can actually execute them as if they are automated test. We’re fully integrated into any CI/CD tools, like Jenkins or CircleCI and so on, so you can actually trigger a Rainforest test. Typically, we can return results in 30 minutes or so, and you can actually test across many different platforms, like different browsers, different OS’s, and the same for mobile as well. And so that allows our customers a wide variety of options, in terms of where they want to run their plain-English test cases and when they want to run it – it’s on demand. And we typically return results in 30 minutes, fully integrated into an automated release cycle.

    Shimel: Great. Excellent. And, Derek, how did it come to be that you became the CIO of Rainforest? Let’s hear a little bit your own personal journey.

    Choy: Cool. Oh, thank you. So I have been always involved in the product engineering side of things. I started off my career earlier with Accenture. Spent a number of years at eBay. And then my last company at Aria Systems, building SAS-based billing system, also running their engineering and product function. So, coming to Rainforest, I brought my experience and knowledge in this space, to help build the engineering and the product organizations. Now here, besides product engineering, I’m also responsible for our professional services team and our client success team. So essentially kind of helping build out product and making sure that our customers are successful in using that.

    Shimel: Absolutely. So, Derek, you know what? Here we are in December. We’re looking at 2019.

    Choy: Mm-hmm.

    Shimel: I probably have spent the last three weeks – if I tell you I’ve spoken to dozens of vendors and C-level execs at large organizations, and, to me, the real story of 2019, as well as what’s emerged as the story of 2018, is around – you know, you wanna call it “digital transformation” and “DevOps,” _____ say great, but, really, down to these two things: companies are – they need scale in what they’re doing today, right?

    Choy: Yeah, absolutely.

    Shimel: When we’re talking about data and computation and transactions or whatever the metric is that’s driving your company, everybody wants to do it at huge scale, like unprecedented scale that, 20 years ago, you would’ve went – you know, I’m just reminded of Carl Sagan saying, “Billions and billions of stars,” _____.

    Choy: [Laughs] Yes, that’s right.

    Shimel: That’s the scale. And the only way to achieve that kind of scale is automation.

    Choy: Yes. Absolutely.

    Shimel: So these are two kind of twins, co-joined at the hip – scale and automation.You can’t have scale, I think – well, you can’t handle scale without automation.

    Choy: Absolutely. Yeah. And – sorry.

    Shimel: Go ahead. No, no, go ahead.

    Choy: I –

    Shimel: You know, to me, that’s it right there. That’s the crux of it.

    Choy: Exactly. And, Alan, I would say that I’ve never been more excited, right, than where we are right now. I think we are definitely at a very exciting time and, just to kinda set the context and maybe kinda recapping a little bit of what you just said, right, the world is very different now, even compared to five years ago. Right? A while ago, you would hear companies having a quarterly release. Some would even have an annual release, if you remember, especially the bigger companies, right? You know, release cycle was a lot longer, takes a lot more time to get things out to the market. Today, release cycles are typically maybe in a month, right? Maybe two weeks and, in some cases, days or even multiple times a day. Right?

    And exactly to you – and the interesting thing is that the world has got accustomed to that and has come to expect that, frankly. Right? Think about the apps that you’re using. If they come back to you and say, “Well, you know what? We update our apps once every six months,” or something, you’re like, “Wait, six months? Wow, that’s unheard of.” Right? “I was expecting a weekly update or at least monthly or something.” So the world has actually comes to expect that.

    Now the challenge, exactly as you pointed out, is how do companies deal with that? Right? How can we scale our organization through automation, among other things, right, to make sure that we can keep up with that pace? I think that that is the challenge with a lot of technical leaders, is we understand what the companies are looking for, understand what the consumers and our customers are looking for, right? But how do we do that? Right?

    And there’re different aspects of it, Alan. I think that there is definitely a development aspect of it, right? How do we scale development? How do we do rapid development, Agile, sprint? You know, all these things. Things have evolved a lot over the last, I would say, ten years, in terms of faster development. There’s a lot _____ –

    Shimel: On the development side?

    Choy: Exactly. And there continue to be more evolution on that, which is super exciting. Now one thing that hasn’t really, at least in my opinion, gone as far in this particular context is testing. Right? If you think about testing, we’ve had automated testing for a long time – 10, 20 years, maybe even longer, right? We’ve always had manual testing, right?

    Now, when you think about testing, that’s – which is a critical part of the release cycle. Of course, right? You cannot push things out without some sort of testing at least, right? There hasn’t really been a lot of innovations and evolutions in testing. We’re still trying to do automated testing; we’re still doing some manual testing; we’re still doing it kinda the same way, so to speak. There’re new automated testing language, but they all kinda do similar things, right? And they all have similar –

    Shimel: Absolutely. And, Derek, let me stop you there for a second.

    Choy: Yeah.

    Shimel: To me, here’s the real crux in the issue.

    Choy: Yeah.

    Shimel: We talked about that we’ve certainly seen, let’s call it, a “revolution” in development acceleration, rapid development over, let’s say, 10 years. I’ll say even 20 years, right? _____ _____ _____ around for about 20 years.

    Choy: Agreed.

    Shimel: Do you consider testing part of development? Or did DevOps come along and say, “Wait a second, it’s all one continuity here, with development, testing, operations, security – you wanna put security next to testing, whatever – but it’s one continuum”?

    Choy: Yeah. It’s definitely – I completely agree with that. It is definitely one continuum, meaning that they are all part of the overall workflow, right, to make automation possible, to make a fast release process possible. You cannot do it without any one of those components, right?

    Shimel: No. But they haven’t kept pace with the changes that we’re in – what we consider when we talk development.

    Choy: Yes.

    Shimel: Where many of us think, you know, of coding.

    Choy: Exactly.

    Shimel: That’s the issue right there.

    Choy: That’s the issue, exactly as you pointed out, right? All the components of that whole continuum hasn’t really kept pace, right, with the developments that we’ve made on coding, right? On the actual coding of the product. And I think that that’s starting to show or actually has been starting to show, in terms of how other components of that, testing in particular, has been frankly dragging down the overall speed of being able to push things out faster and so on, so forth. Right?

    If you talk to – and you do that all the time. If you talk to a lot of CIOs and CTOs and so on, frequently, you’ll hear challenges with testing. Right? And most people will tell you, “Yeah, I’m okay. I get it going,” but very few people –

    Shimel: “It’s good enough.”

    Choy: Yeah, it’s just good enough, but it’s not great, right?

    Shimel: No, it’s not.

    Choy: Yeah.

    Shimel: And, Derek, I’ll go one further with you. What I see is this, is that, when we talk about testing – and _____ _____ the same thing with security, right? Is we’ve got twin challenges.

    Choy: Yes.

    Shimel: I can’t do it fast enough, so I’m constantly behind, running as fast as I can, but I can’t – just not fast enough.

    Choy: Exactly.

    Shimel: And then, number two, the train won’t wait for me.

    Choy: Yeah. Exactly.

    Shimel: If I can’t finish my testing, “Well, you did it good enough.”

    Choy: Yeah. “Let’s go.”

    Shimel: “We’ve gotta release. We’ve gotta release this hour,” or, “We’ve gotta release this week.” You didn’t do – dirty testing? That’s okay; it’s probably secure anyway. And, boom, out the door it goes, right? And that’s the dilemma, the enigma of testing, is “I can’t do it fast enough, but, if I don’t do it fast enough, they don’t wait for me.”

    Choy: Exactly. Right. And there is a reason for that. Exactly, right? Like we talked about earlier, because customers actually expect releases, right, whether you’re ready or not, right? They are expecting releases in a very frequent cycle. Right? And so companies therefore cannot wait. Right? It is not acceptable to go back to the customer and say, “You know what? My release is delayed and therefore you have to wait another week or two.” In the past, that used to be the common thing to do, right? Nowadays, that’s not acceptable.

    And so then what happen, exactly like you said, is that people compromise, right? They’re like, “Oh, you know what? Testing is not done. Okay, well, you know what? It should be fine. Let’s just go.” Right? “Security testing is not complete, but we’ve done a portion,” right? “Okay, well, let’s just go.” Right?

    The downside, however, is that – and you’re seeing it frequently; some people are just not paying attention to it – is that there is a high price to pay for that, right? You’ve seen a lot of security loopholes out there, right? And, yes, the release is out, right, but then at what cost, right? If people found a loophole and there is a data breach and costs companies lots of moneys and reputations and things like that.

    And equally with software quality as well, right? Things don’t work. Even bigger companies, you’ve heard companies like Apple, for example, struggle with that. Google, right, struggle with that. And they release something and people like, “Wow, this is junk,” right? “And I don’t want to upgrade,” and you hear that all the time, right? And it tarnish your reputation.

    Now bigger companies have, obviously, a lot more buffer to kind of weather these kind of quality problems, right? You know, whether you like it or not, you’re gonna continue to use Apple, right? Or Android or whatever. But then smaller businesses may have less tolerance for that, right? And customers of those businesses, if they’re not happy with your quality, they’ll move somewhere else.

    So I think it’s very important for technical leaders to figure that out and not just kinda brush it aside and say, “You know what? It’s not important. If quality’s not good enough, let’s just go. It’s fine. We’ll find bugs in production; we’ll fix it.” Personally, I don’t think that that’s the right approach and I think that it’s gonna hurt businesses down the road.

    Shimel: So you know what I call that? So that’s the double-edged sword of MVP.

    Choy: Yeah.

    Shimel: Right? ‘Cause you talk to these people and they say, “Don’t worry. We’re just doing an MVP. It’s a minimally viable product. We know it’s not 100-percent tested. We know it’s not a 100-percent baked. We know it doesn’t have everything, but we’ve gotta get an MVP out there, god darn it.” Right? [Chuckles] And so –

    Choy: Yeah.

    Shimel: And we appreciate – look, I’ve been – I founded, cofounded several venture-backed companies. I’ve been on pushing the VP of engineering, saying, “Hey, we promised our customer we had a new release coming out before Thanksgiving, man, and it has to get out. It has to get out. I don’t care if it’s fully tested. Get it out.”

    Choy: Yeah.

    Shimel: It’s not – you know, MVPs were being chewed to death.

    Choy: Yeah. I – [laughs]

    Shimel: So that “minimum” – that “M” in MVP keeps getting bigger and bigger and bigger. Right?

    Choy: Exactly. Right, exactly.

    Shimel: And more and more critical.

    Choy: Exactly. I think we continue to push the boundary of MVP. You know, I think that – and that’s really the challenge, right? So, you being kind of the leader of the business, right, you’re not wrong because customers really need it, right? “In order to move my business forward, I really need the release. I really need to get that feature out. I really need to get ahead of the market.” That’s not wrong. Right? And I think that that’s the needs of the business; that’s the market; that’s what people expect today. The challenge that we technical leaders needs to solve – CTOs, CIO, VP of engineering, VP of product – what we need to solve is “How can we support the business in doing that but also maintain the quality?” Right?

    And so, as a leader, in my opinion, going back to the business and say, “You know what? I can’t actually make your delivery date. You will have to wait another two weeks, four weeks, six weeks,” or something – that’s gonna be a tough sell, right? But, at the same time, releasing it without quality assurance, without security and all these stuff, is also not the right approach.

    So I think what we leaders needs to figure out is “How can we do better, right, in QA? How can we do better in security?” All these other things that are probably less mature than development itself, coding itself, right, how can we do better in these areas so that we can also support the business in shipping this MVP? Whatever the definition of this MVP is, right? We can support a business in shipping the MVP because that’s very critical to the business but, at the same time, maintain the level of quality and the level of security and, among other things, right, that we are proud of, right? That we want to have, right?

    And I think that that’s the biggest thing that we need to figure out in 2018 and definitely going into 2019, right? How fo businesses figure that out? How do we implement processes and tools and technologies that will allow us to do that?

    Shimel: Yep. So, Warren – Warren? I’m sorry. Derek, fantastic discussion. Let’s bring it home a little bit to Rainforest.

    Choy: Sure.

    Shimel: What can you do to help?

    Choy: Yeah, so Rainforest has a very – takes a very different approach to QA, right? You know, so the traditional way is, obviously, automated test with Selenium and all these different Appium, all these different technologies, or we can go manual testing and perhaps building an AMI offshore – that’s very, very typical as well. Rainforest looks at it and say, “Well, neither one are the best approach,” right? And therefore we come up with a testing platform, you know, that is powered by the crowd. And we allow our customers to actually put plain-English test cases on our platform. We can execute these tests without actually building an AMI offshore, but, at the same time, you don’t have to worry about the downside of automation, having to hire QEs and spend a lot of time writing Selenium scripts and things like that.

    And so we offer a solution that, at least we think, solves problems on both sides, right, and also allows you to hook it up into your CI/CD process so that you can actually push this MVP out in an automated fashion, fully kinda connected with all the rest of the continuum, right, and be able to actually ship code faster but with higher quality.

    Shimel: So let me ask, so, at some level, though, you are reintroducing or relying on human element?

    Choy: Right. Correct.

    Shimel: So why don’t you have the same scale problems that others do?

    Choy: That is an excellent question. So I would say that there are two elements, right? So, when we look at the human elements, we look at it from a crowdsourcing basis, right? So think about Uber, for example, right? If I were to hire my own team of drivers, that would be a little bit challenging, but then, leveraging the crowd and scaling it based on demand, we’re able to actually solve a lot of the human aspect of the problem. We can have testers that come in whenever they like to come in and we have enough testers to support the test that our customers would like to do. Right?

    And now the challenge there and probably a followup question then is “Well, but what about the quality of these people? Do they know what they’re doing?” Just like a Uber driver, right? How do you know that that guy actually drives well, right? So we actually developed a bunch of AI algorithms that actually analyze the work that they do and also take in feedback from customers, based on their former – the previous tests that they have done. And a combination of that with a lot of data mining and AI analysis helps our customers determine whether that test result is correct or not. If it’s not correct, we will engage additional testers to make sure that the tests are consistent and results are correct.

    So we have refined that algorithm over the years and now we have achieved a very high level of accuracy that, based on our data, is showing us that the accuracy’s actually higher than having your own manual QA team. And so you get better results, without actually hiring an AMI, either onshore or offshore. You can actually run your test on demand – typically, you’ll get results in 30 minutes or so. Right? And it’s fully integrated into your CI/CD cycle. And the best part is you can do all these things and achieve all these benefits without having to hire QEs to write automated scripts and having to maintain it, and so on, so forth.

    Shimel: Excellent. So, Derek, I get the outsource. I get the army of people doing it. But, on the back end, are you doing some automated testing as well?

    Choy: Yes, we are. And so what we’re also doing is we’re developing additional AI algorithms to actually learn from these human executions. So what we do is we have lots of human executions that are happening as we speak. In our environment, we have 80 million, 90 millions of tests that have already conducted on our platform, so what we do is we actually do machine learning through these data and learn from previous executions and develop algorithms so that, instead of actually having to send it to a human tester, we can actually achieve it with a robot.

    Very similar to the approach that Uber is taking. Today, human drivers are driving people around, right? In the back end, they’re developing these self-driving cars so that, in the future, we don’t really need a human drivers anymore. Very, very similar approach, from a QA standpoint. Today, we’re sending testers, but then, in the future, we’ll have these robots that will execute these tests based on what they have learned from these human testers.

    And tomorrow is already here for us today because we’re already doing that and a number of our customers are already using these automated AI algorithms. So they just need to write their test cases in plain English and they’ll see the tests executed by robots automatically, without having to worry about building automations or anything like that. So that’s kind of our approach to solve the QA problem.

    Shimel: So Rainforest, the Uber of QA.

    Choy: I don’t know that marketing will approve that line, but –

    Shimel: No, I don’t think _____ _____ –

    Choy: – personally, but, yes. Yes.

    Shimel: It does remind me – you know, when – you’re out in San Francisco, we’ve all been in venture-backed world.

    Choy: That’s right.

    Shimel: There was a period there where every pitch was “We wanna be the Uber of,” right?

    Choy: Yeah. Exactly.

    Shimel: Uber of this or the Uber of that and _____ _____ to be disruption, or crowdsource in this case, but fascinating take on solving an age-old problem.

    Choy: Mm-hmm. Exactly.

    Shimel: Interesting to see. Just – Rainforest is, what, about two-and-a-half years, three years old now?

    Choy: Yeah, it’s just a little bit longer. We’ve been – our total existence, probably about six, seven years. We’ve kinda pivoted a little bit at the beginning, so our current product is about three to four years old.

    Shimel: That’s when I think I first became aware of it.

    Choy: That’s right.

    Shimel: And, look, testing and continuous testing is such a – I mean, it’s a hot area. There’s a lot of different solutions vying in the market, but this one is really kinda unique, so it’ll be interesting to watch how it happens.

    Choy: Yeah.

    Shimel: Derek, as I promised you before we started, the time goes really fast here. We’re way out of time, but, hey, man, I wanna thank you for being a guest on DevOps Chat. And maybe we’ll catch up with you again in the new year and find out how things are going.

    Choy: That will be awesome. Well, thank you, Alan, and have a wonderful holiday to you and everybody listening. And, hopefully, I’ll talk to you again soon.

    Shimel: Absolutely. Derek Choy, CIO still, not CEO, of Rainforest. Thanks for being our guest on DevOps Chat today. Have a great holiday and thanks very much.

    Choy: Thank you. Buh-bye.

    Shimel: Buh-bye. This is Alan Shimel for DevOps.com and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps and Retail: Transforming Brick-and-Mortar to Brick-and-Click

    DevOps and Retail: Transforming Brick-and-Mortar to Brick-and-Click

    Brick-and mortar-retail is rapidly transforming with the digital age. As physical storefronts turn digital, it’s safe to say that traditional retail is quickly becoming a mesh of “brick-and-click.”

    So, how are retail giants surviving in this new landscape? Interestingly enough, the remaining brick-and-mortar retail are reinventing themselves by applying helpful DevOps principles.

    In this post, we’ll peek into cases of innovation and horror stories from historically brick-and-mortar retail chains and brands. From Target, to Balian Group, Sears and other companies, we’ll discover the importance of DevOps in this new brick-and-click multi-channel retail environment.

    Target

    In an effort to increase agility, Target engineering teams embrace something they call “the Dojo”—immersive, six-week training sessions with hands-on DevOps and Agile coaches. As Target CIO Mike McNamara recently told the Enterpriser’s project: “The Dojo has been fantastic in getting teams engaged with agile and DevOps, removing the natural resistance and fear of change, and then supporting the team through the changes while maintaining productivity. It’s been a huge success for Target.”

    The result of these sessions is increased comfort with methods including containerization and tools that enable continuous integration and continuous deployment. McNamara also noted their grassroots approach; they encourage open source activity and listen to their engineers when they petition the use of new tech.

    “Our engineers have fully embraced DevOps,” he said.

    Bailian Group

    For another case study, take Bailian Group, a large Shanghai retailer that operates 6,000 grocery and department stores. By the time Bailian entered the online marketplace, it suffered from a severe lack of agility, non-native web apps and underutilized server assets.

    “Our transition from traditional brick and mortar to omnichannel business presented a great opportunity but an equally large challenge,” noted Lu Qichuan, director of IaaS and Cloud Integration Architecture at the Bailian Group.

    Qichuan and Bailian realized that to stay relevant, they had to cut long development cycles and embrace “new cloud application development tools and processes that foster a CI/CD and DevOps culture and increase innovation and time-to-market,” he said.

    They ended up implementing a private cloud using OpenStack. Now, midway through their cloud transition, they estimate to have 10 million virtual machines by the end of 2020.

    Sears

    While the previous two examples had positive outcomes, digital transformation has not gone over well for other retailers. Sears declared bankruptcy in October 2018.

    In its final years, Sears was in a sticky situation. To the chagrin of former CEO Eddie Lambert, surveys found their customers preferred to shop in stores as opposed to online. Disregarding customer desires, however, Sears attempted a big data play with its “Shop Your Way” program, under which Sears gathered user data to then sell. The program floundered, resulting in consumer irritation and loss of sales as reported by Business Insider.

    Writing for InformationWeek, Emily Johnson reminded us that evaluating DevOps using the wrong metrics will ultimately lead to failure, citing customer satisfaction as the No. 1 goal.

    In its final years, an abrasive Sears leadership halted any sense of DevOps to flourish. A disengaged Sears CEO Lambert created “a climate of fear,” according to Busines Insider reports. It appears the retailers that stay afloat encourage agility and intrapreneurship—this means encouraging innovation, not fear.

    DevOps Aids the New Omnichannel Retail Benchmark

    Brick-and-mortar are evolving into omnichannel retailers that bridge physical and virtual spaces. Take IKEA’s augmented reality app, which visualizes items in a house. From Disney, to Startbucks, Nordstroms and elsewhere, physical storefronts embrace digital offshoots of their core model to augment the traditional retail experience.

    Surprisingly, physical storefronts aren’t completely dead. They still offer conveniences for urban environments with high walking scores. See the emergence of Amazon physical locations for ironic evidence of their benefit. Other storefronts and pop-up shops have taken on a museum-like quality. The flagship Funko store, for example, creates impressive displays and interactive exhibits, pulling in flocks of weekend shoppers that want more than a dull e-commerce shopping cart.

    DevOpsGroup similarly describes a “reverse showrooming” movement; consumers research products online to then purchase in person. This enables brands such as ASOS, which is emphasizing social media and free worldwide deliveries, to stay competitive.

    “Retailers have been forced to re-evaluate their business strategies and understand how new technologies will affect their offering,” according to the DevOpsGroup website.

    DevOps Turns Bricks to Clicks

    Online shopping has sufficiently disrupted retail, and brick-and-mortar must reinvent themselves to stay relevant. An open-minded leadership and a commitment to fast development, dynamic scaling, uncompromised availability and open source technology underpin a successful evolution.

    Of course, this increased reliance on technology necessitates a hardened look at how development and operations communicate, and brick-and-mortar retailers must adopt the behaviors of tech companies to retain agility.

    This may come in many forms: new user-facing digital experiences, microservices for composability in niche omnichannel environments, containerization to package code that scales well, distributed data stores, heightened user data security or smart incident management techniques, to name a few.

    Traditional retailers, then, should dissuade their doubts against agile. DevOps can aid retail by reducing redundancy, cutting costs and streamlining production and distribution.

    — Bill Doerrfeld

  • The Limiting Factors of Microservices Also Apply to FaaS

    The Limiting Factors of Microservices Also Apply to FaaS

    In enterprise development and deployment, the pattern is easy to detect. A big monolithic application is targeted for re-architecting as a microservices architecture. People excited about microservices get together and break up the design to make it far less monolithic and far more loosely coupled.

    If your organization is lucky, it is at this stage that those responsible realize that breaking a monolithic application down too far is bad for complexity, performance, monitoring and maintenance—pretty much everything re-architecting is supposed to fix.

    Far too many organizations don’t realize this until the implementation phase, though. First, a metric ton of little tiny microservices are deployed, then the organization realizes that functionality such as database access can be applied much more efficiently through one larger service that handles all interaction with the database for the app, rather than through five or 10 smaller services that replicate code and end up calling each other anyway.

    Function as a service (FaaS) has much the same issue. It is an astounding solution for some uses, but in the end, users must consider what access the function requires to other parts of the system and what task is being achieved. The early uses of FaaS are well-documented; longer running independent jobs such as image or video processing were a bit early hit, for example, particularly for services that have highly varying traffic rates. But other uses, such as handling bottlenecks in traffic spikes (hello holiday shopping season!) or out-of-band operations processing, are less documented at this point. Entire applications have been designed from the ground up in serverless, but they are relatively few in terms of overall applications out there.

    FaaS is highly suited to DevOps, because upgrading the function is as simple as redeploying code. There are no concerns about OS or library version, because those are largely beyond your control. But that is as big a negative as it is a positive. There is no flexibility in OS version or library inclusion because those are beyond your control—for the most part, anyway.

    As with the vast majority of new technologies, expect adoption of serverless to grow and the hype to grow more quickly. It is definitely in the market where we have seen massive shifts—virtualization and then containers really did live up to the hype in terms of usage—but it needs to have a driving reason for adoption. Look closely at what your application and its DevOps toolchain are doing before hopping into the deep end. For some uses, FaaS is the fastest/easiest/lowest-maintenance solution. But that does not make it the Swiss army knife that virtualization and containers have proven to be. Indeed, if you think persistent storage is painful under containers, try it in a FaaS environment—as just one example.

    FaaS is useful in many scenarios, but just remember where/when/why you are adding FaaS into your DevOps processes, and take advantage of on-demand processing with few scaling limitations while avoiding seeing everything as a FaaS problem because FaaS is the FaD.

    — Don Macvittie

  • Using Trade Studies in Vetting Tool Stacks

    Using Trade Studies in Vetting Tool Stacks

    Adding to your tool stack should entail more thought than, “Start your free trial today!” It’s great when there is an application need and cloud-based tools are easily grabbed with a few clicks. However, surveying alternatives before making a tool stack change can prevent costly mistakes. Trade studies can help vet best-fit tools for evaluation.

    Short for trade-off, trade studies originated in the aerospace industry as a decision-making aid. Teams of engineers (or developers) usually generate multiple proposed technical solutions for any non-trivial problem. A little searching will find the term multiple criteria decision analysis, with three popular techniques: the analytic hierarchy process, the Kepner-Tregoe method and the Pugh method.

    For DevOps teams, I lean toward variants of the Pugh method because it avoids creating an overly complex weighting and scoring scheme. Pugh analysis has gained popularity among Six Sigma aficionados for the same reason. Multi-disciplinary teams find the process easy to understand and the results just as useful as more algebraic methods taking longer and needing more input.

    Let’s look at three steps in a practical approach: setting criteria, ranking best-fits and starting evaluation.

    Setting Trade Study Criteria

    Most tool stack disasters result from discovering a tool doesn’t meet all the requirements as the project unfolds. In my previous life, our IT team went all-in on a big-name ERP application partly because it featured web-based portals for suppliers. My e-business team discovered those portals required specific port numbers be opened at the firewall, which corporate security immediately rejected. We coded a way out, using Adobe ColdFusion querying the database directly and securing it with LDAP sign-on, but it took months.

    You could search for the “information I could have used YESTERDAY” gif or you can spend time setting the right criteria. Pugh analysis starts with a matrix of criteria rows versus candidate tool columns. What most sources won’t tell you about Pugh analysis is a trick in generating that criteria list:

    • Start with must-have features, with current requirements and anticipated future requirements.
    • Research tools (data sheets!) for near-fits against those must-have criteria and create the matrix.
    • Add all the features prominently listed for each of those near-fit tools to the criteria.
    • Search again for more near-fit tools matching features on the extended list, adding to the matrix.

    A common mistake is stopping after the first two bullets. Almost every trade study I’ve done discovers more tools fit the must-have list but didn’t emphasize all those features on their website. It’s a bit time-consuming, because every time you find a feature of interest you must go back and recheck all the other tools on your near-fit list for it.

    Adding non-requirements? You’ll miss innovation opportunities outside the Venn diagram intersection. My recent client study on marketing reporting tools found one touting support for a dream-list feature. Digging into that tool found it may not support two must-have requirements but does support the others.

    Ranking Best-Fits

    That’s why the trade study criteria list should visually differentiate must-haves from extended features. I usually shade the extended feature rows, then plot how near-fit tools stack up against all criteria. You can certainly add weighting to features for a more sophisticated analysis, but I find a simple must-have versus nice-to-have usually suffices.

    Now start scoring. A strict Pugh analysis uses a plus-same-minus scoring system. Plus means the tool has a clear advantage on that feature, same is same, and minus means that tool is at a disadvantage compared to the others. I sometimes simplify that to just X for a tool having the feature, blank for it doesn’t. This is mostly a data sheet comparison, and you may want to inject other information such as found reading reviews.

    What you’ll find is a best-fit list, and it probably won’t be perfect. You’d like to see a couple tools capturing most or all the must-haves, and a few more capturing some of them and extended features for contrast. As an example, here’s the trade study matrix for that marketing reporting tool assessment I mentioned with the vendor names omitted.

    Trade studies provide simpler, faster, actionable analysis

    Starting Evaluation

    Notice this doesn’t have cost information yet. Cost biases technical decisions if applied too early, and feature coverage doesn’t necessarily correlate with cost. Vendors also don’t price their stuff the same way. Some price by developer seats, some by data source integrations, some by monthly tracked users (MTUs) on the web.

    With a best-fit list in hand, it’s time to discuss the findings with your team and add information for evaluation. Confirm the scoring, check the vendor pricing models, ask the vendors about unclear feature support and download those free trials to see how they work. Consider how to cover those uncovered must-have features, or if those even are must-haves if few tools support them. Maybe swapping out another tool in the tool stack gets better coverage. Think about innovation those extended features may enable.

    Want simpler, faster, actionable analysis without a massive RFP? Trade studies do that. I think it’s valuable to have one person on your team be the keeper of trade studies, someone skilled at interviewing for requirements and refereeing debates during evaluation. You may want to bring in a consultant skilled at competitive research and analysis to help develop your process. In any case, adapt your approach until trade studies help you make better selections—there is no one right answer.

    — Don Dingee

  • Today: Predict 2019 Virtual Summit

    Today: Predict 2019 Virtual Summit

    Predict 2019 Virtual Summit is finally here! The summit is happening today, Tuesday, Dec. 18 at 10 a.m. Eastern. Don’t miss the opportunity to hear from Mirco Herring, Rich Mogull, John Willis, Chenxi Wang and other industry luminaries as they offer their DevOps and security predictions for 2019.

    If you have already registered, then go here to join livestream starting at 10 a.m. Can’t make the live event date? No worries! Register for the event, and we’ll send you the replay link after the event. Click here to download the program guide.

    Predict 2019 is a free virtual summit chock full of information and education for DevOps and security professionals presented in a virtual reality environment. It is a true virtual conference, replete with theaters to view the keynotes and presentations, a conference lobby to chat and socialize and a virtual trade show floor with virtual exhibitor stands equipped with video, downloads and even prizes for participation. And did I mention it’s free?

    This year’s event offers up presentations and sessions from the biggest names in DevOps and security, as well as speakers from well-known companies who’ll be sharing what they’ve gleaned from their DevOps and security initiatives.

    Here’s what the virtual format of Predict 2019 has to offer:

    • Complete control and access over every aspect of your digital experience.
    • Live and on-demand viewing from your home or office.
    • Attend and interact using the device of your choice (laptop, smartphone and tablet).
    • Digital downloads and presentations for all the sessions.

    And, perhaps most importantly, you will have unlimited playback post-event for six months! (This is for attendees who register by December 18 only!)

    Predict 2019 is here today, at a computer or mobile device near you. Visit the website for more information or to register for this daylong event. Registration—did we mention it’s free?—also includes access to the event on-demand. To register, click on the image below or this link.Predict 2019 will feature keynotes from a lineup of DevOps and Security IT executives and industry luminaries including:

    • Mirco Hering sharing his predictions for 2019—Will AIOps take over DevOps?
    • Dr. Chenxi Wang shares her predictions on future of cybersecurity in the cloud computing era.
    • Rich Mogull’s offers up DevSecOps Predictions for 2019.
    • John Willis speaks on the on Future of DevOps in 2019 and beyond.

    In addition, Predict 2019 will include a number of featured panels with topics designed to provide even greater value to attendees. Panels include:

    • Making DevOps More Ops-friendly – Charlene O’Hanlon (host), Damon Edwards, John Willis and Andi Mann
    • The Business Value of Value Stream Mapping – Jayne Groll (host), Michael Orzen and Jeff Keyes
    • Ubiquitous Open Source Makes for Security Challenges – Alan Shimel (host), Cindy Blake, Rami Sass and Baruch Sadogursky
    • Cloud Security in 2019 – Tony Bradley (host), Chris Wysopal, Sam Bisbee and Jo Peterson
    • Continuous Testing Equals Quality – Alan Shimel (host), Anand Akela and Lubos Parobek

    Register Today at https://predict2019.com/#join-us

    — saleem