Category: Features

  • Fourth Annual DevOps Dozen Winners Announced

    Fourth Annual DevOps Dozen Winners Announced

    We are pleased to announce the 2018 DevOps Dozen honorees. When I launched the DevOps Dozen, I hoped they would grow to reflect and recognize the best of the best in the maturing DevOps space.

    This year, there is no doubt in my mind that the winners are unsurpassed in the DevOps community. In fact, the whole process of nominations was open; from the the public making the selections of finalists; the judges and the criteria they used, it really does represent our best efforts.

    Congratulations to each and every one of the winners in the 12 categories. It is quite an accomplishment to make it this far into the process. But congratulations not only to the honorees—all of the finalists should be proud to be part of such an impressive list.

    Since the nomination process was opened, our team has gone through thousands of votes to pick out the finalists in each category. It was not an easy task, as we couldn’t automate (DevOps) it; we had to do it by hand. Also, many thanks to the judges for making the hard calls and thanks to everyone here at DevOps.com for helping out.

    So, without further ado, here are the 2018 DevOps Dozen winners:

    Best DevOps Open Source Project

    Jenkins X is the winner of the Best DevOps Open Source Project for 2018. Jenkins X enables developers to take advantage of Kubernetes to develop cloud-native applications without having to learn the intricacies of Kubernetes. Developers can quickly establish CD best practices and cloud development by using the Jenkins X guided workflow that takes full advantage of GitOps, or environments managed as code. The power of GitOps allows developers to easily define, manage, deploy and scale environments with full history and traceability. Jenkins X leverages and packages many other open source projects of the Cloud Native Computing Foundation community around Kubernetes such as Knative, Helm, Prometheus and Vault, providing automatic integration with them and saving users the trouble of integrating all of these components themselves.
    Learn more: https://jenkins-x.io/

    Best DevOps Commercial Solution

    JFrog Artifactory from JFrog is the winner of the Best DevOps Commercial Solution for 2018. JFrog Artifactory is the world’s only universal repository manager, with more than 5 million developers worldwide supporting development organizations across more than 4,500 global enterprises, and supporting all major packaging formats (more than 25), build tools and CI server. In 2018, JFrog Artifactory also won an Innovator award from IDC and the Firestarter award from 451 Research. Artifactory integrates with your existing ecosystem, supporting end-to-end binary management that overcomes the complexity of working with different software package management systems, and provides consistency to your CI/CD workflow. Artifactory is available in OSS and commercial versions, supporting hybrid development and deployment across the enterprise. Learn more: https://jfrog.com/artifactory/features/

    Best DevOps Solution Provider Executive

    The voting in this category actually resulted in a tie between two of the leading CEOs in the DevOps space. Sacha Labourey is the CEO and founder of CloudBees, the company powering the continuous economy by building the world’s first end-to-end system for automating software delivery. Sacha is also a member of the board of advisors and an investor at Codenvy (formerly eXo Platform), as well as a board member and investor at Wallix. He is praised as being a visionary with a strong understanding of technology and business. Sacha is experienced in open source, cloud computing, software development and more.

    Shlomi Ben Haim is co-founder and CEO of JFrog. He brings more than 20 years of experience in building profitable, high-growth information technology companies. Shlomi is a recognized visionary in the DevOps space, having now guided a company from its inception with just three co-founders (along with Yoav Landman and Fred Simon) to a privately held, global DevOps company with a billion-dollar valuation. With the releases of JFrog Xray and the JFrog EnterprisePlus platform in the last two years, Shlomi continues to foresee market dynamics and push JFrog forward to deliver next-generation solutions.

    Best DevOps Solution Provider

    Electric Cloud was recognized for the third year in a row by Gartner as the leading solution in Application Release Orchestration, scoring highest in three out of three use cases in Gartner’s 2018 critical capabilities for application release orchestration. In Q4, 2018, Forrester ranked Electric Cloud as a leader in the newly released report, “The Forrester Wave™: Continuous Delivery and Release Automation (CDRA).” Additionally, ElectricFlow has been selected by EMA Research as a Top 3 enterprise software product in its new report, “EMA Top 3 Enterprise Decision Guide for Artificial Intelligence (AI) and Machine Learning (ML).” The report provides pragmatic guidance to enterprises on how to optimally benefit from AI and ML and continuously release better software. Electric Cloud is also the founding partner of DevOps Enterprise Summit USA.

    Most Innovative DevOps Solution of the Year

    CA Brightside is the winner of the Most Innovative DevOps Solution for 2018. CA Brightside is the first cross-enterprise DevOps solution designed to greatly improve the productivity and efficiency of development teams to control, script and develop for the mainframe like any other cloud platform. CA Brightside is also a foundational element of the Open Mainframe Project’s Zowe initiative, the first open source project for the mainframe which strives to attract a new generation of IT administrators to mainframe platforms and make it easier to include mainframes within the larger scope of an integrated set of DevOps processes that span multiple platforms. CA Brightside is designed to make it easy to integrate the mainframe into enterprise DevOps workflows by allowing development teams to control, script and build for the mainframe just like they would for any other cloud platform through the use of familiar open source tools such as Jenkins, Gradle and IntelliJ via a command line interface (CLI). Learn more: https://www.ca.com/us/products/ca-brightside.html

    Best DevOps Evangelist

    Chris O’Malley, Compuware’s president and CEO, is the Top DevOps Evangelist for 2018. Chris is a highly vocal, incredibly passionate evangelist for DevOps and, more specifically, Agile and DevOps on the mainframe. Having led the Agile transformation at Compuware, he speaks from the heart. No other executive in the industry comes close to exhibiting the energy Chris brings to every engagement, whether it’s a customer meeting or a LinkedIn update. Chris is unwavering in his commitment to make Compuware customers successful and believes DevOps on the mainframe plays a critical role in facilitating that success. Since late 2014, Chris has spearheaded an effort to educate the marketplace on the benefits of DevOps and Agile on the mainframe, as well as create a new generation of mainframe software that speeds this effort. Chris’ extensive media coverage and social outreach in 2018, included more than 25 articles, blogs, interviews, podcasts and conference presentations. Check out a few of his recent posts on ZDnet, Forbes, InformationWeek, eWeek, DevOps.com Chat, AgileCXO and DevOps Enterprise Summit, as well as more than a dozen LinkedIn posts in 2018.

    Best DevOps Transformation

    capital oneCapital One was the judges’ choice for Best DevOps Transformation for 2018. As one of the most well-known brands in America and among the top 10 largest banks in the nation based on deposits, Capital One offers a wide range of financial products and services to commercial clients, small businesses and individual consumers, both online and in-person at branch locations. The company was founded on the vision that the power of information, technology and testing could be harnessed to bring highly-customized financial products directly to consumers. The thousands of software engineers, testers and other professionals in the Capital One software development organization are making this vision a reality. Beyond their financial success and size, Capital One has a well-known and well-deserved reputation in the tech industry for being one of the most innovative and open source-friendly enterprises in the market.

    Checkout this Case Study: Capital One Invests in Continuous Delivery to Automate Software Development Pipelines

    Best DevOps Transformation Leader


    George Swan is the winner of the Best DevOps Transformation Leader for 2018. George is director of Engineering Solutions at Autodesk, where his responsibilities include modernizing and optimizing Autodesk’s development and deployment capabilities using CI/CD solutions and best practices. George spearheaded the Engineering Solutions team tasked with modernizing the development and deployment solution based on CI/CD methodologies. The team built a source code solution using GitHub Enterprise and a binary management solution using Artifactory. Next, Autodesk standardized on CloudBees Core for orchestration and began implementing secure, automated Jenkins Pipelines. These pipelines enabled both continuous integration and more frequent deployments with shorter lead times via continuous delivery. Swan and his team delivered amazing results: “Productivity increased up to 10X. There is a team within Autodesk that saw a 10X improvement in productivity when they adopted CI/CD. If we can replicate even a fraction of this across the engineering organization, that will have an incredible impact.”

    Checkout this Case Study: Autodesk Powers Cloud Initiative and Faster Releases with CI/CD

    Best New DevOps Solution Company

    ShiftLeft Inc., winner of the Best New DevOps Solutions Company in 2018, is an innovator in application-specific cloud security, delivering the industry’s first fully automated security-as-a-service (SECaaS) solution that understands the unique security needs of each version of each application and creates custom security and threat detection for it. With ShiftLeft, DevOps can make threat detection part of their CI/CD process. ShiftLeft’s approach allows teams to both protect their applications immediately and enhance the security posture of their code. The company was founded by a team with extensive backgrounds in security and cloud infrastructure who were early innovators of technologies such as sandbox, next-generation firewall, next-generation electronic payment network and fraud modeling, as well as several open source initiatives. Headquartered in Santa Clara, Calif., ShiftLeft is backed by Bain Capital Ventures and Mayfield. For more information, see https://www.shiftleft.io/.

    Best DevOps Book/eBook

    “DevOps for the Modern Enterprise,” by Mirco Hering of Accenture, won the Best DevOps Book Award for 2018. In his book, Mirco, a thought leader in managing IT within legacy organizations, lays out a road map to success for IT managers, showing them how to create the right ecosystem, how to empower people to bring their best to work every day and how to put the right technology in the driver’s seat to propel their organization to success. But just having the right methods and tools will not magically transform an organization; the cultural change that is the most difficult is also the most impactful. Using principles from Agile, Lean and DevOps, as well as first-hand examples from the enterprise world, Mirco addresses the different challenges that legacy organizations face as they transform into modern IT departments. Mirco’s book is also featured by BookAuthority in the list of “26 Best New DevOps Books to Read in 2019.”  View on Amazon.

    Best DevOps Presentation of the Year

    “Project to Product: Practical Realities at a Large Scale Enterprise,” a 30-minute presentation at DevOps Enterprise Summit London 2018, is the winner of the Best DevOps Presentation for 2018. The presentation featured Carmen DeArdo, currently working as senior VSM strategist at Tasktop, and Nicole Bryan, vice president of Product at Tasktop. Carmen DeArdo was the DevOps technology director at Nationwide Insurance, where he was part of the leadership team implementing DevOps practices and technologies across the 20+ IT areas at Nationwide. He is considered a DevOps industry leader, speaking at conferences and writing regularly on these topics at DevOps.com. He is also regularly interviewed by analysts (e.g. Forrester) and technical publications such as TechBeacon for research and articles. He has presented at previous DOES U.S. conferences. Check out Carmen’s Reflections from DevOps Enterprise Summit 2018 as well.

    Nicole has more than 20 years of experience in software and product development, focused primarily on bringing data visualization/infographics and human factors considerations to the forefront of Agile and DevOps. She is passionate about increasing representation of women in technology and improving how software is created and delivered—making the experience enjoyable, fun and even delightful.

    Best DevOps.com Article of the Year

    “Continuous Discussions, Episode 90: Gene Kim and DOES18 Speakers,” by Anders Wallgren won the Best DevOps.com Article of the Year Award for 2018. Anders hosted Gene Kim and several speakers from the upcoming DevOps Enterprise Summit Las Vegas (DOES18) conference to talk about DevOps, the conference program and emerging conference theme of next-gen operations and infrastructure.

    The panel of DOES18 speakers included Cornelia Davis, senior director of technology at Pivotal; Damon Edwards, co-founder and Chief Product Officer of Rundeck; Mik Kersten, CEO of Tasktop; Tom Limoncelli, SRE at StackOverflow.com; Gene Kim, founder of IT Revolution and co-author of “The DevOps Handbook,” “The Phoenix Project” and “Accelerate”; and Electric Cloud’s Sam Fell and Anders Wallgren.

    Check out the blog to find out the top takeaways from their discussion.

    Thanks to everyone who voted and nominated candidates. Stay tuned for 2019 DevOps Dozen and, as always, thanks for supporting DevOps.com and the rest of the MediaOps family of communities. If you have questions, please write us DD@devops.com.

    — Alan Shimel

  • Edge Computing: Saving the Cloud from Ephemeral Data

    Edge Computing: Saving the Cloud from Ephemeral Data

    Edge computing is rapidly gaining momentum. Last week’s Linux Foundation news on the launch of LF Edge is one more sign of accelerating growth at the edge. What’s driving this sudden intense interest? It’s more than just the sheer number of edge devices or mounting concerns around interoperability and security. Pushing compute resources closer to the edge can save the cloud and networks from waves of ephemeral data.

    The concept of edge computing certainly isn’t new. In years BC (“before connectivity”), there were plenty of edge computing boxes. These featured single-board computers designed to specifications such as VMEbus, STDbus, PC/104, CompactPCI, AdvancedTCA and many others. Processing happened at the edge as data arrived. Ethernet connections made administration and results-sharing easier, but very few architectures relied on shipping all the data into the network.

    Of course, there was one big exception: a business model pulling all the data into the network. Telecom providers aggregated traffic from the edge into their core networks. As data traffic joined voice traffic, core networks grew with monstrous bandwidth and increased services. Core networks interconnected. Data traffic rose even faster, pushing the network into a cloud architecture. In years AD (“after distribution”), everything from the edge is now connecting to the cloud.

    Much of the increase in data traffic came from the shift to video content. Users expect higher resolution video programming with the same lag-free performance. Streaming networks and quality of service (QoS) implementations have made great strides in content delivery. 5G infrastructure rollouts in progress will keep mobile a strong downstream contender.

    What about upstream applications such as the IoT? Nearly the same terminology applies there. Devices gather data on the edge and transmit it to the cloud through a gateway. There are two key differences with most IoT applications, however. Real-time data may be lost if the streaming connection into the cloud is interrupted. Also, the fallacy of low bandwidth does not work at scale if all the data is transmitted. At some point—perhaps ten thousand, a hundred thousand, or a million or more sensors—an aggregate bandwidth problem develops.

    Just as in the BC age, it’s time to rethink shipping all that IoT data upstream, instead taking steps at the edge. Cisco Systems has studied data trends extensively, producing its white paper, “Cisco Global Cloud Index: Forecast and Methodology, 2016-2021.” The company points to the IoT ushering in the “yottabyte era” very soon. Cisco estimates that 220ZB of data was generated in 2016 and projects that by 2021, there will be nearly 850ZB from people, machines and things combined.

    Now for the interesting part: Cisco also estimates that as much as 90 percent of that data is ephemeral, short-lived data not useful to save. Even if only 10 percent of data is useful, it will swamp projected data center traffic by an estimated factor of four in 2021. Here’s Figure 24 from the Cisco white paper:

    Edge computing, or its close cousin fog computing, allows two things to happen: It can pre-process ingested data, ironing out protocols and format differences such that everything arriving at the cloud is immediately ready for algorithms. Any savings in the cloud from not shuffling data before computation are valuable, increasing processing and network bandwidth availability. Parts of an algorithm could easily be farmed out toward the edge, perhaps decimating or filtering data before shipping it upstream for heavy analysis.

    A bigger use for edge computing may be using algorithms to avoid shipping ephemeral data upstream altogether. Using generative models at the edge could make a huge difference in identifying useful data. Most of us have heard that no human can sit and watch hours and hours of surveillance video from multiple sources looking for one moment of a problem developing. Consider another example with an EKG monitor attached to a smartphone: While the patient is at home, at rest and unstressed, the EKG is in a perfectly normal range as learned by the application. Doctors are alerted when readings slip out of normal range, with raw data transmitted for observation if required. A similar example is waiting for a motor to fail while monitoring its operation.

    Both the LF Edge initiative and work happening in the OpenFog Consortium are creating specifications for edge computing. These initiatives are aimed at interoperable, secure architectures where cooperative processing mines data. If items of interest can be extracted efficiently from useful and ephemeral data at the edge, loads on the cloud and networks would be lighter. Edge computing will likely detect exceptions more quickly, bringing people in to look at what is going on faster. The result will be more scalable IoT applications with better chances of delivering value from all that data.

    — Don Dingee

  • DevOps Chat: Cloud Migration with nClouds’ JT Giri

    DevOps Chat: Cloud Migration with nClouds’ JT Giri

    Moving to the cloud is becoming a must for many companies if they want to grow beyond their current footprint and be more innovative. But for many companies—especially those in the SMB space—their transition to the cloud is hindered by a lack of knowledge and experience, which often results in difficult migrations that sometimes just aren’t successful.

    Since its inception, nClouds has helped organizations of all sizes move to the cloud successfully. Its experience as an AWS Premier consulting partner and its well-architected approach to cloud migration helps companies get the most from their infrastructure by engaging with the cloud, whether they’re adopting a hybrid environment or going all in on cloud.

    In this DevOps Chat, JT Giri, nClouds founder and CEO, and I speak about the triggers that push companies to adopt cloud, some issues companies face in their decision-making and infrastructure’s role in an increasingly cloud-based IT world.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat, or in this case, perhaps, watching a DevOps video. Happy to be joined here by my friend J.T. Giri, who is the CEO and founder of nClouds. J.T., welcome.

    J.T. Giri: Hey—good morning, Alan. Thanks for having me.

    Shimel: My pleasure, nice to have you here. J.T., let’s first of all say Merry Christmas, happy new year.

    Giri: Thank you, and you.

    Shimel: Yeah, it’s been an exciting—we were talking off camera, off mic—it’s been an exciting quarter for you. You’re a new time dad and moving homes and at the same time, nClouds’ business seems to be just booming along with everything else associated with Amazon Web Services and the cloud. So, congratulations.

    Giri: Thank you. Exciting times.

    Shimel: Yeah, it is. So, J.T., I wanted to talk a little bit about—you know, there’s people listening to this or watching this who are saying, “You know, I wanna be like Google,” or, “I wanna be Facebook” or, “I wanna be one of these unicorns in that I wanna harness the cloud. You know, we have our servers in a closet here or a data center or a third-party data center, but we’re not really cloud. And everything seems to be in the cloud. We wanna move to the cloud, but you know, we’re only maybe 250, 500 employees. How do we do that, right? Do we need a helper, like an nClouds. Do we need to update everything? Do we throw out the baby with the bath water and start new?”

    I want you to tell us a little bit, sort of, what’s the typical sort of customer journeys that you see when you guys engage?

    Giri: Yeah, absolutely. So, Alan, you know, we’ve talked in the past. I’ve been migrating companies to AWS ever since EC2 was in beta. And, as I would migrate these companies, people would realize that they need someone to manage it, right? So, that’s how, sort of, nClouds came to be. And as you mentioned, this has been an incredible year for us. We doubled the size and revenue and the number of people.

    What we were seeing in an SMB type of market, when companies migrate or when they try to migrate to AWS, they still need to follow—obviously, they need to follow best practices because cloud or AWS is constantly changing, and the skill set is just not there. So, that’s where we come in play. We can make sure that your infrastructure is well-architected. We take an approach of migrating in a way where you’re really taking advantage of the cloud—so, for example, using containers, things that are really gonna help you to harness the power of cloud. And then, for most of our customers, you know, we’re providing 24/7 support. And when we see people try to do this themselves, they get a bad taste of cloud. They’re like, “Oh, this is not for us. We’re not really innovating fast.”

    So, that’s why, Alan, we’ve been very successful, because there is a huge gap in SMB type of companies. There is a skill gap and just experience. We bring that to the table, and it’s been incredible. We’re able to add a lot of value.

    Shimel: Sure. So, J.T., early on there, you said something about when an organization needs someone to help them manage their cloud migration—when does an organization recognize that they need someone to help them? What’s sort of a trigger point? You know, as, again, we spoke off camera a little bit—is it when someone dives in the pool and says, “Oh, my God, I can’t swim, it’s too deep?” Or is it, before you dive in the pool, a prudent person hires a swim coach, you know what I mean?

    What are sort of the trigger things that people should see as a red flag or as a trigger event that says, “Hey, man, I should be getting some help, here”?

    Giri: Yeah, that’s a great question. So, basically, it depends when the companies come to that realization that we need some outside help, right? Sometimes, it is that they will try to do the project themselves, or in other cases, they realize that they really want to just focus on delivering value to their customer, right? They really wanna just innovate fast.

    So—and they see how they can just stay focused on that, and that’s something we do incredibly well. We have a build—we build systems and processes together where our key focus is to make sure the customer can deliver value to their customers fast and we want to make sure the infrastructure is not getting in their way.

    So, you know, it’s just, this is becoming more and more popular, like, DevOps as a service, where companies are reaching out to partners like nClouds to help them with DevOps related tasks, like, with the migration, setting up CI/CD pipeline, becoming an extension to their team, so they can focus on their core business, right? And, you know, it really depends when they—sometimes, they come to that realization pretty fast, or sometimes they try to do things themselves, and when things don’t work out, they try to use someone like nClouds.

    Shimel: So, J.T., generally, one of the hardest things in life is learning when to ask for help.

    Giri: Right.

    Shimel: And that includes cloud migrations and everything else. At the SMB level, mid-enterprise level, you don’t have an elaborate or as big a structure as, let’s say, you do with a large enterprise where you have layers and layers of management and hierarchy—a lot of the organizations you deal with are rather flat in their management structure.

    So, who is it in the organization who finally kinda raises his hand and says, “Wait a second, I think we should engage in some professional help, right? I think we should being in some experts to help us.” Is it the CEO, CIO, someone lower than that? What’s your experience?

    Shimel: Yes, normally, CTO, VP of Engineering type of person. And also, you know, as you know, we became a premier partner with AWS last year. So, AWS is—Amazon, it’s no secret that they’re very customer obsessed. So, they will—Amazon, when they’re speaking to a customer and if they see the customer is struggling, they will introduce someone like nClouds to help them out with the migration or just modernize their infrastructure. And sometimes, you know—actually, many times, they can come in with funding where they will offset some of the costs.

    So, for a customer, it’s just like a no-brainer to see if we can have some external experts come in and fix up the infrastructure or streamline the infrastructure. So, you know, the conversation, normally, we do get a lot of business directly from people reaching out, like, “Hey, we need DevOps help,” but we also get a lot of business directly from AWS where they identify this customer needs help, and we get involved that way.

    Shimel: So, I’m just gonna bring up two questions. The first one is on track with what we’re talking about. So, now the CTO or CIO or an executive says, “Yeah, we’re gonna bring in nClouds,” whether AWS referred it or is partially subsidizing it or what have you, but, “We’re gonna bring in nClouds or some other type of help”—is there any sort of pushback or resistance normally with, you know, when you’re dealing with people? The—not first responders, but the individual contributors who feel like, “Hey, man, I don’t wanna be replaced. I don’t wanna be outsourced. I don’t want to give up my cheese to some outside company who’s helping us” or, if so, how do you overcome that? How do you work with an organization like that?

    Giri: Yeah, so, normally, there’s not a pushback, Alan. So, I was actually re-reading “The Venus Project” yesterday, and I was just reading the story of Brent, right?

    Shimel: Mm-hmm.

    Giri: So, when you’re talking to these customers, some of these guys are on their honeymoon with their pager with them, right? And then, when you’re coming in and you’re saying, “Hey, we’re gonna help you out with 24/7 support so you can get your life back” or, you know, “We’re gonna help you to streamline this DevOps work which you never really got the opportunity or time to work on, we’re gonna help you out with that,” right? And it’s incredible.

    Sometimes, maybe the initial impression might be the same as you describe, like, “Hey, are you gonna take my job?” But as they understand the value, they normally are super happy. And another thing we do, Alan, in most of our engagements, we do this assessment called architected assessment where we’re coming in and we’re just reviewing your infrastructure to see how well you’re architected, and after that assessment, we give you, like, a roadmap, like, what are some things you should focus on the first month, and what are some things you should focus on short term and long term? And the assessment goes over cost, security, reliability, performance, and operation excellence.

    So, you know, we can get, in the short-term road map, we can show some quick wins where the customer sees the value and they also get confident in our ability, so that’s sort of the path that works really well for us right now.

    Shimel: Got it. J.T., another thing you mentioned is that nClouds is a premier Amazon partner. And, you know, in today’s world, we throw out platinum and gold and these sort of levels all the time—but really, within the Amazon hierarchy, a premier partner has sort of, they don’t hand that out like candy. Talk to us a little bit about what’s entailed in being an Amazon premier partner.

    Giri: Yes. It’s a top tier status with AWS and in order to get there, like you said, there is only 25 premier partners in North America, and you have to show case studies, you have to show the training path of your employees, and you also have to have multiple competencies, like, we have DevOps competency, we have migration competency, and we’re also the well-architected partner.

    And it’s just very subjective. You know, if you work closely with Amazon, even if you hit all the check boxes, they want to make sure that quality is there for premier partners. So, they look how you work well with your customer, what does your customer experience looks like, because that’s what Amazon cares about that as well.

    So, you know, it’s just very hard to get to this status, and we’re honored to be at this level right now. This is great.

    Shimel: Yep. So, J.T., let me go next kind of where I want to take this, and that’s—you know, two or three years ago, migrating a company onto an AWS, or it doesn’t have to be AWS, migrating a company onto the cloud, you know, you set up some virtual instances, maybe they had some separate storage, stuff like that, EC2 kinda stuff. But, you know, I just got back from Seattle a couple weeks ago from KubeCon and CloudNativeCon—Reinvent was the week before that. And certainly, Kubernetes and containers are kind of really quickly, quickly, quickly changing the landscape, here.

    You know, are you seeing that as well? And what does that mean for—typically, SMB businesses are not leading edge or bleeding edge, right in [Cross talk] option?

    Giri: Yeah.

    Shimel: What are you guys seeing?

    Giri: Yeah. You know, it’s very interesting. Who would’ve thought that the infrastructure we built a couple years ago would be considered a legacy infrastructure, you know? People using EC2 instances and an auto scaling group in Amazon’s world will kinda be called outdated right now.

    So, we’re seeing incredible push and a lot of sort of initiatives on our customer side where they wanna go containers, pretty much like 90 percent of our engagements are around containers. Because it’s a no brainer, right? It makes the CI/CD pipeline much easier. You know, most of the time, containers are automatically integrated with scaling, so you can really binpack your resources, it has impact on your cost. So, you know, this is just—it just makes the infrastructure far more streamlined and far more easier to manage.

    And as I mentioned, Alan, I’ve been migrating companies to Amazon and EC2 from the last 10 years, and I’ve been managing infrastructure as long as I’ve been migrating. So, it’s just, when I’m building infrastructure right now, it’s a no-brainer to build something using Kubernetes or on AWS we use EKS or—you know, depending on what the customer wants to do, and we had a customer the other day where they were saying, “I just wanna focus on delivering product to our customers, so what is the easiest way?” We use Fargate for them. Depending on the customer requirement, we’ll go Kubernetes, but long story short, it just makes a lot of sense these days to build infrastructure on containers, because they really streamline how you manage it in the long run. It just makes life easier.

    Shimel: And that’s even at the SMB level?

    Giri: Oh, absolutely, yeah. I mean, because the needs are the same. You need CI/CD pipeline, you need a way for you to scale infrastructure, you need a way for you to run batch or cron job type of jobs. And when you go with something like containers, you get there—like, you know, you don’t have to build home grown tools to facilitate these things. You know, containers or EKS or Kubernetes, they allow versioning when you’re deployed or auto scaling is sort of built in, you know, you can schedule batch jobs.

    Just, it’s a no-brainer, you know? If you’re building out infrastructure, you should definitely explore containers each time, and that’s what we try to do every time. And it’s just incredible, the amount of success we’ve had before and after.

    Shimel: Sure. So, as we sit here at the dawn of a new year, if I would’ve asked you in early 2018, do you think Kubernetes and containers would be one of the major stories of the year, I don’t know if you would’ve said yes or no. But as we sit here in the dawn of 2019 and we project ahead—let’s say I interview you and everything’s all well and at the end of next year, the end of this coming year, 2019, we sit down and talk about, “Well, what’s 2019 really show?”—what do you think are the big stories this year, J.T.? What do you think, coming down the pike, especially—I’m not talking about the world view. For nClouds and for your customer base, what do you think is really big for you in the coming year?

    Giri: Yeah, so, I think in general, the application modernization will continue. We continue to see that trend, and this is also going to be big in SMB. So, we will continue to double down on AWS. It’s been an amazing partner. Our core values, our partnership is based on shared goals, so we’ll continue to kinda double down on that relationship.

    And we’ll continue to utilize this well-architected framework. It helps us to assess the customers when we’re onboarding and it helps us to manage the customer, like, every time the customers were managing, we continued to run a well-architected assessment to make sure they’re well-architected, and they continue to stay well-architected.

    And, yeah, I mean, just continue to focus on SMB, AWS, continue to align with well-architected framework. We also just spun off another company, it’s called nOps, and basically, it just helps to make sure the customers are well aligned with well architected framework, and it’s available on AWS Marketplace. So, we’ll continue to invest in that, because that solution has been incredible, nOps. A lot of our customers are seeing value in that, so, we are actually working with Amazon to give that solution to other partners like nClouds who can use it to manage their infrastructure to make sure the infrastructure is well architected, and we are also offering it to end customers who can use that tool to assess their infrastructure and continuously stay in compliance with well-architected framework.

    Shimel: Excellent. You know, nOps, that’s something we’ll have to discuss on our next chat, J.T.

    Giri: Yeah, absolutely.

    Shimel: Well, you know what? We’ve been on almost a half hour here, so, unfortunately we’re about out of time for this one. J.T. Giri, CEO and founder of nClouds, thanks for being our guest on DevOps Chat.

    Giri: Thank you so much for having me.

    Shimel: My pleasure. Best of luck to nClouds this year, best of luck to you personally with your family and everything else, you know, it’s gonna be a busy year for you, my friend.

    Giri: Absolutely. Thank you. Thank you.

    Shimel: Alright. Hey, J.T. Giri, nClouds—you’re here with Alan Shimel on DevOps Chat. You’ve just listened to another chat. Bye bye, everyone.

    — Alan Shimel

  • APIs and DevOps

    APIs and DevOps

    As always, there are interesting trends in DevOps, and I wanted to point out one that is starting to bother me: the “API economy,” and how it impacts DevOps decision-makers.

    Traditional infrastructure—SAN, LAN, physical systems, etc.—were generally controlled the best from the command line. While there are a million of them, Cisco IOS is probably the one that you’ll remember best (or you stopped using to read this—just depends upon the shop). When large-scale automation started, these command lines became a bit problematic. After all, scripting was possible, but painful, and often had non-portable hardcoded values.

    Virtualization, and later cloud—and even later SDN and NFV—all made this better, but on a layer over the top of (and normally not well integrated with) the physical layer. Years ago I bemoaned that we had doubled the workload of operations by re-implementing what was already implemented at the physical layer. So we were configuring the physical—even for cloud you have to get to the cloud—and then configuring the virtual.

    Then “Software Devs as Kingmakers” came along, followed by “the API Economy,” and finally we started to see some serious attention paid to APIs by infrastructure vendors that should have done so long ago (some former employers of mine might belong in this group).

    Here is the thing: There is a difference between having an API and having an API that is useful. When shopping for solutions, be they physical or software, don’t allow APIs to be a check box because it’s “the API Economy.” And don’t assume that an API useful to DEVops is what is needed to automate infrastructure. Monitoring APIs—particularly ones that provide you detailed information about an app as it runs—are useful to DEVops, and assuming you have tools that are or can be integrated, might provide value to devOPS.

    But monitoring is not management. devOPS is increasingly automated, and increasingly needs viable APIs that can help them deploy/configure infrastructure. Vendors are responding, but the quality of APIs at this point in time varies widely. So make certain that evaluation looks at APIs available with an eye to suitability to task. devOPS needs management and might be able to use monitoring, while DEVops generally needs monitoring and has little use for management.

    This is not 100% true of course, there are a billion different shops, most doing things in slightly different ways, but think of storage (because it can be done in few enough words to fit in a blog)… An app needs access to storage, ways to be notified of storage space limitations, and possibly to metadata. Operations needs to provision, migrate, backup, replicate… The list goes on. These all contribute to the availability and quality of the application, and are all DevOps, but the focus is different. And having a simple “number of blocks free” API will not help with the DevOPS needs even if it helps developers manage a piece of the application.

    But we have more options than we ever did before! So fear not, just watch what your prospective vendors are doing, and check in with long-term vendors on occasion, too—because things are constantly changing, nearly always improving.

    And keep rocking it. Presumably you are working this out already, knowingly or not, or you wouldn’t have time to read this blog.

    — Don Macvittie

  • IoT, Not People, Now the Weakest Link in Security

    IoT, Not People, Now the Weakest Link in Security

    Do a quick search on “people weakest link” and you’ll see a raft of articles in which cybersecurity experts and computer scientists point to employees or end users as the biggest vulnerability. No doubt, people do silly (or outright abusive) stuff and open the door for a variety of enterprise security problems. Spoiler alert: There’s this technology called the Internet of Things (IoT) and it’s a bigger security risk than people ever were. The new theme of this rapidly changing IoT security story is data integrity.

    Increased cybersecurity risk is due in part to the variety of environments IoT applications touch. Most at-scale IoT deployments use some form of a three-tier architecture, with edge, gateway and cloud components.

    • Edge devices are those connected sensors and actuators touching the real world. They are usually small, low-power devices often running a wireless protocol such as Bluetooth, Thread, ZigBee, Z-Wave, sub-GHz, low power wide area (LPWA) networks, cellular IoT technology, Wi-Fi or other protocol.
    • Gateway devices are hubs that groups of sensors connect with. One big role of the gateway is to translate the various protocols from edge devices into Internet Protocol (IP) for transmission into an enterprise network. Gateways also perform a key role in provisioning edge devices securely. Smartphones running Android or iOS often serve as a gateway for consumer IoT devices. For industrial IoT devices, multiprotocol gateways typically are built on a small form factor computer running a real-time operating system or Linux. Edge computing or fog computing architectures use enhanced gateways for more algorithm processing.
    • Cloud platforms are very familiar to most enterprise developers. In IoT apps, data from the edge arrives for processing, storage and presentation. Algorithms can run on a server cluster or in a distributed computing framework such as Hadoop or Apache Spark. Business intelligence and predictive and prescriptive analytics also reside in the cloud.

    In our practice, we see many IoT cybersecurity issues that can be mitigated with proper attention to two areas. The first is shutting down simplistic endpoint attacks by using basic connected device security measures. Avoid edge devices that ship with a well-known default password or PIN—compromising those defaults can be as easy as a battery pull and a factory reset. If a device uses encryption, make sure it doesn’t use a hardcoded key that, if cracked, compromises an entire family. Look for edge devices using over-the-air (OTA) programming allowing for security updates over a long life cycle. As more device developers gain IoT security experience and provide the right features, closing these basic weakest links is easy.

    Now, for the more startling weakest link. When the IoT application runs, is the data any good? According to a just-released survey of 950 IT and business decision-makers, only about 48 percent of companies are confident they can detect an IoT security breach. (BTW, don’t get me started on blockchain; it’s one tool, not a panacea.) A lot can happen before your people get involved. By then, it may be too late.

    Data integrity needs constant monitoring during at-scale IoT deployment, not just during pilot. An easy way into an unprotected IoT network is to add an unauthorized edge device at a gateway, then use it to access other devices. Gaps in end-to-end encryption are also easy exploits. Untrustworthy public cloud elements are also bad news—a big reason we recommend hybrid cloud architecture. A private cloud layer gives you more control over algorithm performance and data stream security. Presentation and archiving can be left to a public cloud layer.

    Bad data can come from either a compromised or faulty device. It propagates quickly across a system, and when an unwitting user at the presentation layer runs a business intelligence tool on it, the bad data could cause issues. How do teams hunt down vulnerabilities and faults that lead to corrupted data and results?

    • Hire a penetration tester, preferably a contractor removed from your day-to-day development who can objectively assess your architecture during pilot and reassess it during deployment.
    • Ensure your architecture can tolerate edge device or gateway failures without ripple effects in algorithms; in other words, protect the application from prolonged operation on bad data streams.
    • Before turning AI loose on automated decision-making, consider an AI-based IoT security analytics tool to spot anomalies and quickly bring people into the loop.
    • Retarget at least part of your cybersecurity experts to ongoing data integrity efforts and help them stay abreast of IoT technology and trends.

    This all sounds like a good job for DevOps, doesn’t it? You know what to do about people; now you’ll need to work magic with devices. The long-held security axiom that people are the weakest link is no longer true when IoT applications run unattended all the way to presentation. There are a few exceptions when people have more interaction at the edge, particularly in the medical device arena. Generally, we’ll see bigger and bigger IoT applications with more data, more processing and less interaction with people.

    If someone on the IoT says there’s a security hole you can drive a truck through, they may mean it literally. Data integrity measures will be critical for DevOps teams moving forward. Do you agree? What types of data integrity issues are you seeing in IoT applications?

    — Don Dingee

  • 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