Category: Blogs

  • Make Presentation and Training More Effective

    Make Presentation and Training More Effective

    Providing effective training is an art form. It requires much dedication and skill to engage your students so they believe they have benefited. Simple presentations can feel dull and unengaging, making the topic less interesting and many times leading to little or no knowledge transfer, even if the subject was covered correctly and the information was spot on.

    Gaining—and keeping—the interest of your audience is paramount in any successful training program. Here are a few essentials to consider when creating your presentation to make it more effective:

    Start with the basics

    Whatever is the level of your course, it’s always good to provide a basic overview of the subject before moving forward to the topic. No style of teaching or learning is the same, and students could have different levels of understanding regarding the subject matter. Provide some basic details on off-topic content—this could be useful to help the audience connect with the main topic. You may never know the exact level of your audience’s expertise and their expectations.

    Engage your audience

    The stand-and-deliver method of training, in which the trainer talks and the trainees listen, is ineffective and only serves to bore the audience. Don’t lose their attention: Keep them involved by asking questions, inputs and thoughts on topic. The trainer also can host a question-and-answer session as another chance to engage the audience.

    Provide some fun in your content

    I have found that humor can play a very important role in the delivery of training or a presentation, providing some energy and creating another way for the audience to engage. It also can help to break monotony of a presentation. A punch of fun may pull the audience from getting sleepy and help them feel fresh-minded. Also helpful: providing some useful general information related to your topic.

    Keep giving breaks

    Small breaks during a session are very important for both the presenter and listeners. Offer breaks at regular intervals—say, every one to two hours. This, too, will help prevent them from getting sleepy by giving them the chance to get up and stretch their legs. Plus, they’ll come back refreshed.

    Give assignments

    Never ever end or break your session without giving some type of assignment to your trainees. That will help them remember and retain what you’ve taught them—it’s very easy for humans to forget the things they learned if they don’t have a chance to practice it. Give your trainees some hands-on, to make sure they understand the topic and can recall it easily.

    Overcoming Presentation Challenges

    Presenters do face certain challenges, which can potentially be disruptive to a training session. Here are a few along with some ways to combat them:

    • It’s very common for the audience to engage with their mobile devices or laptops instead of paying attention to the presenter—and believe me, that is really irritating. Ask your audience to put away those devices before the session starts to  eliminate the distraction.
    • It’s also common for the audience to stay quiet and not ask questions, for whatever reason. It’s up to you to make them feel comfortable enough to speak or ask questions during the session—ask them questions to get them engaged, for example.

    These are just a few points I’ve learned in leading successful training sessions, seminars and presentations. They’re based purely on my personal experience and knowledge, but hopefully they can help you create and deliver effective presentations.

    Other Reference – http://www.scmtechblog.net/2016/02/how-to-provide-effective.html

  • The Difference Between DevOps and Anarchy

    The Difference Between DevOps and Anarchy

    DevOps is about being more efficient. It’s about breaking down silos and removing traditional business obstacles that get in the way of just getting things done. It’s about enabling teams and individuals to collaborate more seamlessly.

    None of that, however, means that DevOps is about turning your IT into some sort of “Wild West” anarchy, where anyone and everyone can just push code to production. That would be insanity.

    One of the primary catalysts that started the DevOps movement was the frustration of developers trying to deal with an operational bottleneck. As developers evolved from the old-school Waterfall development method to the much faster-paced Agile, developers were able create better software more quickly. That simply resulted in a “hurry up and wait” scenario, though, because the Operations and IT infrastructure side of the house couldn’t keep up.

    Fast forward a bit and DevOps was born. Since its inception, however, there has been confusion about what exactly DevOps is or isn’t. That might be a function—at least in part—of the fact that there was no “inception” of DevOps; nobody developed a thing and then rolled it out to the world with the announcement, “This is DevOps.” DevOps was an evolution that occurred organically and out of necessity. It meant different things to different organizations and was implemented in ways that were largely subjective and often not called anything in particular. Organizations were simply struggling to address challenges and coming up with solutions that worked.

    Suppressing the Anarchy

    Although traditional IT operations were the roadblock that sparked the DevOps movement, DevOps doesn’t mean developers get to simply do their own thing. I’ve worked in the trenches as an IT admin at a dotcom startup—I’ve experienced firsthand the disastrous fallout of a developer pushing untested code onto a production server, and I’ve witnessed the wrath of executive leadership when that happens and the proverbial “stuff” hits the fan. It’s not pretty.

    No, DevOps does not mean eliminating Operations from the equation and functioning as an IT anarchy. You’ll note that DevOps is a very obvious portmanteau of developers and operations—implying that operations is half of the DevOps solution. DevOps is about developers working more closely and cooperatively with Operations—not developers bypassing IT Operations.

    There are two components to successful DevOps: culture and continuousness. First, organizations need to shed the traditional mindset of separate siloed teams and departments and let individuals focus on working together in whatever way makes the most sense for efficiency and effectiveness. Empowering individuals to do what’s necessary to collaborate and get things done is a big part of DevOps.

    The other component is continuousness. When developers adopted Agile and started producing code faster, they discovered that Operations was a bottleneck. When developers and Operations started working together more seamlessly, new bottlenecks were identified, and solutions were developed to automate as much of those tasks and processes as possible.

    The ultimate goal of DevOps is continuous delivery—to continuously deliver new solutions and features. Rather than a lawless void where developers just push code out onto production servers willy-nilly, organizations adopt continuous development, continuous testing, continuous deployment, continuous monitoring and other tools that enable their teams and those developing solutions to do so with as little friction as possible.

  • Jay Wampold Gives AWS and Chef a Win-win

    Jay Wampold Gives AWS and Chef a Win-win

    jayChef VP of marketing Jay Wampold is leaving the iconic DevOps company to go to perhaps even a bigger opportunity as an executive at Amazon Web Services, heading up product marketing for AWS. I spoke with Jay last week about this though it was a tough decision to leave his role at Chef, the AWS opportunity was “an offer he couldn’t refuse.”

    Jay joined Chef in January of 2011. Obviously since that time he has helped Chef reach some pretty lofty heights. But you don’t spend that much time at a job/company without developing deep relationships, friends and history. That made this move all the harder for Jay.

    Personally, one of the things I like best about my role at DevOps.com is meeting people like Jay and getting to interact with them on a regular basis. I understand exactly what he was facing. It is not easy moving out of the comfort zone.

    On the other hand some people are not as lucky to pick their exit. In those kind of situations moving from one company to another company which does business with the first company could be a problem. But that is not the case here.  Jay emphasized to me that his relationship with Chef, the executive team and in fact the entire organization remains fantastic.

    The obvious question for Chef is who will take Jay’s place? Right now I am told that Karolin Beck is “Interim Vice President.” Whether she stays in that role or Chef brings in a CMO or other new marketing exec remains to be seen. Jay was very high on Karolin though when I spoke to him.

    So it seems that AWS got their man and it is a win for them. But it also sounds like one of Chef’s folks went over to a major partner of theirs while still a big fan of Chef. That is a win for them.  This may be one of the few times were everyone comes out a winner.

    Good luck to Jay, his new employer and old employer.  I am sure he will continue to execute and succeed.

  • Live Blogging InterConnect 2016

    Live Blogging InterConnect 2016

    We are live in Las Vegas for InterConnect 2016.

  • Flash Mob Inflection: Rugged DevOps Revolution

    Flash Mob Inflection: Rugged DevOps Revolution

    Truthfully, I was never a huge fan of the HBO series “The Sopranos.” It’s not that it wasn’t entertaining; I just didn’t agree with the “best ever” label that so many espoused during the show’s halcyon days.

    This had something to do with living in Hoboken, N.J., at the time and feeling the show was a heavily glamorized caricature of the real-life Mafioso I still perceived to be in my midst. More specifically, it’s hard for anything mob-related to stand up next to “Goodfellas” and “The Godfather”—among my favorite films, ever.

    Either way, I currently find myself identifying with the series’ defining sentiment (copped directly from The Godfather, but hammered home as The Sopranos main theme): “Just when I thought I was out … they pull me back in.”

    It wasn’t that I assumed that I’d never delve back into the domain of IT security after transitioning into the DevOps market last year; leveraging DevOps methodologies to improve security, policy compliance and related workflows stands as a core element of the overall movement.

    But, in recent months and weeks it has become increasingly obvious that the security facet of the larger DevOps revolution appears poised for explosion as the buzz around emerging best practices, business models and solutions providers grows from a low hum into a steady roar.

    After spending a few days talking DevOps security with Derek Weeks of Sonatype at CA World ’15 (we were booth neighbors and dinner mates) and giving more consideration to his company’s angle on securing the systems development life cycle (SDLC) supply chain, the internal gears really got spinning.

    Regardless of whether you buy into Sonatype’s security-heavy approach, the concept of aggressively and proactively addressing security across the DevOps spectrum makes infinite sense. The ultimate downfall of applications security has always been the challenge of securing all the underlying layers of code (and today, microservices), especially as applications are assembled using heavier doses of shared, open source componentry.

    As further evidence, nearly every major solutions vendor focused on the DevOps space—whether oriented toward the vibrant application performance management (APM), configuration management and continuous testing segments, among many others—seems to have launched some initiative aimed at integrating security into their products.

    The rise of security capabilities adjacent to—and supporting inclusion into—the DevOps world, such as container giant Docker’s Content Trust initiative, along with the advancement of related startups including Twistlock, Scalock and StackRoxs, offers more proof of this growing momentum. And that’s only the container security piece of the puzzle.

    Of course, there are also a number of emerging startups aimed at addressing the DevOps security opportunity, backed by well-known venture capitalists. A shortlist might include providers such as Immunio, Prevoty and UpGuard (formerly known as ScriptRock, which recently rebranded itself under the guise of a “DevOps security” provider), and we’re sure to see many more. And don’t forget the growing emphasis on DevOps security among established security industry stalwarts such as CyberArk, Snort and Tripwire, among others.

    For a comprehensive list of the various types of DevOps security best practices and tools that we should expect to see gain wider adoption, this October 2015 blog by noted security analyst Adrian Lane of Securosis serves as a basic framework. Each of the areas of focus that he cites clearly offers significant opportunity for both new and existing methodologies.

    Finally, one need look no further than this year’s RSA Security Conference, to be held in San Francisco at this end of this month, as tacit proof of the continued growth of what people now varyingly refer to as DevSecOps or Rugged DevOps (I prefer the latter as it just sounds cooler).

    In addition to multiple conference sessions, notably a “DevOps Throwdown” between security industry veterans Caleb Sima, Chris Wysopal and Gary McGraw, there’s also the 2nd Annual DevOps Connect: Rugged DevOps Edition. If last year’s event is any indication (standing room only, venue literally at max capacity), this daylong DevOps security track at RSA will be an even more high-profile element of the entire week.

    Further, if DevOps security—or, at the very least, the growing focus on adjacent segments such as container security—isn’t the unofficial theme of this year’s entire RSA show, I’d be extremely surprised.

    Meanwhile (self-serving), my employer CA Technologies absolutely has a lot going on that complements and contributes to this growing DevOps Security market momentum.

    For all of those reasons, here I find myself again, drawn closer back into the security space that I’ve called home for roughly the last decade. I guess that’s just how it goes, as DevOps and security are inarguably two of the most significant trends in IT these days and inextricably linked at their respective cores.

    There are definitely worse fates out there. But, just when you think you’re out …

  • What If We Had Git for DevOps?

    What If We Had Git for DevOps?

    I used to hate Git. Compared to my previous source control systems (SVN, SourceForge and floppies), it was cryptic, opaque and hard to learn. It was comfortable to create a set of files and folder, then snapshot them as a unit. It was simple to understand and improved my individual productivity.

    But that snapshot created a huge tangled mess when I tried to collaborate with other developers.

    Once I got over the learning curve, Git revolutionized how I wrote code. Small changes made a lot more sense with frequent integrations. I could easily review the impacts of collaborators’ changes. Even more critically, I could keep my work around while I tooled their incremental fixes and improvements. Development—especially open source development—is a team sport and requires tools that facilitate collaboration at the most fundamental level.

    But it was not just learning Git; I also had to adapt how I structured projects and collaborated.

    In that context, DevOps automation has been missing the equivalent of Git. We need composability!

    Can a Git Model Work in DevOps?

    We’ve been building great configuration automation tools (Chef, Puppet, Ansible and Saltstack) over the last few years and now there’s a new wave of cloud templates (AWS CloudFormation, OpenStack Heat, Terraform) entering the fray. These tools are like my original source control systems: they create a vertically integrated stack of configuration that works for a specific case and platform. There are ways to merge them into new stacks, but that ends up feeling like creating a whole new stacks.

    Why does merging scripts create new stacks? Changes in other components often break each other.

    When you reuse someone’s script, their changes can quickly break your carefully built automation. Instead of collaborating, you’re just forking their work. It feels like we’re running around data centers with automation on floppies. When we fix something in one module, it’s very hard to push that back into the community—we have not built clear, functional boundaries between modules that isolate changes in a way that reduces the risk of using other authors’ scripts and makes it easier to contribute improvements.

    Isolating changes does not mean we don’t break integration! It just makes it easier to collaborate upstream.

    The answer in our experience is to think of ops scripts like Git: Even inside of a larger set, we need to make the parts independent and decomposable. How do we translate Git into ops terms? Repos are like full systems—directories map to components, files to roles. Like Git, when we make incremental changes to any item, the whole system is impacted. However, we can still isolate that change down to a single line so we can manage collaborative work. This works when the impacts of changes are isolated (like a text file) and fails when changes are part of a tightly integrated unit (like an image file).

    We already have git with ops scripts. How is this different?

    We are suggesting an even more composable approach. Each ops role should be designed as a functional role with clear inputs and minimal side effects. To achieve that isolation, we’ve been building an orchestration platform, Digital Rebar, to feed the right inputs into existing opts scripts. That allows collaboration within a module without unexpected external side effects. It also allows reuse of modules because changes are well isolated.

    When changes are contained, incremental and managed, the whole system is more tolerant to multiple authors. In that way, we may build system automation that’s more Git-like.

  • Preview of IBM InterConnect Speakers

    Preview of IBM InterConnect Speakers

    Next week DevOps.com will be in Las Vegas to cover IBM’s InterConnect Conference. With over 200 DevOps related sessions, there is something for just about everyone on the schedule.

    We thought it would be useful to give you a peek at some of these presenters. Below are interviews of some InterConnect speakers from their recent appearances at the DevOps Enterprise Summit this past October.  While most will be presenting on different topics, there will still be a DevOps angle.

    So here is Alan Shimel, Editor-in-Chief at DevOps.com, with several InterConnect scheduled presenters:

    First is an interview with DevOps leader, author and researcher, Gene Kim. Gene is the host of the DevOps Enterprise Summit and will be at InterConnect in several sessions.

    Next up is Mustafa Kapadia, IBM practice leader and DevOps.com contributor.

    CJ Paul and David Myers join Jayne Grohl, founder of the DevOps Institute who was scheduled to speak at InterConnect but had to withdraw to an injury.

    Of course how can you talk IBM DevOps without Rosalind Radcliffe, distinguished engineer and multi-speed IT expert.

    In this clip, CJ Paul and Rosalind Radcliffe are joined by Gary Gruver, author of Leading the Transformation and well known DevOps expert.

    Finally, Rachel Reinitz CTO Bluemix Garage and IBM VP Angel Diaz and Kristal York talk about innovating like a startup, scaling like an enterprise.

    We are bringing the video gear to InterConnect and hope to have lots of new video interviews for you in the coming weeks!