Category: Features

  • Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners Bridges Global Gaps for DevOps

    Salvador Partners works on a global scale to help its customers grow their business. The company, which has its own set of products, also focuses on assisting startups in making their vision reality. Indeed, it bills itself as “experts at innovation and exploiting innovation.”

    The company started life as a subcontracted electronic components manufacturing company, slowly broadening its lineup to include security products and patents and evolving to become a provider of technology for banking, financial services (fintech), defense and mechanical systems, says Lewis Daniels, founder of Salvador Partners. The company also serves as an incubator and capital arm for new technologies.

    Salvador builds circuit boards and technology products, working across artificial intelligence (AI), augmented reality and blockchain technology, together with its other endeavors. Across its projects, wherever software is part and parcel with its products, Salvador Partners’ international team of developers are hard at work.

    The firm has built a DevOps culture across its organization despite geographical and language barriers. devopsy.kinsta.cloud explores the Salvador Partners devops culture that works in an umbrella fashion among these international developer groups.

    The Global DevOps Culture Challenge

    Salvador Partners works with development teams in Russia, China, India, the U.K. and the United States who build software prototypes, which can sometimes prove tricky: There are challenges to getting foreign teams to plug themselves more deeply in to existing domestic teams for future projects. “There’s an obvious value in their experience from the build of your prototype that you then want to tap. The question is whether they want to be a part of your longer-term vision,” Daniels says.

    The company also grapples with the location question—whether to consider moving some of its operations to those countries, closer to those teams, or move some or all of them to its domestic operations. “Perhaps the world has become small enough through the use of tools like Slack and [project management] tools that you can let the technology bridge any gaps,” says Daniels. The tools so far have helped disparate development teams make the leap, including addressing any time zone and language issues that appear.

    Delineating the Salvador Partners Culture

    Salvador Partners uses an agile approach. “If each client wants a unique tweak, we simply badge up a boutique offering where we can innovate, collaborate and deploy in an agile environment to suit the client requirements,” Daniels says.

    As development teams work together more frequently, they reuse code and proven approaches more often. “We often find tricks that get carried over to the next application or dashboard,” says Daniels.

    Tools are the answer. “Things have changed in recent years. In terms of a culture, I think it’s pretty easy to leverage tools such as Slack and Dropbox to make the team smaller, regardless of where in the world they are positioned,” he says.

    Salvador Partners developers also use Trello for sharing project plans and Skype and Uber conference for team collaboration calls. “We use a secure mobile app we developed internally to communicate on some of the new, high-tech or sensitive topics. WeTransfer is also pretty useful for sending larger files,” says Daniels.

    Though Salvador Partners looks at its DevOps culture as a whole rather than by region, there are some unique, regional aspects. “We have a real good team based in India and they just go get things done, whereas some of their counterparts we use sometimes get caught up in planning the plans. This can make it difficult to pull a number of pieces of a project together,” says Daniels.

    Other Solutions to Challenges

    Locations, languages and distances present other challenges as well. Because some projects work with encryption protocols that by law can’t be shared beyond certain countries, the development work can happens only inside the U.K., the United States, Australia, Canada and some European countries, Daniels notes. In these cases, the company simply keeps the work internal, within the countries permitted.

    Language barriers can also present issues. “Such was the case where Salvador Partners had Canadian companies working on something and had a French speaker cause a few problems for his English-speaking colleagues,” Daniels says. For language challenges, the company simply whiteboards the project or uses translators.

    Time zones can also trip things up. “It creates challenges when you have a New Zealand head office dealing with partners in Singapore and developers in Russia and California. We have had conference calls where participants are going for dinner and at the same time another having their first coffee,” Daniels says.

    However, time zones and geographies are less an issue as the available toolsets to solve communications barriers have evolved.

  • London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    As is to be expected from a world capital city, London is also a hotbed of DevOps adoption. The local London DevOps community is thriving with a near constant stream of DevOps conferences. There are however two great events coming up that are can’t miss. DevOps Connect: CD Connect/Jenkins Days in May and Gene Kim’s DevOps Enterprise Summit in June are both in London. Now you can attend both for the price of one!

    Right now due to the devopsy.kinsta.cloud sponsorship of DOES London and the generosity of the sponsors of both events, if you sign up for the full £179 two-day ticket for DevOps Connect: CD Summit/Jenkins Days you will receive the full £179 back in the form of a credit towards your ticket for DOES London. You wind up attending CD Connect/Jenkins Days for free!

    So what do you get from attending DevOps Connect: CD Summit/Jenkins Days and the DevOps Enterprise London? Glad you asked. Let me give you some of the highlights to look forward to.

    First DevOps Connect: CD Summit/Jenkins Days:

    1. Two-day event, day one features keynotes and three tracks, plus lunch, refreshments, exhibit area and demo theater.
    2. Day two of the event are deep dive workshops on Jenkins, DevOps Transformation, automating deployment in Hybrid Clouds, DevOps Foundation and DevOps Lift off and the Nexus World Tour: Rugged DevOps Heroes Assemble. You can pick and choose which of these workshops to attend, there is on price for admission to all of them.
    3. The event is being held at the KIA OVAL, KENNINGTON OVAL,SE11 5SS LONDON, UNITED KINGDOM.
    4. The keynote and headline speakers for the event are pretty amazing:

    sacha-laboureySacha Labrourey, CEO and Founder CloudBees, former CTO JBoss speaking on “Why Jenkins Has Become the Engine of Continuous Everything.”

     

     

     

    sanjeevSanjeev Sharma, CTO & Distinguished Engineer for DevOps, IBM on “Adopting DevOps at Enterprise Scale.”

     

     

     
    garyGary Gruver, Author of “Leading the Transformation”, Previously executive IT positions at Macy’s and HP, speaking on Leading the Transformation: “Applying Agile and DevOps Principles at Scale.”

     

     

    After this great morning of keynotes, there are three tracks all full of great speakers and topics after lunch.  You really don’t want to miss this event and if you were planning on going to the DevOps Enterprise Summit London, you can go to CD Summit/Jenkins Days for free.

    Why go to DevOps Enterprise Summit London? Well if you want to hear about the experiences of large enterprises in adopting DevOps, there is no better place. In the previous two Summits held in San Francisco, Gene Kim and team have done a great job of shining a light on “horses” DevOps transformations. This first London edition of the franchise promises to be equally as great. It will be held at the Hilton Metropole in London.

    Some of the speakers scheduled to present include:

    geneGene Kim, Author, Researcher and Founder of IT Revolution.

     

     

     

    gareth

    Gareth Rushgrove, Senior Software Engineer, Puppet.

     

     

     

    jasoncox

    Jason Cox, Director, Systems Engineering, The Walt Disney Company.

     

     

     

    This is just the tip of the iceberg really. There will be over 25 speakers at DOES London, as well as community space, breakout sessions and more.

    While London has more than its share of DevOps events, I am not sure it has experienced the likes of these two events before. Please don’t miss them and look forward to seeing you there.

  • Why Is There No DevOps Manifesto?

    Why Is There No DevOps Manifesto?

    Let’s start with a brief story:

    There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

    And the lawyer says, “Well, you eat, don’t you?”

    And the cadet says, “Yes, sir, three times a day!”

    The meals for everyone aren’t served by the book because the canteen isn’t included.


    This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

    Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

    Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

    A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

    You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

    I say: That’s not what DevOps is about.

    DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

    The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

    DevOps searches over time Sep2015

    In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

    If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

    As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:


    Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

    — Arie De Geus


    One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

    Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

    And everyone interested is welcome to sit down and enjoy what’s served.

    Seriously. Join in. You do not need a manifesto to.


    P.S.  It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

    You should check out, in no particular order:

    • The amazing (and amazingly modest) Patrick Debois
    • The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
    • The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
    • Damon’s five-minute video on DevOps history
    • John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
    • Mary Poppendeick’s lean development work
    • John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
    • Ben Rockwood’s (@benr) comprehensive LISA11 keynote
    • The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
    • Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)

    And works from folks including:

    • Jeff Sussna (@jeffsussna)
    • James Turnbull (@kartar)
    • Adam Jacob
    • John Vincent (@lusis)
    • Bridget Kromhout
    • Adrian Cockcroft
    • Gareth Rushgrove
    • Kris Buytaert
    • J. Paul Reed
    • Ernest Mueller
    • James Wickett
    • Ines Sombra
    • Karthik Gaekwad

    I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

    Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

    These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

    Also, if you get a chance to spend time at a DevOps Days anywhere, you should.

  • Walmart OneOps Won’t Be One-Upped

    Walmart OneOps Won’t Be One-Upped

    One of the biggest names in retail also is kind of a big deal in DevOps. Walmart has developed its own platform, OneOps, designed to streamline operations and keep its application development schedule in check.

    “OneOps is an open source cloud and application lifecycle management technology platform with benefits including cloud portability so developers can seamlessly move applications, databases or entire cloud environments from one cloud provider to another,” says Brian Johnson, VP of Engineering, Platform, Walmart Labs. The latter feature allows developers to leverage the broad selection of cloud environments and pricing schemes to their advantage.

    The OneOps platform deploys Walmart website adds/changes, launches new mobile features such as Walmart Pay, and creates APIs so third parties such as Hiku can tap into Walmart’s online grocery offerings, at speed and with a lower investment in the cloud, says Johnson. The OneOps platform once only managed the Walmart.com e-commerce site, but now it also serves individual Walmart stores and supports other initiatives.

    According to Johnson, OneOps undergirds and empowers the work of developers as follows:

    • OneOps continuous lifecycle management continuously auto-pilots the process of automating application scaling and repair whenever any unforeseen changes take place.
    • OneOps promotes accelerated innovation so software engineers can spin up new environments for app hosting in minutes, since the DevOps platform skirts the need to specify the intricate details of any one cloud environment by modeling that for the developer.
    • This abstraction of the cloud environment gives developers control over the tools and technologies they select regardless of the cloud provider they use.

    Life Before OneOps

    “Before OneOps, the process of updating Walmart’s website was so tedious that we rolled out updates only every two months. The process used hundreds of manual steps and required significant resources,” Johnson says. “This was time-consuming and created room for manual errors.”

    Before OneOps, A/B testing was expensive and time-consuming, taking months to set up multiple cloud environments and conduct tests. By the time testing was done, the rationale for the new feature had waned and whatever opportunity it was created to take advantage of had passed, he says.

    At that time, creating enough virtual machines (VMs) in time to handle peak shopping events and traffic would have taken teams of people months to complete, at the risk of exorbitant operating costs, Johnson adds.

    The OneOps Afterlife

    OneOps now fully manages the Walmart e-commerce platform such that in a typical day the site sees more than 1,000 new software deployments, which developers execute on demand in a span of minutes on average, says Johnson.

    OneOps serves a variety of customers such as consumers of Walmart.com, who on black Friday found their shopping experience supported by the tens of thousands of VMs OneOps was able to spin up across multiple clouds to cradle the peak traffic, Johnson says. OneOps is the DevOps and cloud platform for SamsClub.com as well.

    Solving the Single Cloud Provider Dilemma

    Walmart targeted OneOps to use multiple cloud providers easily, because of the pitfalls of being locked in to a single provider. “The fear of vendor lock-in is the major challenge to cloud service adoption. Cloud vendors like AWS don’t make it easy for customers to move from one cloud to another. The complexities of cloud service migration mean that many customers stay with a provider that doesn’t meet their needs simply to avoid the cumbersome and expensive process of migration,” says Johnson.

    Further vendor lock-in concerns, he notes, include:

    • Contracts of lengthy duration geared toward ensuring higher server utilization, maximum ROI and profitability for the cloud provider but providing little benefit for the cloud customer.
    • Lack of freedom of choice where storage space, processing power, bandwidth and tools and technologies are concerned.
    • Because it is typically difficult to find any two cloud providers that use the same tools, compatibility is an issue. “You can’t simply port your site to a new provider without rebuilding it using the new provider’s toolsets,” says Johnson.
    • “While you build and test your site on the new cloud platform, you are still paying to maintain it on the old provider, doubling your costs,” says Johnson.

    This is why OneOps abstracts the use of differing cloud providers, making porting easy.

    The Big Question Is …

    OneOps solves a unique set of DevOps challenges related to the cloud. Can you name another platform that does something similar?

  • DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    I recently had a chance to speak with Mike Pittenger, Vice President of Strategy for Black Duck Software. Black Duck is a company that I have been following for many years. They pioneered the idea of auditing open source usage to ensure compliance with licenses and such. Of course over the years they have expanded into other areas as well, including security, DevOps, containers and more. Mike and I discuss Open Source and DevOps.

    Mike and I had a good conversation I hope you will enjoy. You can listen below or follow along with the transcript below that.

    Alan Shimel:               Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on the chat is Mike Pittenger of Black Duck Software. Mike, welcome.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                So, Mike, our audience, you know, I’m sure many people in our audience have not met you before, unless you’ve invited your relatives. But can you give us a little background on who you are, Mike, and your role with Black Duck?

    Mike Pittenger:            Sure, sure. So I’ve been in the software security space for about 16 years. I started with @stake back when it was a leading software security consultancy. I ran the product team there, and then when Symantec acquired @stake I spun off that team to form a company called Veracode. I stayed there for a couple of years and then started consulting work with Bit9, Digital Guardian, BeyondTrust, Coralogix.

    And Black Duck was a customer of mine – a client of mine – about two years ago and we were involved in a discussion of product enhancements and so on. And I came back to them about a year ago. They called me back in for another project and I found the opportunity so interesting that we – I came on full time to head up their security strategy.

    Alan Shimel:                Very good. And Mike, believe it or not there may be some folks in our audience who aren’t familiar even with Black Duck.

    Mike Pittenger:            That would be hard to believe, Alan. [Laughs] We’ve been around since –

    Alan Shimel:                A long time, I know. I’ve been writing about you all for a long time. But that being said, just in case let’s give them a little background.

    Mike Pittenger:            Sure. The company is about 13 years old and what we’re very good at is looking at source code or binaries to identify the open-source components that are used in that. Once we’ve identified those we can tell the customer anything they want to know about because we track over open-source projects and we’ve been doing it for about 13 years.

    For the first 10 or 12 years of the company’s life, the primary interest in this was the people would run our software internally in order to determine the open source, but they were interested in it because of license compliance. They wanted to make sure that they weren’t using reciprocal or restrictive licenses like GLP code and _____ distributing; something that might put their own IT at risk.

    About five years ago we started adding security information from the National Vulnerability Database and a year ago we came out with a product specifically focused on security. It’s a big deal because while license compliance is still an issue for risk managers, open-source software, because it’s become so ubiquitous, is also a concern to security people.

    There are – there have been over 4,000 new vulnerabilities – excuse me, over 6,000 new vulnerabilities reported in the National Vulnerability Database just in the last two years. So unless people are aware of the software they’re using and the components they’re using in that software, they’re unable to protect themselves from these vulnerabilities and that’s where we come in.

    Alan Shimel:                Excellent. So Mike, I wanted to talk to you a little bit today about open source. And certainly open source vulnerabilities and scanning are big topics today, especially when we talk about that in the context of containers. And I know Black Duck is actually doing some work around container security and vulnerability scanning, etc. But I wanted to just take it up another 50,000 feet and talk overall open source’s – open source’s role in this whole DevOps revolution/evolution, if you will. Can you talk about that?

    Mike Pittenger:            Sure. Yeah, so I mean the big thing, of course, is that a lot of these particular – with the popularity of containers, a lot of those are running on a lightweight version of Linux, and of course that’s open source. Where we see the risk with that is not in using Linux, it’s whether an open-source operating system or component is more or less secure than a commercial component. It becomes a religious argument and you can argue it until the end of the day.

    The fact is you just need to have awareness of what you’re using and monitor that closely. So we did an informal study of the containers on Docker Hub and found that most of them, the majority of those, had security issues with them. And it was easy to see how this happens because containers are constructed just like software is constructed. People are pulling in often open-source components and they build a LAMP stack and add their application to it.

    If they’re going to deploy a new application they may strip off the application layer, maybe strip is right down to the Linux core again, and then build it back up. But if they’re reusing these components and a vulnerability happens to be in there from the beginning, or one is disclosed after you’ve built that initial container, it’s just going to propagate itself. So people are justifiably concerned, I guess is the right word, about the security of these.

    And from our position, it’s really more about understanding the hygiene of the container, understanding what you’re using, and then monitoring that closely because with 6,000 new vulnerabilities in a two-year period, clearly your security posture can change without you doing anything.

    Alan Shimel:                Absolutely. Mike, what we’ve seen in – you know, it’s funny. I was just going over the results of a survey we’re going to be releasing soon about DevOps tools adoption. And it was split between large organizations, over 10,000, and then about an equal number of under 200. So sort of dumb-belled with not a lot in the middle. But fully 25 percent or more, of all of the tools that these people were bringing in, whether they be – let’s call it a legitimate software supply chain or in through the back door, if you will, shadow – 25 percent of them or more were open source.

    Mike Pittenger:            That’s actually lower than what we see.

    Alan Shimel:                Really?

    Mike Pittenger:            So we have a portion of our business, Black Duck On-Demand. So we’re often brought in during an M&A transaction. So if I’m going to buy your software company, I’m going to “Black Duck it.” They use it as a verb. I’m going to Black Duck it to understand the risk associated or whatever risks there might be. And so these are commercial applications. You assume they have plenty of proprietary value because somebody else is interested in acquiring that company.

    And even in those cases we’re seeing that the code base, 35 percent is open source. If you’re talking about an in-house application that, say, a bank is running, they’re building the applications, consuming them themselves, it’s not unusual to see those applications comprised of 70-80 percent open source. And it only makes sense that they’re doing that.

    I mean, open source is saving them from having to build this functionality from scratch, so it’s providing critical functionality without an acquisition cost. So it’s shortening the time to market and it’s lowering the development cost. It makes perfect sense that they’re doing this.

    Alan Shimel:                Got it. I’m surprised to hear. I thought 25 was a big number. You’re saying it’s a small number and it’s pretty significant.

    Mike Pittenger:            Yeah. It is a small – so if you look at those commercial applications – and we’re going to be publishing a report of our own pretty soon on those – but the average number of discrete open-source components in those applications is over 100.

    Alan Shimel:                Got it. Hmm…crazy. Mike, I want to just – believe it or not, as I told you before we started recording, our time here goes so quickly and we’re eight-nine minutes into our recording. I wanted to just quickly pivot into the whole container and open source and security around it and some of the things Black Duck is doing. Again, people in our audience may not be familiar. Would you give them a little – just a little taste of it?

    Mike Pittenger:            Sure. So we have partnerships with both Red Hat and Docker. In the Red Hat world we’re partnering with them for security on their open shift platform as a service and their container platform Red Hat Atomic. And the idea there is simply to be able to quickly assess the security of a container before you deploy it. So we can run our scan client as a container, pull in a Docker image from a repository and scan it before it’s deployed. Very simple.

    From our world, you can point Black Duck at a container, you can point it at typically a development process that’s integrated with a build server. But you could point it at a repository if you wanted to, and to us, a container is simply another code location _____ scanning. And when we’re looking at that, we’re not just looking at the components, we’re also looking at what makes up those components and are able to identify these down to the patch level.

    So instead of saying you’re using a bad version of _____ and Linux, we can actually look at each of the components and tell if those have been patched for reported vulnerabilities just to make the DevOps manager’s job faster, understanding what they need to worry about and what they don’t need to worry about.

    Alan Shimel:                Got it. Excellent. And you know, Mike, we only have about a minute or two left here, but obviously it’s a dynamic situation – the whole container thing, the whole what’s happening with DevOps and open source and all of this. If you can gaze into a crystal ball, where do you see us going in the next three to five years with this? Where do you see it heading?

    Mike Pittenger:            Well, I think the containers are going to obviously grow rapidly. We see some – it’s a hesitation in deploying, to switching over to containers in some worlds, but I think it’s simply trying to understand it better. An analogy might be people switching over to cloud computing a number of years ago. They want to understand both the benefits and the risks before they throw in all of their chips on it.

    So we see some of the very large companies embracing it aggressively, but a lot of the, say in the financial services industries, still testing it, playing with it, seeing – trying to decide when they’re going to jump in and whether they’re going to start in the shallow end of the pool or go right to the deep end.

    Alan Shimel:                Got it. Got it. Believe it or not, Mike, we’re at our time limit. I know it seems to go so quick. But I wanted to thank you for appearing today, and you know what? If people want to find out more about Black Duck, quick plug for their web site?

    Mike Pittenger:            Yeah, sure. It’s BlackDuckSoftware.com. We do provide a – there’s a free trial that will work on an application or on a container and you can sign up for it right on the web site. It’s www.BlackDuckSoftware.com.

    Alan Shimel:                Perfect. Mike Pittenger, Black Duck Software. Thanks for being today’s guest on DevOps Chat.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud.

  • 7 Causes of Continuous Delirium

    7 Causes of Continuous Delirium

    When we think of CD, we typically think of continuous deployment as a result of continuous delivery, which is a goal of DevOps.

    In this article, I coin the phrase, “Continuous Delirium,” to mean unending confusion or bewilderment in development environments. There are probably several examples that could fit the bill here, but for now I offer seven real-world examples. I bet you’ve seen or heard about at least one of these.

    Now that I have your attention, here are seven causes of Continuous Delirium, each with cures rooted in DevOps:

    No. 1: Insufficient Configuration and Build Management

    Insufficient configuration and build management in software builds leads to the same or similar software impurities rearing their ugly heads again and again. You build, test, discover the defect, fix it—or so you think—build again, retest and boom: The same coding error or software malfunction recurs.

    “You can cure this malady with a rational approach to the build and configuration management process, checking software in and out with established procedures for each software module using a tracking sheet that identifies the revision of the sub-modules for the entire software product,” notes Jon M. Quigley, founder of Value Transformation, a product development consultancy and training firm based in Lexington, North Carolina.

    No. 2: What’s Going On? Who’s Doing What?

    When there is no reasonable understanding of the work, who is doing what work and who is responsible for what—and there is no consistent measure of what is good work or bad work—you have a breeding ground for anarchy.

    “You cure this ill by establishing what constitutes the appropriate quality of work as well as by periodically reviewing the state of the objective with the receiving or depending entity,” says Quigley. Make sure everyone is on the same page with the same definition of what constitutes quality work and make sure the objectives have not changed. Also, ensure these goals are also clearly understood by all.

    No. 3: Confusing Clean Daily Compiles with Testing

    When you do not test the software as early as possible and throughout the development process, you can’t really say it has no bugs. Error-free compiling is not error-free software. Software compilation does not have the same investigative effect as using the software in the customer environment.

    “Test throughout development using complimentary testing approaches such as testing to requirements, combinations of stimulus testing and exploratory testing, for examples,” says Quigley.

    No. 4: Planning Too Far Out to Control

    The further you try to plan things out into the future, the less control you have as you follow the project through to conclusion. “When we treat a plan as though we know everything associated with the project for the next 12 to 18 months, we are fooling ourselves,” says Quigley. By breaking projects into bite-sized increments, you can better assure successful completion of sub-projects and of the project as a whole.

    No. 5: A Lack of Customer Involvement

    Customer involvement is critical to customer satisfaction. “By getting the product or a prototype into the customers’ hands for exploration, you can retrieve feedback for developers,” says Quigley. This may expose the project to risk in the form of the potential for a great deal of change at the customers’ request, but the other side of the coin is the risk that nothing changes and the customer doesn’t use the product at all.

    “Rather than try to deliver one incarnation of the product at some future date, break down the delivery into separate iterations that meet prioritized customer expectations one by one as you refine the product and add features as you go along,” says Quigley.

    No. 6: Isolating Change Management from Customer Involvement

    Customer involvement means there will be change. Change requires change management. There is a given—and correct—assumption that customer involvement will trigger change management at some point. You cannot isolate the one from the other.

    Further, just as you can better address customer requests for changes by breaking the project into smaller subsections, so also can you manage budget through change and change management. Project subsections enable you to see the need for change a little at a time so you can create change in a more targeted and cost-effective manner.

    No. 7: Forget About Collaboration—at Your Own Peril

    It is necessary for DevOps team members to collaborate at all levels, except those where the work on software is so minor that it wouldn’t benefit from shared thought. To maintain development as an expedient process that benefits from all stakeholders, open communications and collaboration must reach and pull from all team members. Otherwise, the project could suffer from a lack of critical input.

  • DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    I had a chance to sit down with Michael Azoff, principal analyst for Ovum. Ovum just released a set of matrices that Michael was the author of on ALM, DevOps release management and one on Agile project management. Taken together they provide some great insight into the entire software lifecycle management space.

    I had a chance to view the reports before speaking with Michael and you can too courtesy of IBM. Here are the links:

    1. Ovum Decision Matrix: Selecting a DevOps Release Management Solution, 2016-17
    2. Ovum Decision Matrix: Selecting an Application Lifecycle Management Solution, 2016-17
    3. Ovum Decision Matrix: Selecting an Agile Project Management Solution, 2016-17

    Here is my conversation with Michael. Below is a transcript so you can follow along if you like as well.

    Here is the transcript of our conversation:

    Alan Shimel:                Hi, this is Alan Shimel of devopsy.kinsta.cloud.  Very happy to be joined today by Michael Azoff, principal analyst at Ovum.  Michael, welcome to DevOps Chats.

    Michael Azoff:             Thank you very much, Alan.  Pleased to be here.

    Alan Shimel:                Thank you.  Michael, you – well, Ovum, but you as the author, just published several Ovum decision matrices – I guess plural of “matrix” – in the last day or two, one of which was on DevOps, Agile, et cetera.  For our audience who may not be familiar with the Ovum decision matrix, can you explain kind of what they are, who the audience is, what they’re about?

    Michael Azoff:             Sure.  Yeah, absolutely.  So the Ovum decision matrix is Ovum’s product comparison methodology, where we compare products side by side, across three dimensions – one is the technology; the other is enterprise fit; and then we use the matrixes – the result is displayed as a bubble chart, so the size of the bubble is the marketing, so those are the three dimensions.  And I cover the software lifecycle management at Ovum, and we published three Ovum decision matrices covering the whole life cycle, so one was on application lifecycle management, one was on Agile project management, and the other, DevOps release management.

    Alan Shimel:                Fantastic –

    Michael Azoff:             The ALM – sorry, do you wanna ask a question?

    Alan Shimel:                No, no, I said that’s fantastic.

    Michael Azoff:             Yeah.  It’s not common for us to – for one analyst to do three at the same time – I think I’m the first to do that – but it made logical sense because I’m covering the lifecycle from end to end.  The ALM one we’ve been – we’ve had a cycle of these decision matrices for many years, but this is the first one that spans not just enterprise IT but also engineering manufacturing, where, because of the exponential rise of software content in advanced products, there is a very, very clear need for managing that complexity and a role for ALM.  So this covered, for the first time, the engineering side as well.

    The Agile project management was then a subset of the ALM one and focused purely on enterprise IT, so that’s the original scope for ALM.  Calling it “Agile project management” because it’s very much about the management at a high level, and then using – typically, organizations use a lot of open source tools for code development, so that made logical sense to name it in that fashion, with Agile being now so typical and common, but many of these solutions are generic and allow any kind of process to, from traditional stage-gates through to Agile, allow that coverage.

    And then DevOps release management, which has been around for some time – I think the first report where we looked at products was in 2010, but, this year, we’re seeing the topic has become really, really hot, and it was timely to do an Ovum decision matrix – in fact, the first proper decision matrix on solutions in that sphere.

    Alan Shimel:                Got it.  Let’s talk about some of the companies and what – well, before we do that, Michael, can you give our listeners a little insight into how this was conducted?

    Michael Azoff:             Sure.  So the original matrix terminology, I think, stemmed from the fact that we send the vendors – we invite vendors to participate.  We send them project criteria.  If they fit the criteria, then they’re in.  It’s, essentially, we’re looking at the top players in the market.  I also tend to invite some of the more interesting and innovative smaller companies to participate as well because I think that that’s of interest to the readers.  But, generally, it is the top market leaders who are participants.  So we send them a spreadsheet and that’s their sort of matrix.  It’s – has the 200 to 400, which we’re actually trying to reduce the number of questions, rows, that we have in the matrix, but the vendors fill these out.  We then have a briefing with the vendors.  We have a demo of their product, and we also delve into their marketing approach and we look at their financial numbers.  We look at their approach to customer service.  So it’s very in depth, it’s multi-dimensional, as I mentioned, and, on that basis, we then produce the decision matrix bubble chart.

    Alan Shimel:                Got it.  I don’t know if we wanna name names, Michael, but let’s take the DevOps matrix, to start with.  What were – who – according to the matrix, what were some of the let’s call it “top performers” – is that a good term to use?

    Michael Azoff:             Yeah, it certainly is.  And I think of all the – I’ve been an analyst since 2003 and conducted these type of vendor product comparisons, and I would say this has been the most contentious and the most difficult to, of all of these exercises, in drawing vendors apart.  So I ended up with quite a number of leaders who looked very sort of in that leading category.  Oh, I can – I’ll try and do this alphabetically, so, let’s see, so CA, CloudBees, Automic, Clarive, Microsoft Electric Cloud, IBM, Serena – did I mention CA? –  XebiaLabs, so, yeah.

    Alan Shimel:                Sounds pretty comprehensive.

    Michael Azoff:             [Chuckles] There’re a lot of vendors.  They all did extraordinarily well.  It was very difficult to draw them apart, but they all have rather different approaches to the market, and this is what is sort of delved into in the actual ODM report, so I do encourage people to actually look at the report and read carefully as what – so that’s a strength, weaknesses, opportunities, and threats analysis, which goes into quite a lot of detail and really gives the flavor of each of these solutions, in that leading category.  And then we have some challenger solutions as well, yeah.

    Alan Shimel:                Got it.  And, Michael, I mean, certainly DevOps is on top of everyone’s list of hot topics or near the top of everyone’s list of hot topics.  You know, separating the hype from the reality here, just where’s the ceiling for these things?  I mean, do you see – what do you see down the road in short term – 12 months, 18 months, 24 months?

    Michael Azoff:             Well, we had the first wave of the innovation in this market with support for managing continuous delivery, so, at an open source level, there was activity.  There were vendor startups that provided their own continuous delivery solutions and then, on top of that, management and orchestration.  So all of that was happening around 2011, and the larger vendors made acquisitions.  I mean, IBM acquired UrbanCode; CA acquired Nolio; BMC, StreamStep.  So very much a sort of rationalization and an anticipation of the market.  But we’re still seeing new players come onto the scene, like Clarive, for example, is an interesting one and CloudBees, the open source project – owners of Jenkins have sort of stepped into the enterprise side and expanded their offering with an enterprise-ready release management solution – so still a lot of activity.  And I would say the next step in this market would be ALM and release management tying a lot closer, and I think, from a customer point of view, it would be a useful benefit to have a single ALM solution that included these advanced release management technology in there as well.

    Alan Shimel:                Yeah.  Absolutely.  Michael, where do you see – now one of the questions I always get is, with all due respect, right, these analysts do great reports, but they’re behind firewalls, they’re behind reg-walls.  One of the nice things about these Ovum matrices is I see IBM and some of the other vendors are making the matrices themselves available if you’re willing to fill out their registration form, and what I like about that is it gets this intelligence into the hands of people, whether you wanna take it slanted or whatever because you had to fill out a registration form – that’s up to you – but for people, Michael, who are saying, “How independent – how much stock do we put in these things?”  You’ve already given us a little background into the methodology behind the research, the wide spectrum of companies you’re covering, but talk about independence of Ovum and of your research here, so – I want people to understand that.

    Michael Azoff:             Yeah, absolutely.  So, as analysts, our credibility is our independence, so we’re not aligned with any vendor.  As an analyst firm, we face both ways – we do work for vendors, we work also with end-user customers, and we also provider solutions for vendors and for enterprise customers.  So we face both ways – we work with all parties – but our independence is our credibility in the market, so we take a completely objective view of the responses from the vendor.  And, sometimes, the vendors don’t like what they see, but they actually find it very useful to get a completely unjaundiced and independent view because it helps them understand exactly where they are in the market.

    I think the ALM one, in particular, was a bit of a shock for a number of vendors because of our re-scoping of how we look at ALM.  Some vendors completely ignore the engineering market, and we see that as one of the growth areas in ALM, so I think that caught out a number of vendors by surprise, despite the fact that we’ve been telling them they ought to look at that part of the market, for ALM.

    Alan Shimel:                Absolutely.  Michael, can you give our readers what’s next?  What other matrices related to these subjects or other kind of research might you guys be working on next?

    Michael Azoff:             Sure, sure.  So, personally, so my brief is the software development lifecycle management, and I cycle through three areas – ALM, mobile development platforms, and application performance management – despite the fact that the ALM one was a triplet, but it is, logically, the lifecycle, if you like.  So the next one in the cycle will be Q4 this year, and that’ll be on application performance management.

    Alan Shimel:                Great.  All right.  Michael, we’re just about out of time, unfortunately.  I apologize; maybe we can talk again another time.  It was great chatting with you and I hope our readers have learned something here that can help them.  And thank you for all the research you do – can never have enough information on this stuff.  Micheal Azoff, principal analyst at Ovum, thank you very much.

    Michael Azoff:             Thanks, Alan, for inviting me.

    Alan Shimel:                Thank you, and this is Alan Shimel for devopsy.kinsta.cloud.

  • Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    We are teaming up once again with ClusterHQ for an update on Container usage and adoption. Our new survey is available and shouldn’t take more than 5-7 minutes of your time. We are looking to see if the container adoption and usage has changed since our last survey last summer. Please take a moment to fill out the survey. If you fill out contact info at the end, you are eligible to win a $50 dollar Amazon gift card. One in 50 wins a card. If you don’t want to give any contact information, you don’t have to but we can’t contact you if you were to win a gift card. Either way we would love your input!

    While containers are capturing lots of buzz and attention, many still doubt their impact in real world procurements. However, we are hearing enough subjective feedback to think that this is not the case. We think containers are catching on quickly, perhaps even quicker than cloud adoption did at similar time frames. But that is subjective. We are looking for numbers that prove or disprove it. So even if you are not using containers now, we want to know that too.

    The standard line is that containers are being tested in dev and test environments, but are not ready for prime time. Yet Docker, CoreOS, Kubernetes and the entire container ecosystem point to more and more customer references. Can everyone be just playing with containers in their labs? We don’t think so.

    On the other hand, there are questions about security, scalability, networking. Should you lock in to one vendors complete stack? How open should the ecosystem be? What about data, databases, OS, etc. Lots of questions and we really don’t have a lot of objective data points. Help us change this by giving us your own thoughts, experiences and ideas.

    We will share the full report with analysis with our readers when complete. But don’t miss this chance to be heard and make a difference.

  • SaaS-Powered FlightPartner Fueled by DevOps

    SaaS-Powered FlightPartner Fueled by DevOps

    Private jet charter company FlightPartner is reaping the benefits of DevOps to build a powerful software-as-a-service (SaaS) offering to keep its customers flying high with no delays.

    “FlightPartner does not own any aircraft but rather facilitates the travel needs of clients by offering air charter brokers (agents to the client) access to a global network of private jet charter availability,” says Douglas Schmohl, CEO and founder of FlightPartner. By acting as a global distribution network (GDN), FlightPartner enables access to real-time availability of private jets.

    What TravelPort is to airline seat availability, FlightPartner is to private jet availability, Schmohl says.

    FlightPartner’s cloud-based SaaS manages data exchanges and transactions through a web browser as a web-based service, requiring no client software installs for the brokers or operators. The service uses Angular.js, a “structural framework for dynamic Web apps” to pass data from the browser to a PHP back end. A database and integrated systems back end builds real-time pricing quotes for available private jets, while the payment mechanism supports search, booking and payment, completing the transaction, Schmohl says.

    FlightPartner uses a Laravel open-source PHP framework, which was created by Taylor Otwell and was originally targeted to developing Web applications following the model-view-controller (MVC) architectural pattern. “This framework allows for rapid development, testing and deployment of our SaaS solution,” Schmohl notes.

    SaaS Technical Challenges

    Schmohl and company endured some technical issues as they built FlightPartner software and worked to raise it to the skies where it would eventually soar. Schmohl was committed to following the lean startup practices of Eric Reis, author of “The Lean Startup,” which redefined the roadmap for a startup tech company, Schmohl says. According to the book, one of the first steps in approaching a new business as a lean startup is to try to float a “minimum viable product,” or just enough product or service to test the market demand for it. “This was nearly impossible for us due to the complexity of the air charter marketplace,” he says, so Schmohl had to invest in a more technically developed product rather than a simple solution.

    In the private jet charter industry, with so much change, so many variables, so many players needing access and so many systems that FlightPartner would need to access, a minimum viable product still necessitated numerous external integrations and APIs. “Developmental collaboration to achieve this was difficult at best and developers often pushed code to production only to create more issues with each deployment,” Schmohl says.

    A second technical misstep—and in the absence of formal development structure—Schmohl’s team wrote code to solve specific functional problems one by one. However, the team found that a method for developing one function would conflict with a different method that was used to create another function, and so on. “The constant patching of the front and back end consisted of whatever worked. This code became challenging to manage and scale,” he says.

    Because of these two technical challenges, FlightPartner’s attempts at a minimum viable product and at following a lean startup approach soon were tangled in a mess of spaghetti code and unmanageable methods, Schmohl says.

    FlightPartner Development Pipeline

    Today, development at FlightPartner is much improved. The SaaS and its components start with a local build that the system pushes to a development server in AWS. FlightPartner developers use SourceTree, a Git client and the Git versioning system to manage software versions. FlightPartner uses quality assurance to manage development and to test code, and developers fix errant code and deploy it to AWS using Elasticbeanstalk. “This enables rapid builds and continuous deployment,” Schmohl says.

    Using a DevOps approach to development brings structure to an otherwise-highly dynamic marketplace. “Offering a SaaS solution as a marketplace presents challenges unlike a typical marketplace. Our inventory (aircraft) is fluid in that it moves often and the price changes depending upon location. This operational challenge translates to numerous and constant development with changes in software functionality,” Schmohl notes.

    These are the operational needs that drive software requirements; the developers’ goals increasingly are to meet those requirements so the software seamlessly supports operations. Development uses a priority status to identify and escalate the builds that are most critical to continued, smooth operational activity.

    Results

    FlightPartner’s development process has created a workflow process that minimizes the resources necessary to achieve operational results. Thanks in large part to DevOps and the cloud-based SaaS system, FlightPartner’s GDN has aircraft available for charter in six of the seven continents, including 35 percent of available aircraft located outside the United States, says Schmohl.

  • Murphy’s DevOps: The Internet Apocalypse

    Murphy’s DevOps: The Internet Apocalypse

    I’ve been immersed in cybersecurity for a good stretch, since it was known as just “infosec” and “security.” Over time, I’ve had opportunities to work with some brilliant minds and young-gun “hackers” (I’m not a name dropper, so I’ll refrain from using them as SEO-bait). I’ve watched attackers transition from being basement-dwelling teenagers to organized intruders to APTs. At one point or another, I’ve met all of Five Horsemen of the Internet Apocalypse: Scam, Extortion, Embarrassment, Theft and Death.

    The biggest cybersecurity news story of all time is still Edward Snowden. Fancying himself a “whistleblower,” champion of the Constitution and privacy rights expert, this fugitive data thief accused of espionage by the United States government has done more to force businesses and individuals to think about digital security and privacy than anyone or incident before him.

    Snowden aside, there are thousands of other stories about just how fragile our online lives and businesses are. If you were at the devopsy.kinsta.cloud Rugged DevOps event at RSA 2015 and caught the presentation by Wired cybersecurity and privacy writer Kim Zetter, “2015 — The Year in Hacks,” then you had a chance to get a great overview of some of 2015’s biggest digital crimes. You might have even noticed the Internet Apocalypse Horsemen riding through.

    With an ear to the ground on everything the NSA and APT-using hackers are guilty of, @KimZetter never fails to intrigue readers and live audiences. Whenever you read her stories or listen to her speak, you always walk away reassured that when all the smoke and headlines have cleared, the great deep-down reality is that everything we digitize is subject to the whim of Scam, Extortion, Embarrassment, Theft and Death. If you didn’t have a chance to attend, please enjoy some of the highlights listed below.

    China vs. U.S., Spy vs. Spy

    Internet Apocalypse

    She kicked off with the biggest hack of 2015: the one that penetrated the U.S. Office of Personnel Management (OPM). The full extent of the damage done and who the actual attackers were may never be fully realized. Were they Chinese spies, rogue hackers or a combination of both? What we do know is that it exposed millions of identities tied to covert U.S. operatives and their family members listed on security clearance forms. It may have even exposed personal information on everyone who has ever applied for a job with the federal government. One for-sure lesson is that even after several decades of security product development (with more than 800 available for review at RSA), the world is still in need of innovation in the space.

    Men Behaving Badly …

    Internet Apocalypse

    Some might argue that Embarrassment made a special appearance at Ashley Madison, but the fact that suicide was part of that hack leaves me to think that Death was the lead actor there. @KimZetter pegged the data theft as the most brazen hack of 2015. With 30+GB of account information stolen and dumped, login credentials for 32 million accounts purloined, credit card transaction information accessed and even several suicides tied to the incident, the hack again reminded the world that the great deep-down reality is that everything we digitize can be used by attackers to scam, extort, embarrass, steal and even kill us.

    From the Keyboards of Babes …

    Anyone at the presentation must agree that Embarrassment really stole the show in the hack of CIA Director John Brennan’s AOL email account. Allegedly perpetrated by a teenager, Zetter describes the incident more deeply in her October story: Teen Who Hacked CIA Director’s Email Tells How He Did It

    Internet Apocalypse

    Keep Calm and Internet On

    Anyone reading this may be walking away with a rather pessimistic view of our chances of remaining secure online. The truth, however, is that the existence of determined hackers should do no more to stop individuals or businesses from going online than road rage should to prevent anyone from getting behind the wheel of a car.

    If any lesson can be learned from news articles pumped out by @KimZetter and her peers, it’s that the world should continue to take full advantage of the Internet but to also take the time needed to apply effective security. Quite simply, we all should keep calm and Internet on …